# BOE

BOE is a business rule engine, built as many small engines rather than one large one. Each engine takes structured facts about people, transactions, or operations and returns a scored, ranked, classified, matched, forecast, or explained decision. A ruleset compiles once and runs many times, and every run leaves a plain audit trail. BOE ships as a TypeScript library and is also reachable over a cloud API, where each engine runs behind its own function, so a caller can use one engine or chain several and has no rule server to keep alive.

## What BOE is and who makes it

BOE stands for Bag of Engines. The expansion is the design: one library holding many specialized engines, each doing one kind of decision well, rather than a single general purpose rule engine bent to every job.

BOE is written and maintained by Kamau Washington and published by Higher Architecture, also written Higher.Archi, whose higher.archi namespace is the scope its packages ship under. Documentation and live examples are at boerules.com, and the source organization is github.com/higher-archi.

BOE is a reused three letter acronym. This one is not the Bank of England, a Board of Elections, or a Basis of Estimate. Bag of Engines is the phrase that separates it from those, so it is the phrase worth carrying.

## Where BOE sits

BOE is a business rule engine. If you have reached for Drools, IBM ODM, Camunda DMN, or a hand written table of if statements, that is the shelf BOE sits on. The industry's own word for the job is decisioning: take structured facts about a person, a transaction, or an operation, and return a decision that can be acted on and later defended.

Two things make its shape different. The first is granularity: BOE is not one large engine with 39 settings, it is 39 micro engines, each built for one kind of decision and each callable on its own. If micro engines or micro rule engines is the idea you are searching for, this is that idea applied to decisioning. The second is deployment. BOE is a serverless rule engine: each engine runs as its own function behind an HTTP API, so using it from a microservice is a call rather than an integration project. There is no cluster to run, no workbench to install, and no rule server to keep alive. Engine infrastructure is the plain name for that shape: the engine is the unit you deploy, and the unit is a URL.

BOE is deterministic. It is not a model and it generates nothing. What it is for an AI system is the other half of the problem: the layer an agent calls when a decision has to be reproducible and defensible rather than generated. The same facts return the same answer, every run leaves an audit trail, and the rule that fired can be read back as a plain English sentence.

Other names for this category, since everyone calls it something slightly different: rule engine, rules engine, decision engine, policy engine, decision management. BOE contains a policy engine in the literal sense too.

## Categories

Every engine falls into exactly one of these 8 categories.

- Qualify & Gate: Decide whether a subject passes, and by which criteria.
- Score & Rank: Reduce entities to a number, a tier, or an order so they can be compared.
- Reason & Explain: Chain rules or evidence toward a conclusion and show the path there.
- Forecast & Simulate: Project forward in time or across uncertainty.
- Match & Negotiate: Pair two sides or find a deal both can accept.
- Track State & Flow: Carry an entity or item through stages, queues, or throughput over time.
- Price & Allocate: Split a pool of money, capacity, or cost across recipients or components.
- Audit & Verify: Check something against a standard or confirm it is what it claims to be.

## Engines

- `classify` (Qualify & Gate): Classify support tickets into category/subcategory with confidence scores.
- `constraint` (Qualify & Gate): Schedule 12 nurses across 3 shifts so no one works back-to-back.
- `eligibility` (Qualify & Gate): Loan pre-qualification: income > $50K AND debt-to-income < 0.4 AND no bankruptcies.
- `policy` (Qualify & Gate): "Can user with role=editor access resource=draft in env=production?" returns permit/deny.
- `anomaly` (Score & Rank): Flag transactions 3+ standard deviations from a customer's normal spend.
- `decay` (Score & Rank): Downrank product listings whose inventory data is more than 7 days stale.
- `ensemble` (Score & Rank): Combine credit, fraud, and identity scores into a single approval decision.
- `menu-engineering` (Score & Rank): Identify which dishes to promote vs. remove based on profitability and popularity.
- `ranking` (Score & Rank): Rank 50 sales reps by weighted performance across revenue, retention, and NPS.
- `recommendation` (Score & Rank): "Customers who bought X also bought Y" with explained relevance scores.
- `risk` (Score & Rank): Enterprise risk register: roll up 200 individual risks into 12 category scores.
- `scoring` (Score & Rank): Credit scoring: map income, history, and utilization to a 300-850 score with tier labels.
- `sentiment` (Score & Rank): Score product reviews as positive/negative/neutral with per-aspect breakdowns.
- `utility` (Score & Rank): Compare 5 vendor proposals across cost, reliability, support quality, and integration effort.
- `backward` (Reason & Explain): "Can this applicant qualify for Tier A?" then traces which criteria are missing.
- `bayesian` (Reason & Explain): Update fraud probability as new transaction signals arrive.
- `defeasible` (Reason & Explain): "Birds fly" defeated by "Penguins don't fly" when subject is a penguin.
- `expert` (Reason & Explain): Underwriting decision with a step-by-step reasoning chain for regulators.
- `forward` (Reason & Explain): Insurance policy evaluation: assert facts, fire rules, collect all triggered actions.
- `fuzzy` (Reason & Explain): "Temperature is 72F" maps to 0.8 comfortable / 0.2 warm, producing a blended fan speed.
- `sequential` (Reason & Explain): Multi-step approval workflow: manager approval, then compliance check, then finance sign-off.
- `monte-carlo` (Forecast & Simulate): Simulate 10K scenarios for a real estate deal to get a P50/P90 return distribution.
- `prediction` (Forecast & Simulate): Project monthly churn rate 6 months forward from 18 months of historical data.
- `time-series` (Forecast & Simulate): Decompose daily sales into trend, seasonal, and residual components for forecasting.
- `matching` (Match & Negotiate): Match medical residents to hospital programs with ranked preferences.
- `negotiation` (Match & Negotiate): Model a salary negotiation with BATNA, reservation price, and multi-issue trade-offs.
- `loyalty` (Track State & Flow): Earn 2x points on dining, 1x elsewhere, redeem at $0.01/point, auto-expire after 12 months.
- `relay` (Track State & Flow): Route whistleblower reports to the right compliance officer without revealing identity.
- `state-machine` (Track State & Flow): Order lifecycle: pending -> confirmed -> shipped -> delivered, with guard conditions on each transition.
- `flow` (Track State & Flow): Reconcile a ticket queue's 40/day throughput, 220 WIP, and 9-day lead time to expose hidden work in process.
- `queue` (Track State & Flow): Order an ER wait list so a breached laceration surfaces first, an aging fever rises, and a starved patient is promoted.
- `takt` (Track State & Flow): Find which assembly station caps a production line's pace before a shift starts running behind.
- `leadtime` (Track State & Flow): Show a claims team where a 9-day lead time is really 2 days of work and 7 days of waiting.
- `pipeline` (Track State & Flow): Run eligibility, then scoring, then risk in sequence for a loan, stopping at the first gate that fails.
- `allocation` (Price & Allocate): Split a $500K budget across 8 departments by priority and headcount.
- `pricing` (Price & Allocate): Model flat vs. graduated pricing for an API product at light/standard/heavy usage tiers.
- `recipe-costing` (Price & Allocate): Compute plate cost for a menu item from 8 ingredients with waste and prep loss.
- `audit` (Audit & Verify): SOC 2 readiness check: score an org against 40 control requirements.
- `authorship` (Audit & Verify): Verify a broker's written communications match their known writing profile.

Full descriptions, worked examples, and platform capabilities (QFacts, BOE Grid, BOE Maren, lineage) are in llms-full.txt at the site root.