A-06 — Management Plane for Administrators
Scope: Day-to-day operation of declarative civic rules and their clocks — what a rule is at runtime, how it moves from draft to retirement, how to pause a series or a rule family without editing recorded data, how to tell the system is healthy from the console, and how SOS governance is declared, expired, and audited. (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md)
Status: as of 2026-11-09
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/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md; D-04 — Environmental Playbooks (developer); A-01 — Jijibora Deployment (Administrator Operations); A-04 — Starter Packs for Administrators; Playbook Registry — What You Can Run, Who Runs It, What You Get Back; Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc); Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs
What this means for you
A rule is not a program you deploy; it is a standing instruction the system evaluates whenever matching events arrive, and you manage it by its declared state, not by editing what already happened. Pausing is a policy change that stops future evaluation and leaves the past readable for audit. Your job is to watch delivery depth, receipts, and rule health, and to retire or pause in the open so a verifier can reconstruct every step (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md).
Details
1. What a rule IS at runtime and its lifecycle
At runtime a rule is a declared consumer: a subject filter that says which events it cares about, an evaluation chain that turns a matching event into a fired notice, and a terminal step that alone is allowed to act. The three Jijibora examples show the same shape in words: each declares a criteria subject family to listen on with a predicate on the kind of thing the event concerns, evaluates as criteria with keying by tenant plus the thing concerned, and emits a standard fired notice with causation inherited, while the terminal handler — actuate, shortlist, or dispatch — is the only place commands are issued (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). Live evaluation happens in the orchestration and protocol-translation engines while the durable store is record-only (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json). The background work is event-driven rather than polled, with a durable delivery anchor and a relay that publishes, so a rule does not decide by scanning stored rows (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)).
Lifecycle is a declared state that moves through four legible steps. Draft means the consumer is described but not evaluating — the enablement switch is off and no fired notices are produced. Published means the consumer is enabled and evaluating, on the allowlisted subject in practice posture first and under the ceiling in live posture (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md). Paused means you flip the enablement switch so the rule stops consuming; previously emitted notices remain, and no new ones are produced. Retired means the rule is withdrawn from the active set while its history stays readable. Each leg must be legible in audit: draft, publish, pause, and retire each leave a causal record sharing the voyage identity, and guarded-transition and quorum work already follows that pattern of dated steps with actor and notes (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs). The exact restore and retire workflow wording for a single rule beyond the enablement switch and versioning by rule identity — identity embeds name plus major version and a semantic version on the design — is UNKNOWN in the read set (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: D-04 — Environmental Playbooks (developer)).
Administration discipline for lifecycle: never delete a rule to pause it, and never edit the meaning of a published rule in place. A change is a new version — new identity with the next major mark, new evaluation keying or filter, new terminal handler if the actuation changes — while the old version is paused or retired in the open. Homes whose pack stays practice-only are validated with zero live writes before anything live, and a pack cannot declare itself live (source: A-04 — Starter Packs for Administrators; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back). Changes flow through pinning the previously approved configuration values on revert rather than redeploying (source: A-04 — Starter Packs for Administrators).
2. Tick and scheduler management
Standing orders are the clocks that recur on their own: a watched state that crosses a limit fires a pre-agreed checklist without re-typing, and civic maintenance uses that recurrence as its heartbeat (source: D-04 — Environmental Playbooks (developer); source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). The calendar or cadence is policy, not data: it is a declared value in the pack that says how often to check, how long to wait before escalating, and when the order goes quiet again. Meter-clock windows in the claims plane follow the same idea — windows are values by kind and severity that bind to the workflow flow, so you change the window without changing code (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs). Treat the cadence the same way: a new cadence is a new policy value with its own version lineage, not an edit to a recorded firing.
To pause a series without editing recorded data, you pause the policy that drives it. Stop the enablement for the orders in that series, or move its cadence to a state the evaluation recognises as quiet, and let the existing firings stand as history. The next tick then evaluates as not-breached or not-active and emits nothing new. Do not rewrite the firings, do not delete the orders, and do not hand-mark delivery as complete. Recovery sweeps are recovery only, not the normal path (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc); source: A-01 — Jijibora Deployment (Administrator Operations)). The exact calendar values for each standing-order series and the exact quiet-state wording are UNKNOWN in the read set (source: D-04 — Environmental Playbooks (developer)).
Cooling-off is part of the clock: a breach requires both a true criterion result and an inactive cooldown before it can fire, so a series that just fired will not immediately fire again even if the watched value stays past the limit (source: D-04 — Environmental Playbooks (developer)). When you resume, resume the same series identity so the cooldown and escalation history continue; do not start a duplicate series under a new name to work around cooldown.
3. The reflex kill-switch model and blast radius
Blast radius follows the family, not the single rule. A building-reflex family only senses building state changes and its terminal actuation is scoped to that building concern (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json). A community-sourcing family only qualifies and shortlists sourcing requirements and is bounded by the pre-vetted register and the solver gate before any shortlist (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json). A governance-signal dispatch family only fans out emergency incidents and is bounded by the parent scope as the ceiling (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json). Pausing a family stops that whole evaluation arc; pausing a single rule stops only that consumer.
How to pause in practice: first pause the individual rule whose fired notices look wrong, then pause its family if the whole family misbehaves, since a family pause is wider and should be rarer. A child can never widen the parent promise, and a widening composition is refused at compose time (source: Jijibora Architecture — Design Thesis in Developer Terms). The parent scope is the ceiling for emergency children, and public alerts are drawn only from scrubbed fields (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).
Expected evidence after a pause: the rule's causal trail — what it consumed, what it fired, and what its terminal handler did — remains readable; the pause itself is a dated step with actor and reason; and no new fired notices appear after the pause moment. Terminal-only commands are refused when attempted from a non-terminal stage, so a paused family that still receives events cannot actuate through a side path (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json). The exact kill-switch console wording and family-pause propagation time are UNKNOWN in the read set.
AI never holds the switch: the assistant proposes and narrates, a named human approves at the decision gate, and nothing auto-approves or auto-pays (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md). A governance override uses break-glass with dual approval, a short time-to-live, and audit, and stays bounded by that short time-to-live (source: docs/jijibora-gtm/04_AI_DRIVEN_INTERFACE_AND_ORCHESTRATION.md).
4. Capacity probes: outbox depth, consumer receipts, and rule health
Run the probes in this order from the console; on any red signal, refuse new governed traffic until fixed rather than letting the cell guess (source: A-01 — Jijibora Deployment (Administrator Operations)).
Outbox depth. The producer writes a durable anchor transactionally and a relay publishes it, each record flowing from pending through sent to delivered, or to failed and finally dead-letter with bounded retries (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)). The console line to run is the pending-depth check: count of records still awaiting publish for the subject family you care about. Healthy means the count falls to zero and stays there. If it never falls, the relay is stalled — follow the relay recovery path and never mark rows delivered by hand (source: A-01 — Jijibora Deployment (Administrator Operations)). Alert line: page when pending depth stays above zero across a full relay cadence, not on a single sample.
Consumer receipts. The consumer validates each event against the pack's declared allowlist, dispatches the guarded transition once per event, records refusals as failed delivery anchors, and never re-emits the same event (source: Data Fabric — Message Bus and Engine Interfaces (Developer Concept Doc)). The console lines to run are: how many delivered anchors versus failed anchors in the last window, and whether each transition that returned success also left its consumed receipt. Healthy means delivered anchors are present for recent transitions and failed anchors carry the guard's typed refusal. A transition that returns success but leaves no outbox row is a fault (source: A-01 — Jijibora Deployment (Administrator Operations)). Alert line: page on rising failed-anchor share or on success-without-receipt.
Rule health. For each active rule, the console line is: last fired notice age, fired-notice rate by family, and whether the terminal handler answered. Healthy means recently active rules have recent fired notices, and quiet rules are quiet because their watched events are quiet, not because their consumer is stalled. A rule whose input events are flowing but which has gone silent was paused or its ceiling withdrew the subject — check the enablement state and the ceiling before assuming the sensor is dead. Alert line: page when a rule that should fire on a known recurring watch has not fired across a full cadence window.
Readiness cross-check. Probe the claims readiness surface that reports whether the store is up and a zero check on the claims path stays dark when relay or consumer is broken; watch both health and readiness on every shift (source: A-01 — Jijibora Deployment (Administrator Operations)). Dark plus degraded means refuse new governed traffic until fixed. Production alert wiring and a status page are roadmap, not live, so do not assume a page will arrive on its own (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md).
5. SOS governance loop in operator language
Declare. An SOS is declared by raising the emergency-incident signal itself: the governance signal with the emergency kind is the declaration. The rule then fans out to named responders per the pre-approved cascade, and each forked child carries its own scope under the parent ceiling (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json). Your declaration is the signal plus the pre-approved cascade it triggers — disaster, public works, transport, and welfare each take their SOP task in seconds without a chain of meetings (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).
Expire. Declarations expire by cadence and by closure, not by editing the signal. The standing-order clock and its cooldown govern repeat firings, and the fork tree closes back to the parent as each child reports done (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: D-04 — Environmental Playbooks (developer)). To end an active declaration, close the children and let the parent fold; do not delete the signal. Drill packs never carry a production incident path and must never be reused for a real declaration (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md). The exact expire cadence values are UNKNOWN in the read set.
Dual approval. Decision gates and break-glass both require two-person approval with a full audit trail of who drafted and who co-signed and when; the change or override lands only when both have acted and the base has not moved since drafting started (source: D-06 — FINMON: Money Side — Billing, Desks, and Proof of Value). The same two-person discipline applies to money-side changes such as split profiles, where the draft moves to co-signed to landed (source: D-06 — FINMON: Money Side — Billing, Desks, and Proof of Value). For SOS, that means the commander declares, a second named approver countersigns the cascade, and the override — if one is used — carries a short time-to-live and is audited (source: docs/jijibora-gtm/04_AI_DRIVEN_INTERFACE_AND_ORCHESTRATION.md).
Audit packet assembly steps. Assemble in this order, and do not export if any piece is unverified: collect the fired dispatch notices with causation inherited; collect the emergency match receipt and the resource assignment log; collect the fork-tree receipt with child-closed notices; attach the proof-of-correct-execution receipts that seal each governed step; and attach the public-alert derivation slip showing alerts were drawn from scrubbed fields only (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json). Then export the verified photo-backed compliance packet, which the finance and audit committee can answer in two clicks (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md). Proof bridging covers governed paths that start a proof session — not every login, payment, or sensor — so do not treat a login as proof of a governed action (source: A-01 — Jijibora Deployment (Administrator Operations)).
6. Entity lifecycle stewardship
You are the steward of identities that outlive any single operation. Each enduring thing — a building, a vehicle, a person, an organisation, a resource, and by extension a parcel or a site — carries one identity from first mint to final archive, and the lifelong plane joins that identity to its history of claims so nothing is ever disconnected from its past (source: Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc); source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0). Your stewardship questions are about keeping that identity honest.
Alias dedup. Two mentions of the same thing must not become two identities. The sourced rule is that a first-notice alias resolves to the same person or vehicle and the same journey across search, evidence, and approval, so a caller using a different handle still reaches the same history (source: docs/platform-map/system/D-05-PLAYBOOK-REGISTRY.md). In practice: when intake creates an identity that already exists under another handle, resolve to the existing identity and record the new handle as an alias entry — never mint a second identity to keep the intake path simple. The exact dedup procedure and matching thresholds are UNKNOWN in the read set (source: Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc)).
Merge semantics. When two identities turn out to be one thing, merging is UNKNOWN in the read set. The sources give you alias resolution, append-only history, and the pointer that joins an entity to its claims, but they do not give you a merge operation (source: Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc); source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0). The safe stewardship posture is therefore: do not merge by hand, do not delete one side, and do not rewrite either history. Record the relationship between them, link the claims that concern either, and escalate the merge decision to the council scope that owns the ceiling. Any tool that offers a one-click merge today is inventing semantics the sources do not state — treat it as a defect.
Archive versus delete. Archive is the only end the sources sanction. An entity is minted in an active state, changed and versioned through its life, and eventually finalised, which closes its version chain and marks it archived or cancelled and read-only with no further transitions allowed (source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0). Pausing an entity is a status on that same identity, not a second identity (source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0). Delete is never the archival path: history is append-only and a finalised entity stays readable forever, so if an identity must leave the active set you archive or cancel it and leave the record. Legal hold blocks any erasure path that would remove it, and until erasure passes its gate you refuse to promise erasure at all (source: docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md).
Stewardship checks you run. Before archiving, confirm the version chain reads without gaps and the associated claims still resolve through the same identity, and confirm no governed proof session is still open against the entity — governed sessions seal the steps they governed and a finalised entity cannot take new steps (source: Lifelong Entities API (non-fungible lifespan) — OpenAPI 1.0.0; source: Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc)). Before resolving an alias, confirm the scrubbed facets still match under the indexability profile for that kind, so dedup never leaks raw metadata into a match (source: docs/event-sourcing/rules/lifelong-entity-state-rule.example.json). After either action, the audit must show the stewardship step itself — who authorised it, when, and what stayed unchanged — because a history that cannot show its own stewardship cannot be trusted (source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs).
Open items / gaps
- Rule lifecycle beyond the enablement switch: the exact draft, publish, pause, and retire transitions per rule and their console wording are UNKNOWN (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json).
- Standing-order calendar and cadence values per series are UNKNOWN (source: D-04 — Environmental Playbooks (developer)).
- Kill-switch console wording, family-pause propagation, and expiry cadence values are UNKNOWN (source: D-04 — Environmental Playbooks (developer)).
- Full alert wiring and a status page are roadmap, not live; operators run the probe lines above by hand (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md).
- Live money movement behind SOS or civic work stays gated until finance keys, a human approver, and the payments ledger are ready; no console action opens that gate (source: D-17 — Backlog Validation (platform-map recommendations)).