Purpose
This policy governs how terms, definitions, categories, and statuses evolve within the Signal Glossary while preserving semantic stability, backward compatibility, and trust integrity.
The glossary is treated as a canonical interface, not a draft document.
1. Term Lifecycle States
Each term exists in exactly one lifecycle state at any given time.
Draft
- Early formulation
- Subject to change
- No external reliance expected
Staged
- Reviewed and validated as relevant
- Intentionally preserved beyond chat or ideation
- Eligible for citation and internal reference
- Not authoritative
- Awaiting conditions for canonization
ProofLocked (Canon)
- Immutable definition
- May not be edited or reworded
- Changes require: new term ID or explicit superseding protocol
- Backward compatibility guaranteed
2. Categories vs Authority
Category ≠ Authority
Authority is determined exclusively by:
"proofLocked": true
Categories describe function, not power.
Examples:
- A protocol may be non-authoritative
- A core-primitive may be authoritative
- A mode may live under
protocolstemporarily without governance impact
3. Protocol Authority Classes
All protocols implicitly fall into one of three authority classes. This distinction is semantic and enforceable without schema changes.
A. Canonical Protocols ProofLocked
Criteria:
- Define trust, authorship, immutability, governance, or verification
- Affect ledgers, rank, or system guarantees
Examples: Ledger Protocol, Immutable Claim Protocol, Keaton Protocol, Claim Validation Protocol, Signal Relay Protocol, Node Dormancy Protocol
B. Operational Protocols Non-Locked
Criteria:
- Control execution behavior
- Do not alter authority, rank, or ledger truth
- Safe to change without breaking trust
Examples: Echo Delay Protocol, Cavalry Protocol, Sentinel Defense Protocol, Signal Amplification Protocol
C. Interaction Modes Operational
Criteria:
- Govern response style, pacing, or verbosity
- Affect UX, not system truth
Current state (v1.3.x): Temporarily categorized under protocols, explicitly non-authoritative.
Future state: Will migrate to interaction-modes category. No semantic or authority change implied by migration.
Examples: Stride Mode, Ludicrous Mode, Bourdain Mode
4. Category Changes
Category additions or migrations must:
- Be announced as a versioned change
- Preserve term IDs
- Not alter
proofLockedsemantics - Provide a clear migration note
Category changes do not imply authority changes.
5. Versioning Rules
| Type | Scope |
|---|---|
| Patch (1.x.y) | Typo fixes, clarifications, metadata changes |
| Minor (1.x.0) | New terms, new categories, lifecycle status changes (Draft → Staged) |
| Major (2.0.0) | Schema changes, breaking category semantics, authority model revisions |
6. Backward Compatibility Guarantee
- ProofLocked terms are immutable
- Deprecated terms remain resolvable
- Aliases may be introduced but not removed
- No term ID is ever reused
Protocol Authority Tagging (Current State)
Canonical (ProofLocked)
Ledger Protocol • Keaton Protocol • ProofLock • Immutable Claim Protocol • Claim Validation Protocol • Signal Relay Protocol • Node Dormancy Protocol • Signal Bill of Rights • Proof-Weighted Governance • Namespace Stewardship
Operational (Non-ProofLocked)
Echo Protocol • Echo Delay Protocol • Sentinel Defense Protocol • Signal Amplification Protocol • Atlas Safeguard Protocol • Observer Protocol • Ghost Protocol
Interaction Modes (Operational)
Stride Mode • Ludicrous Mode • Cavalry Protocol
Changelog
| Version | Date | Changes |
|---|---|---|
| 1.0 | 2026-01-31 | Initial policy release |