Enclave SOP

Substrate Operations: The Enclave SOP

Version 2.2 · DRAFT (reconciles to Constitution v12.8; adds §13 Evolution Cycle) · Tier 3 — Tier 3 — Operations & Learning · part of Charter Release 2026.3 · effective 2026-07-01

Purpose and Scope

The operational cadences, thresholds, and runbooks for the technology substrate — what the Enclave Doctrine designs and the Constitution bounds, made concrete. Custodian-tunable (Constitution §13B); changes are version-bumped here.

§1 — The Backup Bridge

The substrate’s state crosses nodes only over the encrypted Backup Bridge to Proxmox Backup Server (PBS) in the Basement, under Drop-Only — the source writes backups it cannot read or delete (Constitution §5A).

• Cadence: the Annex pushes to PBS every 4 hours; the Outpost likewise pushes its durable Climb datasets — the free community forge, the tracker, and the curation records — under the backup exception (Constitution §5A, §9). The ephemeral practice forks are excluded (rebuilt from templates).
• Canary: a 30-minute-offset canary verifies the push landed; a miss is an L0 event (§3, Constitution §8).
• Integrity: a weekly GitLab integrity test restores the latest repository snapshot to a scratch target and verifies it.
• Storage stays local (ZFS) on every node; nothing distributed spans nodes (Constitution §5B).

§2 — The External Pulse

Liveness is watched from outside the enclave so a total-node failure still alerts.

• Uptime Kuma runs on an independent micro-VPS (never on an enclave node) and checks each public front and key service endpoint.
• Dead-man’s switch: Uptime Kuma expects a periodic heartbeat from inside; if it stops, Uptime Kuma alerts the Custodian directly, out-of-band from the enclave’s own alerting.

§3 — Active Alerting Baseline

Wazuh and Grafana feed Pushover to the Custodian. The baseline alert set, tuned quarterly:

(Rows reconstructed after the loss of sop v1.3; severities map to the Kill Switch Matrix — Constitution §8 — but verify the set.)

Tuning policy: the table is reviewed every quarter; thresholds are adjusted to keep false positives low without dropping a real L0–L3.

§4 — OPNsense Resilience Procedures

• HA priority: OPNsense (virtualized on the Manor) holds the top HA restart priority — it returns before anything that depends on the network boundary.
• Config export: the running config is exported to BookStack-Alpha on a cadence, so a rebuild starts from a known-good config.
• Recovery target: OPNsense is rebuildable within 30 minutes from the exported config.

§5 — Disaster Recovery Procedures

• Per-node backups follow the RTO/RPO commitments (Constitution §9): Manor 4h/15m, Annex 8h/4h, Outpost 24h/last snapshot, Den Gateway 2h/24h, Den Engine 4h/daily.
• Rebuild priority: Den Gateway → OPNsense → LDAP + Authentik-Business → Den Engine → automation/observability → GitLab + Traefik → talent-facing services → Outpost.
• The DR runbook lives in BookStack-Alpha (the Grimoire); the Den’s runbook is local to the Engine with no enclave dependency.
• Multi-node drill: at least once per cycle a multi-node loss is rehearsed against the runbook (paired with §7).

§5B — The credential-bootstrap safe. The break-glass credentials — the printed credential-bootstrap section in the Custodian’s physical safe, plus the encrypted copy in Vaultwarden — are the deepest fallback for total loss. They are tested for legibility and completeness on the §7 cadence, and sit below the live override in the order of resort (§12).

§6 — RAM Headroom Audit

Every node’s RAM allocation is reviewed quarterly against the Hardware Manifest. The standing ceiling is 75% committed; crossing it on any node raises a warning (§3) and triggers a headroom-recovery action (rebalance or scale) before it becomes an availability risk.

§7 — Tabletop Exercise Cadence

Quarterly tabletop walkthroughs rehearse the incident paths — a backup-restore, an OPNsense rebuild, a single-zone isolation (L2), a node sever (L3), and a break-glass drill. Findings feed back into §3 thresholds and the §5 runbook.

§8 — Documentation Structure

The Constitution (§6) mandates the split; the homes are:

• §8A — Technical source of truth: the Kitchen production GitLab (secret-bearing) and the free community forge (public/open development — on the Range / Zone 5, LDAP-Beta).
• §8B — Custodian private documentation: BookStack-Alpha (the Grimoire, Basement).
• §8C — Community documentation: BookStack-Beta (the Common Library, Lounge), tiered public/member shelves.
• §8D — Den documentation: local to the Engine; no enclave dependency.

§8C member shelves are: internal community discussions; draft documents; member work products, organized by specialty (Engineering / Logistics / Finance / Marketing), not by rank; Gate-2 endorsement records — Developer-space vote summaries plus curation notes referencing work in the free community forge (on the Range / Zone 5, per Constitution v12.8 §2 and Enclave Doctrine v1.1); and the structural-space shaping shelves — the future-enclave roadmap drafts of the Evolution Cycle (§13). (No rank-based shelves: the abolished rank model has no place here.)

§9 — Routine Operational Checks

The standing cadence. All Basement-touching duties remain the Custodian’s and are never delegated.

(Cadence/owner rows reconstructed after the loss of sop v1.3 — verify against any surviving copy.)

§10 — Recruitment and Disbursement (relocated)

Moved in full to the Workplace SOP. The Tech Board’s funded-work workflow, the ERPNext recruitment process, and disbursement are real-identity-workplace mechanics and live with the Workplace domain. Nothing of it remains here. (CNMCyber and KenyaX are team/brand names, not domains; the domain SOPs are the Commons SOP and the Workplace SOP — Constitution v12.8 §13.)

§11 — Cutting a Charter Release

Procedure: reconcile the corpus → cut the immutable lockfile → move the charterRelease pointer → rebuild and verify. Document ids are stable primary keys; releases are immutable.

Under the four-triad composition (Constitution v12.8 §13), each domain pins a Doctrine + SOP + course. A Charter Release pins:

• constitution (keystone)
• Enclave triad: enclave-doctrine, enclave-sop (this document), enclave-bootcamp
• Commons triad: commons-doctrine, commons-sop, welcome-to-opplet-commons
• WiseNxt triad: wisenxt-doctrine, wisenxt-sop, wisenxt-orientation
• Workplace triad: workplace-doctrine, workplace-sop (no course yet — Constitution §13)
• the manifests, the URL Nomenclature, the Official Website document

The first Charter Release after the restructure performs a coordinated id migration (permitted only at a release boundary), reflecting the full v12.6–v12.8 target state: sop → enclave-sop (this re-issue completes it); the Participant Doctrine splits — its ladder content keeps wisenxt-doctrine, its community content forks to commons-doctrine; the paid-workforce pair migrates to workplace-doctrine / workplace-sop; and the single moodle-syllabus is retired, splitting into the three domain courses — welcome-to-opplet-commons (Commons), enclave-bootcamp (Enclave), and wisenxt-orientation (WiseNxt). New ids are minted for any remaining triad members. Re-pin everything in a fresh charter-YYYY-N+1.yaml; old lockfiles stay immutable.

§12 — Sovereign Override and Break-Glass

The Constitution (§2, §3) fixes that the Custodian’s override is isolated from both population directories. This is how it is operated.

• The live override is normally dormant. It is enabled only when invoked, reached only over the Custodian network path (Constitution §7C), and gated by a hardware token. It exists to let the Custodian respond to a compromise of either population directory — a Talent Wipe of Beta, or a workforce-directory incident in Alpha — without a full break-glass.
• Invocation is logged immutably to Watchtower (Pillar 4); the override is disabled again on completion. An enabled-and-idle override is itself an alertable condition (§3).
• Break-glass remains the deeper fallback (§5B): the printed credential-bootstrap section in the Custodian’s physical safe, plus the encrypted copy in Vaultwarden. Break-glass is for catastrophe — total loss, or a compromise that reaches the override itself. The order of resort is: ordinary admin → live override → break-glass.

§13 — The Evolution Cycle

The runbook for the Evolution Loop the Doctrine designs (Enclave Doctrine §10) — how a structural space is stood up, how it shapes and assesses, and how its projects reach the Tech Board gate. Custodian-tunable (Constitution §13B); the constitutional authorities it invokes are fixed and not tunable here.

§13A — Designation. The Tech Board designates a Lounge Developer-space as structural (Constitution §16); the Custodian records the designation and provisions the space’s shaping shelf on BookStack-Beta (§8C). Designation is reviewed each cycle and lapses if the space goes dormant.

§13B — The shaping shelf. Each structural space drafts on its member shelf in BookStack-Beta (the Common Library, §8C) — proposals, designs, and roadmap entries for the enclave’s next state. Mature drafts are surfaced on the Vision section as working documents (not load-bearing until adopted). The current queue leads with Den Migration.

§13C — The tour cadence. Assessment of the running enclave is delivered by standing visibility and guided tours:

No tour or visibility grant crosses the Sovereign Gap: nothing exposes Alpha secrets, the Kitchen deploy layer, or the Basement (Constitution §5, §7). A staffer drives; the space observes.

§13D — The Tech Board gate. Once per cycle the Tech Board reviews the shaped projects and records, for each, a disposition:

The disposition and its rationale are recorded to the space’s shelf (§8C) and, for funded work, to the Bursar (ERPNext, Zone 2). The Board sets funding and track only; it may not route privacy-, security-, or contract-bearing work to the Volunteer track to keep it pseudonymous (Constitution §15E, §16).

§13E — Cadence and owners.

Funded projects flow to the Workplace (contract); WiseNxt-available projects flow to the Climb (work-discovery). Neither the shaping shelf nor a tour confers any authority the Constitution reserves (§17).

END OF DOCUMENT

• Tier 0 — Keystone: Opplet Constitution
• Tier 1 — Doctrine & Architecture: Enclave Doctrine, Commons Doctrine, WiseNxt Doctrine, Workplace Doctrine
• Tier 2 — Manifests & Reports: Software Stack, Hardware Manifest, URL Nomenclature, Opplet.Com Website
• Tier 3 — Operations & Learning: Commons SOP, Enclave SOP (this document), Enclave Bootcamp, Commons Welcome, Space Organizer, WiseNxt SOP, WiseNxt Orientation, Workplace SOP, Website SOP
• Tier 4 — Zone Projects: Den Migration