Infrastructure Constitution — Version 10.1

Document Status: RATIFIED (The Sovereign Participation Amendment)

Classification: INTERNAL // COMMAND EYES ONLY

Effective Date: 2026-06-03

Document Compatibility (The Charter Release):

• Infrastructure Constitution v10.1 (this document)
• Standard Operating Procedures v1.0
• Hardware Manifest v1.0
• Software Stack Manifest v1.0
• Den Migration Project v1.0
• WiseNxt Doctrine v2.1
• URL Nomenclature & Routing Strategy r4
• Moodle Orientation Syllabus v9.19

Preamble: The Doctrine of Sovereign Computation

We, the People of Opplet, in order to secure our digital sovereignty, ensure the integrity of our data, and cultivate a meritocratic forge for talent, do ordain and establish this Infrastructure Constitution.

This enclave exists to enforce a separation of powers between The Sovereign (who owns the infrastructure) and The Talent (who utilizes it). We reject the fragility of monolithic chaos and the tyranny of third-party dependence.

On Sovereignty and Openness. Opplet is an open-source technology platform. Sovereignty does not mean secrecy: the codebase, configurations, and architecture are public. What “Sovereign Computation” protects is operator control — the Sovereign holds root over their own running instance — not the privacy of the source. An open platform and a sovereign operator are fully compatible; indeed, the platform’s openness is what allows others to fork it and become sovereign operators of their own instances.

The Four Pillars of Operation

1. Identity is Sovereign. Control of the root credential is the only true ownership. We delegate access, never authority. Corollary: identity is earned through participation, never granted on request. Self-registration into privileged directories is forbidden.
2. Code is Law. Policy is not written in memos; it is enforced by firewalls, pipelines, and automation.
3. Automation is the Manager. Human intervention is a failure of design. The machine must govern the routine; the human governs the exception.
4. Observation is Truth. Trust is a vulnerability. We do not trust; we verify through logs, metrics, and immutable audit trails.

Changelog: v10.0 → v10.1 (The Sovereign Participation Amendment)

A single-rule addition to §12 acknowledging the case of the Sovereign optionally participating as a community member. Pseudonymous participation is permitted, subject to the same calibration requirements as any other community member. The amendment closes a previously undefined case (LDAP-Alpha-first followed by optional LDAP-Beta) without changing any other rule.

• §12 — Single Intake, Sequential Recruitment: Added Rule 4 (Sovereign Participation). The Sovereign may hold a Community membership alongside their LDAP-Alpha role, provided they complete the same Moodle calibration as any other candidate. The connection between the community callsign and the Sovereign role is at the Sovereign’s discretion to disclose — pseudonymous participation is permitted.
• Companion Doctrine update: WiseNxt Doctrine v2.1 adds operator-facing detail on what Sovereign Participation looks like in practice (§3A).
• No other changes to architecture, identity model, network protocol, or any operational mechanic.

Changelog: v9.3 → v10.0 (The Charter Split)

Version 10.0 is a structural refactoring, not a substantive policy change. No architectural decision has been reversed; this is a redistribution of content across documents whose amendment friction now matches their change rate.

Extracted from the Constitution:

• Hardware specs (former §3) → Hardware Manifest v1.0.
• Software product choices (former §4 software matrix and §5 quartet tech stack) → Software Stack Manifest v1.0.
• Operational cadences and thresholds (former §6D backup mechanics, §8C external pulse cadences, §8D alert thresholds, §9 OPNsense recovery target, §10A–10E DR specifics, §11 RAM audit cadence) → Standard Operating Procedures v1.0.
• The Den Development Plan (former §13) → Den Migration Project v1.0.
• Documentation Structure specifics (former §12) → SOP v1.0 with the architectural principle retained in §6F of this document.

Retained as architectural law:

• Hemispheric Strategy, Zoning Strategy, Network Protocol principles, Kill Switch principles, Three Layers model, Identity model, Single Intake model, Authentik Default Rule, Doctrine Reference.
• RTO/RPO commitments (the resilience promises) are restated in §9 of this document; SOP holds the implementation details.

Net effect: the Constitution is now roughly half its v9.3 length. SOP-level numbers can be tuned without Constitutional amendment. Hardware and software refreshes don’t bump the Constitution.

1. The Hemispheric Strategy (Physical Topology)

The enclave is partitioned into four physical nodes to isolate the Sovereign’s personal life, business control plane, talent workloads, and adversarial exercises from one another.

• The Den (Sovereign Life): Cloud-hosted, physically independent of all other nodes. Role: The Life Raft. Personal identity, communication, finance, files, and telephony. Must remain 100% operational if all Hetzner nodes are lost.
• The Manor (Sovereign Core): High-availability sovereign infrastructure. Role: The Structure and Brain. Business identity, internal automation, capital preservation, observability.
• The Annex (Delivery Edge): High-performance, high-bandwidth delivery node. Role: The Forge & Front Door. Source code, talent lifecycle, CI/CD compilation, public traffic proxies.
• The Outpost (Live Fire Range): High-density, volatile node. Role: The Muscle. Network-isolated range existing strictly for exploitation and target practice.

The Life Raft Principle. The Den has zero dependency on the Manor, Annex, or Outpost. If all Hetzner infrastructure is destroyed, the Sovereign’s email, phone, finances, files, calendar, and contacts remain fully operational.

Specific hardware specifications for each node are maintained in the Hardware Manifest.

2. Infrastructure Zoning Strategy (The Dwelling Analogy)

The Alpha-Override Rule. Zone 4/5 apps use LDAP-Beta for community members and talents but MUST map administrative privileges to LDAP-Alpha to prevent Sovereign lockout during a Talent Wipe.

3. The Identity Architecture (Dual-Authentik Model)

The enclave operates two independent Authentik instances to enforce complete separation between the Sovereign’s personal life and business operations.

Zero Cross-Pollination Rule. The two Authentik instances share no users, no tokens, and no federation. A compromise of the business identity layer must have zero impact on the Sovereign’s personal services, and vice versa.

4. The CMS/Static Quartet (Public Fronts)

Hosted on The Annex (Zone 4 – The Lounge) behind Traefik. Public-anonymous posture per §7.

• Opplet.com: Commercial / Infrastructure brand.
• KenyaX.com: Logistics & Impact brand.
• WiseNxt.com: Public front for the WiseNxt work discovery methodology.
• CNMCyber.com: CNMCyber volunteer community landing.

Specific static-site generators and build tooling are tracked in the Software Stack Manifest.

5. Network Protocol (The Sovereign Gap)

5A. The Janitor Rule

• The Manor → Annex/Outpost: ALLOWED (telemetry pull, admin management).
• Annex/Outpost → The Manor: DENIED.

Three Constitutional Exceptions:

1. OIDC calls to Authentik-Business (HTTPS 443).
2. n8n-Alpha triggers via encrypted internal webhooks (X-Internal-Token).
3. The Backup Bridge — The Annex pushes state to PBS (Zone 0) under Drop-Only permissions: the Annex cannot read or delete existing backups on the Manor.

Backup frequency, canary verification cadence, and integrity-test schedules are SOP-level concerns and live in the SOP.

5B. The Storage Isolation Mandate

Distributed storage protocols (Ceph, GlusterFS, vSAN, and the like) are EXPLICITLY BANNED from spanning physical nodes. Storage must remain strictly local (ZFS) to each hypervisor to preserve NVMe IOPS capabilities and enforce the Sovereign Gap. State transfer shall occur exclusively via the encrypted Backup Bridge.

5C. The Talent Proxy

Talents access Outpost VMs only through the Air-Lock (Guacamole) at access.opplet.com. Apache Guacamole proxies the VNC/SSH connection to the Outpost via Hetzner’s vSwitch. The talent’s local hardware never touches the execution network layer.

5D. The Den Network Isolation

The Den operates on an entirely separate network with no routing to the Hetzner enclave.

• Den ↔ Manor/Annex/Outpost: NO CONNECTIVITY. No Tailscale mesh, no VPN, no firewall exception.
• Gateway ↔ Engine (internal to the Den): Connected via Tailscale private mesh. The Engine has no public-facing ports; all traffic is reverse-proxied through the Gateway.
• Sovereign Access: The Owner accesses Den and Hetzner environments independently via separate credentials and separate network paths.

Rationale: The Life Raft Principle demands that no failure, breach, or misconfiguration in the Hetzner enclave can propagate to the Den. Total network isolation is the only way to guarantee this.

5E. Edge Router Resilience (Principle)

OPNsense is virtualized on The Manor (Basement), coupling edge routing availability to the Manor hypervisor. Three Constitutional requirements:

1. The OPNsense VM must hold the highest HA restart priority on the Manor cluster.
2. OPNsense configuration must be automatically exported to BookStack-Alpha on a recurring cadence (defined in SOP).
3. OPNsense must be rebuildable from a current config export and Proxmox template within a defined recovery target (specified in SOP).

6. Documentation Structure (Principle)

Documentation is physically split across locations to enforce isolation boundaries. The Constitution mandates the split; the SOP specifies which document lives where in detail.

• Technical Source of Truth: GitLab (The Annex – Kitchen).
• Sovereign Private Documentation: BookStack-Alpha (The Manor – Basement). The Grimoire.
• Community Documentation: BookStack-Beta (The Annex – Lounge). The Common Library, with tiered shelf model: public-read public shelves, member-read member shelves, authenticated write throughout.
• Den Documentation: Local to the Engine VPS; no dependency on Hetzner-side documentation systems.

7. The Authentik Default Rule

Every HTTP service in the enclave is Authentik-walled (Authentik-Business or Authentik-Personal as appropriate) unless it falls into one of the named exception categories below. Each exception must be justified; adding new unwalled services requires deliberate categorization, not default permission.

7A. The Seven Exception Categories

7B. The Three Protection Postures

Every service in the enclave falls into one of three postures. Posture must be assigned before provisioning.

7C. Defense-in-Depth Note

Sovereign-only services should additionally use Authentik where the application supports it. The network boundary is the primary protection; Authentik is the second layer. A service that is only network-protected (e.g., OPNsense itself, which cannot put Authentik in front of itself without circular dependency) is the exception, not the norm.

Specific service-to-posture assignments are documented in the URL Nomenclature & Routing Strategy.

8. The Kill Switch Matrix (Principle)

The enclave maintains four escalating response levels for compromise or failure scenarios. The principle of escalating, automated containment is Constitutional; the specific triggers and thresholds are SOP.

The Den has no Kill Switch entry because it operates independently. If the Den’s Engine VPS is compromised, the Owner revokes its Tailscale key from the Gateway. This is an operational procedure, not an automated switch.

9. Resilience Commitments (RTO/RPO)

The enclave commits to the following recovery objectives per node. These are Constitutional promises; the implementation procedures that achieve them live in the SOP.

Rebuild Priority (Constitutional ordering for multi-node failures):

1. Den Gateway (the Sovereign’s lifeline to the outside world).
2. OPNsense (edge routing — without it, no Hetzner service is reachable).
3. LDAP-Alpha + Authentik-Business (identity must precede dependent services).
4. Den Engine.
5. n8n-Alpha + Watchtower (automation and observability).
6. GitLab + Traefik.
7. Moodle, HumHub, Jitsi, Guacamole (talent-facing services).
8. The Outpost (rebuilt from VM templates; no backup dependency).

10. The Intelligence Layer (Principle)

10A. The Split-Brain Protocol

• Sovereign Data (internal ops): Stays on The Manor ZFS. No offsite transit except via encrypted PBS.
• Personal Data (Den): Stays on Den VPSs. No transit to Hetzner enclave under any circumstances.
• Liability Data (talent logs): Forwarded immutably from Outpost and Annex to Watchtower (Zone 0) for non-repudiation.

10B. Observation Mandate

The enclave mandates active observability across three dimensions: external uptime monitoring (continuous reachability checks), service-level health checks (application-specific endpoints), and active alerting on defined event classes (failed authentications, ZFS pool health, anomalous egress, container instability, backup canary failures, telephony health, mail queue health).

Specific monitoring cadences, alert thresholds, and notification destinations are SOP-level concerns. The Constitution mandates the existence of monitoring across these dimensions; the SOP defines the tuning.

11. The Meritocracy Loop (Two Merit Gates)

The enclave operates two distinct merit gates. The first is a promotion within a single directory (candidate → member, both inside LDAP-Beta). The second is a recruitment between organizations (a CNMCyber community member is recruited into an Opplet operational track, gaining LDAP-Alpha). The vocabulary is deliberate: one moves you up within where you already are; the other moves you across into a different organization.

Community-Tier Promotion (Exam → Community Membership):

1. Event: New candidate completes the foundational exam in Moodle (The Lounge) with a 100% score.
2. Signal: Moodle sends an encrypted webhook to n8n-Alpha.
3. Action: n8n-Alpha promotes the candidate from candidate to member group within LDAP-Beta.
4. Result: The member gains SSO access to HumHub, BookStack-Beta member shelves, and Jitsi.

The 72-Hour Calibration Clock. L0 candidate accounts have a hard 72-hour lifetime from creation. If the candidate has not passed the Moodle calibration within that window, n8n-Alpha purges the account, releases the callsign suffix to the pool after a 30-day quarantine, and cleans up Moodle state. There is no cooldown on re-registration. The clock exists to keep the candidate pool fresh, not to penalize the candidate.

Track-Tier Recruitment (Demonstrated Competence → Operational Track):

1. Event: An LDAP-Beta community member in good standing applies to a track recruitment posting in ERPNext.
2. Review: The candidacy is reviewed by an Opplet Track Lead. Approval is recorded in ERPNext.
3. Action: On approval, n8n-Alpha provisions an additional LDAP-Alpha account (dual membership per §12 Rule 2).
4. Result: The member retains LDAP-Beta community access and gains LDAP-Alpha track access.

Operator rank, callsign format, the four track-specific rank prefixes, and the endorsement workflow are defined in the WiseNxt Doctrine (referenced in §13).

12. Single Intake, Sequential Recruitment

The enclave operates one public intake (into the CNMCyber community) and one downstream recruitment path (from that community into Opplet’s operational tracks). There is no parallel pipeline for external recruitment; Opplet’s operators are recruited from existing community members.

Four Constitutional Rules:

1. No Parallel Intake. There is no public URL anywhere in the enclave that creates an LDAP-Alpha account directly. LDAP-Alpha membership is reachable only by recruitment from LDAP-Beta.
2. Dual Membership on Recruitment. Recruited track members retain their LDAP-Beta account in addition to gaining LDAP-Alpha. This preserves the Alpha-Override Rule, keeps historical contributions attached to a single identity, and matches the “growing from user to governor” meritocratic framing.
3. Internal Sourcing Rule. Opplet recruits track members exclusively from CNMCyber’s LDAP-Beta directory. There is no public Opplet recruitment funnel. A candidate must first become a CNMCyber community member (via commit.opplet.com → Moodle exam → LDAP-Beta) before they are eligible for Opplet track recruitment via the Bursar. Every track holder began as a community member.
4. Sovereign Participation. The Sovereign may optionally hold a Community membership in addition to their LDAP-Alpha role. The Sovereign’s LDAP-Alpha account exists by ownership, not by recruitment; a Community account is acquired by the same path as any other community member — registration via commit.opplet.com and completion of the Moodle calibration. The connection between the Sovereign’s community callsign and the Sovereign role is at the Sovereign’s discretion to disclose. Pseudonymous community participation by the Sovereign is permitted and is the architectural default; this honors Pillar 1 (work, not identity, is the credential) by extending the same anonymity protection to the Sovereign that applies to every other community member.

13. The WiseNxt Doctrine Reference

Operator rank progression, callsign generation, the endorsement workflow, the four track-specific rank names, and pod structure are defined by the WiseNxt Doctrine — a separate document maintained at its own version cadence. This Constitution treats the Doctrine as authoritative for participant-facing progression questions and reserves infrastructure-level decisions to itself.

13A. Authority Split

13B. Doctrine Substantive Changes

Substantive Doctrine changes — new ranks, new tracks, new calibration gates, modifications to the endorsement workflow — require Sovereign approval but do not require Constitutional amendment unless they touch the infrastructure boundary above. A Doctrine change that does cross into infrastructure territory requires a paired Constitutional amendment.

14. The Four Engagement Doors

The enclave presents four public engagement doors under opplet.com, each a single-purpose intake.

14A. Constitutional Rules for the Doors

1. Action-Verb Naming. All engagement door subdomains use action verbs. The verbs commit, partner, sync are reserved Constitutional concepts.
2. Public Anonymous Posture. All four doors are public-anonymous (§7, Exception 2).
3. Only commit Creates Accounts. Of the four doors, only commit.opplet.com provisions identity.
4. No Hidden Fifth Door. There is no other public account-creation endpoint anywhere in the enclave. Any future account-creation flow must either be added as a fifth door with Constitutional ratification, or operate as a downstream recruitment from an existing LDAP-Beta member per §12.

15. The Three Layers of the Enclave

The enclave is best understood as three layers, each with a distinct nature and ownership rule. All three are themselves work products — produced by participants working under the WiseNxt methodology — but they differ in what they are and who holds them.

15A. The Platform — Opplet

Nature: Open-source technology platform. The infrastructure, network, identity layers, and operating environment that the rest of this Constitution describes.

Ownership: Operated by Economic Group, a nonprofit. The codebase and configurations are open source.

15B. The Methodology — WiseNxt

Nature: Open-source work discovery / pre-entry-level job methodology. WiseNxt is the documented practice for how a participant moves from newcomer to capable operator — “from user to governor” — by doing real work inside real services.

Manifestation: WiseNxt is not a system with its own servers. It manifests across Platform services: the foundational exam in Moodle, mentorship in HumHub, reference material in BookStack-Beta, progression tracking in ERPNext, and hands-on work in the Forge and the Range. Its four work-discovery tracks are engineer, logistics, finance, and marketing.

Ownership: Open source. Currently held by Economic Group; assignable to a partner steward when one is identified.

Public surface: The marketing site at wisenxt.com.

15C. The Sounding Board — CNMCyber

Nature: The development community and Opplet’s sounding board — the place where members participate, mentor one another, and provide feedback to the Platform before changes are committed. The volunteer pool from which Opplet recruits track members (§12).

Operational Scope: Community services on cnmcyber.com — HumHub, BookStack-Beta, Jitsi, and the CNMCyber landing site.

Affiliation: CNMCyber has historically affiliated with Career Network Ministry.

Infrastructure Boundary: CNMCyber’s services run on the Annex (Zone 4), but the underlying infrastructure remains under Sovereign control. CNMCyber has no root access to the Annex node; its authority extends only to application-layer administration via LDAP-Alpha admin accounts mapped through the Alpha-Override Rule.

15D. On Work Products and Brands

Everything in the enclave is a work product: the Opplet platform, the opplet.com site, the kenyax.com site, the WiseNxt methodology, the cnmcyber.com site. “Work product” is the nature of everything here, not a separate layer.

KenyaX is a brand attached to one such work product (currently the kenyax.com static site). It is not a layer and has no current operational scope.

Shared infrastructure (Moodle, Guacamole, the Range) belongs to no single layer’s operator; it is Platform infrastructure administered by the Sovereign directly, consumed by the Methodology and the Sounding Board alike.

16. Amendment Procedure

The Constitution may be amended only by the Sovereign. Substantive amendments produce a new version number (e.g., v10.0 → v10.1) and are recorded in the Changelog. Editorial changes (typo fixes, clarification, formatting) may be made without version bump but should be noted in the document compatibility block.

Amendments that do NOT require Constitutional change:

• Hardware refreshes (Hardware Manifest)
• Software product substitutions within an established role (Software Stack Manifest)
• Operational threshold tuning (SOP)
• New WiseNxt Doctrine ranks, tracks, or workflows that do not touch infrastructure (Doctrine)
• New service-to-posture URL assignments within existing exception categories (URL Nomenclature)

Amendments that DO require Constitutional change:

• Changes to the Four Pillars
• Changes to the Hemispheric Strategy or Zoning Strategy
• Changes to the Sovereign Gap (Janitor Rule, Storage Isolation, Den Network Isolation)
• Changes to the Authentik Default Rule’s exception categories
• Changes to the Four Constitutional Rules of §12 (Single Intake)
• Changes to the Three Layers identity (Platform / Methodology / Sounding Board)
• Changes to RTO/RPO commitments in §9
• Addition of a fifth Engagement Door
• Any change that crosses the Authority Split in §13A from Doctrine side to Constitution side

END OF DOCUMENT