Differentiating Roadmap
The Prism architecture rests on a four-part spine — the Capability Library, Evidence Graph, Outcome Compiler, and Trust Dashboard described on the Vision page. On top of that spine, the system grows along eight differentiation axes. Each axis has a sequencing dependency: the spine has to be in place first, then the axes layer on top. This page is the canonical home for that growth roadmap.The eight axes
- Journal + Work Accounting. A typed daily/project journal with carry-forward, evidence trail, and time accounting bucketed across the categories engineering organisations want to measure but rarely can: thinking/planning, build, test, review/coordination, docs/communication, and blocked/waiting time. The DFW-style journaling discipline made structural — every session produces structured deltas with timestamps, the tri-graph already records when each state transition happened, the Outcome Compiler can read backward from a charter to see how time actually went on similar prior work. This is what makes “where did time actually go on this project?” answerable from primary data instead of from reconstruction. Sequenced immediately after Trust Dashboard surfaces, so the journal lands on a substrate the operator can already audit.
- Pattern-Guided Build Mode. Editors build against known-good patterns selected from the Library before agents implement, instead of improvising from chat context. Patterns include explicit anti-patterns and rejection criteria, so review can say not just “this is wrong” but “this violated a known pattern.”
- Active Memory productisation. Memory becomes active guidance, not passive retrieval. “This resembles a prior failure / matches a successful pattern / this ADR has been superseded.” Per-warning suppression, per-pattern threshold tuning, daily warning-volume telemetry, and a mute knob with audit trail are required before launch — false-positive rate is the load-bearing metric.
- Dynamic expert agents. Canonical agents cover durable lanes; Prism also needs transient workers for massively parallel work — bounded task, explicit write/resource ownership, expiry/cleanup behavior. SPEC-070’s persona-daemon invariants already cover most of this; the delta is
expiry_atsemantics for transient workers (vs. always-on for canonical persona daemons), shipped as a SPEC-070 amendment rather than a new SPEC. - Work decomposition engine. Extends SPEC-078 from methodology into an execution engine — dependency graph, ownership boundaries, conflict risks, merge order, review gates, validation commands, handoff contracts. The dependency graph and merge order surface in the dashboard so operators can intervene before parallelism turns into chaos.
- Quality Gate Generator. Given a goal, project type, and pattern set, Prism generates tests, smoke plans, acceptance criteria, review rubrics, telemetry expectations, deploy verification, and rollback checks — emitted as artifacts into the existing pipeline (test files in repo, smoke entries in deploy verbs), not as a parallel test surface.
- Project Type Engines. Prism supports non-code projects as typed work systems — research/literature review, financial analysis, multimodal media production, travel planning, home improvement, strategy/planning, legal/compliance research, data analysis. Each engine defines artifacts, tools, patterns, review gates, and done criteria. Ship one fully-shaped engine end-to-end (software/application, the type Prism eats its own dog food on) before broadening.
- Capability Rationalization + Continuous Improvement Coach. The same rationalization being applied to ADRs (Plan #12 / SPEC-083) extends to every capability
kind: duplicates, deprecated capabilities, overlapping tools, underused skills, patterns with weak evidence, capabilities that should be merged or retired. The Coach v0 ships only the recurring-postmortem-theme detector — adding signals is easy once the surface exists; getting the noise/value ratio right requires real operator data. - Multimodal Workbench. Ingestion of PDFs, spreadsheets, images, audio, video, web pages, datasets, design assets — extracting claims, evidence, decisions, assets, tasks, constraints, and candidate artifacts. Each modality is its own engineering arc; the Workbench is a separate plan on top of the spine, not part of v0.
Operational discipline carried forward
Every layer above ships under the deploy and smoke discipline the SPEC-080 / SPEC-081 / SPEC-082 arc proved out: default-off feature flags, live smoke against the disabled production path, ephemeral-compose pytest gates against the enabled path, backfill CLIs with explicit row-count assertions, automatic deploy-evidence binding when a PR ships green, performance budgets per LLM invocation, and a capability-change postmortem hook so deprecated/retired capabilities never lose their reasoning. The capability surface is right. The order matters more than the count.Vision
The four-part spine, the destination thesis, and why Prism is positioned ahead of where the market is heading.
Hybrid RAG
The four-leg retrieval architecture (vector, lexical, graph, temporal) that the Capability Library and Evidence Graph ride on.

