R91 — μ Phase 4 Staging — Audit (Step 1 of 5)
Scope. Inventory the canonical surface that the future Phase 4 μ Integrity Monitor must cover, so that the
p4.1-mu-integrity.mdprompt file (Step 4) has a verifiable spec-to-task mapping in Step 5. This audit reads only the canonical specs + the concept doc + the dependency code paths. Nosrc/mutation is in scope for R91.
1. Source documents read
| # | File | Lines read | Reason |
|---|---|---|---|
| 1 | docs/spec/s14-integrity-monitor.md |
64 | Authoritative μ spec |
| 2 | docs/3-world/physics/enforcement/integrity.md |
190 | Concept doc (Phase 0 declares colibri_code: none; Phase 4 scope at §Phase 4 scope, lines 172–178) |
| 3 | docs/spec/s10-admission.md |
64 | HARD BLOCK target surface (s14 §When advisory becomes enforcement → s10 admission) |
| 4 | docs/3-world/physics/enforcement/governance.md (preamble + FSM) |
60 | π proposal lifecycle (BLOCK applies at π intake pre-ENACTED) |
| 5 | docs/3-world/physics/constitution.md |
928 | Seven axioms AX-01–AX-07 that axiom drift detector watches against |
| 6 | docs/guides/implementation/task-breakdown.md §Phase 4 + §Task Summary + §Mermaid graph |
~85 | The 2 canonical roadmap entries (P4.1.1, P4.2.1) + dependency declarations |
| 7 | docs/5-time/roadmap.md §Phase 4 |
~50 | “estimated 15 tasks” budget; 7 file targets; 3 detection types; “later, ~8 weeks” cadence |
| 8 | docs/guides/implementation/task-prompts/p1.1-kappa-rule-engine.md (front matter + first 140 lines) |
140 | Reference structure (20-sub-task pattern; introduction + group summary table; per-task entry template) |
| 9 | docs/guides/implementation/task-prompts/p2.1-lambda-reputation.md |
200 (full intro) | Closer reference (7-sub-task pattern; design-invariant numbered list; dependency-map table) |
| 10 | docs/guides/implementation/task-prompts/p3.1-theta-consensus.md (~700 lines sampled) |
~700 | Closest reference (13-sub-task pattern; wave structure; ADR gate disclosure; ι handoff stub at P3.9.1) |
| 11 | docs/guides/implementation/task-prompts/index.md |
213 | Where the new file must register |
| 12 | src/domains/rules/engine.ts etc. (dependency surface listing only) |
dir-listing | Confirm κ deps exist on main |
| 13 | src/domains/reputation/penalties.ts |
50 | Confirm λ penalty surface signature for μ → λ slashing handoff (BLOCK → axiom violation → severity HIGH → ban) |
| 14 | src/domains/consensus/ (dir listing of 14 files) |
dir-listing | Confirm θ deps exist on main (events, votes, fork-hook stubs) |
2. Canonical μ surface (extracted from s14 + integrity.md)
s14 + integrity.md jointly define μ as the advisory layer. Three detection classes, three advisory roles, one output envelope, four escalation actions. The concept doc adds three full algorithms (DFS, option-set enumeration, sliding window), a JSON record schema, an escalation table, and a Phase 0 declaration that μ is deferred to Phase 4 with no code shipped.
2.1 The three detection classes (μ.detect)
| ID | Detection | Algorithm | False-positive profile | Method (concept doc) |
|---|---|---|---|---|
| D1 | Circular logic | DFS cycle detection on thought_records.cites edges |
low (cycles are rare) | find_cycles(records) graph walk; integrity.md lines 28–52 |
| D2 | Coercion trap | Option-set enumeration; compare presented vs. available; flag all-negative or empty-set | medium | detect_coercion(decision_record) integrity.md lines 62–85 |
| D3 | Axiom drift | Sliding window over 6-month periods; cumulative delta_bps per domain; 8% WARN / 10% HARD BLOCK; also AX-invariant regression check pre-ENACTED |
high without long history | check_axiom_drift(domain, now) integrity.md lines 95–115 |
2.2 The three advisory roles (μ.report)
| Role | Authority | Access | Can execute |
|---|---|---|---|
| Translator | read-only | input | suggest commands; never execute |
| Sentinel | read-only | event queue + rule set | detect patterns; never veto |
| Guide | read-only | state | explain state; never modify |
All three are read-only (s14 §Advisory roles + integrity.md §Three advisory roles). There is no Mutator role in μ. Execution requires a π proposal or T0 authorization (integrity.md line 127).
2.3 The advisory record schema (μ output)
{
"role": "Translator" | "Sentinel" | "Guide",
"check": "circular_logic" | "coercion_trap" | "axiom_drift" | "axiom_regression",
"result": "PASS" | "WARN" | "BLOCK",
"severity": "LOW" | "MED" | "HIGH",
"evidence": [ <references> ],
"recommendation": "<free-form>",
"decision_hash": "SHA-256(role || check || canonical(input) || result)",
"timestamp_logical": <uint64>
}
Per integrity.md §Advisory record schema. The decision_hash doubles as
dedup key. timestamp_logical (uint64) is Lamport, not wall-clock
— inherited from θ design invariant 2.
2.4 The escalation table (μ → enforcement)
| Result | Action | Maps to enforcement surface |
|---|---|---|
| PASS | Logged to ζ at thought_type=advisory |
ζ Decision Trail (no rule change) |
| WARN | Logged + surfaced in operator console | (no enforcement) |
| BLOCK | Denies the proposal at π intake (pre-ENACTED) | π Governance (proposal FSM) |
| HARD BLOCK | Denies at α tool-lock admission (s10) |
α tool-lock + κ admission |
Per integrity.md §Escalation mapping. BLOCK is recoverable (re-submit amendment); HARD BLOCK requires governance path.
2.5 The mapping from advisory → hard-block (s14 §When advisory becomes enforcement)
WARN converts to hard block only when the detection maps to a rule engine invariant:
- Circular logic in rule update → rule rejected at κ rule loader (P1.2.4)
- Coercion in admission gate → event rejected at κ admission (P1.4.1)
- Axiom drift beyond limits → governance proposal rejected at π intake
3. Dependency map (already shipped at main HEAD post-#248 = 332feb62)
Every Phase 4 μ slice has hard deps on shipped axes:
| Upstream | What μ consumes | Path | Shipped in |
|---|---|---|---|
| κ Rule Engine (Phase 1, closed R87) | Rule evaluator, version hash, integer math, denial reasons | src/domains/rules/engine.ts, versioning.ts, integer-math.ts, denial-reasons.ts |
R85→R87 |
| κ Admission Evaluator | Hooks for HARD BLOCK on coercion-in-admission | src/domains/rules/admission.ts (P1.4.1, #215) |
R87 |
| κ Rule Loader / Registry | Hooks for BLOCK on circular-logic-in-rule-update | src/domains/rules/registry.ts (P1.2.4, #212) |
R86 |
| λ Reputation (Phase 2, closed R89 Phase A) | reputation rows (drift sliding window may read participant action history); penalty surface (axiom-regression at HIGH triggers reputation event) |
src/domains/reputation/schema.ts, compute.ts, penalties.ts |
R89 Phase A |
| θ Consensus (Phase 3, closed R89 Phase B) | Vote events + finality state (axiom drift may aggregate over θ rounds; fork-hook from P3.9.1 may surface POST_FORK_INVARIANT checks) | src/domains/consensus/messages.ts, finality.ts, fork-hook.ts |
R89 Phase B |
| ζ Decision Trail (Phase 0, closed R75) | thought_records — substrate for circular-logic graph walk; advisories logged here at thought_type=advisory |
src/domains/trail/repository.ts |
R75 |
| η Proof Store (Phase 0, closed R75) | (downstream — proofs of advisories are Merkle-anchored) | src/domains/proof/ |
R75 |
| β Task Pipeline (Phase 0, closed R75) | Task UUIDs for slice writeback | src/domains/tasks/ |
R75 |
Net: every μ Phase 4 dependency is shipped at main HEAD. No new upstream blockers beyond the still-spec-only π Phase 6 (governance proposal FSM — μ BLOCKs prepare a denial event that π will execute when π ships).
4. Coverage shape (what the 8–12 sub-task entries must cover)
Mapping the canonical μ surface to slice candidates:
| Spec section | Required surface | Suggested sub-task |
|---|---|---|
| s14 §Output + integrity.md §Advisory record schema | Typed envelope + decision_hash | P4.1.1 — Advisory Record Schema + Envelope |
| Concept §Algorithm (DFS cycle detection) lines 28–52 | Circular-logic detector | P4.2.1 — Circular Logic Detector |
| Concept §Algorithm (option-set enumeration) lines 62–85 | Coercion-trap detector | P4.2.2 — Coercion Trap Detector |
| Concept §Algorithm (sliding window) lines 95–115 + AX-01..AX-07 | Axiom-drift sliding window + AX regression | P4.2.3 — Axiom Drift Tracker |
| s14 §Advisory roles + integrity.md §Three advisory roles | 3 read-only roles | P4.3.1 — Three Advisory Roles (Translator/Sentinel/Guide) |
| Integrity.md §Escalation mapping + s14 §When advisory becomes enforcement | Escalation FSM | P4.4.1 — Escalation Adapter (κ + π hooks) |
| Concept §Phase 4 scope line 173 + integrity.md line 168 | Persistence | P4.5.1 — Advisory Persistence (mcp_advisories migration) |
| Concept §Phase 4 scope line 174 | MCP tool surface | P4.6.1 — μ MCP Tool Surface (≥4 tools; MCP surface 23 → 27+) |
| κ P1.5.5 + λ (none) + θ P3.8.1 precedent | Parity harness | P4.7.1 — Parity Harness + Default Corpus |
| Concept §Phase 4 scope line 175 + P3.9.1 ForkHookRegistry | Subscriber to θ fork hook | P4.8.1 — Fork Hook Subscriber (post-fork invariant sweep) |
That gives 10 slices spread across 8 sub-axes — inside the 8–12 budget specified in the dispatch packet. Single-detector classes (D1, D2, D3) get distinct slices for parallelizability; the schema slice gates the detectors; the role adapter and escalation slice gate the MCP tools and the parity harness.
5. Granularity comparison (precedent)
| Axis | Roadmap canonical | Prompt-file actual | Round |
|---|---|---|---|
| κ (Phase 1) | 10 sub-tasks | 20 sub-tasks | R76.P1 (pre-stage) |
| λ (Phase 2) | 7 sub-tasks | 7 sub-tasks (1:1) | R89.B |
| θ (Phase 3) | 7 sub-tasks | 13 sub-tasks (almost 2×) | R89.C |
| μ (Phase 4) | 2 canonical (P4.1.1 + P4.2.1) | 10 candidate slices | R91 (this audit) |
Roadmap §Task Summary line 1138 declares “P4 μ Integrity | 2 tasks | 2 weeks”. Roadmap §Phase 4 line 430 declares “estimated 15 tasks” with 7 file targets. The two numbers disagree (Phase 4 in the task summary is undercounted relative to the roadmap’s own file list); the staging file resolves this by carrying 10 slices with explicit traceability back to the canonical specs. (κ went 10 → 20; this is the same granularity-refinement precedent.)
6. Open issues + spec gaps surfaced during audit
| # | Issue | Action in prompt file |
|---|---|---|
| Q1 | s14 line 33 schema vs. integrity.md schema differ slightly (s14 has details + evidence + decision_hash + reasoning_trace; integrity.md uses evidence + recommendation + decision_hash + timestamp_logical) |
Adopt integrity.md’s schema (newer, 2026-04-16) as canonical for the slice; document the difference in §P4.1.1 |
| Q2 | task-breakdown.md §P4.1.1 references docs/concepts/μ-integrity-monitor.md (legacy path) — actual file is docs/3-world/physics/enforcement/integrity.md |
Cite the live path; flag the stale roadmap reference for separate hygiene |
| Q3 | task-breakdown.md §P4.2.1 acceptance criterion “Translator: sanitize natural language → structured commands” — but integrity.md §Three advisory roles describes Translator as “Summarize advisory reports for a human operator” | Use integrity.md’s description; the spec-doc-newer rule wins per CLAUDE.md §9.4 |
| Q4 | task-breakdown.md only lists 2 Phase 4 sub-tasks (P4.1.1, P4.2.1); roadmap.md lists 7 files; concept doc lists 3 detector classes, 3 roles, persistence, tools | Stage 10 slices per audit §4; precedent: κ went 10 → 20 |
| Q5 | μ → π BLOCK target: π Phase 6 not yet shipped (spec-only). μ’s BLOCK output records an event that π will consume when π activates | Document: μ MCP tools record BLOCK events into ζ at thought_type=advisory; π integration is out of scope for Phase 4 implementation |
| Q6 | s14 §Output uses severity levels not enumerated; concept doc uses LOW | MED | HIGH; task-breakdown.md uses INFO | WARNING | CRITICAL |
Adopt integrity.md’s LOW | MED | HIGH (matches λ severity bands; minimizes drift) |
| Q7 | “decision_hash” formula differs: s14 line 36 uses SHA-256(check + input + result + model_identity); integrity.md line 142 uses SHA-256(role || check || canonical(input) || result) |
Use integrity.md’s formula (delegates to κ canonical serialization; matches θ pattern of canonical-serialize-then-hash) |
None of these contradictions block staging. They are spec-divergences between an older s14 (date stamp not provided) and the newer 2026-04-16 concept doc. The staging prompt cites integrity.md as the canonical resolution and flags the spec for a separate documentation-hygiene round (R91+ or later).
7. Forbiddens for the R91 staging slice itself
- No
src/mutation (this is a docs-only meta PR per the dispatch packet). - No frontmatter graduation of μ from
colibri_code: none(staging ≠ shipping). - No ADR-002 / ADR-003 / ADR-005 modifications.
- No
task-breakdown.mdmutation — flag Q2, Q3, Q4 above as separate hygiene candidates, do not rewrite Phase 4 §here. - No κ/λ/θ frontmatter touched — every prior axis closure is locked.
- No new ADR for μ — the existing concept doc + s14 cover the surface.
- File status MUST be
staged, notready— μ Phase 4 dispatch waits for explicit T0 confirmation per dispatch packet.
8. Conclusion
s14 + integrity.md jointly specify a coherent μ surface: three detectors
(D1/D2/D3), three roles (Translator/Sentinel/Guide), one output schema
(8 fields with Lamport clock + canonical hash), four escalation levels
(PASS/WARN/BLOCK/HARD BLOCK), and explicit hooks into κ admission + κ rule
loader + π intake. Every upstream dependency (κ Phase 1, λ Phase 2,
θ Phase 3, ζ ε β Phase 0) ships at main HEAD (332feb62). The
2-canonical-vs-7-file mismatch resolves naturally to 10 slices at
prompt-file granularity, matching the κ precedent (10 → 20) and θ
precedent (7 → 13).
Step 2 (contract) will assert a row-by-row mapping from §2’s canonical surface to slice IDs, so Step 5 (verification) can confirm no spec orphan.
Audit closed 2026-05-13. Base SHA at audit: 332feb62 (post-#248 R90
hygiene). Next: Step 2 contract.