Protocol Change Process

last updated: 2026-02-27

This chapter defines the standard lifecycle for making changes to Scintilla Locate under SDD governance.

Change classes

• Docs-only: explanatory text, no protocol effects
• Non-breaking protocol change: additive or clarifying, preserves existing behavior
• Breaking protocol change: changes normative semantics; requires version bump

Mandatory artifacts

Any change that affects protocol semantics, canonicalization, mappings, disputes, or economics MUST include:

• ADR (if the change is governance-level)
• updated normative spec text
• schema updates (if applicable)
• updated test vectors / conformance corpus
• verification evidence (CI logs, watcher recomputation as applicable)
• risk assessment (security + economics)

Lifecycle (end-to-end)

1. Proposal

   • Jira issue created with required fields (scope, risk, acceptance criteria)
   • Labels determine agent eligibility

2. Specification Gate (Human)

   • Confirm spec intent and scope
   • Decide whether ADR is required

3. Planning Gate (Human)

   • Approve implementation strategy and repo touchpoints

4. Risk Gate (Human)

   • Required for high-risk areas (economics, disputes, mappings, canonicalization)

5. Implementation

   • Constrained to pinned spec/IR commits
   • No “latest spec” references

6. Deterministic Gates

   • locate-sdd lint/build-ir/verify
   • watcher-as-adversary checks where relevant

7. PR/MR Review

   • Code owners + protocol reviewers
   • Spec Authority Council approval when required

8. Release Gate (Human)

   • Final merge authorization after green CI

Anti-patterns (prohibited)

• spec changes without ADR/spec PR
• implementation changes that are not pinned to a spec/IR hash
• LLM-generated canonicalization / hashing / Merkle logic
• agent merges to main/master