Status: accepted · ADR-6 · Filed 2026-04-17
Decision
Adopt a four-ring layered enforcement architecture for the Prism methodology: (Ring 1) CLAUDE.md and AGENTS.md as thin BIOS bootstraps — universal principles and launch imperative only; the agent runtime reads these deterministically. (Ring 2) PRISM.md as project-type-specific methodology, scaffolded at bootstrap from a composable template system (prism-base.md + prism-<ptype>.md), version-pinned in the project, cached-by-virtue-of-being-a-file. (Ring 3) prism_start returns live project state and methodology-drift warnings — dynamic, Prism-dependent, degrades gracefully. (Ring 4) Server-side enforcement hooks — prism_wrap warns on missing accounting, prism_start surfaces drift reminders. Upgrades to PRISM.md when canonical template changes are opt-in: Prism asks the user to run update, never overwrites silently.
Rationale
Static-only drifts from reality (confirmed today: PID-PGR01 showed Phase 0 for four phases). Dynamic-only is brittle (Prism outage = no methodology). The resilience gradient must go from ‘always works offline’ (CLAUDE.md) to ‘works better with Prism up’ (prism_start + Ring 4). Version-pinning PRISM.md with opt-in upgrades preserves project autonomy — projects agree to methodology, they don’t have it imposed. Ring 4 is the feedback loop that makes compliance emerge from utility rather than exhortation: if prism_start tells you about your open TODOs and phase drift, you want to call it. This is the answer to ‘how do you enforce methodology on agents’ — you make the compliant path the useful path.
Alternatives Considered
Static-only (CLAUDE.md contains everything) — simple but drifts and can’t reflect live project state. Dynamic-only (everything comes from Prism) — brittle, breaks when Prism is down, no offline mode. Single PRISM.md regenerated every session — loses version-pinning and ability to diverge intentionally.
