Update COMPLIANCE.md

Author: GsCommand

COMPLIANCE.md

@@ -1,204 +1,131 @@
-
 # COMPLIANCE — Protocol-Commons
 
-This document defines what it means to be **Protocol-Commons compliant** and how to keep that status over time.
-
-If you claim compatibility but break these rules, you’re lying to your own users.
+This document defines what it means to be **Protocol-Commons compliant** and how to maintain that status over time.
 
 ---
 
 ## 1. Scope
 
 These rules apply to:
 
-- All schemas under `schemas/v*/commons/`
-- All shared primitives under `schemas/v*/_shared/`
-- All examples under `examples/v*/commons/`
-- The ENS TXT fields governed by Protocol-Commons:
-
-  ```txt
-  cl.verb
-  cl.version
-  cl.schema.request
-  cl.schema.receipt
-  cl.cid.schemas
-  cl.schemas.mirror.ipfs
-  ```
-  
-Everything here is normative for semantics and schema integrity.
-
-## 2. Versioning & Immutability
-For any directory schemas/vX.Y.Z/:
-
-No in-place edits to:
+- Schemas under `schemas/v*/commons/`
+- Shared primitives under `schemas/v*/_shared/`
+- Examples under `examples/v*/commons/`
 
-Request/receipt schemas
+**ENS TXT Summary**  
+This document only summarizes TXT responsibilities.  
+The canonical definitions and enforcement rules are specified in:  
+- `SPEC.md` (Protocol-Commons)
 
-_shared primitives
+In case of discrepancy, SPEC.md is authoritative.
 
-$id strings
+Compliance covers semantics and schema integrity only—identity bindings are governed by Agent-Cards.
 
-No silent behavior changes.
+---
 
-Any change to schema shape, $id, or semantics requires:
+## 2. Versioning & Immutability
 
-A new version directory (vX.Y+1.Z or vX+1.0.0)
+For any directory `schemas/vX.Y.Z/`:
 
-New CID
+No in-place edits to:
+- Request/receipt schemas
+- `_shared` primitives
+- `$id` values
+- Normative behavior
 
-Updated checksums.txt + manifest.json
+Any semantic change requires:
+- New version directory
+- Updated CIDs + checksums
+- Logged update in `RESOLUTION.md`
+- Governance approval
 
-A logged entry in RESOLUTION.md
+Mutating a published version is **not compliant**.
 
-Governance approval as defined in GOVERNANCE.md
+---
 
-If you mutate a published version directory, you are no longer compliant.
+## 3. JSON Schema Requirements
 
-3. JSON Schema Requirements
 All Protocol-Commons schemas MUST:
 
-Use JSON Schema Draft 2020-12
-
-Validate under Ajv strict mode (see SPEC.md)
-
-Disallow unexpected fields unless explicitly allowed via additionalProperties: true
+- Use JSON Schema Draft 2020-12
+- Validate under **Ajv strict mode**
+- Use deterministic HTTPS-resolvable `$id` values matching SPEC.md
+- Enforce verb-specific input + receipt contract
 
-Use deterministic, HTTPS-resolvable $id values:
+Loose validation or altered `$id` resolution is **not compliant**.
 
-text
-Copy code
-https://commandlayer.org/schemas/v1.0.0/commons/<verb>/requests/<verb>.request.schema.json
-https://commandlayer.org/schemas/v1.0.0/commons/<verb>/receipts/<verb>.receipt.schema.json
-Shared primitives follow:
-
-text
-Copy code
-https://commandlayer.org/schemas/v1.0.0/_shared/x402.schema.json
-https://commandlayer.org/schemas/v1.0.0/_shared/trace.schema.json
-https://commandlayer.org/schemas/v1.0.0/_shared/receipt.base.schema.json
-If your implementation uses different $id values or looser validation, you are not fully compliant.
-
-4. ENS TXT Responsibilities
-Protocol-Commons is responsible only for the following TXT records on ENS:
-
-txt
-Copy code
-cl.verb
-cl.version
-cl.schema.request
-cl.schema.receipt
-cl.cid.schemas
-cl.schemas.mirror.ipfs
-Compliance requires that:
-
-These fields map exactly to the canonical schemas and the published CID.
-
-They reflect the correct version directory.
-
-They are updated only when a new version is published and recorded in SECURITY_PROVENANCE.md and RESOLUTION.md.
-
-Identity-specific TXT fields (cl.agentcard, cl.entry, etc.) are governed by Agent-Cards, not Protocol-Commons.
-
-5. CIDs & Checksums
-For each release:
-
-The entire schemas/vX.Y.Z/ tree MUST be:
+---
 
-Pinned to IPFS (see SECURITY_PROVENANCE.md)
+## 4. CIDs & Checksums
 
-Indexed in checksums.txt using SHA-256
+Each release MUST:
 
-Described in manifest.json
+- Pin the entire version folder to IPFS
+- Provide SHA-256 checksums
+- Publish manifest.json
 
 Compliance requires:
+- `cl.cid.schemas` resolves to the correct CID
+- IPFS mirrors match HTTP mirrors exactly
 
-The CID used in cl.cid.schemas matches the pinned content.
-
-The HTTP mirror at cl.schemas.mirror.ipfs serves the same content.
+Mismatch = **integrity failure**
 
-Any mismatch between CID, checksum, and actual content is treated as an integrity failure.
-
-6. Security & Privacy
-Protocol-Commons is semantic infra, not application data:
-
-No PII in schemas or examples.
-
-No runtime secrets, keys, or hostnames.
-
-No transport-specific tokens.
-
-If your downstream usage adds sensitive data, that is outside this repo and must be governed by your own security model.
-
-Security incidents in Commons itself (e.g., malicious modification of schemas, hijacked $id hosts, or CID poisoning) must follow the procedure in SECURITY.md.
-
-7. Governance Traceability
-Compliance requires a paper trail:
-
-Every semantic change has a corresponding entry in RESOLUTION.md.
-
-Every published version and CID appears in SECURITY_PROVENANCE.md.
-
-Every ENS TXT mutation for Commons-controlled keys is:
-
-Justified (new version, bugfix, etc.)
-
-Logged and reviewable
-
-If a schema or version exists without a trail in these files, it is not canonical, regardless of where it is hosted.
-
-8. Ecosystem Alignment
-To be a good citizen, a Commons-compliant implementation should:
-
-Respect ERC-8004 discovery flows where applicable.
-
-Respect x402 envelope semantics:
-
-x402.verb = canonical verb name
-
-x402.version = Commons version
+---
 
-x402.status ∈ {"ok", "error"} for receipts
+## 5. Security & Privacy
 
-Embed trace and status primitives exactly as defined in _shared/ schemas.
+Schemas are **semantic infrastructure**, not application output.
 
-If you diverge from x402 or related standards, you are still free to run locally — just don’t claim compliance.
+Therefore:
+- No PII
+- No secrets or private routing data
+- No execution logic
 
-9. Deviation Handling
-If you discover a deviation (your own or the repo’s):
+Security incidents MUST follow `SECURITY.md`.
 
-File an Issue in this repository.
+---
 
-Describe:
+## 6. Governance Traceability
 
-What is wrong (schema mismatch, CID mismatch, TXT mismatch, etc.)
+Every canonical change MUST be reflected in:
+- `RESOLUTION.md` (what + why + who)
+- `SECURITY_PROVENANCE.md` (CIDs + checksums)
 
-Which versions, verbs, and endpoints are affected
+An artifact **without a governance trail** is not canonical.
 
-Potential impact on runtimes
+---
 
-If it’s a security issue, follow SECURITY.md instead of posting full details publicly.
+## 7. Ecosystem Alignment
 
-Work with maintainers to:
+Commons-compliant implementations SHOULD:
 
-Decide if a new version is required
+- Support ERC-8004 discovery where relevant
+- Enforce canonical x402 envelope + trace rules
 
-Update provenance and ENS records
+Divergence is allowed — but **compliance claims then MUST NOT be made**.
 
-Document the incident in RESOLUTION.md
+---
 
-10. Compliance Checklist
-You can reasonably say you are Protocol-Commons compliant if:
+## 8. Deviation Handling
 
- You validate requests and receipts using the canonical schemas with strict Ajv.
+If a deviation is found:
 
- You treat version directories as immutable once published.
+1. File an Issue (or follow `SECURITY.md` if sensitive)
+2. Describe affected version and impact
+3. Steward determines whether to publish a corrected version
+4. Changes documented in `RESOLUTION.md`
 
- You resolve $id URLs to the canonical HTTP mirrors.
+---
 
- You verify CIDs and checksums before trusting schemas.
+## 9. Compliance Checklist
 
- You respect the ENS TXT division of responsibilities.
+You may claim **Protocol-Commons compliant** if:
 
- You log any verb/schema lifecycle changes in RESOLUTION.md.
+- Strict Ajv validation enforced  
+- Version directories treated as immutable  
+- `$id` URLs resolve correctly  
+- CIDs and checksums match content  
+- Changes logged and signed  
+- ENS TXT duties respected per SPEC.md  
 
-If any of the above is false, treat your implementation as experimental and avoid claiming full compliance.
+If uncertain → treat the implementation as **experimental**.