THE PLATFORM
An engine-driven platform for structured software development.
Every kind of project work — capture, planning, change, build, verify — runs through a specialised engine that produces structured artifacts in a typed graph. The graph is the substrate; the engines are the faculties; the specbook is the surface. Code gets generated and verified against the graph, not hoped into existence.
THE GRAPH
entities · operations · guards · dependencies · tests · infrastructure
nodes + edges · typed + versioned · queryable
THE BET
The spec should be a typed graph. Verification should be a compile step.
Most AI coding systems treat specifications as documents — markdown, prose, or prompt preambles — that guide generation. Some add workflow discipline on top. A few attempt to update specs as code changes. All of them share an architectural limit: when it comes time to verify whether the code matches the spec, another LLM reads both and gives an opinion.
We made a different bet. In Strata19, the spec is a typed graph in a database — entities, operations, guards, dependencies, tests, and infrastructure, all as nodes and edges. Every generation step writes bridge edges from code back to spec. Verification is a structural comparison between the spec's expected data flow, control flow, and execution order, and what the compiled code actually produces. No LLM judges whether code matches spec. The compiler and the graph do.
This isn't incremental improvement on prose-spec workflows. It's a different architecture — one where "done" is a computable property instead of a judgment call. It's closer to a compiler than to a software development framework. The spec graph is our typed intermediate representation; the generated code is our compilation target; convergence is our type-checking phase.
THE ENGINE PATTERN
Five engines. One typed graph.
Each engine has a single responsibility. Each one reads from and writes to the same typed graph. They compose because they share a substrate — not because they were bolted together.
Source Engine
Captures intent from every input surface into spec nodes.
- Structured discovery conversation that extracts entities, roles, workflows, and guards
- Business profile and industry context ingestion to pre-populate the graph before a line is written
- Brownfield import via Tree-sitter + CPG: converts existing codebases into spec nodes
Change Engine
Propagates requirement changes across the full spec graph deterministically.
- Blast-radius computation from any spec node edit — affected files, endpoints, guard rules
- Change request authoring with full before/after spec diffs
- Cascade evaluation that re-runs convergence checks on every downstream node
Code Engine
Generates implementation from spec nodes in topological order.
- Topological generation: entities before operations, operations before endpoints, endpoints before UI
- Every generated file carries a bridge edge back to its originating spec node
- CEGIS retry loop re-generates any file that fails structural verification on first pass
Template Engine
Extracts reusable patterns from converged projects and instantiates them into new graphs.
- Pattern extraction from completed projects: spec subgraphs become parameterised templates
- Template instantiation starts a new project from a verified structure, not a blank graph
- Library of pre-seeded templates derived from analysed open source reference projects
Verification Engine
Runs five structural gates before any deployment proceeds.
- Gate 1 — Schema: database schema matches all spec entity nodes
- Gate 2 — Relations: all foreign-key and edge relationships are resolved
- Gate 3 — Guards: every guard constraint from the spec is applied in generated code
- Gate 4 — Coverage: all spec endpoints have generated implementations
- Gate 5 — Orphan check: no unlinked spec nodes remain without code counterparts
"Engines compose. The platform extends by adding engines, not by bolting features onto a monolith."
THE COMPOUNDING
One compounding mechanism. Four levels of granularity.
Most software products have one moat — data, network effects, or switching costs. Strata19 has one compounding mechanism that operates at four scales simultaneously: every project converges, every converged artifact persists in the graph, and every subsequent project pulls from the accumulated library at whichever level of granularity is useful.
The Spec Graph
Highest-granularity compounding: the typed intermediate representation itself. Every project Strata19 has ever spec'd contributes to a growing accumulated structure of patterns, edge cases, and verified compositions. The graph gets smarter at inferring gaps, proposing constraints, and catching missing guards as your portfolio grows. This is the substrate that all the other levels live in — every hook, component, and template is also nodes and edges in the graph.
Templates
Higher-granularity compounding: full subgraphs that encode proven patterns. A SaaS admin shell. A field-service dispatch system. A marketplace foundation. Templates are instantiable — a new project starts from a verified template instead of a blank graph, then customises the parts that are specific to the engagement. Templates can be authored from scratch, but most are extracted from successful projects: a converged HVAC implementation becomes the HVAC template the next engagement starts from.
Components
Mid-granularity compounding: UI components composed from hooks, with their own specs and tests. Components ship as integrated units — the data fetching, the state management, the rendering, the event handlers all specified together. Verification re-runs every time a component is instantiated into a new spec context, ensuring it still holds under the new constraints. Component count grows monotonically; nothing falls out of the library through neglect.
Hooks
The lowest-granularity compounding artifact: runtime primitives. Data fetching patterns, state machines, domain logic, side-effect wrappers. Each hook is specified with its inputs, outputs, side effects, and guarantees; verification proves the implementation matches. Hooks accumulate in a library — projects that need a new behaviour contribute it; projects that need an existing behaviour pull from the library instead of rewriting it. This is the layer where the most code reuse happens because primitives are the most universally applicable.
THE SURFACES
One platform. Four entry points.
You reach the same engine set from four different surfaces. Which one you use depends on your workflow, not on what the platform supports.
Strata19 Studio
A browser workspace for spec authoring, change management, convergence tracking, and brownfield analysis. The full platform surface — no CLI required.
CLI
The @strata/cli package. Covers the same MCP tool surface as the plugin. Project creation, spec inspection, engine triggers, convergence status — scriptable and composable.
Claude Code MCP Plugin
A Model Context Protocol server that exposes the full engine suite as slash commands inside Claude Code. Spec, generate, converge, blast-radius — all in the editor workflow.
API
A REST + WebSocket API for programmatic access. Every Studio action is backed by an API call. Custom tooling, CI/CD integration, and third-party workflow connections all go through the same surface.
All three surfaces share the same MCP tool interface underneath. A project created via the CLI is fully available in Studio and the plugin. A change spec'd in Studio gets implemented by the plugin. The CLI can drive the same engines Studio does. The surfaces are different ergonomics; the platform is one.
THE BOUNDARY
What this is and isn't.
What Strata19 is
- +A graph-native platform for structured software development
- +Engine-driven across planning, change management, and execution
- +Multi-surface — a Claude Code plugin, a Studio workspace, a CLI
- +Compounding via verified work persisting in the graph
- +Verifiable through structural analysis and the compiler
- +Closer to a compiler-and-IR for spec-to-code than to a workflow framework
What Strata19 is not
- –A general-purpose IDE or code editor
- –A replacement for an agentic coding tool — it integrates with one
- –A documentation tool — documentation falls out of the graph automatically
- –A project management tool — projects have state, but PM isn't the product
- –An AI agent that writes code freeform — generation is always graph-constrained
ADJACENT CATEGORIES
Workflow frameworks for agentic coding
Collections of skills, prompts, and patterns that structure how a developer collaborates with an AI agent. Generally complementary; some focus on workflow discipline, we focus on what's being worked on (the spec graph). Users can run both.
AI-powered editors and IDEs
The surfaces developers code in. Strata19's plugin runs inside one of these today; broader integrations are on the roadmap. We don't replace the editor; we add a graph-aware layer to it.
Markdown-based spec-driven development frameworks
Same problem space (specifications before code), different architectural position. These treat the spec as a document with workflow discipline around it. We treat the spec as a typed graph with structural verification. Same axis, different end.
Multi-agent coding systems
Same problem space, different architectural bet. They verify LLM output with more LLM calls. We verify with deterministic graph queries and the compiler.
CAPABILITIES
Explore what the platform can do.
Six capabilities — each one built on the typed project graph.
Project Overview
138 node types, 73 edge types, 11 graph layers. Every node is a page.
Learn more →Living Documentation
Docs that can't lie. Traceability from spec to code and back.
Learn more →Proactive Insights
Dead code, drift, wiring gaps. The graph surfaces what's wrong.
Learn more →Impact Analysis
Blast radius, change sizing, coupling risk. Know what breaks.
Learn more →Verification
6 binary convergence gates. Done is a proof, not a feeling.
Learn more →Integrations
Claude Code MCP, CLI, ~20 graph queries. Talk to your graph.
Learn more →THE STATUS
Where we are, where we're going.
We're in active use internally across real client projects. The items below reflect what we've verified works, not what we've planned.
Shipping today
- ✓Discovery conversation (Source Engine) — structured elicitation with entity/role/workflow extraction
- ✓Spec graph — typed graph database with nodes, edges, and convergence properties
- ✓Brownfield ingestion pipeline — Tree-sitter + CPG analysis from a GitHub URL
- ✓Convergence verification with five structural gates
- ✓@strata/cli covering the MCP tool surface
- ✓Claude Code MCP plugin with slash command set
- ✓Strata19 Studio workspace (spec, code, brownfield, knowledge graph tabs)
- ✓Business profile and industry profile systems (Source Engine context)
- ✓Change request authoring with blast-radius computation
- ✓Template library seeded from verified open source reference projects
In development
- ○Template instantiation for custom vertical segments (HVAC, field service, marketplace)
- ○Template marketplace — agencies publish and share verified subgraphs
- ○Component and hook library surface in Studio
- ○Multi-user Studio with attribution and collaboration
- ○Additional agentic IDE integrations beyond Claude Code
- ○Custom engine authoring interface
- ○Private deployment for compliance-sensitive customers
- ○Expanded vertical templates — target 10+ industry templates by end of year
We update this list when something ships. If you're evaluating Strata19 and something in the "in development" column is a dealbreaker, reach out — the roadmap is prioritised by real use cases.
The spec layer is ready. The question is whether your stack is.
Strata19 is in active development with a small cohort of technical teams. Early access is open. If you're building software that needs to be specifiable, verifiable, and maintainable — we should talk.