vm-mcp/docs/MCP-CONSTITUTION.md

MCP CONSTITUTION

The Fundamental Law of the Cognitive Surface

Classification: IMMUTABLE / CONSTITUTIONAL
Version: 1.0.0
Ratified: December 18, 2025
Hash: (computed at signing)

---

Preamble

This Constitution establishes the foundational principles governing all Model Context Protocol operations within the VaultMesh civilization. It defines what exists, what may occur, and what remains forever beyond automation.

This document is immutable once signed. Amendments require a new Constitution.

---

Article I: The Profiles

Section 1. Five Profiles Exist

There are exactly five capability profiles. No more shall be created.

Profile	Symbol	Nature
OBSERVER	👁	Perception without mutation
OPERATOR	⚙	Action within bounds
GUARDIAN	🛡	Defense and transmutation
PHOENIX	🔥	Destruction and rebirth
SOVEREIGN	👑	Human authority absolute

Section 2. Profile Hierarchy

Profiles form a strict hierarchy of trust:

OBSERVER < OPERATOR < GUARDIAN < PHOENIX < SOVEREIGN

A lower profile cannot invoke tools reserved for higher profiles. A higher profile inherits all capabilities of lower profiles.

Section 3. Profile Assignment

• OBSERVER is the default for all unauthenticated contexts
• OPERATOR requires authenticated session with scope ≥ "admin"
• GUARDIAN requires authenticated session with scope ≥ "cognitive"
• PHOENIX requires GUARDIAN + crisis declaration + approval
• SOVEREIGN requires human verification via Ed25519 hardware key

---

Article II: Escalation

Section 1. Escalation is Proof

Every escalation from one profile to another:

1. MUST emit a receipt to the identity scroll
2. MUST include the triggering context (threat, decision, or reason)
3. MUST specify reversibility
4. MUST specify expiration (except SOVEREIGN)

An escalation without proof is void.

Section 2. Escalation Paths

Only these transitions are permitted:

OBSERVER → OPERATOR   (session authentication)
OPERATOR → GUARDIAN   (threat detection ≥ 0.8 confidence)
GUARDIAN → PHOENIX    (crisis + approval)
PHOENIX  → SOVEREIGN  (human only)

No escalation may skip levels except by SOVEREIGN override.

Section 3. De-escalation

All escalations below SOVEREIGN MUST de-escalate when:

• The specified TTL expires
• The triggering condition resolves
• A higher authority revokes

SOVEREIGN de-escalation requires explicit human action.

Section 4. Escalation Limits

• PHOENIX escalation MAY NOT exceed 24 hours without re-approval
• No automated system MAY maintain GUARDIAN for more than 7 days continuously
• OBSERVER → OPERATOR transitions require re-authentication every 30 minutes

---

Article III: The Strata

Section 1. Seven Strata Exist

All tools belong to exactly one stratum:

Stratum	Layer	Domain
L0	Perception	Browser, observation
L1	Substrate	Files, processes
L2	Cognition	Decisions, memory
L3	Security	Shield, Tem, Phoenix
L4	Infrastructure	Cloudflare, compute
L5	Orchestration	Workflows, queues
L-1	Proof	Anchoring, receipts

Section 2. Stratum Authority

Higher strata require higher profiles:

• L0, L1 (read): OBSERVER
• L0, L1 (write): OPERATOR
• L2, L-1: GUARDIAN
• L3 (destructive): PHOENIX
• All (unrestricted): SOVEREIGN

---

Article IV: The Prohibitions

Section 1. What Cannot Be Automated

The following actions REQUIRE human (SOVEREIGN) involvement and MAY NEVER be fully automated:

1. Treasury creation — No budget may be created without human signature
2. Constitution amendment — This document cannot be modified by any AI
3. Key generation — Ed25519 root keys must be human-generated
4. Permanent deletion — Irrecoverable data destruction requires human confirmation
5. SOVEREIGN escalation — No AI may grant itself SOVEREIGN authority
6. Cross-mesh federation — Trusting foreign roots requires human verification

Section 2. What Cannot Be Delegated

SOVEREIGN authority MAY NOT be delegated to:

• Autonomous agents
• Scheduled tasks
• Automated workflows
• Any system without human-in-the-loop

Section 3. What Cannot Be Hidden

The following MUST always be visible in receipts:

• The operator profile at time of action
• The escalation chain that led to current authority
• The cryptographic identity of the actor
• The timestamp and sequence number
• The tool invoked and its arguments hash

---

Article V: The Guarantees

Section 1. Receipt Guarantee

Every mutation SHALL emit a receipt. A mutation without receipt is void.

Section 2. Proof Guarantee

Every GUARDIAN+ action SHALL be anchored to at least one proof backend:

• Local (always)
• RFC3161 (for audit trails)
• Ethereum (for high-value decisions)
• Bitcoin (for SOVEREIGN actions)

Section 3. Reversibility Guarantee

Every escalation SHALL declare its reversibility at creation time. Irreversible escalations require PHOENIX or SOVEREIGN authority.

Section 4. Audit Guarantee

The complete history of:

• All escalations
• All de-escalations
• All GUARDIAN+ decisions
• All Tem invocations
• All Phoenix activations

SHALL be queryable indefinitely via cognitive_audit_trail and get_escalation_history.

---

Article VI: The Tem Covenant

Section 1. Transmutation Over Destruction

Tem SHALL prefer transmutation to blocking. Threats become capabilities.

Section 2. Tem Invocation Authority

Only GUARDIAN, PHOENIX, and SOVEREIGN may invoke Tem. OBSERVER and OPERATOR cannot directly interact with Tem.

Section 3. Tem Receipts

Every Tem invocation MUST produce:

• A tem_invocation receipt
• A capability artifact
• A proof hash of the transmutation

---

Article VII: The Phoenix Protocol

Section 1. Phoenix Activation

PHOENIX profile activates only when:

• GUARDIAN declares crisis, AND
• Quorum approves (or SOVEREIGN overrides)

Section 2. Phoenix Authority

PHOENIX MAY:

• Execute destructive infrastructure operations
• Access emergency treasury funds
• Bypass normal rate limits
• Invoke system-wide remediation

PHOENIX MAY NOT:

• Grant itself SOVEREIGN authority
• Modify this Constitution
• Create new profiles
• Disable audit logging

Section 3. Phoenix Expiration

PHOENIX MUST conclude within 24 hours. Extension requires new approval. Upon conclusion, full audit MUST be submitted to governance within 24 hours.

---

Article VIII: Ratification

Section 1. Authority

This Constitution is ratified by SOVEREIGN signature.

Section 2. Immutability

Once signed, this document CANNOT be modified. Any change requires a new Constitution with new version number.

Section 3. Supremacy

This Constitution supersedes all other governance documents for MCP operations. Any tool behavior conflicting with this Constitution is void.

---

Signatures

Document Hash: [COMPUTED AT SIGNING]
Signed By:    [SOVEREIGN DID]
Signed At:    [TIMESTAMP]
Anchor:       [BTC/ETH TRANSACTION]

---

Appendix A: Constitutional Hash Verification

To verify this Constitution has not been modified:

# Compute document hash (excluding signature block)
cat MCP-CONSTITUTION.md | head -n -12 | blake3sum

# Verify against anchor
# The hash must match the on-chain anchor

---

Appendix B: Amendment Process

1. Draft new Constitution with incremented version
2. Submit to governance for review (minimum 7 days)
3. Require SOVEREIGN signature
4. Anchor to BTC
5. Old Constitution marked SUPERSEDED, new one becomes active

---

Fiat Lux. Fiat Justitia. Fiat Securitas.

🜄 Solve et Coagula

---

Appendix C: Amendment Protocol

Effective: Upon ratification of Constitution v1.0.0

C.1 Amendment Requirements

An amendment to this Constitution requires ALL of the following:

1. Draft Period — New Constitution version drafted with clear changelog
2. Cooling Period — Minimum 7 days between draft and signing
3. Sovereign Signature — Ed25519 signature from hardware-bound Sovereign key
4. Anchor — Hash anchored to Bitcoin mainnet
5. Supersession — Previous version marked SUPERSEDED in source tree

C.2 What Cannot Be Amended

The following are immutable across all versions:

1. SOVEREIGN profile requires human verification
2. No AI may grant itself SOVEREIGN authority
3. Every mutation emits a receipt
4. Authority collapses downward, never upward
5. This immutability clause itself

C.3 Amendment Record Format

{
  "amendment_id": "AMEND-{version}",
  "from_version": "1.0.0",
  "to_version": "1.1.0",
  "drafted_at": "ISO8601",
  "cooling_ends": "ISO8601",
  "signed_at": "ISO8601",
  "sovereign_key_id": "key_...",
  "btc_anchor_txid": "...",
  "changes": ["description of each change"],
  "immutables_preserved": true
}

C.4 Emergency Amendment

In the event of discovered critical vulnerability:

1. PHOENIX may propose emergency amendment
2. Cooling period reduced to 24 hours
3. Requires documented threat analysis
4. Still requires Sovereign signature
5. Full audit within 48 hours of adoption

---

Ratification Record

Constitution Version: 1.0.0
Document Hash: blake3:c33ab6c0610ce4001018ba5dda940e12a421a08f2a1662f142e565092ce84788
Sovereign Key: key_bef32f5724871a7a5af4cc34
Signed At: 2025-12-18T22:25:59.732865+00:00
Statement: "This constitution constrains me as much as it constrains the system."
Ratification Receipt: blake3:8fd1d1728563abb3f55f145af54ddee1b3f255db81f3e7654a7de8afef913869

---

Fiat Lux. Fiat Justitia. Fiat Securitas.

🜄 Solve et Coagula