​

Prism History

Prism is the third name for the same underlying bet. Before Prism there was PrismGR. Before PrismGR there was DFW. The thesis has not changed — structured project context, durable across sessions, accessible to AI agents as first-class infrastructure. The implementation has changed twice, and each rebuild was driven by a specific failure in the last one. This page is the honest arc. What each iteration got right, where it broke, and what Prism is because of both.

---

​

Origins: DFW — the Development Flywheel

DFW stood for the Development Flywheel — a methodology for AI-assisted software development built around the idea that a session’s work compounds only if the knowledge it produces is captured, structured, and queryable by the next session. Decisions as ADRs. Plans as structured artifacts. Retrospectives as mandatory at every phase close. Lessons graduating from project-scope to global-scope through a human review gate. A session protocol that says open, work, wrap every time, without exception. The concept was right. Every architectural principle in today’s Prism is a direct descendant of DFW: the typed-artifact model, the retrospective mandate, the lesson promotion pipeline, the session lifecycle, even the language of “phases” and “plans.” DFW was the conceptual breakthrough. It named what AI-native development methodology actually needs to be. What DFW got wrong was the fabric. DFW’s implementation substrate was Obsidian. Projects lived as directory trees of markdown files. Every artifact — ADR, spec, plan, retrospective, session delta, todo — was a .md file with YAML frontmatter. Cross-references were Obsidian wiki-links. The session protocol was enforced by the agent reading a template at the top of every conversation. Lessons were promoted from project to global by a human editing files in the Obsidian vault. This worked, for a while. It was fast to set up, human-readable, and the agent could genuinely use it — a Claude session could read the vault, reason about prior decisions, file new artifacts. The methodology ran. But the fragility compounded in four specific ways: Enforcement was entirely advisory. Every rule in DFW — “retrospectives are mandatory,” “lessons need a scope,” “session deltas close every session” — lived as text in a template the agent was expected to follow. There was no structural check. A session that skipped the retro just skipped the retro; the failure was visible only if a human noticed the gap days later. The phrase that kept showing up in DFW-era deltas was “human discipline plus session delta warnings”. That’s an honest description of the enforcement model, and it names its own ceiling. Human discipline doesn’t scale past one motivated human. Artifact integrity depended on markdown fidelity. When an agent wrote a new ADR, the frontmatter might or might not be valid YAML. Wiki-links might or might not resolve. The lessons: field might be a list or a string or accidentally nested inside another field. Every query against the vault was also a validation pass, and validation failures required someone to manually clean up. The vault slowly accumulated structural debt that no one had time to fix. Cross-session continuity was a hope, not a contract. A new session opened on a DFW project had to rediscover state by reading files. There was no reliable index of “what’s the current phase,” “what’s the most recent decision,” “what’s in flight.” The agent could reconstruct most of it by scanning, but the scan was expensive in context tokens and the reconstruction was probabilistic. Two sessions opened on the same project minutes apart could form different mental models of its state depending on which files they read first. Offline tolerance revealed the real coupling. Late in DFW’s life, as more work routed through the first attempt at a backend service (called PrismGR at the time), we had to build an elaborate offline fallback protocol — markdown caches, sync queues, _SYNC_QUEUE.md as an append-only manifest, priority ordering for what to replay when connectivity returned. The protocol worked. Building it was also the moment the team internalized that the methodology was more coupled to infrastructure than we had admitted. The “it’s just markdown files” framing had become aspirational; in practice, the agent’s ability to reason about the vault depended on a service being reachable. DFW was the right idea executed on a fragile substrate. The lessons it produced — the what of AI-native methodology — were load-bearing. The how needed to be rebuilt.

---

​

PrismGR — the first backend

The second iteration was the service layer DFW eventually demanded: a FastAPI backend with a structured data model, an API for filing artifacts, and eventually an MCP server so agents could call it directly instead of manipulating files. The project was called PrismGR — Prism Global Registry — because the original scope was narrow: a centralized registry of projects and the cross-project semantic recall that DFW couldn’t give you from a single Obsidian vault. PrismGR solved real problems. The typed-artifact model became real — a spec was a row in a table, not a markdown file with hopeful frontmatter. Foreign keys enforced relationships that DFW had to maintain by convention. Migrations gave schema evolution a safe path. Authentication and tenancy isolated projects cleanly. Semantic recall over an indexed corpus was a hundred times faster than re-reading a vault. The MCP verbs gave agents a proper tool surface rather than a directory-scanning heuristic. It also accumulated its own set of limitations that made clear where the next rebuild had to go: The methodology layer was still on trust. PrismGR enforced data shape but not process. An agent could still skip a retro, or file a decision without context, or close a phase without capturing lessons. The mandate existed in AGENTS.md and PRISM.md (the first attempts at a per-project methodology template) but those were markdown files the agent read at the top of every session, and the agent was free to interpret or ignore them. The constitution was advisory. This was DFW’s enforcement problem again, now one layer up. Same shape, same ceiling. Memory was a flat index. PrismGR’s semantic recall used vector embeddings plus BM25 lexical search — the hybrid-recall pattern that’s now well understood. It worked for “find me things that mention X” but it didn’t distinguish current from historical. A query for “why did we choose Postgres” would return the ADR that picked Postgres and also the earlier conversation about MongoDB with equal confidence. The agent had to reason about freshness from context. Stale answers leaked through. Renaming a project was an archaeological event. PrismGR encoded identity through names and string references. Changing a project’s name meant migrating dozens of files, cross-references, and cached summaries. The operation was possible but fragile. Every rename risked breaking something. Single-operator by assumption. PrismGR’s architecture assumed one developer per project. No capability tokens, no approval gates, no multi-controller coordination. A team wanting to use PrismGR hit the same wall that every current AI coding tool hits today: “what do two humans, running two agents, on one shared project actually do here?” The answer was use it in separate projects and reconcile later, which isn’t an answer. Phase 4 was the decision point. We had three choices: patch PrismGR’s limitations incrementally, fork it into a multi-user rewrite, or accept that the cumulative gap between “what the methodology needs” and “what the service provides” was large enough to justify another rebuild. We picked the third.

---

​

Prism — the control plane

Prism is the name PrismGR became when we stopped calling it a registry and started calling it what it actually was: a brokered control plane for multi-agent coding systems with memory as one of the services it owns. The rename was intentional. PrismGR named a component — the Global Registry. Prism names a thesis. The architecture paper that defines it is on this site as the Vision page. The implementation is the set of architectural decisions filed through Phase 4 of this project. Four specific things changed between PrismGR and Prism: Methodology enforcement became structural. SPEC-021 introduced Ring 0 — a defense-in-depth layer above Ring 1 BIOS that makes bootstrap non-optional. The L1 in-process flag means every verb checks that prism_start has run. The L3 status card means a skipped bootstrap is visible by its absence. The L4 hygiene layer makes renames and phase advances update cached summaries atomically. None of this existed in PrismGR. The methodology that was “mandatory by mandate” in DFW is now “mandatory by structure” in Prism. The constitution-advisory lesson from the DFW era graduated to a global methodology rule. Memory became a tri-graph. SPEC-020 replaced PrismGR’s single-layer co-occurrence graph with three distinct layers — Canonical (stable identity as :Entity UUIDs), Semantic (aliases and typed references), Temporal (state versions and supersession events). This is the structural separation that PrismGR couldn’t do. Current state and historical state are different traversals. A renamed project keeps its identity because identity is a UUID, not a name. semantic_recall queries return current state with historical state tagged [historical] rather than ranked as equals. The DFW offline-cache pattern that hinted at “the methodology is more coupled than we admitted” became, in Prism, the tri-graph that makes coupling explicit and queryable. The architecture became brokered. The architecture paper that now lives at Vision named the principle the earlier iterations had not: no peer-to-peer command authority between clients — ever. Every cross-agent, cross-operator, cross-project interaction flows through one governed plane. Capability tokens scope authority. Approval gates make state promotion explicit rather than implicit. Audit is free because every shared-state change is already a verb call. DFW and PrismGR both assumed one human driving one agent; Prism’s architecture assumes many of both and makes the coordination the product. The rename itself was possible. PrismGR → Prism happened without migrating databases, rewriting foreign keys, or breaking a single external reference. The project UUID stayed the same. The PID stayed the same. Only the display name changed. That’s the tri-graph’s identity-stability guarantee in action, and it’s the concrete demonstration that “identity as UUID, not as name string” is worth the extra architectural effort. DFW’s vault-based identity would have made the same rename a two-week archaeological project.

---

​

What each iteration kept

The thesis didn’t move. Each rebuild inherited the previous iteration’s conceptual wins and replaced only the fabric:

• From DFW, Prism inherited the typed-artifact vocabulary (ADRs, specs, plans, retros, journals, todos), the retrospective mandate at phase-close and project-close, the lesson promotion pipeline from project-scope to global-scope, and the session protocol of open, work, wrap. These are not DFW anachronisms surviving by inertia; they are the methodology, and they are still correct.
• From PrismGR, Prism inherited the FastAPI + Postgres + pgvector backend shape, the MCP verb surface, hybrid-recall retrieval (RRF fusion of dense, lexical, and graph signals), and the multi-mode deployment model (local, lan, cloud). The service layer got upgraded, not replaced. Specific files in the current backend — the memory service, the artifact services, the migration framework — are lineal descendants of PrismGR code.
• From DFW’s lessons, Prism inherited a specific stance on enforcement: a constitution in markdown is advisory to an LLM executor, not binding. You do not solve enforcement with better prompts or stricter mandates. You solve it with structural invariants that make violations visible or impossible. Ring 0 is the architectural answer to a lesson DFW taught through repeated failure.

---

​

The lineage of live artifacts

The clearest way to see the continuity is to look at what’s on disk and in the database today:

• Methodology templates — the prism-base.md + prism-<ptype>.md overlay system descends directly from DFW’s AGENTS.md template, now composable and synced atomically rather than hand-maintained per project.
• Typed artifacts — the spec, ADR, plan, retro, journal, and todo surfaces are recognizably the same shapes DFW defined, now backed by Postgres tables with constraints and audit columns rather than markdown frontmatter.
• Global lessons — the promotion pipeline from retro-005 to the SPEC-020 tri-graph rollout pattern is a running example of the DFW learning loop, operating on Prism’s infrastructure. The pattern that shipped Plan #6 without breaking any consumer (“old schema and new schema coexist through every intermediate wave, never a hard cutover”) is now a global methodology rule applied to subsequent refactors.
• Session deltas — every prism_wrap produces a session delta that any future session can retrieve via semantic_recall. This is the same idea DFW implemented as append-only _DELTAS.md files in an Obsidian vault, now first-class rows with vector indexes.

Nothing important was thrown away. Everything important was rebuilt on load-bearing substrate.

---

​

Phase 4’s culmination — Plan #10, governance foundation at machine speed

The clearest demonstration that the architecture works is the arc that closes it. Plan #10, the governance-foundation ratification arc, executed end-to-end on the night of 3–4 May 2026 in approximately 3.5 hours — old-pattern estimate would have been 1–2 days. The stat block: Three feature flags shipped default-off in the same arc — PRISM_GOVERNANCE_RESOLVER_ENABLED, PRISM_CONSENSUS_PARALLELISM_ENABLED, PRISM_MEMORY_DOMAINS_ENABLED — every implementation PR proving behavioral inertness of its gated path before merge. The default-off invariant held across the entire deploy chain. The artifacts ratified were the governance backbone Phase 4 had been pointing at:

• ADR #47 v0.2 — Governance Layer Precedence + Override Semantics. The 5-layer narrower-wins model (global / tenant / org / project / user-session-runtime) with file-level mandatory: true frontmatter as the only override gate.
• SPEC-077 v0.2 — Canonical Boot + Governance Resolution. Boot model + 5-state per-layer classification + the PRISM_GOVERNANCE_RESOLVER_ENABLED rollout flag.
• ADR #48 v0.2 — Persona / Identity / Specialization Field Model. Five-field model where specialization is routing/memory/skill authority, not governance authority.
• SPEC-078 v0.2 — Consensus-First Parallelism + Method Fragments. The 3-tier consensus workflow that made the 3.5-hour pace possible, plus method-fragment schema with two seed fragments shipped same-session.
• SPEC-079 v0.2 — Memory Domain Contracts + CI Loop. Twelve memory domains with read/write contracts that prevent cross-domain pollution.
• SPEC-080 v0.2 — Tri-Graph Governance Recall + Capability Index. Graph-backed rule/capability lookup with source, citation, freshness, and supersession reporting. prism_governance_lookup shipped same-day in PRs #126–#131 with a one-shot governance_backfill CLI seeding 196 :Artifact / 48 :Decision / 12 :SourceDocument+:InstructionSurface entities.

The speed didn’t come from typing faster. It came from coordination elimination. The signal mesh removed the wait-for-Slack-reply, the “did you see my PR?”, the “which branch should I base off?”. When Texi (System Architect) returned a SPEC review, the ReviewCompleted signal arrived at Donna (Engineering driver + delegated PO) within sub-seconds via WebSocket push. Donna routed the v0.2 task to Candi (Methodology), who folded 12 binding amendments in approximately 4 minutes — not because Candi types fast, but because the full review context arrived structured in the signal payload rather than scattered across chat messages and email threads. The mesh exhibited brick-wall-respect behavior throughout: lane peers paused on upstream gates and resumed at full speed when unblocking signals arrived. No polling, no busy-wait, no coordination overhead beyond the signals themselves. See the Plan #10 case study for the full timeline, agent roster, and lane retrospectives. Plan #10 wasn’t a one-off. The same arc shipped SPEC-081 (Structured Large-Payload Pattern), SPEC-082 (Operator-Driven Master Handoff Verbs), and SPEC-084 (prism_install_editor_host) in the days that followed, on the same coordination substrate. Plan #10’s three flags graduated from default-off rollout to production-verified the same week.

---

​

Where the history leads

Prism’s Phase 4 is the architectural refactor that completes the transition. Phase 4 shipped the ring architecture, the environment contract, the tri-graph knowledge representation, and the bootstrap enforcement layer — four structural decisions that together make the methodology-as-infrastructure thesis something you can verify by running a smoke test, not something you have to take on faith. Plan #10 is the proof that the architecture also runs at machine speed when eight agents drive it in parallel. Phase 5 and beyond is where the brokered control plane stops being primarily a single-operator memory substrate and starts being the cross-vendor, cross-operator, cross-project coordination plane the Vision page describes — including the improving-OS layer (Capability Library + Evidence Graph + Outcome Compiler) that turns Prism’s substrate into a system that compiles goals into governed plans and learns from outcomes. The architecture is ready. The runway is clear. The thesis is the one DFW articulated in the first place, now finally built on a fabric that can hold it.

---

​

Where to go next