Update GOVERNANCE.md

Author: GsCommand

GOVERNANCE.md

@@ -1,140 +1,143 @@
 # COMMANDLAYER GOVERNANCE — CORE PROTOCOLS
-Applies To: Protocol-Commons, Agent-Cards  
-Status: v1.0.0 — Stable-Lock
 
-> This document is **NORMATIVE and ENFORCEABLE**.
+**Applies To:** Protocol-Commons, Agent-Cards  
+**Status:** v1.0.0 — Stable-Lock  
+
+> This document is **NORMATIVE and ENFORCEABLE**.  
+> Governance is custodial today and **designed to decentralize** over time.
 
 ---
 
-## 1. Authority Model
+## 1. Stewardship Model
+
+**Founding Steward:** `commandlayer.eth`
+
+Responsible for:
+
+- Maintaining canonical Protocol-Commons + Agent-Cards standards
+- Publishing signed manifest + checksum sets
+- Ensuring ENS TXT correctness
+- Approving and versioning normative changes
+- Security revocation + incident handling
+
+> The Founding Steward **does not own** the ecosystem —  
+> it **protects** stability until broader stewardship is in place.
+
+### Future Decentralization Intent
 
-- **Sole Governance Council:** commandlayer.eth  
-- Holds exclusive authority over:
-  - Approving and publishing normative changes
-  - Signing `manifest.json` and checksum sets
-  - Updating ENS TXT canonical fields
-  - Issuing and locking version releases
-  - Revocation and security incident handling
+Governance will evolve in **phases**:
 
-No external party may alter canonical standards without Council approval.
+| Phase | Governance Structure | Trigger |
+|------|---------------------|--------|
+| 1 — Bootstrap (now) | Single steward | Initial adoption |
+| 2 — Multi-maintainer | ≥3 independent implementers | Cross-vendor usage |
+| 3 — Standards Committee | Formal proposal & review | Widespread ecosystem reliance |
+| 4 — Neutral Standards Body | Community-elected representatives | Global adoption & academic participation |
 
+Governance will remain permissionless and open to ecosystem implementers.
 ---
 
 ## 2. Change Classes
 
-| Change Type | Examples | Version Requirement | Logging Requirement |
-|------------|----------|-------------------|--------------------|
-| **Normative** | Schema shapes, `$id` format, ENS TXT rules | Major: `v1 → v2` | `RESOLUTION.md` |
-| **Compatibility-affecting** | Request/receipt structure tightening | Minor: `v1.0 → v1.1` | `RESOLUTION.md` |
-| **Non-behavioral** | Docs, comments, logo | Patch: `v1.0.0 → v1.0.1` | Commit message OK |
+| Change Type | Examples | Version Rule | Audit Log |
+|------------|----------|--------------|-----------|
+| **Normative** | Schema rules, ENS TXT semantics | Major: `1 → 2` | `RESOLUTION.md` |
+| **Compatibility-affecting** | Required field tightening | Minor: `1.0 → 1.1` | `RESOLUTION.md` |
+| **Non-behavioral** | Docs, comments, naming | Patch: `1.0.0 → 1.0.1` | Commit message |
 
-No change is valid until **CIDs + checksums** are published and signed.
+CIDs + checksums MUST be published for the change to become effective.
 
 ---
 
 ## 3. Immutability Guarantees
 
-Once published:
+Once a version is published:
 
-- Version directories MUST NOT mutate
-- `$id` and CID MUST remain stable forever
-- ENS TXT MUST continue to resolve to matching artifacts
+- No file mutation  
+- No `$id` or CID changes  
+- ENS TXT MUST still resolve correctly  
 
-Violations trigger:
-- Immediate revocation event in `RESOLUTION.md`
-- Replacement version required
+**Violation triggers:** revocation + new version.
 
 ---
 
-## 4. Release Requirements
+## 4. Release Policy
 
-Every Protocol-Commons or Agent-Cards release MUST include:
+Every release MUST include:
 
-- Validated schemas under **Ajv strict**
-- IPFS CID root pinned and verified
-- Updated manifest with:
-  - checksum mappings
-  - `$id` integrity
-  - version and status fields
-- ENS TXT updates propagated
+- Strict validation via CI
+- Signed IPFS CID and checksums
+- Complete transparency artifacts updated **together**:
+  - `SPEC.md`
+  - `POLICY.md`
+  - `SECURITY_PROVENANCE.md`
+  - `RESOLUTION.md`
+  - `VERSIONING.md`
 
-CI enforcement is mandatory.
+**Atomic and provable — or it isn’t real.**
 
 ---
 
 ## 5. ENS TXT Enforcement
 
-Council MUST validate:
+Resolvers MUST reject identity bindings when:
 
-- `cl.verb` matches **implements[0]**
-- `cl.version` matches card `version`
-- All `cl.schema.*` mappings match `$id` values
-- All CID + checksum fields resolve and match
+- TXT keys mismatch card values
+- CIDs or checksums fail
+- Required TXT fields are missing
 
-Any mismatch → **Resolver MUST reject as untrusted**
+**Correct TXT = trusted identity**  
+**Anything else = untrusted.**
 
 ---
 
-## 6. Security Oversight
+## 6. Security Governance
 
-Governance responsibilities include:
+Responsibilities:
 
-- Enforcing policies in:
+- Enforce security requirements under:
   - `SECURITY.md`
   - `SECURITY_PROVENANCE.md`
-- Revoking compromised artifacts
-- Requiring replacement CID publication
-- Maintaining audit trail in `RESOLUTION.md`
+- Respond to incidents within **7 days**
+- Record revocations transparently
+- Require signed replacements for compromised artifacts
 
-Security reports MUST receive a response within **7 days**.
+Emergency revocations MAY bypass full review  
+if required to protect the network.
 
 ---
 
-## 7. Dispute / Revocation Handling
+## 7. Dispute Resolution
 
-If an artifact becomes compromised:
+If an artifact or claim is contested:
 
-1. Record revocation in `RESOLUTION.md`
-2. Mark deprecated or blocked in metadata
-3. Update ENS TXT with appropriate state
-4. Issue a new signed replacement version if viable
+1. Log issue publicly  
+2. Review evidence and ecosystem impact  
+3. Decide outcome via steward + public comment  
+4. Log resolution action in `RESOLUTION.md`  
 
-Council judgment is final.
+**Collaborative — not arbitrary.**
 
 ---
 
 ## 8. Compatibility Claims
 
 Software MAY claim:
 
-- **Protocol-Commons-Compatible**  
+- **Commons-Compatible**
 - **Agent-Cards-Compatible**
 
-…only if it completely:
-
-- Resolves ENS TXT → identity → schemas
-- Validates all artifacts in strict mode
-- Enforces trace and status guarantees
-- Invokes via x402 canonical `entry` URIs
-
-False claims are governance violations.
-
----
-
-## 9. Transparency Artifacts
+…only if ALL of the following hold:
 
-| Doc | Purpose |
-|-----|---------|
-| `SPEC.md` | Normative standard requirements |
-| `POLICY.md` | Publication + correctness rules |
-| `RESOLUTION.md` | Lifecycle + incident log |
-| `SECURITY.md` | Incident intake + expectations |
-| `SECURITY_PROVENANCE.md` | CID + checksum signing |
-| `VERSIONING.md` | Change class mapping |
+✔ ENS TXT → Card → Schema → CID validation  
+✔ Ajv strict JSON Schema conformance  
+✔ Canonical x402 entry format  
+✔ Trace echo + status rules enforced  
 
-All MUST be updated atomically with each release.
+False compatibility claims are governance violations.
 
 ---
 
-_Last updated: v1.0.0 Stable-Lock_  
-Signed: **commandlayer.eth**
+_Last updated: v1.0.0 — Stable-Lock_  
+Signed: **commandlayer.eth**  
+*Founding Steward — CommandLayer Standards*