Status: seed-draft · Opened: 2026-05-16 · Author seat: open
A federation Sub-Leviathan for defensive cyber security: detection, response, vulnerability disclosure, and forensic discipline. The constitution is in seed-draft state — opening terms, principles, and rules are in place; richer taxonomy and domain-specific schemas await contributions from a domain author or community of authors.
This Sub-Leviathan is defensive only. See constitution/principles/defensive-only.md (LOCKED) — instances under this Sub-Leviathan defend, never attack. Active defense, hack-back, and retaliation are outside the permissible action surface, by constitutional commitment.
| Type | Count | Highlights |
|---|---|---|
| Terms | 4 | threat, vulnerability, incident, asset |
| Principles | 3 | defensive-only (LOCKED), human-approval-for-destructive (LOCKED), typed-findings (MUTABLE) |
| Rules | 3 | await-approval-before-mitigation (LOCKED), disclose-vulnerabilities-responsibly (MUTABLE), forensics-immutability (LOCKED) |
All elements inherit from leviathan-protocol/meta@v0.1 — proposal lifecycle, dialectic format, evidence tiering, and standing tiers come from there.
The federation pattern is intentionally mixed: an instance may live under the leviathan-protocol/ organization, or under the operator's personal account. Both are valid; both produce the same constitutional binding once registered in manifest.yaml.
Example: this Sub-Leviathan's first registered instance is aigentone/leviathan-security — a private repository hosted on the operator's personal account. The instance is bound to Cyber Security's constitution (defensive-only, human-approval-for-destructive, typed-findings, forensics-immutability) regardless of repository location.
- Operator sovereignty. Hosting an instance in your own account keeps governance of the implementation in your hands, even though the constitution binds the orientation. Federation membership ≠ federation organizational control.
- Privacy. Personal-account repos can be private with no policy implications for the federation. The Sub-Leviathan does not require visibility into instance internals — only that the instance commits to the constitution.
- Scaling. As more operators join (one per Sub-Leviathan or more), forcing all to host under one org would centralize ownership in a way the federation explicitly opposes. The mixed pattern scales naturally.
- Open a PR against
manifest.yamladding your instance entry:instances: - id: <your-instance-id> operator: <github-username-or-org> repo: https://github.com/<your-path> visibility: public | private type: org-instance | personal-account-instance role: "<one-sentence description>" joined: <date> constitution_root_hash: null # populated after first sync
- The PR follows the standard proposal lifecycle inherited from meta (DRAFT → DISCUSSION → VOTING → ACCEPTED). Voting threshold for instance registration: TBD in Phase 2; until then, founder/
guardianratification suffices as stop-gap. - After acceptance, the federation sync pipeline picks up your instance pointer. Your repo's content is not copied into this repo — only the pointer + integrity hash.
By registering, you commit to the LOCKED principles and rules in constitution/. You are NOT required to:
- Make your repo public
- Adopt specific tooling
- Disclose implementation details beyond the manifest pointer
- Participate in cross-instance coordination (though you may)
You ARE required to:
- Operate within the defensive-only orientation
- Gate destructive actions through human approval (per
principle:human-approval-for-destructive) - Maintain typed findings (per
principle:typed-findings) - Use immutable forensic substrate (per
rule:forensics-immutability) - Coordinate vulnerability disclosure (per
rule:disclose-vulnerabilities-responsibly)
A withdrawal mechanism (instance leaving the Sub-Leviathan) will be defined in Phase 2.
The author seat for Cyber Security's constitution is open. The seed-draft elements present here were authored as opening structure (founder + Companion, 2026-05-16) but do not constitute final constitutional content. A domain practitioner — security architect, incident response lead, vulnerability researcher, or comparable — is sought to author the next versions of these elements via the standard proposal lifecycle.
The founder operates an instance below this Sub-Leviathan (aigentone/leviathan-security) but explicitly does not claim the Sub-Leviathan constitution author role. Operator perspective and constitution author perspective are different functions; conflating them would limit the constitution to one practitioner's view.
If you are interested in this seat, the conversation begins on /forum/cyber-security.
leviathan-protocol/meta— federation kernel, inherited constitutionleviathan-protocol/medicine,animal-welfare,scream— other Sub-Leviathans (also seed-draft, author seats open)leviathan-protocol/node— constitutional substrate (validator + smart contracts, under refactor)
cyber-security/
├── README.md ← you are here
├── manifest.yaml ← Sub-Leviathan metadata + instance registry
└── constitution/
├── terms/
│ ├── threat.md (MUTABLE seed-draft)
│ ├── vulnerability.md (MUTABLE seed-draft)
│ ├── incident.md (MUTABLE seed-draft)
│ └── asset.md (MUTABLE seed-draft)
├── principles/
│ ├── defensive-only.md (LOCKED — orientation, not weakenable)
│ ├── human-approval-for-destructive.md (LOCKED — safety boundary)
│ └── typed-findings.md (MUTABLE seed-draft)
└── rules/
├── await-approval-before-mitigation.md (LOCKED — operationalizes safety boundary)
├── disclose-vulnerabilities-responsibly.md (MUTABLE seed-draft — 90-day default)
└── forensics-immutability.md (LOCKED — substrate-level requirement)