D-07 — Playbook Building (developer)
Scope: Definitive design dossier for how playbooks get authored from configuration fragments and wire into the runtime. This is the single source through which a developer understands every playbook in the set: fragment taxonomy, end-to-end flow, configuration anatomy, per-family dossier sheets, registration lifecycle, groundedness, and safety invariants. (source: D-03 — Jijibora Playbook Designs (developer); source: D-04 — Environmental Playbooks (developer); source: D-05 — Starter Packs for Developers)
Status: as of 2026-11-09
Reader: developers/integrators building or extending playbooks on the platform.
Blueprint sources: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json; docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json; docs/event-sourcing/rules/sourcing-continuous-match-rule.example.json; docs/event-sourcing/rules/criteria-pipeline-sla.example.json; docs/event-sourcing/rules/lifelong-entity-state-rule.example.json; docs/event-sourcing/rules/standing-order-breach-rule.example.json; docs/event-sourcing/rules/truth-graph-state-rule.example.json; datasets/lookups/lookup.jijibora.building.reflex.v1.json; datasets/lookups/lookup.jijibora.community.starter.v1.json; datasets/lookups/lookup.jijibora.community.sourcing.v1.json; datasets/lookups/lookup.jijibora.mars.ice.v1.json; datasets/lookups/lookup.jijibora.property.playbook.v1.json; datasets/lookups/lookup.jijibora.property.standing_orders.v1.json; datasets/scenarios/scenario.jijibora.building.reflex.v1.json; datasets/scenarios/scenario.jijibora.community.starter.v1.json; datasets/scenarios/scenario.jijibora.community.sourcing.v1.json; datasets/scenarios/scenario.jijibora.mars.ice.v1.json; datasets/scenarios/scenario.jijibora.property.playbook.v1.json; datasets/scenarios/scenario.jijibora.property.standing_orders.v1.json; datasets/lookups/lookup.claims.threshold.v1.json; datasets/lookups/lookup.claims.evidence.v1.json; datasets/lookups/lookup.claims.sod.v1.json; docs/commercialization/playbooks/dictionary.v1.json; Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc); Jijibora Architecture — Design Thesis in Developer Terms; D-06 — Ontology Pack for Developers; docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md; docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md; docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md
Conventions: read UNKNOWN as "sources do not show this; do not invent it." Dataset paths below are seed-time conventions only; runtime never reads disk. Confirm every citation before building; if a mapping cannot be expressed as a fragment/config/lookup, say so before writing code. (source: D-03 — Jijibora Playbook Designs (developer); source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md)
1. Fragment taxonomy
1.1 Diagram-in-words — the six artifact classes as one picture
SEED-TIME (version control + offline seeder only)
reflex rule ─┐
scenario pack ─┼─ seeder ──► KV: lookups bucket (values) + KV: scenarios bucket (orchestration)
governance rule ─┤ │
starter pack ────┘ ▼ runtime reads KV only (never disk)
relay-to-core-bus → consumer → guard checks
│
▼
outputs: canonical claim record
+ durable outbox anchor
+ receipt (proof / fired notice)
│
▼
verify: dry-run plan-only + outbox row + acceptance
Every playbook is declarative data on a shared substrate: one subject family in, one standard fired notice out, bounded depth, terminal-only actuation. Evaluation lives in the engines; the record store is system-of-record only. A variant is not new code — it is new typed names + fragments + vocabulary + KV lookups. (source: D-03 — Jijibora Playbook Designs (developer); source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md)
1.2 Where each type lives (dataset path conventions)
| Artifact class | What it is | Lives (seed-time convention) | Loaded into (runtime) |
|---|
| Reflex rules | Declarative event-binding signatures: rule_id, runtime.tier/chain, pipeline.id/stage, inputs[] (stream+filter), evaluation (kind, key_by), outputs[], side_effects.handled_by terminal-only (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json; source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json) | docs/event-sourcing/rules/*.example.json — one file per rule; the three Jijibora rules are the shape all variants copy (source: D-03 — Jijibora Playbook Designs (developer)) | Declared as pack bindings (emits/consumes/camel_routes/kestra/enrichment/security_bound) resolved by the runtime from KV; the rule signature itself is hoisted configuration, never inline procedural logic (source: docs/commercialization/playbooks/dictionary.v1.json; source: D-06 — Governance Rules Architecture and Event Contracts) |
| Scenario packs | Orchestration definitions the workflow/protocol engines execute: namespace + flow + route + proof path-spec binding (source: Jijibora Architecture — Design Thesis in Developer Terms) | datasets/scenarios/scenario.jijibora.*.v1.json — six property/community scenario seeds; claims siblings use the claims scenario seeds in the same directory family (source: Jijibora Architecture — Design Thesis in Developer Terms; source: D-05 — Starter Packs for Developers) | KV scenarios bucket only. Runtime must not fs.readFile scenario files; the seeder seeds the bucket (source: D-05 — Starter Packs for Developers) |
| Governance rules | Value families referenced by transition policy: threshold / evidence / separation-of-duties (+ transition policy) resolved at runtime by declared config references (source: datasets/lookups/lookup.claims.threshold.v1.json; source: datasets/lookups/lookup.claims.evidence.v1.json; source: datasets/lookups/lookup.claims.sod.v1.json) | datasets/lookups/lookup.claims.*.v1.json — threshold, evidence, separation, transition-policy lookups (source: D-06 — Governance Rules Architecture and Event Contracts) | KV lookups bucket only; packs bind the lookup keys plus the governed claim/entity types and scenario pack (source: docs/commercialization/playbooks/dictionary.v1.json) |
| Starter packs | The day-one composition: lookup + scenario + governed types + consumer wiring bound as one dictionary pack entry (source: docs/commercialization/playbooks/dictionary.v1.json) | Starter composition is declared in the playbook dictionary plus datasets/lookups/lookup.jijibora..v1.json and datasets/scenarios/scenario.jijibora..v1.json conventions above (source: docs/commercialization/playbooks/dictionary.v1.json; source: D-05 — Starter Packs for Developers) | KV lookups + scenarios buckets; the dictionary pack entry binds all five things together (source: docs/commercialization/playbooks/dictionary.v1.json) |
| Outbox envelope | The only wire shape + durable delivery anchor: canonical envelope {correlation_id, trace_id, voyage_id, envelope_subject, payload, headers?, signature?, proof?} on platform.criteria.v1.* subjects; transitions only enqueue outbox rows, the relay sweep publishes and marks the row, never direct publish (source: Jijibora Architecture — Design Thesis in Developer Terms; source: Jijibora Features → Interfaces Map) | Envelope contract lives in the event-spine/data-fabric design, not in a dataset file; packs declare canonical_subject/canonical_event_type/pipeline_id on their lookups (TODO in read set — design with it in mind, do not assume it live) (source: D-03 — Jijibora Playbook Designs (developer); source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) | Outbox row in the durable anchor; relay → core bus → consumer (source: Jijibora Features → Interfaces Map) |
| Walk rows | The verifiable traces: create → transition → outbox row → relay sweep → consumed receipt; plus guard-stage dry-run verdicts and watcher/cooldown/breach assessments (source: Jijibora Features → Interfaces Map; source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) | Not dataset files — walk rows are runtime evidence produced by executing the fragments above (source: Jijibora Features → Interfaces Map) | Receipts and outbox rows are the audit trail (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
Pattern library (copy these shapes for any new playbook): criteria one-shot (kind: criteria, keyed meta.tenant+entity_id|payload.match_key, single input, on_match → platform.criteria.v1.match.fired); join (kind: join, two inputs, min_score: 0.8, non-terminal); solver stage (input filtered by pipeline stage, kind: solver, contract-versioned capability, on_feasible/on_infeasible pair); windowed SLA (kind: window, event-time, on_missing: breach, escalation handler owns tickets/notifications/proof). No second bus or envelope may be invented. (source: D-03 — Jijibora Playbook Designs (developer))
2. The end-to-end fragment flow
| Stage | What happens | Contract |
|---|
| 1. File (seed-time only) | Author reflex-rule JSON, scenario-pack JSON, and lookup-value JSON under the conventions in §1.2; declare the pack in the playbook dictionary (emits/consumes/enrichment/solver_stages/security_bound) and validate against the dictionary schema matrix before building (source: D-03 — Jijibora Playbook Designs (developer); source: docs/commercialization/playbooks/dictionary.v1.json) | Files are versioned artifacts. No table may be added here — if a new record kind is needed, STOP AND ASK (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md) |
| 2. KV seed (lookups / scenario buckets only) | Offline seeder loads file contents into KV lookups bucket and KV scenarios bucket. Every lookup declares canonical_subject, canonical_event_type, pipeline_id (pattern from governed lookups; TODO in read set) (source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md; source: D-03 — Jijibora Playbook Designs (developer)) | Never runtime-read from disk. Runtime services read KV only (SOVEREIGN_LOOKUPS, SOVEREIGN_SCENARIOS); disk copies are seed-only (source: Jijibora Architecture — Design Thesis in Developer Terms; source: D-05 — Starter Packs for Developers) |
| 3. Relay-to-core-bus / consumer | Transition/finalise paths only enqueue outbox rows; the relay sweep performs the publish and marks the row. Stage handlers never publish directly; criteria subjects carry inherit_causation: true so causation and correlation identifiers propagate (source: Jijibora Features → Interfaces Map; source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json) | One canonical envelope, one criteria subject family. Legacy bare payloads without the envelope are refused (source: D-06 — Governance Rules Architecture and Event Contracts) |
| 4. Guard checks | Governed runner evaluates stages in order — gate, quorum, separation, evidence, execution proof, external verdict — resolving values from the declared packs and lookup groups; refuses on any failing stage. Missing required evidence, barred creator pairs, under-threshold quorums, stale spatial bindings, and missing value references all refuse (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: datasets/lookups/lookup.claims.evidence.v1.json; source: datasets/lookups/lookup.claims.sod.v1.json; source: datasets/lookups/lookup.claims.threshold.v1.json) | Self-check is plan-only with zero writes. Failure of an infrastructure dependency returns 502/503 and never returns a synthetic pass (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md) |
| 5. Outputs (claims, outbox, receipts) | Feasible run lands a canonical claim record plus an outbox anchor plus a typed receipt: guarded-transition receipt (step, actor, guard verdict), quorum chain, evidence seal, fired notice (match.fired with typed event_type), breach assessment + fire command, fill plan / explicit infeasible, decision record with provenance and checker verdict (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: D-09 — Optimization Capability (developer)) | Terminal stage owns side effects. Non-terminal stages emit criteria only (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; source: D-03 — Jijibora Playbook Designs (developer)) |
| 6. Verify | Respond-catalog dry run across each guard stage with zero mutation; spine consumer accepts the outbox event and emits the expected receipt; negative case (allowlist-external subject for a ghost identity) produces no receipt; Soft acceptance suite per pack (ticket end-to-end, outbox row for the emit, billing-adapter Soft binding check, honest refusal when a downstream service is down) (source: D-06 — Governance Rules Architecture and Event Contracts; source: docs/commercialization/playbooks/dictionary.v1.json; source: D-05 — Starter Packs for Developers) | Soft (practice) vs LIVE (production) governs every readiness claim. Soft = outbox + allowlisted subject; LIVE = JetStream + ceiling. A pack never declares itself live (source: D-05 — Starter Packs for Developers; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) |
Executor placement (who evaluates what): Tier-1 flow/protocol engines for criteria/reflex; stream-join job for continuous matching (min_score 0.8, keyed tenant + match key) and for event-time windows; allocation engine only for allocation, only after a real match. Evaluation in the engines; the record store is record-only. (source: docs/event-sourcing/rules/sourcing-continuous-match-rule.example.json; source: docs/event-sourcing/rules/criteria-pipeline-sla.example.json; source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json; source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json)
3. The configuration anatomy — five patterns every fragment honors
| Pattern | Meaning | Enforced by |
|---|
| 1. VALUES only | Packs supply values only. Swapping a value group changes quorum, separation, and evidence rules with zero code change. The runner never branches on claim type (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md) | Transition policy stages reference values by declared config keys (config.threshold_ref, config.evidence_ref, config.rule) and resolve them at runtime against the named value groups (source: datasets/lookups/lookup.claims.threshold.v1.json; source: datasets/lookups/lookup.claims.evidence.v1.json; source: datasets/lookups/lookup.claims.sod.v1.json) |
| 2. Environment-of-record | Durable facts live on the canonical claim and graph records; the message bus carries live evaluation; KV buckets carry the values the runtime reads. Fragments on disk are proposals — the config store is the authority (source: D-06 — Governance Rules Architecture and Event Contracts; source: AGENTS.md) | Runtime reads KV (SOVEREIGN_LOOKUPS/SOVEREIGN_SCENARIOS) only — never filesystem paths for lookups/templates (source: Jijibora Architecture — Design Thesis in Developer Terms) |
| 3. Indifference between kinds | One generalised claim primitive serves every vertical and every claim kind. A new village, ward, or building is a new themed registration + fragment + vocabulary, not a new branch or storage primitive (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md) | Scope/floor-ceiling fragments that only narrow (child cannot widen parent); thresholds change declaratively (source: D-03 — Jijibora Playbook Designs (developer)) |
| 4. NO guard imports | Guards are resolved values, not imported code. Threshold / evidence / separation values are data files the pack points at; the engine interprets them generically (source: datasets/lookups/lookup.claims.threshold.v1.json; source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) | Missing value, unknown claim type, or unmatched band refuses rather than inventing a default (source: datasets/lookups/lookup.claims.threshold.v1.json) |
| 5. Fail closed when missing | Referenced-but-missing configuration fails closed. Engine-down fails closed with 502/503 and never returns synthetic OPTIMAL/APPROVED/deterministic fallbacks. Missing evidence refuses. Unattested provider refuses. Sealed content never travels in a match (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) | Dry-run validation produces zero writes; honest empty states on compose failure; stale snapshots refuse before any allocation is invoked (source: D-09 — Optimization Capability (developer)) |
Threshold/evidence/separation shape (the three governance value families, minimally):
| Family | Shape | Guard consequence |
|---|
| Threshold | risk_vocabulary + per-type quorum bands (resolver.min_approvals, assembly.min_approvals) (source: datasets/lookups/lookup.claims.threshold.v1.json) | No matching band refuses rather than inventing a threshold (source: datasets/lookups/lookup.claims.threshold.v1.json) |
| Evidence | Per-type required fields per stage (e.g. triage_note) (source: datasets/lookups/lookup.claims.evidence.v1.json) | Missing required evidence refuses the transition (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| Separation | Per-type creator-approval rules (forbid_creator) (source: datasets/lookups/lookup.claims.sod.v1.json) | Barred pair co-approval refuses; insurance/government lines forbid creator-approval while community lines use the lenient form (source: datasets/lookups/lookup.claims.sod.v1.json) |
4. Per-family dossier sheets
Coverage commitment: 15 rows cover all 29 fragments — 9 reflex rules + 6 scenario packs + 6 property/community lookups + 4 governance value lookups + 4 cross-cutting bindings (envelope, walks, dictionary, monetization). Each sheet answers: Purpose, Inputs/events, evaluation chain, actuation surfaces, guard rails, evidence left behind, versioning, and Soft vs LIVE. UNKNOWN marks what the sources do not show.
Row 1 — Building reflex trio (rule + scenario + reflex lookup)
| Dimension | Detail |
|---|
| Purpose | A named building reacts to its own state change — a sensor or resident report — by a pre-agreed sense-reason-actuate arc, without human glue-work (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: S-03 — Jijibora Playbook Registry (stakeholder + developer)) |
| Inputs/events | platform.criteria.v1.building.entity_state, filter entity_type = building, keyed meta.tenant + entity_id; pipeline pipe:jijibora:building-reflex, stage sense, max_depth: 8, non-terminal (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json) |
| Evaluation chain | kind: criteria, engine: tgc, keyed meta.tenant + entity_id; Tier-1 chain via orchestration then protocol translation. Promotion to the stream-join job when fan-out warrants (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json) |
| Actuation surfaces | Terminal actuation only (side_effects.handled_by: terminal:actuate). Non-terminal stages emit criteria only (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json) |
| Guard rails (what blocks it) | Non-terminal stage attempting a command refuses; ceiling refuses a child that widens the parent promise; long chain stops for human review; AI proposes, human approves at decision gates; live evaluation in engines, storage record-only (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: S-03 — Jijibora Playbook Registry (stakeholder + developer)) |
| Evidence left behind | Fired notice building.reflex.fired on platform.criteria.v1.match.fired with causation inherited; proved reflex trail. Exact receipt shape beyond that notice: UNKNOWN (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: S-03 — Jijibora Playbook Registry (stakeholder + developer)) |
| Versioning (how it evolves) | Never edit 1.0.0 in place. rule_id embeds name + :v1; semantic version on the design. Re-apply strategy: new fragment + fresh version mark + new pipeline.id/stage + new subject filter; thresholds change via lookup, not code (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md) |
| Soft vs LIVE | Soft: outbox + allowlisted subject, zero live writes; engine-down in Soft refuses, never invents dispatch (source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md). LIVE: JetStream + ceiling + real probes green (source: D-05 — Starter Packs for Developers) |
| Dimension | Detail |
|---|
| Purpose | A sourcing requirement is qualified and shortlisted against pre-vetted local candidates, only from the approved register (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; source: S-03 — Jijibora Playbook Registry (stakeholder + developer)) |
| Inputs/events | platform.criteria.v1.sourcing.requirement (entity_type = sourcing_requirement, keyed meta.tenant+payload.match_key, pipeline pipe:sourcing:qualify-to-shortlist, stage requirement_opened) + platform.criteria.v1.candidate.state (entity_type = candidate) (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; source: docs/event-sourcing/rules/sourcing-continuous-match-rule.example.json) |
| Evaluation chain | Tier-1 qualify (chain: [kestra, solver-gateway], governance criteria then allocation) then Tier-2 continuous join (engine: flink, min_score: 0.8, non-terminal). Flink job is the sole continuous matcher; no parallel protocol-engine evaluator (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; source: docs/event-sourcing/rules/sourcing-continuous-match-rule.example.json) |
| Actuation surfaces | Terminal shortlist owns commands (handled_by: terminal:shortlist). Shortlisting and award allocation are downstream of the fired notice (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json) |
| Guard rails (what blocks it) | Qualification + optimizer before any shortlist; sealed content never travels in a match (facets only); unattested provider refuses; matching fails closed to manual assignment when the network cannot run; solver down refuses with 503, never invents an allocation (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) |
| Evidence left behind | sourcing.match.fired on platform.criteria.v1.match.fired (causation inherited); privacy-safe match transcript (facets only) + bind receipt; onboarding ledger per step for provider onboarding (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) |
| Versioning (how it evolves) | Never edit 1.0.0 in place. Tier-1 v1.0.0 with promotion.status: promoted; continuous match promotes to the stream-join job as sole matcher by declaration + job activation. Re-apply: change filter.entity_type, payload.match_key, min_score via KV lookup (source: docs/event-sourcing/rules/sourcing-continuous-match-rule.example.json; source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md) |
| Soft vs LIVE | Soft: match transcript + outbox row, zero live writes; honest 503 when the optimizer is down counts as a Soft pass. LIVE: JetStream + ceiling; solver invoked only after a real match (source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) |
Row 3 — MARS/ICE dispatch trio (rule + scenario + emergency lookup)
| Dimension | Detail |
|---|
| Purpose | A distress signal fans out to named responders per the pre-approved cascade (disaster + works + transport + welfare), plus governed proof sessions per step; estate emergency dispatch is a Tier C/D add-on, not in the Starter Pack (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json; source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md) |
| Inputs/events | platform.criteria.v1.governance.signal, filter entity_type = emergency_incident, keyed meta.tenant + entity_id; pipeline pipe:jijibora:mars-ice-dispatch, stage sos_raised (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json) |
| Evaluation chain | kind: criteria, engine: tgc; Tier-1 chain via orchestration then protocol translation; extended cadence uses orchestration timers + protocol handling (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json; source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md) |
| Actuation surfaces | Terminal dispatch only (handled_by: terminal:dispatch + proof). Each forked child carries its own scope; the parent ceiling bounds them (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json) |
| Guard rails (what blocks it) | Child cannot widen parent scope; public alerts from scrubbed fields only unless a purpose grant exists; decision gates keep a named human as approver; break-glass dual control with expiry + audit; external-verdict gate FAIL blocks advance, no invented PASS (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) |
| Evidence left behind | emergency.dispatch.fired on platform.criteria.v1.match.fired (causation inherited); emergency match receipt + resource assignment log; fork-tree receipt with child-closed notices; public alerts from scrubbed fields only (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) |
| Versioning (how it evolves) | Never edit 1.0.0 in place. rule_id embeds name + :v1. Re-apply: new agency/child scopes arrive via governance vocabulary + fragments, not hardcoded agency lists (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json; source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md) |
| Soft vs LIVE | Soft: outbox + allowlisted subject; drill packs enforce test-only handling with no production incident path. LIVE: JetStream + ceiling; public-safety formatted location / trusted timestamping exist only when the corresponding authority customer arrives, otherwise UNKNOWN/not promised (source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) |
Row 4 — Property playbook pair (scenario + lookup)
| Dimension | Detail |
|---|
| Purpose | The generalized property surface: a property record is associated to a set of event handlers managed by flow/protocol engines, sourcing events from the criteria fabric (source: AGENTS.md — declarative playbook directive) |
| Inputs/events | Property entity-state deltas on the criteria family; exact headless subjects for this pair beyond the property entity-state family: UNKNOWN in the read set — do not invent subjects (source: Jijibora Architecture — Design Thesis in Developer Terms) |
| Evaluation chain | Same honesty spine: criteria evaluation → standard fired notice with causation inherited; bounded depth; terminal-only actuation. Configuration is pushed down the hierarchy — endpoints consume config, they do not hardcode behaviour (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md; source: AGENTS.md) |
| Actuation surfaces | Terminal handler commands only. Non-terminal stages emit criteria only (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json) |
| Guard rails (what blocks it) | Child cannot widen parent ceiling; workflow/scenario content must not be hardcoded as static arrays or mock state — it must load declaratively from the scenarios bucket (source: D-03 — Jijibora Playbook Designs (developer); source: AGENTS.md) |
| Evidence left behind | Fired notice with causation inherited; evaluation depth and ceiling refusals are observable. Exact receipt shape for this pair: UNKNOWN |
| Versioning (how it evolves) | Never edit in place. Version by design version + pipeline identity + fragment lineage; a new property kind is a new themed registration + fragment + vocabulary (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md) |
| Soft vs LIVE | Soft: outbox + allowlisted subject, zero live writes. LIVE: JetStream + ceiling + real probes (source: D-05 — Starter Packs for Developers) |
Row 5 — Standing orders + breach watcher (scenario + lookup + breach rule)
| Dimension | Detail |
|---|
| Purpose | Standing orders recur on their own clock: a watched state crossing a limit fires a pre-agreed checklist without re-typing. Hot path is observe → evaluate breach per affected order → emit breach assessment → fire only when breached and not in cooldown; recovery sweep exists only as recovery (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: D-04 — Environmental Playbooks (developer)) |
| Inputs/events | Normalized inventory/entity state change; predicate is the order's breach criterion. Reference shape consumes platform.criteria.v1.inventory.state (entity_type = inventory, event_type = state_changed) (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: D-06 — Governance Rules Architecture and Event Contracts) |
| Evaluation chain | Per-affected-order breach evaluation; emits platform.criteria.v1.standing_order.breach_evaluated then, on breach within cooldown, a fire command platform.standing_orders.v1.fire; state key template claim:standing_order:{standing_order_id} — authoritative watcher/cooldown state lives on the standing-order claim record (source: D-06 — Governance Rules Architecture and Event Contracts) |
| Actuation surfaces | Fire commands handled by a projection + command handler updating the order record idempotently; escalation handling owns tickets, notifications, proof (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md) |
| Guard rails (what blocks it) | Breach requires both a true criterion result and an inactive cooldown; duplicate/past-cooldown firings suppressed; child cannot widen parent promise; missing sorting checks or viewer evidence refused rather than guessed (source: D-06 — Governance Rules Architecture and Event Contracts; source: S-03 — Jijibora Playbook Registry (stakeholder + developer)) |
| Evidence left behind | Breach assessment + fire command, each a causal record sharing the correlation identifier; completion seals the milestone before any money moves. Exact calendar cadence values: UNKNOWN (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)) |
| Versioning (how it evolves) | Never edit in place. Version by design version + pipeline identity + fragment lineage. Re-apply: new order checklist is a new lookup value + scenario binding, never new code (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md) |
| Soft vs LIVE | Soft: breach assessment written to outbox only, no live fire. LIVE: JetStream + ceiling; overdue/penalty escalation cadence remains UNKNOWN until declared per pack via lookup (source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) |
Row 6 — Multi-source fill solver (fill rule)
| Dimension | Detail |
|---|
| Purpose | A buyer who needs a quantity (e.g. 100 kg across farms) gets a feasible allocation plan after a real shortlist, not a hand-rolled spreadsheet (source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json; source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) |
| Inputs/events | platform.criteria.v1.match.fired filtered by pipeline stage continuous_match (source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json) |
| Evaluation chain | kind: solver, capability procurement.multi_source_fill@1, contract decision-request-v1, min_score: 0.8, objective min_suppliers_then_score; optional routing stage thereafter (source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json; source: D-09 — Optimization Capability (developer)) |
| Actuation surfaces | Fill plan is the terminal outcome; reserve/award consumes the plan downstream. The optimizer never emits an approval, award, or settlement — it only proposes (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md; source: D-09 — Optimization Capability (developer)) |
| Guard rails (what blocks it) | Solver only after a real match; shortlist with score below the emit floor never reaches the solver; stale entitlement/presence/supply snapshots refuse before invoke; allocation engine down → 503 invent_refuse, no synthetic OPTIMAL (source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json; source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md; source: D-09 — Optimization Capability (developer)) |
| Evidence left behind | sourcing.fill_plan (allocations + unmet_qty + decision record with bound/gap, checker verdict, and provenance) or explicit sourcing.fill_infeasible — never a silent award (source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json; source: docs/schemas/decision-contract-v1.md) |
| Versioning (how it evolves) | Never edit in place. promotion.status: designed, soft_soft_ne_live: true. Re-apply: new solver pack is a new versioned pack file + thresholds via lookup, never hardcoded supplier lists (source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json) |
| Soft vs LIVE | Soft: allocation computed against the real engine but written only to the outbox; engine-down in Soft refuses honestly (an honest 503 passes the Soft gate). LIVE: SOURCING_SOLVER_LIVE=1 + JetStream + ceiling + real gateway probes; env flags alone never satisfy live_gate_met (source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json; source: Honesty Invariants) |
Row 7 — Criteria pipeline SLA (window rule)
| Dimension | Detail |
|---|
| Purpose | Qualified work must be acknowledged in time; silence is a breach, not an assumption. Event-time windows escalate to a handler that owns tickets, notifications, and proof (source: docs/event-sourcing/rules/criteria-pipeline-sla.example.json; source: D-03 — Jijibora Playbook Designs (developer)) |
| Inputs/events | Two inputs: qualified + acknowledgement. Headless subject names for this window: UNKNOWN beyond the criteria family — do not invent subjects (source: docs/event-sourcing/rules/criteria-pipeline-sla.example.json) |
| Evaluation chain | kind: window, event-time, on_missing: breach. Stream job emits criteria + command only; the escalation handler owns the response (source: docs/event-sourcing/rules/criteria-pipeline-sla.example.json) |
| Actuation surfaces | Escalation handler is the terminal owner (tickets / notifications / proof). The stream job never drafts a customer-facing notice on its own (source: docs/event-sourcing/rules/criteria-pipeline-sla.example.json) |
| Guard rails (what blocks it) | Non-terminal stages never issue commands; timers are out for this class — the stream job is the evaluator; missing acknowledgement escalates rather than self-clearing (source: D-03 — Jijibora Playbook Designs (developer)) |
| Evidence left behind | Breach evaluation + escalation receipt. Exact breach subject wording for this rule: UNKNOWN in the read set beyond the window shape |
| Versioning (how it evolves) | Never edit in place. New SLA windows are new declarations (window + ack subjects + handler binding); thresholds change declaratively (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md) |
| Soft vs LIVE | Soft: breach evaluation to outbox only, no live escalation. LIVE: JetStream + ceiling; exact timer/backoff values must be declared per pack via lookup, not hardcoded (source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) |
Row 8 — Lifelong facet notify (entity-state rule)
| Dimension | Detail |
|---|
| Purpose | Enduring entities (building, vehicle, person, resource) accumulate claim history through one identity; scrubbed facets are the only thing that matches. Sensing notifies; a human approves (source: D-06 — Ontology Pack for Developers; source: S-03 — Jijibora Playbook Registry (stakeholder + developer)) |
| Inputs/events | platform.criteria.v1.entity_state (entity_type: lifelong_entity, meta.domain: lifelong), keyed by entity_id; facets only — entity, graph, and lifecycle facets (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json; source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md) |
| Evaluation chain | Tier-2 stream join (lifelong-facet-match job) for continuous facet matching; lifecycle normalization retained while evaluation retires to the stream job behind a cutover flag when patched off; volume gate decides promotion to avoid two live evaluators (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json) |
| Actuation surfaces | Non-terminal notify. Downstream pipeline stages (sourcing, standing-order) consume the fired notice; terminal handlers still own commands (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json) |
| Guard rails (what blocks it) | Indexability scrub required before matching — raw metadata in a facet refuses; never auto-approved; no second runner; advisory hooks stay advisory and optional (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json; source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) |
| Evidence left behind | lifelong.entity.facet.matched fired notice with causation inherited. Per-message delivery receipt shape: UNKNOWN (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json) |
| Versioning (how it evolves) | Never edit in place. Version 1.1.0, promotion.status: promoted (2026-10-28). Re-apply strategy: cutover retires the older evaluator when the new one is attested — never two live evaluators on the same facet stream (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json) |
| Soft vs LIVE | Soft: facet match to outbox only. LIVE: JetStream + ceiling; the cutover flag moving to the stream job is the LIVE gate for this family (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json) |
Row 9 — Truth-graph state (state rule)
| Dimension | Detail |
|---|
| Purpose | Graph-state changes become criteria events the spine can react to, keeping the navigable place graph and the event fabric consistent without a second sync path (source: docs/event-sourcing/rules/truth-graph-state-rule.example.json; source: Jijibora Architecture — Design Thesis in Developer Terms) |
| Inputs/events | Graph-state deltas on the criteria family. Exact input subjects: UNKNOWN in the read set beyond the state-rule shape — do not invent subjects |
| Evaluation chain | Criteria evaluation keyed by tenant + entity; each stage mints a new event identity with causation pointing upstream (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md; source: D-03 — Jijibora Playbook Designs (developer)) |
| Actuation surfaces | Emit only. Terminal registration/update of the graph record is owned by the graph planes, not by this rule (source: Jijibora Architecture — Design Thesis in Developer Terms) |
| Guard rails (what blocks it) | Canonical envelope only; no direct publish outside the outbox anchor; traversal/lease gating is owned by the graph planes — this rule does not bypass them (source: Jijibora Architecture — Design Thesis in Developer Terms) |
| Evidence left behind | Fired notice with causation inherited. Exact event-type wording for this rule: UNKNOWN in the read set |
| Versioning (how it evolves) | Never edit in place. New graph surfaces are new rule declarations + pipeline identities + lookup values |
| Soft vs LIVE | Soft: outbox + allowlisted subject only. LIVE: JetStream + ceiling |
Row 10 — Governance threshold values (claims threshold lookup)
| Dimension | Detail |
|---|
| Purpose | Approval expectations as data: swapping a threshold group changes quorum rules with zero code change (source: datasets/lookups/lookup.claims.threshold.v1.json) |
| Inputs/events | Referenced from transition-policy stages by config.threshold_ref; resolved against per-type quorum bands (source: datasets/lookups/lookup.claims.threshold.v1.json) |
| Evaluation chain | Amount-by-risk band selection picks the quorum: higher amount/risk selects the two-person or three-person band and widens the approver role set (source: datasets/lookups/lookup.claims.threshold.v1.json; source: D-06 — Governance Rules Architecture and Event Contracts) |
| Actuation surfaces | None directly. The guarded runner consumes the resolved band when evaluating a transition; the values never actuate (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| Guard rails (what blocks it) | Unknown claim type, missing value reference, or unmatched band refuses rather than inventing a threshold. The resolver never defaults (source: datasets/lookups/lookup.claims.threshold.v1.json) |
| Evidence left behind | Guarded-transition receipt carrying the band that decided the verdict (step, actor, guard verdict) (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| Versioning (how it evolves) | Never edit in place. New bands are new lookup revisions; rollback is a new change set under dual control, never a silent undo. Re-apply: re-pin the previously approved configuration values (source: D-06 — Governance Rules Architecture and Event Contracts; source: D-05 — Starter Packs for Developers) |
| Soft vs LIVE | Soft: dry-run guard verdicts with no mutation; fixture metrics excluded by default (metadata.fixture=true). LIVE: same values enforced on the JetStream path with the ceiling; a pack cannot declare itself live (source: D-17 — Backlog Validation (platform-map recommendations); source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) |
Row 11 — Governance evidence values (claims evidence lookup)
| Dimension | Detail |
|---|
| Purpose | Evidence expectations as data per claim type and stage (source: datasets/lookups/lookup.claims.evidence.v1.json) |
| Inputs/events | Referenced by config.evidence_ref; consumed at the evidence stage of the guarded runner (source: datasets/lookups/lookup.claims.evidence.v1.json) |
| Evaluation chain | Evidence stage runs after gate/quorum/separation in the ordered guard evaluation; property inspection requires an assessment note plus a photo reference, and litigation-grade property inspections add the authority inspection reference (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: datasets/lookups/lookup.claims.evidence.v1.json) |
| Actuation surfaces | None directly. The runner refuses or advances; evidence values never send anything (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| Guard rails (what blocks it) | Missing required field reference refuses the transition — never completed with defaults (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: datasets/lookups/lookup.claims.evidence.v1.json) |
| Evidence left behind | Evidence seal + exportable evidence checklist on the canonical claim and its receipts (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| Versioning (how it evolves) | Never edit in place. New evidence demands are new lookup revisions; changing which types demand which fields needs no code change (source: datasets/lookups/lookup.claims.evidence.v1.json) |
| Soft vs LIVE | Soft: plan-only check that the checklist is satisfiable, zero writes. LIVE: enforced on the guarded transition path. Missing evidence → refuse in both modes (source: D-05 — Starter Packs for Developers) |
Row 12 — Governance separation values (claims separation lookup)
| Dimension | Detail |
|---|
| Purpose | Separation-of-duties expectations as data: who may not approve what (source: datasets/lookups/lookup.claims.sod.v1.json) |
| Inputs/events | Referenced by config.rule; evaluated at the separation stage (source: datasets/lookups/lookup.claims.sod.v1.json) |
| Evaluation chain | Separation runs after quorum: creator-approval is forbidden on property/insurance/government lines; community lines use the lenient form (source: datasets/lookups/lookup.claims.sod.v1.json; source: D-06 — Governance Rules Architecture and Event Contracts) |
| Actuation surfaces | None directly (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| Guard rails (what blocks it) | The mover being the creator on forbidden types, or a declared barred pair co-approving, refuses. The resolver cannot approve its own close (source: datasets/lookups/lookup.claims.sod.v1.json; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) |
| Evidence left behind | Guarded-transition receipt carrying the separation verdict (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| Versioning (how it evolves) | Never edit in place. New separation rules are new lookup revisions; tightness changes propagate by re-seeding KV and re-pinning, not by code branches (source: D-06 — Ontology Pack for Developers) |
| Soft vs LIVE | Soft: dry-run separation verdict, zero writes. LIVE: enforced on the transition path; cross-agency quorum (benefit/compensation) adds the second-agency condition on top (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) |
Row 13 — Transition policy values (claims transition-policy lookup)
| Dimension | Detail |
|---|
| Purpose | The transition-policy document that binds threshold/evidence/separation into the guarded lifecycle stages and the scenario pack the orchestration engines execute (source: docs/commercialization/playbooks/dictionary.v1.json; source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| Inputs/events | Bound by the pack entry: lookup keys + scenario pack + governed claim/entity types + consumer wiring (emits/consumes/routes/ceiling) (source: docs/commercialization/playbooks/dictionary.v1.json) |
| Evaluation chain | Data plane enforces the eight-state lifecycle (draft → submitted/cancelled; submitted → validation/rejected/cancelled; validation → approved/rejected/disputed; approved → settled/disputed; rejected → disputed/cancelled; disputed → validation/cancelled) with guarded stages in order; finalisation accepts only approved/settled/rejected claims and requires an execution session (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| Actuation surfaces | Transition + finalise paths via the outbox (never direct publish). Intake triggers the external gate by publishing to the intake route and consuming the gate response route (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: docs/commercialization/playbooks/dictionary.v1.json) |
| Guard rails (what blocks it) | Missing verdict blocks; unattested provider refuses; unattested close refuses; the runtime fails closed when a required value is absent from the KV lookups bucket (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: docs/commercialization/playbooks/dictionary.v1.json) |
| Evidence left behind | Guarded-transition receipt, quorum chain, evidence seal, audit export (benefit); decision pack + approval receipt (compensation); service-level timeout records a breach + re-dispatch with no verdict invented (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: docs/commercialization/playbooks/dictionary.v1.json) |
| Versioning (how it evolves) | Never edit in place. Claims spec version + interface contract version are recorded against the pack; readiness (infra_ready vs rollout_enabled, default off) is environment-gated, not a code branch (source: D-17 — Backlog Validation (platform-map recommendations); source: D-03 — Jijibora Playbook Designs (developer)) |
| Soft vs LIVE | Soft: zero-write practice check (dry-run guard verdicts, fixture exclusion by default). LIVE (rollout_enabled): JetStream + ceiling + real probes; service-level timeouts record breach honestly in both modes (source: D-03 — Jijibora Playbook Designs (developer); source: D-17 — Backlog Validation (platform-map recommendations)) |
| Dimension | Detail |
|---|
| Purpose | Day-one entry: maintenance desk (WhatsApp/USSD intake classified, nearest certified vendor proposed, one-tap manager approval, photo + location verification, escrow released only on proof) plus financial desk (dues/fines/charges/payables ledger, scheduled reminders/collection, monthly statement + dashboard). Emergency command, full orchestration, and clinical features are explicitly out (source: docs/commercialization/playbooks/dictionary.v1.json; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md) |
| Inputs/events | Declared intents (plumbing, electrical, security, facilities) + location + urgency + photo extraction; dues emits on the dues signal; consumes the commerce invoice/payment events (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md; source: docs/commercialization/playbooks/dictionary.v1.json) |
| Evaluation chain | Assistant classifies → truth graph bylaws/assets/credentials → optimizer proposes assignment → decision gate (human approves) → flow/protocol actuates → proof receipt seals the loop. Advisory hooks are tracking-only; the core path works with hooks empty (source: docs/jijibora-gtm/04_AI_DRIVEN_INTERFACE_AND_ORCHESTRATION.md; source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) |
| Actuation surfaces | Work-order emit, dues signal, subscription/entitlement/billing-usage, split settled, wallet credit (source: docs/commercialization/playbooks/dictionary.v1.json) |
| Guard rails (what blocks it) | Work-order create permission + scope membership; resolver cannot approve own close; missing triage evidence refuses; split must sum exactly to the whole with two-person approval; AI never auto-approves or auto-pays; board approves what the assistant proposes (source: docs/commercialization/playbooks/dictionary.v1.json; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md) |
| Evidence left behind | Work-order outbox row; PoCE receipt sealing the milestone; escrow release only on proof (photo + location + sign-off); monthly statement (source: docs/commercialization/playbooks/dictionary.v1.json; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md) |
| Versioning (how it evolves) | Never edit in place. Pack maturity soft_shipped. Re-apply: new intents/approval gates/evidence gates/payout gates are declared as refused-by-default gates in the pack + lookup, not as comments or code branches (source: docs/commercialization/playbooks/dictionary.v1.json; source: D-05 — Starter Packs for Developers) |
| Soft vs LIVE | Soft = COLD: validation + plan with zero live writes (soft_billing_ne_live_paid, fail_closed_soft_ne_live); Soft acceptance suite (ticket end-to-end, outbox row for the work-order emit, billing-adapter Soft binding check; honest refusal rather than a synthetic answer when a downstream service is down) (source: D-05 — Starter Packs for Developers; source: docs/commercialization/playbooks/dictionary.v1.json). LIVE: JetStream + ceiling + real probes; real money movement stays gated until finance keys, a human approver, and the payments ledger are ready (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) |
Row 15 — Cross-cutting bindings: envelope + walks + dictionary + monetization
| Dimension | Detail |
|---|
| Purpose | The wiring that makes the other 14 rows one system: the canonical envelope + outbox anchor (how every fragment talks), the walk rows (how every playbook proves itself), the dictionary bindings (how a pack declares its subjects/routes/ceiling), and the monetization lookups (how a cohort is targeted and a split settles) (source: Jijibora Architecture — Design Thesis in Developer Terms; source: docs/commercialization/playbooks/dictionary.v1.json; source: datasets/lookups/lookup.finmon.cohort_billing.v1.json) |
| Inputs/events | Envelope on platform.criteria.v1.* subjects; dictionary emits/consumes/camel_routes/kestra/enrichment/security_bound + SKU monetization ref (offer package, subscription plan, entitlement policy, billing adapter binding, split profile, creator fee) (source: Jijibora Architecture — Design Thesis in Developer Terms; source: docs/commercialization/playbooks/dictionary.v1.json) |
| Evaluation chain | Fragments merge by hierarchy and quorum rules, are overridden by ceiling policy, materialise as declarative configuration in the KV planes, are executed by the workflow/protocol engines, then are sealed with a proof receipt, a federation event, and the transactional outbox before any evidence export (source: Architecture — Design Thesis and Planes (Developer Concept Doc)) |
| Actuation surfaces | The relay publishes outbox rows to the core bus; consumers consume typed subjects; terminal handlers actuate. Cohort targeting pins an offer identifier without inventing an invoice and never decides amounts (source: Jijibora Features → Interfaces Map; source: datasets/lookups/lookup.finmon.cohort_billing.v1.json) |
| Guard rails (what blocks it) | Wider child → refusal (ceiling); legacy bare payloads without the envelope refuse; allowlist-external subject for a ghost identity produces no receipt; billing never invents an invoice; a split that does not sum exactly to the whole refuses; heterogeneous-currency settles refuse with a clear error rather than converting (source: docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md; source: docs/commercialization/playbooks/dictionary.v1.json; source: datasets/lookups/lookup.finmon.revenue_split_profile.v1.json) |
| Evidence left behind | Outbox row per emit (digest-pinned soft. key with invent_refuse_live: true, live_gate_met: false in Soft); consumed receipt per walk; quorum receipt chains; billing-usage and split-settled signals carrying identifiers + amount/rate only (money events never carry claim payloads and never advance a claim) (source: docs/commercialization/playbooks/dictionary.v1.json; source: D-06 — FINMON: Money Side — Billing, Desks, and Proof of Value) |
| Versioning (how it evolves) | Never edit in place. Envelope and dictionary are versioned contracts; cohort billing is an allowlist of four offer-package ids today — adding a fifth is a lookup change, not a schema change, but it must still pass the digest pin before it takes effect. Re-apply: re-pin the previously approved configuration values; rollback rehearsed by re-pinning (source: datasets/lookups/lookup.finmon.cohort_billing.v1.json; source: D-05 — Starter Packs for Developers) |
| Soft vs LIVE | Soft: validation + plan, writes 0; outbox row written for the pack emit; live_gate_met: false. LIVE: ceiling enforced + digest pin matches + real probes green; env flags alone never satisfy live_gate_met. Money movement gated as in Row 14 (source: D-05 — Starter Packs for Developers; source: Honesty Invariants) |
Coverage check: 3 + 4 + 3 + 2 + 3 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 2 + 4 = 29 fragments across 15 rows (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: D-03 — Jijibora Playbook Designs (developer)).
5. The five-level lifecycle to register a new playbook
| Level | Action | Gate that must pass |
|---|
| 1. Author | Copy the rule shape exactly (rule identity, runtime tier/chain, pipeline identity/stage, subject inputs + filters, evaluation kind + keying, outputs, terminal-only side effects). Reuse the spine — consume platform.criteria.v1.*, emit platform.criteria.v1.match.fired (or the pack's allowlisted subject) with inherit_causation: true. Never invent a second bus or envelope (source: D-03 — Jijibora Playbook Designs (developer); source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) | Dictionary schema validation passes; pack binds all five things (lookup keys, scenario pack, governed types, consumer wiring, SKU monetization ref) (source: docs/commercialization/playbooks/dictionary.v1.json) |
| 2. Declare values | Write thresholds/evidence/separation as declarative lookup groups + declare every lookup with canonical_subject, canonical_event_type, pipeline_id; bind the scenario pack the orchestration engines execute and the claim/entity types the pack operates on (source: D-06 — Governance Rules Architecture and Event Contracts; source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md) | Every referenced value resolves; a missing value fails closed rather than falling back to an invented default; child scopes inherit but only tighten; AI-hook allowlists start off-by-default (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: D-05 — Starter Packs for Developers) |
| 3. Guard-check dry run | Run the dry-run, plan-only validation across each guard stage (gate → quorum → separation → evidence → execution proof → external verdict) without mutation; confirm the wrapped refusal path for each guard (missing evidence, barred creator, under-threshold quorum, stale spatial binding); confirm the negative case (allowlist-external subject for a ghost identity produces no receipt) (source: D-06 — Governance Rules Architecture and Event Contracts; source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) | Zero writes during dry run; every refusal is a typed refusal, never a synthetic pass (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) |
| 4. Soft-apply validation | Soft apply validates and plans: digest pin checked, references resolved, outbox row written for the pack emit, Soft acceptance tests pass (ticket end-to-end, outbox row for the work-order emit, billing-adapter Soft binding check, honest refusal when a downstream service is down); Soft pin writes the soft. key with invent_refuse_live: true and live_gate_met: false (source: D-05 — Starter Packs for Developers; source: docs/commercialization/playbooks/dictionary.v1.json) | Writes 0 live. A Soft apply that writes anything live is a failure. If an external service is down in Soft, refuse honestly — an honest 503 counts as a pass (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md; source: D-05 — Starter Packs for Developers) |
| 5. Live enablement gates | Flip to LIVE only when the live path's real checks pass: the ceiling is enforced, the digest pin matches, and each LIVE probe reports genuinely green. Real money movement additionally needs finance keys, a human approver, and the payments ledger. A pack never declares itself live (source: D-05 — Starter Packs for Developers; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back) | Rollback rehearsed by re-pinning the previously approved configuration values before enablement. Env flags alone never satisfy live_gate_met (source: D-05 — Starter Packs for Developers; source: Honesty Invariants) |
Authoring checklist (start from the community starter template, then declare the new pack in the dictionary): intents declared; approval/evidence/payout gates refused-by-default; service-level clocks, amount/risk bands, and add-on eligibility lookup-composed; AI-hook allowlists off-by-default with the core path working with hooks empty; pack fully bound (lookup keys + scenario + governed types + consumer wiring + SKU monetization ref consistent); separation + anti-self-approval wired; Soft-first proof attached with rollback rehearsed and the LIVE gate still reporting dark; no schema change smuggled in (new behaviour is themed registration entries + interface catalog + manifest + fragments + vocabulary + KV lookups only). (source: D-05 — Starter Packs for Developers)
TODO/FIXME/TBD/UNKNOWN register for builders (design with these in mind, do not assume them live): canonical_subject/canonical_event_type/pipeline_id declarations on pack lookups (ESP-02); generalized ontology normalizer (ESP-03); Soft ceiling assert (ESP-04); per-pack stream-promotion candidates (ESP-11); hierarchy-aligned access (ESP-08); typed client catalog (ESP-10); test-track enforcement meta.is_test (ESP-13); claims finance gates (timestamp authority, public-safety answering point, billing-adapter production migration) — live money stays Soft until an external party arrives (source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md; source: D-17 — Backlog Validation (platform-map recommendations); source: D-03 — Jijibora Playbook Designs (developer))
6. Source groundedness page
| Family (row) | Repo anchors — docs sources | Rule / scenario / lookup identities |
|---|
| Row 1 — Building reflex | Registry + designs + environmental playbooks (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: D-03 — Jijibora Playbook Designs (developer); source: D-04 — Environmental Playbooks (developer)) + architecture (source: Jijibora Architecture — Design Thesis in Developer Terms) | rule:jijibora:building-reflex:v1, v1.0.0, pipeline pipe:jijibora:building-reflex (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json); scenario + lookup conventions datasets/scenarios/scenario.jijibora.building.reflex.v1.json, datasets/lookups/lookup.jijibora.building.reflex.v1.json |
| Row 2 — Community sourcing | Registry + designs + optimization capability (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: D-03 — Jijibora Playbook Designs (developer); source: D-09 — Optimization Capability (developer)) + government trial narrative (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md) | rule:jijibora:community-sourcing:v1, v1.0.0, pipeline pipe:sourcing:qualify-to-shortlist; continuous-match join min_score: 0.8 (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json; source: docs/event-sourcing/rules/sourcing-continuous-match-rule.example.json); scenario + lookup scenario.jijibora.community.sourcing.v1, lookup.jijibora.community.sourcing.v1 |
| Row 3 — MARS/ICE dispatch | Registry + designs + environmental playbooks (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: D-03 — Jijibora Playbook Designs (developer)) + starter deferral (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md) | rule:jijibora:mars-ice-dispatch:v1, v1.0.0, pipeline pipe:jijibora:mars-ice-dispatch (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json); scenario + lookup scenario.jijibora.mars.ice.v1, lookup.jijibora.mars.ice.v1 |
| Row 4 — Property playbook | Architecture + declarative directive (source: Jijibora Architecture — Design Thesis in Developer Terms; source: AGENTS.md) | Scenario + lookup scenario.jijibora.property.playbook.v1, lookup.jijibora.property.playbook.v1 |
| Row 5 — Standing orders + breach | Environmental playbooks + governance rules (source: D-04 — Environmental Playbooks (developer); source: D-06 — Governance Rules Architecture and Event Contracts) | rule:standing_order:breach:inventory:v1 (source: docs/event-sourcing/rules/standing-order-breach-rule.example.json); scenario + lookup scenario.jijibora.property.standing_orders.v1, lookup.jijibora.property.standing_orders.v1 |
| Row 6 — Multi-source fill | Designs + optimization capability (source: D-03 — Jijibora Playbook Designs (developer); source: D-09 — Optimization Capability (developer)) | procurement.multi_source_fill@1, contract decision-request-v1, min_score: 0.8 (source: docs/event-sourcing/rules/sourcing-multi-source-fill-rule.example.json); decision contract (source: docs/schemas/decision-contract-v1.md) |
| Row 7 — Pipeline SLA | Designs pattern library (source: D-03 — Jijibora Playbook Designs (developer)) | Window shape kind: window, on_missing: breach (source: docs/event-sourcing/rules/criteria-pipeline-sla.example.json) |
| Row 8 — Lifelong facet notify | Designs + ontology pack (source: D-03 — Jijibora Playbook Designs (developer); source: D-06 — Ontology Pack for Developers) | Lifelong rule v1.1.0, lifelong-facet-match job (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json) |
| Row 9 — Truth-graph state | Architecture (source: Jijibora Architecture — Design Thesis in Developer Terms) | State-rule shape (source: docs/event-sourcing/rules/truth-graph-state-rule.example.json) |
| Row 10 — Threshold values | Claims plane + governance rules (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: D-06 — Governance Rules Architecture and Event Contracts) | lookup.claims.threshold.v1 (source: datasets/lookups/lookup.claims.threshold.v1.json) |
| Row 11 — Evidence values | Claims plane (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) | lookup.claims.evidence.v1 (source: datasets/lookups/lookup.claims.evidence.v1.json) |
| Row 12 — Separation values | Claims plane (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs) | lookup.claims.sod.v1 (source: datasets/lookups/lookup.claims.sod.v1.json) |
| Row 13 — Transition policy | Claims plane + starter packs + validation (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs; source: D-05 — Starter Packs for Developers; source: D-17 — Backlog Validation (platform-map recommendations)) | lookup.claims.transition_policy.v1 + claims scenario packs + cns://claim/type/insurance/motor_claim + cns://claim/type/entity/vehicle (source: docs/commercialization/playbooks/dictionary.v1.json) |
| Row 14 — Community starter | Starter packs + bundles + entry point (source: D-05 — Starter Packs for Developers; source: D-07 — Starter Bundles for Developers; source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md) | Pack pack.jamii.community.starter.v1, scenario scenario.jijibora.community.starter.v1, lookup lookup.jijibora.community.starter.v1; flow kestra.jijibora.community.starter_dispatch.yaml (source: docs/commercialization/playbooks/dictionary.v1.json) |
| Row 15 — Envelope + walks + dictionary + monetization | Architecture + data fabric + features/interfaces (source: Jijibora Architecture — Design Thesis in Developer Terms; source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc); source: Jijibora Features → Interfaces Map) + commercial dictionary (source: docs/commercialization/playbooks/dictionary.v1.json) | Envelope on platform.criteria.v1.*; 3 worked walks: create claim, guard, revive/consume (source: Jijibora Features → Interfaces Map); cohort billing allowlist of four offer ids incl. offer_package.jamii.starter.v1, offer_package.materra.amcos.pilot.v1, offer_package.bundle.estate_safe.v1, offer_package.claims.orchestration.pilot.v1 (source: datasets/lookups/lookup.finmon.cohort_billing.v1.json); split profile revenue_split_profile.claims.orchestration.v1 (source: datasets/lookups/lookup.finmon.revenue_split_profile.v1.json) |
Honesty register — where sources do not show headless wiring (do not invent): exact headless subjects for government benefit/compensation packs, audit-file assembly, citizen notifications, industrial/local-content gate, waste route/stop, weather-prep, proximity, and civic-maintenance stages are UNKNOWN in the read set; exact receipt shapes beyond the fired notices above are UNKNOWN; exact re-optimization timers, tariffs, fine schedules, store-of-record projections beyond the canonical primitives, naming-broadcast subject wording, merge semantics between entities, and committee charters for naming approval are UNKNOWN. (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: D-03 — Jijibora Playbook Designs (developer); source: D-04 — Environmental Playbooks (developer); source: D-06 — Ontology Pack for Developers)
7. Built-in safety invariants (apply to every fragment, on every run)
| Invariant | Consequence for builders |
|---|
| Zero bespoke tables | All domain entities map into the canonical primitives (claim record, truth node/edge, resource record, universal integration ledger). If an entity cannot be mapped, STOP AND ASK — never create new tables. A new community is new themed registration entries + interface catalog + manifest + fragments + vocabulary, zero schema changes (source: docs/jijibora-gtm/02_PRODUCT_STRATIFICATION.md; source: AGENTS.md) |
| Alias/mint for entities | Entities enter through deterministic universal naming + a mint path, with no domain-specific extension fields ever added. Alias resolution keeps one identity across many mentions; history is append-only and a finalised entity is read-only — correct by adding a new record that references the old one, never by editing in place (source: Architecture — Design Thesis and Planes (Developer Concept Doc); source: D-06 — Ontology Pack for Developers) |
| Idempotent candidates | Watcher/fire, guard transitions, and replan deliveries are idempotent (cooldown-suppressed re-fires, compare-and-swap under dual control, causation-preserving replans that displace rather than silently delete). Report/fine/reschedule paths never duplicate a stop or a fire silently (source: D-06 — Governance Rules Architecture and Event Contracts; source: D-09 — Optimization Capability (developer); source: D-06 — FINMON: Money Side — Billing, Desks, and Proof of Value) |
| No AI-approval on its own | AI is a compiler and narrator, never an authority. Advisory suggestions carry no decision authority; hooks are tracking-only and optional; the core path works with hooks empty; no second runner; never auto-approved, no autonomous award/payout; five governance hops (eligible set, scope pre-retrieval, decision gates, break-glass, cost reconciliation) keep a named human as decider (source: docs/jijibora-gtm/04_AI_DRIVEN_INTERFACE_AND_ORCHESTRATION.md; source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md; source: S-03 — Jijibora Playbook Registry (stakeholder + developer)) |
| No settlement from optimizers | The optimizer proposes; a named human or governed terminal handler disposes. Allocation engines emit fill/route plans with decision records, provenance, and checker verdicts — never approvals, awards, or settlements. A recommendation never becomes a receipt until evidence (photo/location/inspector or governed proof) closes the loop; verified escrow is "no sign-off, no payout" (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md; source: D-09 — Optimization Capability (developer); source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md) |