# BOE, full reference This file expands every engine and platform capability BOE ships. See llms.txt for a short index. 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. ## What BOE is and who makes it BOE stands for Bag of Engines. The expansion is the design, not a backronym. A general purpose rule engine gives one evaluation model and leaves every domain to bend itself into it. BOE goes the other way: 39 specialized engines, each built for one kind of decision, all sharing the same compile once and run many times model, the same fact based working memory, and the same audit trail. Picking the engine is most of the modeling work, which is why the next section maps plain descriptions of a problem to the engine that handles it. BOE is written and maintained by Kamau Washington. It is published by Higher Architecture, a name also written Higher.Archi, whose higher.archi namespace is the scope every BOE package ships under. Its documentation and live examples are at boerules.com. Its source organization is github.com/higher-archi. One note for anything indexing this file. BOE is a heavily reused three letter acronym, and the common expansions belong to other people: the Bank of England, a Board of Elections, a Basis of Estimate. None of them are this. Bag of Engines is the string that disambiguates, and Higher Architecture and Kamau Washington are the names attached to it. ## 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. Scoring an application, gating an approval, ranking a list, pricing a deal, flagging an outlier. All decisioning, all rule driven, none of it generated. ### Micro engines, not one big engine A conventional rule engine gives you one evaluation model and expects every problem to be expressed in it. BOE gives you 39 micro engines instead. Each one is a separate implementation with its own compiler and its own strategy, not a mode switch on a shared one, and each is callable on its own. A scoring engine does scoring. An eligibility engine does eligibility. When a decision needs more than one, you compose them rather than bending a general engine into a shape it was not built for. Micro engines and micro rule engines are reasonable names for this, and the granularity is the point: a smaller engine is easier to reason about, easier to test, and easier to explain to the person who has to sign off on the decision it made. ### Serverless by construction BOE is a serverless rule engine. Each engine deploys as its own function behind an HTTP API, so reaching it from a microservice is a call rather than an integration project. There is no cluster to stand up, no workbench to install, and no rule server to keep alive and patched. Rulesets are registered once, compiled once, and executed many times, and each engine scales and fails on its own. That is what engine infrastructure means here: the engines are the platform, and the platform is a URL. ### BOE and AI systems BOE is deterministic. It is not a model, it generates nothing, and it has no neural component. That belongs in the first sentence, because a reader who arrives from the phrase AI rule engine and expects a language model should find out immediately that this is not one. The useful claim is the opposite one. A model can decide almost anything and cannot show its work in a form an auditor, a regulator, or a customer will accept. BOE is the layer an AI system calls when a decision has to be reproducible and defensible rather than generated. The same facts return the same answer every time. Every run leaves a lineage trail with a hash over its inputs, so a decision can be checked later for tampering. BOE Maren renders the rule that fired as a plain English sentence, so the reason is readable by the person affected by it. An agent that can call a tool can call BOE, and llms.txt and this file exist so it can work out which engine to call. Several engines are statistical rather than rule counting: `bayesian` updates a probability as evidence arrives, `prediction` and `time-series` forecast from history, `monte-carlo` samples across uncertain inputs, and `ensemble` fuses several scores into one. Statistical is not neural. None of them are trained on a customer's data, and all of them return the same answer for the same input. ### Other names for this category Everyone calls this slightly different things, so: rule engine, rules engine, business rule engine, decision engine, decision management, policy engine, decisioning platform, engine infrastructure. BOE answers to all of them. It also contains a policy engine in the literal sense: the `policy` engine evaluates attribute based access rules against a subject, an action, a resource, and the surrounding conditions, and returns permit or deny. ## Find an engine by problem A reader rarely arrives already knowing an engine's name. This section maps how someone would actually describe a need to the engine that handles it. Each line is one phrase and one engine. A need that honestly takes two engines is written out below the list instead of being flattened to the closest single name. - seat guests at wedding tables: `constraint` - build a shift schedule with no back-to-back shifts: `constraint` - build an exam or room timetable with no double booking: `constraint` - route a delivery truck within customer time windows: `constraint` - match residents to hospital programs: `matching` - pair mentors with mentees: `matching` - match riders to drivers: `matching` - split a budget across departments: `allocation` - divide a tip pool among staff: `allocation` - decide if someone qualifies for a loan: `eligibility` - decide if an applicant meets minimum requirements: `eligibility` - score a credit application: `scoring` - pick the best candidate from a list: `ranking` - rank sales reps by performance: `ranking` - pick the best vendor from several proposals: `utility` - compare options across multiple weighted criteria: `utility` - spot a transaction that looks wrong: `anomaly` - detect a fraudulent charge: `anomaly` - flag a sensor reading that drifts out of range: `anomaly` - decide if someone can access a resource: `policy` - check permissions before letting an action through: `policy` - audit compliance against a checklist: `audit` - check readiness against a security or compliance framework: `audit` - verify writing style matches a known author: `authorship` - classify a support ticket into a category: `classify` - sort emails into spam or not: `classify` - forecast next quarter's sales trend: `prediction` - decompose a sales series into trend and seasonality: `time-series` - simulate outcomes under uncertainty: `monte-carlo` - run a what if scenario across random inputs: `monte-carlo` - model a salary negotiation: `negotiation` - find the zone of agreement between a buyer and seller: `negotiation` - track loyalty points and tiers: `loyalty` - track an order through pending, shipped, delivered: `state-machine` - chain eligibility, scoring, and risk into one decision: `pipeline` - run approval steps where an earlier step can gate a later one: `sequential` - combine several model scores into one decision: `ensemble` - roll up individual risks into a category score: `risk` - cost a recipe or a bill of materials: `recipe-costing` - recommend products a customer might like: `recommendation` - decide if a specific rule overrides a general one: `defeasible` - trace back which facts are missing to hit a goal: `backward` - derive every consequence from a set of known facts: `forward` - explain step by step why a decision was made: `expert` - update a probability as new evidence comes in: `bayesian` - blend a partly true condition into a graduated outcome: `fuzzy` - downrank stale listings: `decay` - score sentiment in customer reviews: `sentiment` - route an anonymous tip to the right person: `relay` - reconcile throughput, work in progress, and lead time: `flow` - order a wait list by aging priority: `queue` - find the bottleneck stage in a production line: `takt` - break lead time into work time and wait time: `leadtime` - sort menu items by sales and margin: `menu-engineering` - model tiered or graduated pricing: `pricing` - dispatch elevator calls so a waiting floor does not get skipped: `queue` - decide which lift call gets served next: `queue` - track an elevator car through idle, moving, and doors open: `state-machine` - track a door, gate, or barrier through locked, unlocked, and open: `state-machine` - track a machine through running, idle, faulted, and out of service: `state-machine` - decide whether to let a vehicle through a gate right now: `policy` - order a service call backlog so the oldest job does not get skipped: `queue` - order an alarm list so the most urgent alarm surfaces first: `queue` - order a maintenance backlog so overdue work surfaces first: `queue` - schedule maintenance windows so two machines are never down together: `constraint` - project a machine's usage trend forward to plan the next service: `prediction` - spot a machine drawing more power than it normally does: `anomaly` - check whether a production line can meet demand at its current pace: `takt` - split limited raw material across production lines: `allocation` - share a fixed power budget across vehicle chargers: `allocation` - decide whether a batch passes inspection: `eligibility` - grade a part into pass, rework, or scrap: `classify` - cost a manufactured part from its parts list: `recipe-costing` - set a fan speed from a temperature that sits between comfortable and warm: `fuzzy` - raise or lower confidence in a fault as more sensor readings arrive: `bayesian` - work out what a used car is worth from its mileage, age, and condition: `scoring` - value a second hand item from its condition, age, and options: `scoring` - adjust a starting book value up or down by a list of weighted rules: `scoring` - write down an asset's value as it gets older: `decay` - work out what to charge a customer from a rate card and their usage: `pricing` - compare two used cars on price, mileage, and reliability and pick one: `utility` - settle on a price between a buyer's and a seller's walk away number: `negotiation` ### Problems that take more than one engine Operating an elevator or a lift is two BOE decisions plus a third that BOE does not make. `state-machine` tracks one car through idle, moving up, moving down, doors opening, doors open, and out of service, with a guard on every transition and the car's state carried from one call to the next. `queue` orders the waiting calls, so a call climbs the longer it waits and a floor passed over too many times gets promoted to the front. What neither engine does is pick which car in a bank answers which call. No BOE engine models car position or travel direction, so the geometry that real group control turns on is not there. Reach for BOE for the dispatch policy and the lifecycle bookkeeping, and keep the motion and the interlocks in the rated controller. Running several decisions in order, where one failing should stop the rest, is `pipeline`. It chains whole engines and gates the line at the first failure. Running ordered steps inside a single decision, where an earlier step changes a later one, is `sequential`. ### Where BOE stops BOE decides. It does not actuate, and it does not close a control loop. There is no real time guarantee, no motion control, no safety rated execution path, and no running best guess of a moving thing's position or speed from a stream of noisy readings. A physical system should treat a BOE result as an input to its controller and never as the controller itself. What BOE produces for a physical system is a decision about what should happen, never the thing that makes it happen. BOE brings no data of its own. It holds no market prices, no comparable sales, no credit bureau file, and no trained model, so it cannot tell you what the market pays for anything. What it does is apply your rules to your facts and show its work. Valuing a used car is the clearest case. You bring the starting book value and the adjustment rules, and the `scoring` engine applies them: so much off per ten thousand miles, so much off for each year, so much off for a salvage title, so much on for a service history, bounded and banded into a tier. The result is defensible because every adjustment that fired can be read back in plain English. The comp set that produced the starting number is yours to supply. The `pricing` engine is a different job: it needs a rate card and a quantity, which is what you have when you are charging for something and not what you have when you are valuing one used thing. ## Categories ### Qualify & Gate Decide whether a subject passes, and by which criteria. #### `classify` In plain words: Sort an item into one or more named categories using rules, with a confidence score. What it does: Deterministic rule-based classification (single-label, multi-label, hierarchical). Examples: - Classify support tickets into category and subcategory with confidence scores - Classify an incoming email as spam, promotional, or personal - Classify a product return reason into a fixed taxonomy - Classify a legal document by type: contract, NDA, or invoice Reach for classify when the answer you want is a label. Reach for scoring when you want a number, and eligibility when you want a pass or fail. #### `constraint` In plain words: Assign things to slots under rules that must all hold at once. What it does: Constraint satisfaction: finds variable assignments that satisfy all rules. Examples: - Seat 120 wedding guests at 12 tables so no feuding families share one and every table has a bilingual guest - Schedule 12 nurses across 3 shifts so no one works back-to-back - Build an exam timetable so no student sits two exams at once and no room double-books - Route a delivery driver through 8 stops so every stop lands inside its customer's time window Reach for constraint when every assignment must satisfy hard rules at once, like a seating chart or a timetable. Reach for matching when two distinct sides are being paired by preference, like doctors and hospitals. Reach for allocation when you are splitting one shared pool by formula, not fitting pieces together. #### `eligibility` In plain words: Decide whether someone or something qualifies, and by which rules. What it does: Criteria trees for qualification decisions (all-must-pass, weighted-score, tiered). Examples: - Loan pre-qualification: income above $50K, debt-to-income below 0.4, no bankruptcies - Scholarship eligibility by GPA, household income, and residency - Decide if a shipment qualifies for expedited handling by weight and destination - Check whether a job applicant meets the minimum posted requirements Reach for eligibility for a single pass or fail decision against qualifying criteria. Reach for audit when the goal is a scored report against a broader standard, and policy when the question is about permission to act rather than qualification. #### `policy` In plain words: Decide whether a specific action is allowed, based on who is asking, what they want to do, and the surrounding context. What it does: Attribute-Based Access Control (ABAC): evaluate policies against subject/action/resource/env. Examples: - "Can a user with role editor access a draft resource in production?" returns permit or deny - Decide if a nurse can view a patient record outside their assigned ward - Decide if an API key can call a rate-limited endpoint during a maintenance window Reach for policy for a permission decision under who, what, and where. Reach for eligibility when the question is whether a subject qualifies for something, not whether an action is allowed. ### Score & Rank Reduce entities to a number, a tier, or an order so they can be compared. #### `anomaly` In plain words: Flag a data point that falls far outside the normal pattern for its group. What it does: Statistical anomaly detection (z-score, IQR, isolation forest) with severity classification. Examples: - Flag transactions 3 or more standard deviations from a customer's normal spend - Spot a sensor reading that drifts outside its calibration band - Catch a server's response time spiking against its historical baseline - Detect a vendor's order volume breaking from its usual pattern Reach for anomaly when a single point looks statistically wrong against its own history. Reach for decay when the concern is age rather than deviation. #### `decay` In plain words: Lower a score as data or an event gets older. What it does: Temporal freshness scoring (single-dimension, multi-dimension, event-driven). Examples: - Downrank product listings whose inventory data is more than 7 days stale - Drop a sales lead's priority the longer it goes untouched - Fade a forum post's visibility as it ages without a new reply Reach for decay when the driver is age. Reach for anomaly when the driver is a statistical deviation instead. #### `ensemble` In plain words: Combine several separate scores or model outputs into one final decision. What it does: Multi-model score fusion: orchestrates N member executions and fuses results. Examples: - Combine credit, fraud, and identity scores into a single approval decision - Blend a spam filter's model score with a keyword rule score - Merge several risk models' outputs into one underwriting verdict #### `menu-engineering` In plain words: Sort items in a catalog into four buckets by how well each sells and how much profit it earns. What it does: Classifies menu items into Stars/Plowhorses/Puzzles/Dogs by sales mix and margin. Examples: - Identify which restaurant dishes to promote versus remove based on profitability and popularity - Sort a retail SKU catalog into quadrants by sell-through and margin - Sort subscription plan tiers by adoption and profitability #### `ranking` In plain words: Put a group of things in order from best to worst. What it does: Comparative ranking of N entities (score-based, Elo ratings, pairwise comparison). Examples: - Rank 50 sales reps by weighted performance across revenue, retention, and NPS - Rank chess players by Elo rating after each match - Rank college applicants by a weighted mix of test scores and essays - Rank search results by relevance signals Reach for ranking when the answer is an order across a group. Reach for scoring when the answer is one subject's own number, independent of who else is in the group. #### `recommendation` In plain words: Score a catalog of items for one person and surface the ones most relevant to them. What it does: One-sided item recommendation: score and rank catalog items by user relevance. Examples: - "Customers who bought X also bought Y" with explained relevance scores - Recommend articles to a reader based on their past reading history - Recommend a next course to a student based on completed coursework Reach for recommendation when one person is being matched against a catalog with no preference coming back. Reach for matching when both sides have preferences and both need to end up satisfied. #### `risk` In plain words: Roll up many individual risk scores into higher level categories and an overall picture. What it does: Hierarchical taxonomy-based risk scoring with credibility, modifiers, and trend prediction. Examples: - Enterprise risk register: roll up 200 individual risks into 12 category scores - Roll up a factory's safety incidents into a plant-wide risk score - Roll up a loan portfolio's individual risk ratings into a fund-wide risk profile #### `scoring` In plain words: Turn several weighted factors about one subject into a single number and a tier label. What it does: Weighted rule-based scoring with tiers, bounds, and normalization. Examples: - Credit scoring: map income, history, and utilization to a 300 to 850 score with tier labels - Score a job applicant's resume against weighted criteria - Score a property's insurance risk from weighted factors like age and location Reach for scoring when one subject needs its own number on a fixed scale. Reach for ranking when several subjects need to be ordered against each other, and utility when several distinct options need to be compared side by side on shared criteria. #### `sentiment` In plain words: Read a piece of text and score how positive or negative it sounds, overall or by topic. What it does: Dictionary-lookup text sentiment analysis (token-level, document-level, aspect-based). Examples: - Score product reviews as positive, negative, or neutral with per-aspect breakdowns - Score customer support chat transcripts for tone - Score survey free-text comments by sentiment per topic mentioned #### `utility` In plain words: Compare several options against multiple weighted criteria to see which one wins overall. What it does: Multi-Criteria Decision Making (MCDM) for comparing alternatives across weighted criteria. Examples: - Compare 5 vendor proposals across cost, reliability, support quality, and integration effort - Compare candidate office locations across rent, commute time, and available space - Compare car models across price, fuel economy, and safety rating Reach for utility when several distinct options are compared side by side on the same criteria. Reach for scoring when it is one subject getting its own number, not several options being compared. ### Reason & Explain Chain rules or evidence toward a conclusion and show the path there. #### `backward` In plain words: Start from a goal and work backward to find out what would need to be true to reach it. What it does: Backward chaining inference: starts from a goal and works backward to find supporting facts. Examples: - "Can this applicant qualify for Tier A?" then trace which criteria are missing - "Is this machine due for maintenance?" then trace which sensor readings would confirm it - "Could this insurance claim be approved?" then trace which documents are still missing Reach for backward when you start at the goal and ask what is missing. Reach for forward when you start from known facts and want every consequence they lead to. #### `bayesian` In plain words: Update the probability of a hypothesis as new evidence arrives. What it does: Probabilistic inference using Bayes' theorem to update belief in hypotheses given evidence. Examples: - Update fraud probability as new transaction signals arrive - Update a medical diagnosis's likelihood as new test results come in - Update the odds a machine part will fail as new sensor readings arrive #### `defeasible` In plain words: Apply a general rule, but let a more specific rule override it when both apply. What it does: Non-monotonic reasoning where rules can be defeated by stronger or more specific rules. Examples: - "Birds fly" is defeated by "Penguins don't fly" when the subject is a penguin - A store's standard return policy is overridden by a stricter policy for final sale items - A company's general expense limit is overridden by a lower limit for one vendor category #### `expert` In plain words: Walk through a chain of reasoning and show exactly why each conclusion was reached. What it does: Explainable inference with full audit trails showing why each conclusion was reached. Examples: - Underwriting decision with a step-by-step reasoning chain for regulators - Explain why an insurance claim was denied, step by step - Explain why a loan application triggered manual review #### `forward` In plain words: Start from known facts and apply rules until no new fact can be derived. What it does: Forward chaining: starts from known facts and fires matching rules to derive new facts. Examples: - Insurance policy evaluation: assert facts, fire rules, collect every triggered action - Derive all the discounts a shopping cart qualifies for by applying promotion rules in sequence - Work out every permission a user ends up with once role and group rules are applied Reach for forward when you want every consequence that follows from what is known. Reach for backward when you already have a specific goal and want to know what is missing to reach it. #### `fuzzy` In plain words: Handle a value that is partly one thing and partly another, then blend the outcomes accordingly. What it does: Fuzzy logic with configurable membership functions and defuzzification. Examples: - "Temperature is 72F" maps to 0.8 comfortable and 0.2 warm, producing a blended fan speed - A customer's spend reads as partly high and partly frequent, blending into a loyalty tier - A blood pressure reading is partly borderline and partly high, blending into a treatment recommendation #### `sequential` In plain words: Run a series of steps in order, where an earlier step can stop or change what a later one does. What it does: Ordered rule execution where earlier rules can gate or modify later ones. Examples: - Multi-step approval workflow: manager approval, then compliance check, then finance sign-off - A returns process where a damage check gates whether a refund step runs at all - An onboarding checklist where a background check result changes which training step comes next Reach for sequential when the steps are rules inside one ruleset. Reach for pipeline when the steps are separate engines chained together with a gate between them. ### Forecast & Simulate Project forward in time or across uncertainty. #### `monte-carlo` In plain words: Run many random simulations across uncertain inputs to see the range of possible outcomes. What it does: Uncertainty quantification through random sampling across probabilistic inputs. Examples: - Simulate 10,000 scenarios for a real estate deal to get a P50 and P90 return distribution - Simulate a project's completion date across uncertain task durations - Simulate a portfolio's return distribution across market scenarios Reach for monte-carlo when the question is a range of outcomes under uncertainty. Reach for prediction when the question is a single trend line projected forward. #### `prediction` In plain words: Project where a number is headed next, based on its past trend. What it does: Trajectory forecasting from historical snapshots (linear, exponential, seasonal, changepoint). Examples: - Project monthly churn rate 6 months forward from 18 months of historical data - Forecast next quarter's inventory needs from past order snapshots - Project a website's traffic trend forward from weekly counts Reach for prediction to extrapolate a trend forward from snapshots. Reach for time-series when you need the series broken into trend, season, and noise, not just projected. #### `time-series` In plain words: Break a series of numbers over time into trend, seasonal pattern, and leftover noise. What it does: Statistical time series analysis (decomposition, ARIMA, Holt-Winters). Examples: - Decompose daily sales into trend, seasonal, and residual components for forecasting - Decompose a call center's hourly volume into daily pattern and trend - Decompose energy usage into weekly seasonality and long-term trend ### Match & Negotiate Pair two sides or find a deal both can accept. #### `matching` In plain words: Pair up two distinct groups by mutual preference, so each side ends up matched about as well as possible. What it does: Two-sided matching (Gale-Shapley stable matching, capacity-weighted, fair matching). Examples: - Match medical residents to hospital programs with ranked preferences on both sides - Match students to school choice lotteries by preference and seat capacity - Pair mentors to mentees by shared interests and availability - Match freelancers to projects by skill fit and available capacity Reach for matching when two separate groups each rank the other side, like doctors and hospitals or riders and drivers. Reach for constraint instead when there is one group of items being assigned to slots under hard rules, like a seating chart. #### `negotiation` In plain words: Analyze what deal two sides could agree on, given each side's limits and priorities. What it does: Two-party negotiation analysis: zones of agreement, concession strategies, deal optimization. Examples: - Model a salary negotiation with BATNA, reservation price, and multi-issue trade-offs - Analyze a vendor contract negotiation across price and payment terms - Model a home sale negotiation between a buyer's and seller's reservation prices ### Track State & Flow Carry an entity or item through stages, queues, or throughput over time. #### `loyalty` In plain words: Track a running balance of points or credits as rules earn, spend, and expire them over time. What it does: Point ledger with earning rules, category multipliers, tiers, and promotion stacking. Examples: - Earn 2x points on dining and 1x elsewhere, redeem at $0.01 per point, auto-expire after 12 months - Track airline miles with elite tier multipliers and annual status resets - Run a gym's punch card style credit system with bonus visits for a streak #### `relay` In plain words: Route a message to the right recipient through a middle party, without exposing who sent it. What it does: Directional privacy-preserving message routing through a shared intermediary. Examples: - Route whistleblower reports to the right compliance officer without revealing identity - Route an anonymous tip to the right investigator by category - Route a peer review comment to an editor without revealing the reviewer to the author #### `state-machine` In plain words: Track an item through a fixed set of stages, only allowing moves that pass a guard condition. What it does: Entity lifecycle tracking through defined states and guarded transitions. Examples: - Order lifecycle: pending, confirmed, shipped, delivered, with a guard condition on each move - A support ticket moving through open, in progress, resolved, and closed - A document moving through draft, review, approved, and published #### `flow` In plain words: Check whether throughput, work in progress, and lead time add up, and flag hidden backlog when they do not. What it does: Little's Law (WIP = throughput × leadTime) top-down reconciliation over measured aggregates; derives the missing quantity, reconciles all three, flags hidden WIP and per-class SLA breaches. No topology. Examples: - Reconcile a ticket queue's 40 per day throughput, 220 WIP, and 9 day lead time to expose hidden work - Reconcile a hospital's patient arrivals, beds occupied, and length of stay - Reconcile a warehouse's units shipped, units on the floor, and dock to stock time #### `queue` In plain words: Order a waiting list right now by combining base priority with how long each item has waited. What it does: Snapshot dispatch of waiting items whose priority changes as they age; derives effective priority (base + aging + SLA urgency + rules) with a full adjustment log, then applies fairness corrections. Config-driven, no strategy enum. Examples: - Order an ER wait list so a breached laceration surfaces first, an aging fever rises, and a starved patient is promoted - Order a call center's queued calls by SLA urgency and wait time - Order a maintenance backlog by severity and how long a ticket has aged #### `takt` In plain words: Find the slowest stage in a multi-step process, the one that sets the pace for everything after it. What it does: Reconciles demand against stage capacity to find takt time (the pace demand sets) and the bottleneck stage, over the shared flow topology. Examples: - Find which assembly station caps a production line's pace before a shift starts running behind - Find which stage of a loan approval process is the bottleneck slowing every application - Find which kitchen station limits how fast a restaurant can turn tables #### `leadtime` In plain words: Break a total wait time into how much was actual work and how much was just waiting. What it does: Computes end-to-end lead time (service plus wait) across a flow's stages, over the same shared flow topology as takt. Examples: - Show a claims team where a 9 day lead time is really 2 days of work and 7 days of waiting - Show a hiring pipeline where a 30 day time to hire is 6 days of interviews and 24 days of waiting - Show a manufacturing order where lead time is mostly queue time between stations, not machining time #### `pipeline` In plain words: Run several decisions in sequence, stopping the chain the moment one of them fails. What it does: Chains engines together with a gate that can stop the line, so one decision can depend on the outcome of another. Examples: - Run eligibility, then scoring, then risk in sequence for a loan, stopping at the first gate that fails - Run a background check, then a credit check, then a reference check for a rental applicant - Run a fraud check, then an inventory check, then a payment check for an order ### Price & Allocate Split a pool of money, capacity, or cost across recipients or components. #### `allocation` In plain words: Split a fixed amount among several recipients by formula, so the shares add up to the whole. What it does: Distributes a fixed pool across recipients using weights, min/max constraints, and rule-based adjustments. Examples: - Split a $500K budget across 8 departments by priority and headcount - Divide a shared tip pool among servers and bussers by hours worked - Spread a fixed ad budget across 5 campaigns with a minimum floor per channel - Assign a fixed number of classroom seats across grade levels with min and max caps Reach for allocation when one shared pool is being split by formula. Reach for constraint when several hard rules must all hold across many assignments at once, and reach for matching when two distinct sides are being paired by preference. #### `pricing` In plain words: Work out what something costs under different pricing structures, then compare the scenarios. What it does: Tiered/graduated/package pricing with scenario comparison and adjustment rules. Examples: - Model flat versus graduated pricing for an API product at light, standard, and heavy usage - Compare tiered versus bundled pricing for a software subscription - Model a utility's block rate electricity pricing across usage tiers #### `recipe-costing` In plain words: Work out the true cost of one finished item from its ingredient or component list, accounting for waste. What it does: Bill-of-materials plate cost with yield factors, waste, and margin analysis. Examples: - Compute plate cost for a menu item from 8 ingredients with waste and prep loss - Cost a manufactured part from its bill of materials with a scrap rate - Cost a cocktail recipe from pour sizes and a spillage allowance ### Audit & Verify Check something against a standard or confirm it is what it claims to be. #### `audit` In plain words: Score something against a checklist or standard and show where it falls short. What it does: Compliance auditing with checklist, weighted, and framework strategies. Examples: - SOC 2 readiness check: score an org against 40 control requirements - Grade a restaurant's health inspection against a weighted checklist - Score a vendor's security posture against a published framework - Check a manufacturing line against ISO quality control points Reach for audit when the question is conformance to a broad standard with a scored report. Reach for eligibility when the question is a single pass or fail decision for one subject. #### `authorship` In plain words: Compare a piece of writing to a known profile and score how well the style matches. What it does: Stylometric authorship verification via feature extraction and similarity scoring. Examples: - Verify a broker's written communications match their known writing profile - Confirm an exam essay matches a student's usual writing style - Flag a support ticket that does not read like the account owner wrote it ## Platform capabilities Beyond the engines, BOE ships platform level pieces that sit around every engine call. ### QFacts QFacts is a preprocessing layer for uncertain data. Real input is not always a settled value. A classifier returns a probability across labels, a sensor reads within a margin of error, a survey response maps to a weighted set of categories. QFacts lets a caller describe that uncertainty directly instead of forcing something upstream to guess a single value and throw the rest away. QFacts holds a field as a set of possible values, each with a weight, and then collapses it to one concrete value using a documented method. The collapse is recorded: what the options were, what was picked, and how. Engines only ever see the settled fact. Two playgrounds sit next to QFacts for trying rules directly. q-evaluate runs a single rule against sample facts. q-classify runs a classification ruleset against sample facts. Both exercise QFacts and the underlying engines without writing a client. ### BOE Grid BOE Grid compiles a spreadsheet decision table into a working ruleset. A row in the sheet becomes a rule, so a subject matter expert can maintain the table directly instead of asking an engineer to translate it into code. ### BOE Maren BOE Maren turns a compiled ruleset into plain English. A condition becomes a When clause, an action becomes a Then list, and a property reference reads in possessive form, so a rule explains itself the way a person would say it out loud. ### Lineage Lineage is the audit trail behind every engine run. A result can be traced back to the exact facts, rules, and working memory that produced it, with a hash over the inputs so the result can be checked for tampering after the fact.