JJijibora Docs
docs.jijibora.online
On this page (11 sections)

A-04 — Environmental Ops (administrator)

Scope: Enablement and steady-state operations for the environmental playbook families — building reflex, community sourcing, recurring civic maintenance rounds, emergency and SOS dispatch, and civic sensing — in place of generic server operations. 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; S-03 — Jijibora Playbook Registry (stakeholder + developer); A-01 — Jijibora Deployment (Administrator Operations); A-02 — Jijibora Compliance Operations (Administrator)

What this means for you

You enable each environmental family as a named list of subscriptions, gates, and clocks rather than as code changes: turn the whole family on or off by one setting, pause a series by one setting, and watch capacity by three probes (queue depth, consumer receipt health, rule health). You fail closed on doubt — if a check below is ambiguous, you refuse the action and never substitute a synthetic success (source: A-01 — Jijibora Deployment (Administrator Operations); source: A-02 — Jijibora Compliance Operations (Administrator)).

Details

ENVIRONMENT note — the line every environmental reflex respects

These reflexes only act on entities registered in the canonical claim and turf graph — never raw device data. A sensor reading, a phone report, and a river gauge become eligible only once they are normalized to a named entity in the shared registry (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). Facets are scrubbed before they may be used; raw metadata inside a facet is refused rather than matched (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md). Raw personal names, phone numbers, and addresses are never written into event messages or receipts (source: A-02 — Jijibora Compliance Operations (Administrator)).

1. Subscribing ops for each reflex — subject family, engine, queue, durability

Subscribe each family under its own subject family — do not share one catch-all feed. This keeps capacity and refusals legible per family (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).

Building reflex. Subject family: building state — platform.criteria.v1.building.entity_state, filtered to building entities (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json). Engine: sense-reason in the flow engine with a two-step chain (first orchestration, then protocol translation); actuation only from the terminal stage (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json). Queue and durability: each reflex deposits its evidence in the durable delivery anchor before any hand-off, and the flow follows pending → sent → delivered → failed → dead-letter with bounded retries; the relay never blocks the durable write on a publish failure (source: A-01 — Jijibora Deployment (Administrator Operations); source: A-02 — Jijibora Compliance Operations (Administrator)). Durable in the plain sense: the delivery anchor outlives a brief restart of the flow engine (source: A-02 — Jijibora Compliance Operations (Administrator)).

Community sourcing. Subject family: sourcing requirement plus candidate state — requirement stream plus candidate stream (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json). Engine: qualification in the same flow chain, then an optimizer for allocation; continuous matching promotes to the stream-join job when fan-out warrants (source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json). Queue and durability: same durable anchor as above; the optimizer in an interval without a match never invents an allocation — it refuses and records an honest outcome instead (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).

SOS and emergency dispatch. Subject family: governance signal filtered to emergency incidents (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json). Engine: two-step chain (orchestration, then protocol translation) with proof-of-correct-execution bridging (source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json; source: A-02 — Jijibora Compliance Operations (Administrator)). Queue and durability: durable anchor plus a dedicated dispatch queue group enabling round-robin handling of emergency cases (source: A-01 — Jijibora Deployment (Administrator Operations)).

Civic maintenance recurring rounds and civic sensing. Subject family: inventory and entity state plus scrutified facet streams; drill packs enforce test-only handling with no production incident path (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). Engines: block/keep of breech assessment uses translation as the hot path and orchestration as recovery; sensing facets prefer the stream-join engine for continuous matching (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). Queue and durability: same durable anchor, per-subject bounded reads, so depth — not log volume — is the capacity signal (source: A-01 — Jijibora Deployment (Administrator Operations)).

Operator setup checklist per reflex: confirm the subject family is allowlisted in the ceiling, confirm the queue group for translation round-robin exists, confirm the durable anchor empties to zero after a test fire, and confirm the terminal handler receipt is produced before declaring the reflex enabled (source: A-01 — Jijibora Deployment (Administrator Operations); source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).

2. Reflex enabling gates — enabled and version discipline, disabling without a Red flag

Each family has one enabled switch and one version mark. Enable status and semantic version appear directly on the rule design; change them declaratively, never by editing stored data (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).

  • Enable switch. Set the switch true to admit the family to the flow chain; set it false to quiesce without force. Disabling by switch is the normal path — it stops admission, does not purge history, and does not count as a Red flag (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: docs/event-sourcing/rules/jijibora-mars-ice-dispatch-rule.example.json).
  • Version discipline. New versions land as a new name plus a new version mark, with the semantic version on the design (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json; source: docs/event-sourcing/rules/jijibora-community-sourcing-rule.example.json). Overwriting a live version in place is refused; a changed behaviour gets a changed version (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).
  • Soft before live. Every family lands in practice mode (Soft) before production mode (Live): Soft means outbox plus an allowlisted subject; Live means the message fabric plus a ceiling asserted; drill packs carry test-only handling (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). A pack cannot declare itself live — live cutover needs the written go-live check (source: A-01 — Jijibora Deployment (Administrator Operations); source: A-02 — Jijibora Compliance Operations (Administrator)).
  • How to disable without a Red flag. In sequence: set the enabled switch false; let the durable anchor drain (depth zero); observe that no new fires appear; record the disable in the audit narrative. Do not delete history or purge pending rows — purge of receipts and audit rows is refused (source: A-02 — Jijibora Compliance Operations (Administrator)). If you must stop immediately, suspend the translation queue group as the kill switch, then perform the same drain check (source: A-01 — Jijibora Deployment (Administrator Operations)).

UNKNOWN: the literal CLI command or config key to flip enabled at runtime is UNKNOWN in the read set — the design field is enabled, but the operator control to change it is UNKNOWN (source: docs/event-sourcing/rules/jijibora-building-reflex-rule.example.json).

3. The recurring orders clock — how standing orders fire and how to pause a series

A standing order is a pre-agreed checklist with a limit (a height, a threshold, a time window). It starts by itself when the watched state crosses the limit — river gauge, rain station, meter, or citizen phone report — and it may act faster than the council promise but may never loosen it (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). The hot path observes normalized state changes and emits a breach assessment; a sweep in orchestration is recovery only, not the daily clock (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).

How a fire is clocked. Watch state changes, evaluate each affected order against its breach criterion, record the breach assessment, and issue a fire command only when breached and not in cooldown (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). Cooldown is per-order and prevents a flap from re-firing; state behind cooldown lives on the order claim, and lifecycle events flow on the fabric (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).

How to pause a series without editing data. Pause is a setting, not an edit: set the order's active setting false (or the family's enabled switch false for a full pause) and let the durable anchor drain (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md; source: A-02 — Jijibora Compliance Operations (Administrator)). Confirmation of a pause is honest: depth zero and no new fires, not a hardcoded zero claim. A ward may act faster than the council promise, but may not secretly loosen it — a loosening request is refused at write time (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).

UNKNOWN: exact recurrence cadence values and the pause control's literal name are UNKNOWN in the read set; only the pattern — setting false, draining, and observing no new fires — is evidenced (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).

4. Capacity probe steps — delivery depth, consumer receipt health, rule health

Run all three probes per shift and per pilot go-live; dark on any probe means refuse new governed traffic until fixed (source: A-01 — Jijibora Deployment (Administrator Operations); source: A-02 — Jijibora Compliance Operations (Administrator)).

  1. Delivery depth. Read the pending count of the durable anchor; steady-state expectation is zero (source: A-01 — Jijibora Deployment (Administrator Operations)). If depth never falls, follow the outbox-relay runbook: confirm depth, drain only on a temp instance, verify with the consumer-live check, expect depth returning to zero (source: A-01 — Jijibora Deployment (Administrator Operations)).
  2. Consumer receipt health. Watch receipt statuses: published means delivered; guard-refused means failed and recorded; max retries means dead-letter with an audit row (source: A-01 — Jijibora Deployment (Administrator Operations); source: A-02 — Jijibora Compliance Operations (Administrator)). Criterion: one receipt per event, refusals recorded, never re-emitted (source: A-02 — Jijibora Compliance Operations (Administrator)). A transition that returns success but writes no delivery row is a fault (source: A-02 — Jijibora Compliance Operations (Administrator)).
  3. Rule health. Confirm each enabled family's switch and version, and that the flow chain engine is reachable; if the optimizer or translation engine is down, sourcing solves and gated dispatches refuse with 502/503 and never return synthetic success (source: A-01 — Jijibora Deployment (Administrator Operations); source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). Confirm CLI health of process translation with a round-trip, never with a health endpoint alone (source: A-01 — Jijibora Deployment (Administrator Operations)).

Thresholds: steady-state pending depth expected zero; any non-zero persistent depth triggers the runbook (source: A-01 — Jijibora Deployment (Administrator Operations)). UNKNOWN: numeric alert thresholds (e.g. depth > N for M minutes) are UNKNOWN in the read set (source: A-01 — Jijibora Deployment (Administrator Operations)).

5. SOS and escalation business rules — who can declare, thresholds as values, plain text

Who can declare. A resident or officer raises the distress signal by the governed channel (panic button, alarm, phone report); the emergency playbook opens the crisis posture and tasks named responders (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: A-02 — Jijibora Compliance Operations (Administrator)). A named human closes the incident; "the system" never approves (source: A-02 — Jijibora Compliance Operations (Administrator)).

Escalation thresholds as values. Standing-order limits are values set declaratively (a river height, a time window, a score) and may be tightened by a ward but never loosened beyond the parent promise (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). Break-glass emergency override uses dual control with a time limit: default one hour, maximum twenty-four hours, with an expiry attached and an audit entry written; it does not auto-open a proof session and does not auto-file follow-up actions (source: A-02 — Jijibora Compliance Operations (Administrator)). In plain text: one person asks, a second named person approves; the grant expires on its own; only then is the action taken (source: A-02 — Jijibora Compliance Operations (Administrator)).

Behaviour in plain text. The signal fans out to named responders with exact location and needed materials (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). Public alerts are drawn only from scrubbed fields unless a purpose grant exists (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). Any governed emergency action writes its own proof session and audit trail (source: A-02 — Jijibora Compliance Operations (Administrator)). The system never skips its ceiling, even in crisis: a widening child still refuses (source: A-02 — Jijibora Compliance Operations (Administrator)).

UNKNOWN: exact numeric escalation thresholds (seconds to broadcast, minutes to declare multi-agency) are UNKNOWN in the read set; only the pattern (value + dual control + expiry + audit) is evidenced (source: A-02 — Jijibora Compliance Operations (Administrator)).

6. If the reflex hurts — refuse-first debugging

Kill switch per rule family first, then ordered checks. Do not diagnose while the family is still firing (source: A-01 — Jijibora Deployment (Administrator Operations); source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md).

Step 0 — kill switch. Set that family's enabled switch false to quiesce; if you must stop immediately, suspend the translation queue group for that family. Expectation: no new fires after drain.

Ordered checks (in order — do not skip):

  1. Inbox (durable anchor). Symptom observed: relay failure line repeating on interval, or a readiness check that stays dark while the store shows up, and pending depth never falls (source: A-01 — Jijibora Deployment (Administrator Operations)). Response flag: depth probe reports non-zero persistent count. Fix: diagnose the relay construction fault on a temp instance, verify with the consumer-live check, expect depth zero again (source: A-01 — Jijibora Deployment (Administrator Operations)).
  2. Consumer (receipt health). Symptom observed: a transition returns success but no delivery row exists (source: A-02 — Jijibora Compliance Operations (Administrator)). Response flags: delivery row absent; response field indicating the sink failed (payload-not-object), or a missing identifier that makes the pack refuse with an unknown-pack style refusal (source: A-02 — Jijibora Compliance Operations (Administrator)). Fix: ensure the envelope is the payload and identifiers are present; re-check receipt status (source: A-02 — Jijibora Compliance Operations (Administrator)).
  3. Allowlist (ceiling). Symptom observed: a child request that widens the parent promise is refused on write; a wider publish is refused with a ceiling-denied response (source: A-02 — Jijibora Compliance Operations (Administrator); source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md). Response flag: ceiling-denied. Fix: refuse the widening; do not negotiate the ceiling down to make it fit (source: A-02 — Jijibora Compliance Operations (Administrator)).
  4. Handler (terminal owner). Symptom observed: a transition call returns an internal fault about an unknown capability (source: A-01 — Jijibora Deployment (Administrator Operations)). Fix: re-import the governing design and re-exercise the transition; expect success with a delivery row present (source: A-01 — Jijibora Deployment (Administrator Operations)).

Refuse rule throughout: on any infra failure, refuse with 502/503 and never return synthetic success; never mark rows delivered by hand; never purge history to make a pack look clean (source: A-01 — Jijibora Deployment (Administrator Operations); source: A-02 — Jijibora Compliance Operations (Administrator)).

UNKNOWN: family-specific log lines printed by the flow engine or translation routes for building reflex, community sourcing, and SOS dispatch are UNKNOWN in the read set; only the relay and transition faults above are evidenced. Capture the failing component's line verbatim the first time you see it and paste it into the incident note (source: A-01 — Jijibora Deployment (Administrator Operations)).

Open items / gaps

← BackHome — all documentationNext →Jijibora set index