Participant Doctrine

Ladder Methodology: Participant Doctrine

Version 3.1 · RATIFIED (The Three-Rung Ladder) · Tier 1 · part of Charter Release 2026.2 · effective 2026-06-10

Purpose and Scope

This Doctrine governs the enclave’s progression ladder: its states, the calibration gates, callsign generation, the four work-focus tracks, and the endorsement workflow. The Constitution governs infrastructure and the governance bodies — including the Tech Board (Constitution §16), which awards paid work — while the SOP carries the recruitment and disbursement mechanics. This Doctrine is authoritative for the ladder’s methodology up to the point where it crosses into paid work; the award itself belongs to the Tech Board (Constitution §16).

The Constitution acknowledges both documents in its §13.

1. The State Model (The Ladder)

A participant occupies one of three internal states, with a fourth reserved at the apex. The states form a ladder: each is reached only from the one below, which makes the Constitution’s Internal Sourcing rule (§12 Rule 3) structural rather than something to police. The first three rungs are internal — LDAP identities under Opplet’s governance. The fourth, Custodian Partner, is a graduation out into an independent peer partnership and is reserved (mechanics TBD; see Constitution §11 Gate 4).

The single hard directory boundary sits between rung 1 and rung 2: crossing into committed-volunteer status is the crossing into the operational directory (LDAP-Alpha, the Kitchen). Rung 2 → rung 3 is a change of compensation and contract scope, not of directory. LDAP-Alpha is the authentication boundary; per-service authorization is layered on top, least-privilege, so an Associate holds scoped project roles, not keys to everything (Constitution §2).

Not a rank ladder. These are states, defined by directory and compensation — not ranks, titles, or prefixes. There is no five-rung rank ladder (that v1.0 idea was abandoned in v2.0 and is not revived here), and nothing is appended to a participant’s callsign as they rise. “Action is the credential” is taken at face value: a participant is described by what they do and what they have shipped — which track they work on, which contracts they hold — not by a label. The states answer “what access and what pay,” nothing more.

A Community member may carry internal sub-distinctions (the LDAP-Beta candidate vs. member group; a declared track focus) but these are operational details, not new states.

2. Calibration Gates

Movement up the ladder happens at three named gates, each owned by a distinct body.

Gate 1 — The CNMCyber Gate (Entry into Community)

• Event: Registration via commit.opplet.com and completion of the Moodle orientation course at 100%.
• Trigger: Moodle webhook to n8n-Alpha (Constitution §11).
• Effect: LDAP-Beta group changes from candidate to member. Access to HumHub, BookStack-Beta member shelves, and Jitsi.
• Time pressure: Must complete within 72 hours of account creation. Failure triggers automatic purge (§4).
• What does not change: The callsign (§5). It is permanent from registration onward.

Gate 2 — The WiseNxt Gate (Recruitment into the Lab)

This gate has two stages — an endorsement signal followed by a recruitment decision. Both must complete.

Stage 2A — Endorsement (two channels of unequal weight). A Community member produces visible project work: improvement proposals to the platform’s products in BookStack-Beta and, where the project allows, contributions to public GitLab projects. Endorsement flows through two channels that measure different things:

• Project-member curation (GitLab) — the necessary signal. Existing Associates and Contractors vouch, individually or collectively, for work they have reviewed. At least one credible project-member endorsement is required, because this is the evidence the gate actually asks about: readiness for Kitchen access. A curation record is a structured entry stored in BookStack-Beta (Common Library, member shelf), naming the participant, the target track, the body of work referenced, the endorsing member(s), and the date.
• Community member vote (HumHub Developer spaces) — a supporting, visibility signal. Members of a product’s Developer space vote on proposals. The vote surfaces candidates and adds weight, but a popularity vote with no insider vouching does not by itself clear a gate that grants LDAP-Alpha.

There is no Community Board. Endorsement is not issued by any body; it is the combination of the two channels above. (The CNMCyber Community Board of earlier doctrine is abolished — see Changelog.)

Stage 2B — Recruitment (WiseNxt Track Lead). A Track Lead reviews endorsed candidates in the ERPNext recruitment module (bursar.opplet.com), interviews, and approves or declines. The endorsement credentials a candidate; the Track Lead’s decision is the actual pass/fail.

• Effect on approval: n8n-Alpha provisions an additional LDAP-Alpha account (LDAP-Beta retained per Constitution §12 Rule 2).
• What does not change: The callsign suffix. The same suffix identifies the participant in both directories.

Gate 3 — The Tech Board Gate (Award of a Paid Contract)

The top rung, where unpaid project work becomes a paid contract. The awarding body is the Tech Board (Constitution §16); the recruitment and disbursement mechanics are in the SOP. Summarized here for ladder completeness.

• Event: An Associate’s demonstrated work warrants compensation. Paid work takes one of two contract types — a project contract (one-time deliverable) or an operation contract (term-based running of a standing system).
• Authority: The Tech Board awards all paid contracts (it disburses Economic Group funds). WiseNxt Track Leads scope and recommend project contracts within their domain; the Tech Board scopes operation contracts itself.
• Effect: The Associate becomes a Contractor. No directory change — same LDAP-Alpha account, same callsign. The change is compensation and contract scope.

Gate 4 — The Custodian Partner Gate (reserved)

The ladder’s apex and the only gate that leads out of the internal hierarchy. A Contractor ready to run their own enterprise may enter a formal partnership with Opplet as a Custodian Partner — forking the open blueprints to stand up their own sovereign instance, becoming the custodian of their own root, and partnering back as an equal. The gate is owned by the Economic Group (Constitution §11 Gate 4); the Economic Group does not own the partner’s instance. Reserved — the name is fixed; the mechanics are TBD.

Future Calibration Gates

As of v3.0 the ladder has three live gates plus the reserved Gate 4 (Custodian Partner). Gate 3 fills the reservation that v2.0 left open; Gate 4 opens a new one. If a future revision activates Gate 4 or introduces further states, they will be defined here or in the Constitution, and should explicitly justify the addition rather than treat it as a default.

3. The Four Tracks and the Endorsement Pattern

WiseNxt is organized around four work-focus tracks. A track is a description of what you work on, not a state you hold. A Community member or Associate working on Engineering tasks is “focused on Engineering,” not holding any rank.

The four tracks describe project work focus. Operation contracts are operation-based, not track-based — running a standing system (e.g., a Moodle operation contract) is defined by the Tech Board’s contract types (Constitution §11 Gate 3, §16), not by one of these four tracks.

The endorsement pattern in one line: same kind of work, higher-trust environment, after demonstrated competence — and, at the top rung, compensated. Community work earns the Associate gate; Associate work earns the Contractor gate. Recruitment stays grounded in observable output, not self-reported qualification.

3A. Custodian Participation

Per Constitution v11.0 §12 Rule 4, the Custodian may optionally hold a Community membership in addition to their root role. This is uncommon — the Custodian already has root access to everything — but it serves a real purpose: it lets the Custodian participate as a peer rather than as the owner, hearing authentic conversation and giving feedback without the social weight of “the Custodian just replied to me.”

How it works in practice:

• The Custodian registers via commit.opplet.com exactly like any other candidate, under the standard 72-hour clock, and passes the same Moodle calibration.
• Upon passing, the Custodian holds both a root identity (by ownership) and an LDAP-Beta community account (by calibration), with separate, unconnected callsigns — IAM-generated for the community one.
• In community-facing services (HumHub, BookStack-Beta, Jitsi), the Custodian appears as their community callsign — just another two-word identifier.

Pseudonymous by default. The connection between the community callsign and the Custodian role is not disclosed by default; the community sees only a callsign. This honors the same anonymity protection extended to every other member (§5). The Custodian may disclose the connection at any time, and once disclosed it is permanent for that callsign; regaining pseudonymity requires purging the callsign and re-registering.

What the Custodian does not do as a community member:

• Does not apply for Gate 2 or Gate 3 recruitment — the Custodian already holds operational access by ownership; the ladder is for those who don’t.
• Does not exercise Custodian authority under the community callsign. Custodian actions — overrides, the veto, policy — are taken under the Custodian identity. Mixing the two would defeat the pseudonymity.

Honesty note. Pseudonymous participation by the owner is a privacy choice, not a deception. Rule 4 makes pseudonymity the architectural default, so the community knows in principle that any callsign could be the Custodian. If the connection is ever discovered, the Custodian should acknowledge it directly rather than deny it.

4. The 72-Hour Calibration Clock

New Community candidate accounts have 72 hours from account creation to pass the Moodle calibration. The clock applies to Gate 1 only — it keeps the candidate pool fresh and prevents dead accounts from accumulating. Once a candidate is promoted to member, the candidate account no longer exists and the clock no longer applies.

Mechanics:

• Trigger: Clock starts when n8n-Alpha provisions the LDAP-Beta candidate account on commit.opplet.com form submission.
• Reminders: At 24 hours remaining and 6 hours remaining, via Moodle messaging and registered email if provided.
• Expiry action: At T+72 with no pass, n8n-Alpha deletes the candidate account, releases the callsign suffix to the pool after a 30-day quarantine, and cleans up Moodle state.
• No cooldown. A purged candidate may re-register immediately; a new attempt starts a fresh 72-hour clock with a freshly generated suffix.
• What doesn’t count: Time spent waiting for the system. The clock is wall-clock time from successful account creation.

5. Callsign Generation

Every account is assigned a callsign at registration: a two-word combination from a curated WiseNxt wordlist of military-technical and signals/cryptographic terms.

Format: Word1-Word2. Examples: Echo-Bravo, Cipher-Tango, Sigma-Vector, Beacon-Compass.

No prefix, no rank suffix. The callsign is the participant’s only identifier across every service — Moodle at Gate 1, HumHub and BookStack-Beta after passing, GitLab and beyond after Gate 2, and unchanged through Gate 3. The same string identifies a Day-1 Community candidate and a multi-year Contractor.

Suffix generation:

• The wordlist is Custodian-controlled, maintained in BookStack-Alpha (the Grimoire, Constitution §6), and not published to participants.
• n8n-Alpha selects two distinct words uniformly at random, joined by a hyphen, with a collision check against active accounts; regenerate on collision.
• When an account is purged, its callsign returns to the pool after a 30-day quarantine.

Wordlist guidelines: PG-rated, non-controversial, free of references to real military operations, active service branches, real people, or real call signs. Generic military-technical and signals vocabulary (NATO phonetic alphabet, signals/cryptographic terms, generic operational nouns and verbs). Extensible by Custodian approval and a single-line update to the BookStack-Alpha wordlist page.

No real-world identity: No real name, email, or other personal identifier is displayed in any participant-facing service. Participants interact under their callsign exclusively, enforcing the meritocracy principle and protecting privacy.

6. Identity Stability Across Gates

Per Constitution §12 Rule 2 (Dual Membership), identity persists across all three gates:

• Gate 1 (CNMCyber): Same LDAP-Beta account; group change only (candidate → member). Same callsign.
• Gate 2 (WiseNxt): Additional LDAP-Alpha account provisioned; LDAP-Beta retained. Same callsign in both directories.
• Gate 3 (Tech Board): No new account, no directory change. Same LDAP-Alpha account; compensation and contract scope change only. Same callsign.

Why this matters: A participant’s HumHub posts, BookStack-Beta drafts, curation records, exam history, and contract history all attach to a single callsign-identified identity that persists from registration. Nothing about visible identity changes when a participant crosses a gate; only access and (at Gate 3) pay.

Dual membership also guarantees that every LDAP-Alpha holder still holds an LDAP-Beta member account, which is what lets Associates and Contractors read community surfaces and perform project-member curation (§2 Gate 2A) in their own right — no cross-zone exception required.

7. Operational Roles and Authority

This section names who does what, to prevent role-creep and authority confusion. The CNMCyber Community Board no longer exists; endorsement is a mechanism (§2), not a body.

The Recruitment Decision principle. The endorsement signal (vote + curation) is separate from the recruitment decision, and the two recruitment decisions are separate from each other. At Gate 2 the Track Lead decides; at Gate 3 the Tech Board decides; neither is decided by the endorsement mechanism, and neither body owns the other’s gate. This separation keeps any single actor from controlling the whole climb from community to paid contract.

8. Doctrine Versioning and Updates

The Doctrine is versioned independently of the Constitution. Revisions do not require Constitutional amendment unless they touch infrastructure (directory writes, automation triggers, URL changes, identity destruction) — in which case a paired Constitutional amendment is required (Constitution §13B).

Stored at: BookStack-Alpha (the Grimoire) as the canonical copy; mirrored to participant-facing reference in BookStack-Beta member shelves once published.

Change cadence: Substantive changes (new states, new tracks, changes to the endorsement workflow) require Custodian approval. Editorial changes may be made by Track Leads with Custodian notification.

Open question — never resolved here: What happens to this Doctrine if WiseNxt is assigned to a partner steward per Constitution §15B? The methodology is open source and assignable, but this specific implementation may or may not transfer with the brand. Reserved for future consideration.

Changelog

v3.1 (2026-06-10) — Tech Board Reference Alignment

• Operations Charter references repointed. The companion charter is abandoned; Gate 3’s awarding body is the Tech Board, defined in Constitution §16, with recruitment and disbursement mechanics in the SOP. The Tech Board’s seating now references §16 rather than the charter.
• No change to the ladder, the gates, callsigns, tracks, or endorsement.

v3.0 (2026-06-10) — The Three-Rung Ladder

• Two-state model → three-state ladder. Community / Track becomes Community member (LDAP-Beta) / WiseNxt Associate (LDAP-Alpha, unpaid) / Contractor (LDAP-Alpha, paid). The directory boundary sits between rungs 1 and 2; rung 2 → 3 changes pay and contract scope, not directory.
• Gates named and numbered to three (§2). Gate 1 (CNMCyber), Gate 2 (WiseNxt), Gate 3 (Tech Board), filling the reservation v2.0 left open.
• CNMCyber Community Board abolished (§2, §7). Endorsement is now a two-channel mechanism: project-member curation (necessary) plus community member vote (supporting). No board issues endorsements.
• Endorsement rule set (§2 Gate 2A). Curation is necessary; the vote is supporting and not independently sufficient; the Track Lead’s decision is the actual pass/fail.
• §7 rebuilt around WiseNxt Track Lead, Tech Board, Economic Group, and Custodian. “Sovereign Choice” becomes “the Recruitment Decision.”
• Owner renamed Custodian throughout; §3A becomes Custodian Participation, paired with Constitution v11.0 §12 Rule 4.
• Gate 3 summarized here, detailed in Constitution §16 and the SOP (the Tech Board and its mechanics).
• Preserved: the 72-hour clock (§4), permanent two-word callsigns and wordlist governance (§5), the four work-focus tracks, identity stability across gates (§6).

v2.1 (2026-06-03) — Sovereign Participation

• §3A added, documenting the owner optionally holding a Community membership with pseudonymous participation as the default. (Carried into v3.0 as Custodian Participation.)

v2.0 (2026-06-02) — Rank Abandonment

• The five-rank ladder (L0–L4) and track-specific rank prefixes were abandoned in favor of a two-state model. Callsigns simplified to a single permanent two-word combination. Tracks reframed as work focus, not ranks. (The two-state model is itself superseded by the three-rung ladder in v3.0; the no-rank principle is retained.)

v1.0 (2026-05-29) — Initial Release (superseded)

• Established the five-rank ladder, callsign generation, calibration gates, endorsement workflow, and aspirational pod structure.

END OF DOCTRINE

• Opplet Master Architecture: Enclave Constitution, URL Strategy
• Opplet Operations: Enclave SOP, Hardware Manifest, Software Stack
• Opplet Development Plan: Den Migration