D-05 — Playbook Registry (Sellable Repeatable Business Processes)

Status: 2026-11-09. Audience: product, ops, and stakeholders who buy and run business processes as configured packs. Format: Each playbook is a named SKU — the customer buys it, the desk runs the pack, guardrails refuse anything unsafe, and the audit packet proves it happened. Every playbook below states PROBLEM → MECHANISM → INTERFACES → INVARIANTS so a buyer can challenge the decision, not just the prose. The full 31-entry registry is complete; gaps and honesty limits are listed at the bottom. (Source: operational memory 180-day work; commercialization backlog; AGENTS.md mandate violations validated; 16-phase remediation sequence.)

Playbook Catalog

P-01 — Configuration Rollout (FCT)

Problem. A configuration change must be offered, reactions gathered, and finalized only when every connected unit has answered, with a signed receipt chain that cannot be declared final on one unit's word alone. No trusted timestamp was available for finalize; that was deferred.

Mechanism. The change is offered to every unit; each unit responds accept/reject/timeout. The change is finalized only when all units have answered and a signed receipt chain is complete. The receipt is signed by the gateway, and a missed deadline can be caught and rolled back with two-person control (quorum = met). If trusted timestamp is not yet available, the finalize step remains soft until a timestamp-authority customer arrives.

Interfaces.

• POST /v1/config/rollout — offer a change to connected units.
• POST /v1/config/rollout/finalize — finalize when all units have answered; returns outbox.ok with a receipt.
• GET /v1/config/rollout/status — check pending/rejected/timeout counts.

Invariants. A rollout can never be declared final on the word of one unit; the receipt is signed by the gateway; a missed deadline can be caught and rolled back with two-person control; trusted timestamp on finalize is deferred until a timestamp-authority customer arrives. (Source: Doc 02; Doc 30 consolidated program backlog.)

P-02 — Sourcing — Publish-and-Match (CAPSRC)

Problem. A person, organization, vehicle, or building must be published as a searchable candidate, but only approved, privacy-safe details are visible; sealed personal content must never appear in a match result, and no invented matches may appear when the service is down.

Mechanism. Each entity type (person, org, vehicle, building) is published with a recipe that defines which fields are privacy-safe and visible in match results. All 19 sourcing items are complete. A request to reveal sealed content through search or matching is refused. A change to a person or building updates search within the normal notice flow, and all matches are real — no invented matches when the service is down.

Interfaces.

• POST /v1/sourcing/publish — publish an entity as a candidate.
• GET /v1/sourcing/match — match a query against published candidates.
• GET /v1/sourcing/status — check service health.

Invariants. A request to reveal sealed content through search or matching is refused; a change to a person or building updates search within the normal notice flow; all 19 items are complete with no invented matches when the service is down; live counter plane required; the system refuses rather than imagining a match when it is down. (Source: Doc 39 capability supply sourcing backlog; Doc 41 week in review.)

P-03 — Interaction Requests — One Governed Record (INTRQ)

Problem. Everything that used to be a separate ticket, SOS, order issue, or claims-assistance note must be one governed request record with child requests for multi-agency work, and the public description must never name a third-party workbench.

Mechanism. A parent emergency request can fork to fire and ambulance children, each closed child updates the parent, and swapping the provider tool does not change the customer's request number or web address. An emergency-call location format is deferred until a public-safety answering point (emergency call center) is the buyer.

Interfaces.

• POST /v1/requests — create a governed request record.
• POST /v1/requests/:id/fork — fork a parent to children.
• PATCH /v1/requests/:id/close — close a child and update parent.
• GET /v1/requests/:id — read a request with its children.

Invariants. A parent emergency request can fork to fire and ambulance children; each closed child updates the parent; swapping the provider tool does not change the customer's request number or web address; emergency-call location shape deferred until a PSAP customer arrives. (Source: Doc 40 unified interaction request plane; Doc 41 week in review.)

P-04 — Claims Engine — One Guarded Path (claims families)

Problem. A single guarded path must work for insurance, government benefit, community ticket, Materra loss, or commerce: a claim cannot move forward unless its required quorum, separation of duties, evidence, proof receipt, or outside-victory steps are satisfied, with no path that skips a declared stage.

Mechanism. Every claim follows the same guarded path with declarative policy: quorum, SOD, evidence, external checks. Missing evidence is refused with a clear error; the creator cannot approve their own claim; metrics are computed only from real cases and otherwise show an honest empty result; a create-first-notice alias resolves to the same person or vehicle and the same journey number across search, evidence, and approval.

Interfaces.

• POST /v1/claims — create a claim.
• POST /v1/claims/:id/transition — guarded transition.
• POST /v1/claims/:id/finalise — finalise with proof receipt.
• GET /v1/claims/:id — read claim with stage and receipts.

Invariants. Missing evidence is refused with a clear error; the creator cannot approve their own claim; metrics are computed only from real cases and otherwise show honest empty result; a create-first-notice alias resolves across search, evidence, and approval; large-scale fleet routing and optional thin customer facade deferred to outside demand. (Source: Doc 37 claims orchestration backlog; Doc 41 week in review.)

P-05 — Ready-Made Claims Packs (motor, medical, home, etc.)

Problem. Lines of business need their claim types and traits, but custom code for each vertical is unnecessary and reduces reuse and federation.

Mechanism. Motor, medical, home, government benefit, government compensation, community ticket, and industrial-local-content packs are prepared as configuration packs with service-level times, approval bands by amount and risk, provider panels, and intake forms. A pack can be checked with zero writes before it runs; an unapproved provider is refused; a service-level breach is recorded and re-dispatched or escalated; outside verdicts are honoured — a negative verdict blocks settlement.

Interfaces.

• POST /v1/packs/:pack_name/check — check a pack before it runs.
• GET /v1/packs/:pack_name — read a pack's declaration.
• POST /v1/packs/:pack_name/activate — activate a pack for a claim.

Invariants. A pack can be checked with zero writes before it runs; an unapproved provider is refused; a service-level breach is recorded and re-dispatched or escalated; outside verdicts are honoured — a negative verdict blocks settlement. (Source: Doc 37 claims orchestration backlog; Doc 41 week in review.)

P-06 — Optional AI Help — Advice Only, Never Approval

Problem. Automated text help can prepare a draft or flag missing evidence, but it must never approve or advance a claim on its own.

Mechanism. AI help is off by default. The claim path continues if the help service is down unless the pack marks it as mandatory. Only an allow-listed set of notes can be added. The help is advice only; the claim path always continues without it if the service is unavailable.

Interfaces.

• POST /v1/claims/:id/ai-help — invoke AI help (optional, off by default).
• GET /v1/claims/:id/ai-status — check if help is mandatory or off.

Invariants. Help is off by default; claim path continues if the help service is down unless the pack marks it as mandatory; only an allow-listed set of notes can be added. (Source: Doc 37 claims orchestration backlog; Doc 41 week in review.)

P-07 — Money — Declarative Splits, Entitlements, and Wallets (FINMON)

Problem. Revenue splits, wallet credits, and subscription percentages are hidden in code and cannot be audited or changed without a code deploy.

Mechanism. Subscriptions, entitlements, invoices, revenue splits, and wallet credits are expressed as declarative profiles rather than hidden percentages in code. Every split must add up to exactly 100% of the invoice; a creator's share is visible as a named party; changes to a split profile require two-person approval with a full audit trail; life-safety features degrade gracefully rather than stop when payment is late.

Interfaces.

• POST /v1/money/split-profiles — create or update a split profile.
• GET /v1/money/split-profiles/:id — read a split profile.
• POST /v1/money/wallets — create or update a wallet binding.
• GET /v1/money/wallets/:id — read a wallet binding.

Invariants. Every split must add up to exactly 100% of the invoice; a creator's share is visible as a named party; changes to a split profile require two-person approval with a full audit trail; life-safety features degrade gracefully rather than stop when payment is late. (Source: Doc 35 playbook monetization backlog; Doc 41 week in review.)

P-08 — Emergency + Community Configuration (VF / MARS-CFG)

Problem. Emergency and community configuration must be shared across connected products, not forked; emergency dispatch is a pack, not a separate vertical; drill configuration can be authored.

Mechanism. Connected products share one fabric; emergency dispatch is a pack, not a fork; drill configuration can be authored. Signed live desk and live runbooks are required for the live gate; drill-pack acceptance, carrier/consent wiring for anonymous intake, ultrasonic client, and liability note are deferred.

Interfaces.

• POST /v1/emergency/drill — author a drill configuration.
• GET /v1/emergency/drill-status — check drill configuration status.
• POST /v1/community/config — author community configuration.

Invariants. Connected products share one fabric; emergency dispatch is a pack, not a fork; drill configuration can be authored; signed live desk and live runbooks required for live gate; drill-pack acceptance and carrier/consent wiring for anonymous intake deferred. (Source: Doc 30 consolidated program backlog; Doc 41 week in review.)

P-09 — Configuration Rollout Trusted Timestamp

Problem. A configuration rollout finalize step needs trusted timestamping to prove when the finalization happened, but no timestamp-authority customer has arrived yet.

Mechanism. Trusted timestamping is deferred until a timestamp-authority customer arrives; until then, finalize without a timestamp and note the gap. When the customer arrives, the finalize step gains timestamp proof and the rollout is retroactively auditable.

Interfaces.

• POST /v1/config/rollout/finalize — finalize with timestamp when available.
• GET /v1/config/rollout/timestamp-status — check if timestamp is available.

Invariants. Trusted timestamp on finalize is deferred until a timestamp-authority customer arrives; until then finalize without timestamp and note the gap; when customer arrives, finalize gains timestamp proof and rollout becomes retroactively auditable. (Source: Doc 41 week in review.)

P-10 — Large-Scale Fleet Routing (optional, outside demand)

Problem. Large-scale fleet routing requires capabilities beyond the core platform (fleet management, routing algorithms, vehicle tracking beyond the core claim path).

Mechanism. Large-scale fleet routing and an optional thin customer facade are deferred until an outside fleet provider wants them. No core platform change is needed; the feature remains gated.

Interfaces. None in core — feature gated behind outside demand.

Invariants. Large-scale fleet routing and optional customer facade deferred to outside demand; no core platform change needed. (Source: Doc 37 claims orchestration backlog.)

P-11 — Live Money Movement (FINMON-16)

Problem. Real money movement through the Estate Safe pack requires finance keys, a human approver, and the payments ledger — all ops-side gated items.

Mechanism. Live money movement is gated until finance keys, a human approver, and the payments ledger are ready; no code change opens the gate; the desk waits on the finance team to provision the production environment.

Interfaces. None in soft — ops gate only.

Invariants. Live money movement opens only when finance keys + human approval + payments ledger are ready; no code change opens the gate. (Source: Doc 35 playbook monetization backlog; Doc 41 week in review; FINMON-16.)

P-12 — Emergency-Call Location Shape (INTRQ-20)

Problem. The emergency-call location format is deferred until a public-safety answering point (emergency call center) is the buyer — the exact shape of the location data that the system must accept and validate.

Mechanism. Location shape deferred until a PSAP customer arrives; until then, the system refuses emergency-call location submissions that do not match the expected shape. When the PSAP customer arrives, the shape is defined and the gate lifts.

Interfaces. None in soft — ops gate only.

Invariants. Emergency-call location shape deferred until a PSAP customer arrives; until then the system refuses submissions that don't match the expected shape. (Source: Doc 40 unified interaction request plane; Doc 41 week in review.)

P-13 — Kill Bill Production Migration (FINMON-16)

Problem. Kill Bill production migration requires production keys, a live ledger, and tenant migration procedure — all ops-side gated items that cannot be code-deployed.

Mechanism. Kill Bill production migration is gated on the human approval and finance gate; the desk waits on the finance team to provision production keys and the ledger migration procedure; no code change opens the gate.

Interfaces. None in soft — ops gate only.

Invariants. Kill Bill production migration is gated on human approval and finance gate; no code change opens the gate. (Source: Doc 35 playbook monetization backlog; FINMON-16.)

P-14 — Emergency Drill Packs — Author, Not Yet Accepted

Problem. Emergency drill packs can be authored now but their acceptance checks have not yet passed — the desk can create drills but cannot yet run them in live mode.

Mechanism. Drill packs can be authored now; acceptance checks are deferred until the live desk is signed and runbooks are live; until then, drills run in soft mode only.

Interfaces.

• POST /v1/emergency/drill — author a drill pack.

Invariants. Drill packs can be authored now but acceptance checks not yet passed; drills run in soft mode until live desk and runbooks are live. (Source: Doc 30 consolidated program backlog.)

P-15 — Anonymous Intake — Separate Audited Path

Problem. Anonymous and gender-based-violence intake is kept on a separate audited path and is deliberately not connected to live dispatch — the system refuses rather than guesses.

Mechanism. Anonymous and GBV intake is kept on a separate audited path; it is deliberately not connected to live dispatch; the system refuses rather than invents a path; the desk may author intake records but they never advance to live claim creation.

Interfaces.

• POST /v1/intake/anonymous — author an anonymous intake record (soft mode only).

Invariants. Anonymous and GBV intake is kept on a separate audited path; deliberately not connected to live dispatch; system refuses rather than invents a path; records never advance to live claim creation. (Source: Doc 30 consolidated program backlog.)

P-16 — AI Writing Helpers — Beyond Generic Runner

Problem. Specific writing helpers beyond the generic runner remain TODO — they are not yet offered; they stay off until each pack asks for one.

Mechanism. Writing helpers beyond the generic runner remain TODO; they are not yet offered; they stay off in packs by default; turning them on is a product choice, not a technical missing piece.

Interfaces. None — feature gated behind pack configuration.

Invariants. Writing helpers beyond the generic runner remain TODO; not yet offered; stay off in packs by default; turning on is a product choice. (Source: Doc 37 claims orchestration backlog.)

P-17 — Configuration Rollout Rollback (two-person control)

Problem. A configuration rollout finalize with a missed deadline must be caught and rolled back with two-person control — one person initiates the rollback, the other co-signs.

Mechanism. If a deadline is missed during finalize, either unit can initiate a rollback; the rollback is co-signed by a second named person; the base configuration must not have moved since finalize started (CAS-check); the rollback reverts the change and records the audit.

Interfaces.

• POST /v1/config/rollout/rollback — initiate a rollback with two-person control.

Invariants. A missed deadline can be caught and rolled back with two-person control; the base must not have moved since finalize started (CAS check); rollback records full audit trail. (Source: Doc 30 consolidated program backlog.)

P-18 — Money Split Two-Person Approval (dual-control MSS)

Problem. Changes to a money split profile require two-person approval with a full audit trail — one person drafts, the other co-signs.

Mechanism. One person drafts a split profile change; a second named person co-signs; the change lands only when both have acted (quorum = met) and the base configuration has not moved since draft started (CAS); the change is recorded with a full audit trail including who drafted and who co-signed and when.

Interfaces.

• POST /v1/money/split-profiles/:id/draft — draft a split profile change.
• POST /v1/money/split-profiles/:id/co-sign — co-sign a drafted change.

Invariants. Changes to a split profile require two-person approval (quorum = met); the base must not have moved since draft started (CAS check); full audit trail records who drafted and who co-signed and when. (Source: Doc 35 playbook monetization backlog.)

P-19 — Proof of Correct Execution — Hash-Chained Receipt

Problem. Governed execution needs evidence that the authorised path was followed, with a tamper-evident receipt bound to the path specification, stage sequence, and result.

Mechanism. Proof is a hash-chained, append-only receipt trail: each step hash = hash(session, index, stage, spec version, predecessor, inputs, outputs, rules); root binds specification, version, chain head, result claim, and result hash; steps cannot be mutated or reordered after the fact; finalisation binds the root to exactly one result; minting is event-driven, never polled.

Interfaces.

• POST /v1/poc/session/start — start a proof session from a path specification.
• POST /v1/poc/step — append a step receipt with input/output hashes and rules applied.
• POST /v1/poc/finalise — finalise into a receipt bound to a result claim and result hash.
• GET /v1/poc/verify — verify a completed session chain.

Invariants. Steps cannot be mutated or reordered after the fact; finalisation binds the root to exactly one result; specification version at execution time is part of every hash; minting is event-driven, never polled. (Source: Doc 10 proof-of-correct-execution design.)

P-20 — Governance Path Specification — Versioned Stages

Problem. A governance path specification must declare required stages, optional rules, stage authority bindings, transitions, schemas, deadlines, and event triggers, scoped to a catalogue identifier or wildcard.

Mechanism. A path specification is a versioned declaration of required stages plus optional rules, stage authority bindings, transitions, schemas, deadlines, and event triggers, scoped to a catalogue identifier or wildcard. The specification version is part of every proof hash. Callers register and fetch path specifications; the version at execution time determines which stages are required.

Interfaces.

• POST /v1/poc/path-spec — register or update a path specification.
• GET /v1/poc/path-spec/:id — read a path specification.
• POST /v1/poc/path-spec/:id/activate — activate a specification for use.

Invariants. A path specification is versioned; the specification version is part of every proof hash; stages, rules, authority bindings, transitions, schemas, deadlines, and event triggers are all declarative. (Source: Doc 10 proof-of-correct-execution design.)

P-21 — Scope Governance — Delegation Chain with 15 Invariants

Problem. Authority must be a formal delegation chain with bounded depth, immutable grants, and 15 monotonicity and cycle guards.

Mechanism. Authority is a formal delegation chain: root scope owns max delegation depth (capped at 10), join policy, and recovery quorum; each delegation is immutable and hash-linked from issuer to subject for a scope and set of claim types, with its own depth, parent hash, validity window, signature, and lifecycle state; hierarchy adds directed A-DAC relation of containment/management/observation between scopes; claim-type registry states which types are valid in which scopes and whether they require a public anchor or trusted-execution attestation; fifteen invariants guard monotonicity, cycles, root binding, membership, join policy, orphanhood, transfer quorum, temporality, scope consistency, stale signatures, expiry, depth overflow, duplicate hashes, and sealing.

Interfaces.

• POST /v1/scope/delegate — delegate within depth.
• GET /v1/scope/verify-chain — verify a delegation chain.
• POST /v1/scope/join — join a scope under its join policy.
• POST /v1/scope/transfer-request — request root transfer.
• POST /v1/scope/transfer-approve — approve root transfer.
• GET /v1/scope/sweep-orphans — sweep orphans and expired delegations.

Invariants. Fifteen invariants guard monotonicity, cycles, root binding, membership, join policy, orphanhood, transfer quorum, temporality, scope consistency, stale signatures, expiry, depth overflow, duplicate hashes, and sealing; delegation depth capped at 10; all delegations are immutable except lifecycle state; authority verified through bounded chain check. (Source: scope governance authority spec and invariants.)

P-22 — Quorum — Named Threshold Group with Signature Collection

Problem. A quorum is a named threshold group with a default threshold of two signers; more than one person must say yes for a high-stakes action; signer collection and open/close status must be recorded.

Mechanism. Quorum is a named threshold group with a default threshold of two signers, a signer array, an open status, and an expiry; one signature record per signer; small list and lookup operations; no separate storage beyond the companion design; exceeding a threshold is established by collected signatures, never by a solo flag.

Interfaces.

• POST /v1/quorum/open — open a quorum with a named group and threshold.
• POST /v1/quorum/sign — add a signer's signature.
• GET /v1/quorum/status — check if quorum is met.
• POST /v1/quorum/close — close a quorum.

Invariants. Default threshold is two signers; exceeding a threshold is established by collected signatures, never by a solo flag; quorum has open status and expiry; one signature record per signer; no separate storage beyond companion design. (Source: lifelong + quorum bridge design.)

P-23 — CNS Address Grammar — Canonical Naming Rules

Problem. A canonical naming grammar must exist for every typed thing so lineage, routing, and proof share a single addressable vocabulary.

Mechanism. A canonical path uses a mandatory scheme followed by slash-separated segments, with a depth floor of two segments and a ceiling of sixteen segments; an empty body and a wrong scheme are rejected distinctly; ancestors are resolved nearest-first; traits and capability references are inherited from ancestor paths; interfaces carry versioned category path-at-version; validation callback caches compiled schemas and maps canonical paths to event subjects at runtime.

Interfaces.

• POST /v1/cns/interface — register a CNS interface.
• GET /v1/cns/interface/:path — read a CNS interface.
• POST /v1/cns/type — register a CNS type.
• GET /v1/cns/type/:path — read a CNS type.
• POST /v1/cns/entry — register a CNS entry.
• GET /v1/cns/entry/:path — read a CNS entry.

Invariants. Path depth floor 2, ceiling 16; empty body and wrong scheme rejected distinctly; ancestors resolved nearest-first; traits and capability references inherited from ancestor paths; interfaces carry versioned category path-at-version; validation callback caches compiled schemas and maps canonical paths to event subjects at runtime. (Source: CNS naming directory design.)

P-24 — Claim Dual-Map — Claim Plus Graph as One Fact

Problem. A claim without graph linkage is isolated; a graph without a claim record is unaccountable; the two representations must agree.

Mechanism. Every claim-eligible entity is both a claim record typed by a canonical claim-type path AND a graph participant linked by a typed edge; claim typing and graph typing carry the canonical name and must agree; never create a claim without its graph link; never expose a graph object whose typing disagrees with its claim typing; federation metadata exists equally on claims, nodes, and edges so federation decisions are uniform across the dual representation.

Interfaces.

• POST /v1/claims — create a claim and link to graph.
• GET /v1/claims/:id — read claim with graph edges and attestations.
• POST /v1/graph/edge — create a typed edge linking a claim.
• GET /v1/graph/traverse — traverse from a claim node.

Invariants. Typing agreement is mandatory between claim and graph; never create a claim without its graph link; never expose a graph object whose typing disagrees with its claim typing; federation flags uniform across dual representation. (Source: operational memory dual-map mandate.)

P-25 — Lifelong + Quorum Bridge — Entity-to-Claim Linkage

Problem. Entities live longer than any single operation; governed lifecycle events must bridge into proof sessions; quorum expresses threshold agreement.

Mechanism. Lifecycle event names entity type, entity identifier, event type, actor, prior/next states, scope, governed-execution flags with path specification reference, and resulting proof session reference; new lifecycle signals publish to the delivery anchor; entity reference pointer remains lifelong identity with index for range/paging lookups by entity and time; governed lifecycle signals publish to anchor rather than persisting as private stream; quorum = named threshold group, default threshold 2, signer array, open status, expiry.

Interfaces.

• POST /v1/lifecycle/event — publish a lifecycle event.
• GET /v1/lifecycle/events/:entity_id — read events for an entity.
• POST /v1/poc/session/start — start a proof session (auto from governed event).
• GET /v1/entity/:id — read entity with lifelong history.

Invariants. No new tables for lifelong history; governed lifecycle signals publish to anchor rather than private stream; quorum threshold is declarative and versioned; exceeding threshold established by collected signatures, never by solo flag. (Source: lifelong + quorum bridge design.)

P-26 — Verification Machine — Hash-Chained Append-Only Receipt

Problem. The verification machine must produce a hash-chained, append-only receipt trail that proves a governed request followed an authorised path.

Mechanism. Each step hash = hash(session, index, stage, spec version, predecessor, inputs, outputs, rules); root binds specification, version, chain head, result claim, and result hash; steps cannot be mutated or reordered after the fact; finalisation binds the root to exactly one result; minting is event-driven, never polled.

Interfaces.

• POST /v1/poc/session/start — start a session.
• POST /v1/poc/step — append step.
• POST /v1/poc/finalise — finalise into receipt.
• GET /v1/poc/verify — verify a session chain.

Invariants. Steps cannot be mutated or reordered; finalisation binds root to exactly one result; specification version is part of every hash; minting is event-driven, never polled. (Source: Doc 10 proof-of-correct-execution design.)

P-27 — Outbox — Durable Delivery Anchor

Problem. If a producer writes an event and the bus is down, the event is lost; synchronous call chains swallow errors and cannot be replayed.

Mechanism. The outbox is a durable table; the producer writes a delivery anchor transactionally; the relay reads pending rows, publishes to NATS JetStream, marks status='sent', and on success marks status='delivered'; on failure marks status='failed'; after max retries status='dead-letter' and an audit row is created; every row has a bounded retry count.

Interfaces.

• POST /v1/outbox/write — write a delivery anchor.
• GET /v1/outbox/pending — read pending rows.
• POST /v1/outbox/relay — relay pending to NATS.

Invariants. Relay is best-effort — failure never blocks the legacy write; every row has bounded retry count and a dead-letter after max retries; the durable store remains the record plus a bounded vocabulary; background work uses events, not polling; sweep endpoints are recovery only. (Source: operational memory outbox relay design.)

P-28 — Fail-Closed — Infrastructure Failures Produce Typed Errors

Problem. When an external service is down, the platform must never invent a success; it must produce a typed error and refuse the request.

Mechanism. Infrastructure failures produce typed errors (HTTP 502/503/422) and never synthetic success objects; no mock adapters, synthetic mocks, fake generators, dummy card metrics, or un-production-ready placeholder values appear anywhere; if a caller's request does not match the real service's contract, return HTTP 400 or update the caller/test to send a valid contract.

Invariants. Zero synthetic fallback objects; zero mock adapters; infrastructure failures produce typed errors, never invented success; if real data is not available, render honest empty states or skeleton loaders. (Source: AGENTS.md mandates: zero bespoke tables, declarative-first, fail-closed, no synthetic payloads.)

P-29 — No Synthetic Payloads — UI Cards and Dashboards Display Live Data Only

Problem. UI cards, dashboards, and analytics must never display hardcoded numbers, coordinates, or fake data.

Mechanism. All card values, badges, and stats must be backed by live backend API responses, database queries, or engine telematics; if real data is not yet computed or available, the UI must render honest empty states, skeleton loaders, or fail closed; never synthesize data to make a dashboard or card look complete.

Invariants. Zero hardcoded numbers on cards or dashboards; all values backed by live responses or queries; honest empty states when data is unavailable; no fake status chips or metrics. (Source: AGENTS.md mandate: zero synthetic payloads.)

P-30 — Events-Not-Polling — Background Work Uses NATS JetStream Anchors

Problem. Polling loops waste resources and cannot guarantee event delivery; background work must use event-driven anchors.

Mechanism. Background work uses NATS JetStream anchors + delivery anchors + sweeps for recovery only; no polling loops; the nats_outbox table is the durable write; the relay publishes from the outbox; consumers subscribe by interest on the event spine; sweep endpoints exist only for recovery when the system has been down and needs to catch up.

Invariants. No polling loops in background work; events delivered via NATS JetStream anchors + outbox delivery anchors; sweep endpoints for recovery only; if the system was down, sweep catches up on restart. (Source: AGENTS.md mandate: events-not-polling.)

P-31 — Zero Bespoke — Every Domain Entity Maps to Canonical Primitives

Problem. No domain-specific tables, columns, or functions may be created; every entity must map to the canonical claim, truth node, resource, or integration entity primitive.

Mechanism. Every domain entity (assets, logs, tenders, bids, parcels, visits, audits, sensor stations, disputes) maps directly to the existing canonical base infrastructure: claim (with CNS types and traits), truth_node and truth_edge (Truth Graph), resource and resource_edge (Stratum 1 Canonical Resource Graph), integration_entity (Stratum 356 universal integration and mirror table). If an entity cannot be mapped, the designer must STOP and ask the user — do not create new tables.

Invariants. Zero bespoke tables; every entity maps to canonical primitives; if unmappable, stop and ask; never create new tables. (Source: AGENTS.md mandate 1: zero bespoke tables; mandate 10: zero synthetic payloads.)

Gaps and Honesty Limits

• P-08 live gate — signed live desk and live runbooks are required before the live gate can flip; no signed live desk yet exists (source: Doc 30 consolidated program backlog).
• P-09 trusted timestamp — deferred until a timestamp-authority customer arrives; no customer yet (source: Doc 41 week in review).
• P-10 large-scale fleet routing — deferred to outside fleet provider; no core platform change needed (source: Doc 37 claims orchestration backlog).
• P-11 live money movement — FINMON-16 gate: finance keys + human approval + payments ledger needed; not yet provisioned (source: Doc 35 playbook monetization backlog; FINMON-16).
• P-12 emergency-call location shape — deferred until a PSAP customer arrives; until then the system refuses submissions that don't match the expected shape (source: Doc 40 unified interaction request plane; Doc 41 week in review).
• P-13 Kill Bill production migration — gated on human approval and finance gate; no code change opens the gate (source: Doc 35 playbook monetization backlog; FINMON-16).
• P-14 emergency drill packs — acceptance checks not yet passed; drills run in soft mode only (source: Doc 30 consolidated program backlog).
• P-15 anonymous/GV intake — kept on separate audited path, deliberately not connected to live dispatch (source: Doc 30 consolidated program backlog).
• P-16 AI writing helpers — beyond generic runner remain TODO; not yet offered; stay off in packs by default; turning on is a product choice (source: Doc 37 claims orchestration backlog).
• Stakeholder brief language — overclaims where capability is still being wired declaratively and no live gate exists (source: operational memory; Doc 01).
• Orchestration facade — proposed optional ergonomics over existing engines rather than shipped code (source: Doc 10 §2 gaps).
• Master-plan pillars beyond Done boundary — enterprise messaging, commercial operations, notarisation, trade, lifecycle mesh, and parts of external engines remain gaps and must not be inferred as shipped (source: Doc 10 §2; Doc 36 §§0, 3.2, 5; Platform Master Plan §3 gaps and §7 Done boundary).
• Quorum signing beyond threshold-group shape — shape beyond default threshold of 2 and signer array is not specified (source: lifelong + quorum bridge design).
• Token-mint grant policy beyond the cited mint call is not specified (source: proof-of-correct-execution design).
• Precedence between canonical-name resolution and the directory service is not stated in sources read (source: core concepts unknowns).
• Full lifelong HTTP inventory beyond lifecycle and paging reads is not enumerated (source: lifelong unknowns).
• Realm-facade 2026-09 pointer — the DEPLOYMENT_TOPOLOGY header cites a September 2026 realm-fabric design that was not read for some files; must re-verify against that design (source: A-01 deploy topology).
• Gateway staleness risk — Caddy :8088 and Gravitee :8089 cards rest on May 2026 documents; the September 2026 realm-fabric design may supersede them (source: A-01 deploy topology header).
• Compose skim note — only service names, images, and ports were taken from compose files; internal networks, volumes, and healthcheck probe semantics were not audited (source: docker/compose.microservices.yml).
• No live inventory — operational memory is not a verified live inventory of running services; it is the 180-day work catalog. (Source: this doc's own honesty note.)

Playbook Index by Audience