Private reference

Middleware architecture

Rule creation, execution, saved facts, and delivery — the healing example.

Sources: PROJECT_CAPABILITY_REGISTER.md · MIDDLEWARE_CHARTER.md · RULE_ENGINE_PACKAGE.md · Last refreshed:

From a healing rule to a saved result

Full flow reconstructed from the earlier healing-rule visual and the retained rule-engine contract. Status colors are refreshed from the master register, so they may differ from the older screenshot.

Green · built or designed within the named bounded scopeOrange · repair, extension or integration remainsPurple · required implementation or proof pending

Green does not establish the complete path with a live GM and Discord. Each box names its roadmap IDs; the mechanic and definition boxes are design evidence.

Open full diagramDelivery roadmapReference Index
Middleware architecture — the complete healing-rule path Create the rule: agreed mechanic, executable definition, validation, versioned library. During play, frozen player input, the fact register and approved rule source feed context and a GM proposal. Validation either pauses without spending or calculates and commits allowed effects. Saved facts and history feed eligible output and Discord delivery. Saved receipts support retries without duplicate effects. Second-definition reuse and independent review remain separate gates. Creating the healing ruleStage 2 · reviewed semantics → definition → checks → pinned rule sourceBounded evidenceAgreed mechanicConsume 1 dose.Restore 2 health, capped atthe known maximum.Outside-combat example; nomana.RE02Bounded evidenceReusable executable ruledefinitionInputs, requirements, costs,effects and stop conditions.Contract settled as design.RE02Integration / repairRule validation and testsCheck supported operationsand rule examples.Success, failure, no-spendand replay cases.RE03Integration / repairVersioned rule libraryPinned imports, versions andprocedure descriptors.General reuse is a separateproof.C02 · C40Using that rule during play — the same healing exampleIllustrative facts and outcome, not a live player action or a change to campaign state.Integration / repairPlayer input and frozen batch“I drink one of my healingdoses.”Resolve freezes the contributedintent; later input waits.C19Integration / repairFACT REGISTERStorage, versions and historyfoundation.Example: health 7/10; doses 2.Item/resource integration haswider open gates.C01 · C14 · C15Integration / repairApproved rule sourceUse the reviewed, pinneddefinition.The GM cannot invent costs oreffects.RE02 · RE03Pinned sourceRead factsIntegration / repairContext and GM proposalRelevant facts, intent and rule.The GM proposes a supported action; itdoes not write state.C04 · C05Integration / repairValidate and calculateCheck actor authority, access,quantity, known health and eligibility.Calculate only the allowed cost andeffect.RE03 · C03 · C15Cannot proceedIntegration / repairReject or pause — no spendFull or unknown health, empty doses,invalid access or missing facts.Keep the reason and await valid input.RE03ValidIntegration / repairCommit allowed changesHealth 7/10 → 9/10.Doses 2 → 1.Save effects, history and receipttogether.RE03 · C03Saved factsIntegration / repairSaved result and eligible outputProject public facts from thecommitted result.Keep private context out of narrationand delivery.C20Public resultIntegration / repairDiscord deliveryDeliver saved narration and theappropriate controls.Actual GM / Discord proof stays aseparate gate.C30 · C31Integration / repairFailure and retryRoll back an incomplete commit.Reuse saved receipts/results aftercommit; never double-spend.C03 · C06Saved retryNext contributed intent → next ResolveRemaining roadmap gatesRE04 · Second-definition reuseNot startedRequired proof; bounded healing evidence does not close this gate.RE05 · Independent shared-path reviewNot startedRequired proof; bounded healing evidence does not close this gate.

Current roadmap status

Current delivery

NOW

Batch 4 planned (Block 9)

Blocks 1–8 accepted; loadout decision/effects blueprint B9-01–08 ready, no B9 runtime acceptance. RE03/WI14 gates open.

Next: Sol High builds/tests B9; Astra separately reviews; final Batch 4 process report must be presented before successor/archival.

Planning decisions

DEC

Pending

Stage 1 still needs selected pilot-mechanics/interface decisions and a finite evaluation envelope before dependent pilot work.

Next: Bundle Brian's decisions into the Stage 1 planning/handoff record.

Shared-path gates

RISK

Needs repair

WI14 and G6R01-G6R04/BP01-BP08 remain open; bounded demonstrations do not close the shared-path or pilot gates.

Next: Carry the named failures and blueprint into RE03 evidence and later independent review.

Downstream route

NEXT

Blocked by RE03

RE04 must prove a second definition on the shared path; RE05 then independently reviews reuse and retained affected gates.

Next: Complete remaining RE03 shared-path scope before formal RE04 begins.

Governing direction

RE02 settled contract — 2026-09-22

Disposition: design complete; implementation and behavioral acceptance pending. Brian's continue authorized this design stage. C40 stays open; WI14 stays NEEDS REPAIR. This section settles engineering details of SC-009, not new game rules. The retained AH blueprint still controls all…