Aligned with IATA Modern Airline Retailing
The IATA Modern Airline Retailing programme — Offers & Orders, NDC, ONE Order — defines the request shape in JSON Schema. The Offer is JSON. The Order is JSON. The Service, Bundle, Pax, Journey, and Price are all JSON. RuleForge consumes them exactly as the standard defines them — no ORM, no shred-and-rebuild, no schema drift.
Filter on $.passengers[*].type. Iterate over $.bundles[*].products[]. Look up tax rates by $.journey.origin. Mutate $.bundles[0].products[0].price. The rule speaks the same language as the request — and as the response envelope your downstream systems already consume.
ALTER TABLE. No engine upgrade. No vendor ticket.
Built for Offer Management
An Offer Management System has to do three things at the speed of a shopping cart: assemble offers from many components, apply the right rules to each component, and hold the offer long enough for the customer to act. Every one of those operations is a sequence of rule evaluations:
- Eligibility — is this passenger / route / channel / time-of-day eligible for this product? Filter graph;
decision: skipmeans hide it. - Ancillary pricing — bag fees, seat fees, lounge access, priority boarding. Lookup-replace from a reference table; calc node applies the markup.
- Tier & loyalty — frequent-flyer bonuses, status uplifts, partner-airline reciprocity. Sub-rule call into the tier engine; output mapping stamps the bonus on the bundle.
- Tax & surcharges — country-specific taxes, fuel surcharges, FX. Iterator over
$.passengers; per-pax sub-rule; merge modesumover$.amount. - Fare conditions — change fees, refundability, baggage allowance. A product node emits the structured conditions block straight onto the offer.
Built for Order Management
An Order Management System needs to evaluate rules at every state transition: order creation, payment, ticket issuance, change, refund, no-show. RuleForge runs each one as an isolated evaluation with full trace — every decision is explainable, every version is pinned, every result is signed by the engine.
- Order validation — does the assembled order satisfy minimum-stay, advance-purchase, or carrier-specific constraints? Logic graph (
andover a fan of filters);decision: errorwith named errors blocks the order. - Change & refund eligibility — given the original order, fare rules, and the requested change, what is allowed? Sub-rule per condition;
onError: defaultfalls back to deny. - Settlement & reporting — accrual splits, partner allocations, BSP/ARC settlement. Calc graph over the priced order; merge mode
sumper partner.
Common rule patterns, ready to compose
Eligibility filter
Chain string + number + date filters into an AND logic node, route to a product. fail ⇒ skip; pass ⇒ apply with the product as the result. Hide a bag offer when tier ≠ GOLD and fareUSD < 200.
Reference-set lookup
Pull rate from a versioned reference set (price matrix, FX table, country code). Apply markup with a calc node. The reference set lives in DocumentForge; new rates are a write, not a deploy.
Per-passenger tax
Iterate $.passengers; sub-rule call computes per-pax tax stack; merge with mode collect. The per-pax sub-rule has its own immutable version — change it without touching the orchestrator.
Tier-based uplift
Constant node seeds a product shell; mutator stamps paxId from $pax.id; calc applies a tier-based markup. Three nodes, three responsibilities, all explainable in the trace.
Multi-jurisdiction taxation
Reference node returns every applicable tax row for the route; iterate the rows; product node emits one tax line per row; merge with mode sum on $.amount for the total.
Hierarchical fare conditions
Sub-rule per condition family (changes, refunds, baggage). Output mapping merges each family's verdict onto a single fare-conditions object the offer can carry verbatim.
Your data, your control
RuleForge is a single binary running in a process you own, on a machine you own, in a datacenter you control. The rule snapshots live in DocumentForge — also yours. There is no vendor cloud, no per-evaluation pricing, no opaque license audit risk, no hostage data. Open the rule file with our binary or any other tool you write — it is yours.
The same engine runs in your laptop sandbox, your staging environment, your production region, and your DR site. The same JSON rule that fires in dev fires byte-identical in prod. No drift between authoring tool and runtime; the engine evaluates the file exactly as it was published.
Governance & audit, built in
Every rule is an immutable versioned snapshot. The engine resolves endpoint + method → ruleId → version → snapshot at boot and on every change. Environment pinning is explicit — staging can run v8 while production stays on v7 until QA signs off.
- Trace on demand. Add
?debug=trueand the envelope carries a per-node trace. Trace is the auditor's friend: every decision is reproducible. - Approval workflows. Drafts → review → published. Approval logs live in the same DocumentForge collection, queryable with SQL.
- Diff-friendly. Two rule versions are two JSON documents — diff them in any tool you already use. No proprietary diff viewer required.
- Export anywhere. Mirror the entire rule estate to another DocumentForge instance, a JSON file pack, or a backup volume with one CLI command.
A 5ms budget. We use 70µs.
The IATA MAR latency brief targets <5ms for a typical rule evaluation. RuleForge clears it by 70× on a single laptop:
| Workload | Latency p50 | Throughput |
|---|---|---|
| 8-node rule, warm steady-state | 70µs | 73K eval/s @ 16 workers |
| Sub-rule call (in-process) | +12µs per call | — |
| Cold path (rule fetch + parse) | ~2.5ms | cached after first call |
| Reference-set lookup (cached) | <5µs | — |
Production mode skips trace and duration tracking entirely. Sub-rule snapshots are cached indefinitely (immutable per version). Rule resolution is cached for the lifetime of the process — change a binding and the engine picks up the new version on next boot.
When RuleForge fits
You own an Offer or Order System
You're building or running an OMS / ORM, an ancillary engine, a tax engine, a fare-rules engine, an eligibility engine. Anywhere business logic is a graph of filters / lookups / calcs / sub-rules — RuleForge is the runtime.
You're replacing a closed engine
You're migrating off a proprietary rules / decision engine and you want to keep the rules in a format your team can read, fork, and extend. RuleForge ships the runtime; pair it with whatever editor you prefer (or build one).
Your domain is rule-shaped
Rules engines aren't airline-only. Insurance pricing, mortgage eligibility, telco plans, content moderation, feature flagging — anywhere business logic lives in a directed graph, RuleForge runs it. Airlines are the canonical use case, not the only one.
You need a workflow engine
RuleForge is a runtime rules engine, not a long-running BPMN workflow. If your workload is "given a request, compute a verdict + result", that's us. If your workload is "wait three days for a customer signature", that's something else — though sub-rules + an external scheduler can compose.
Next step
The fastest way to know if RuleForge fits is to try it. Five minutes from binary download to first envelope: