Product overview
An open system for keeping AI-native products coherent.
ContractSpec is not one narrow generator. It is the explicit layer that lets teams define system behavior, keep multiple surfaces aligned, regenerate safely, and move into Studio when they want the operating product.
What the category really is
Lead with the system, not just the generation step.
Generation matters, but it is not the whole story. The real value is that contracts, runtime adapters, proof surfaces, and the Studio operating loop all remain legible as parts of the same product system.
Better umbrella
Open spec system for AI-native software
Where “compiler” belongs
Inside the technical proof, not as the whole company category
Architecture by layer
Each layer exists to keep the next one from drifting.
The repo structure already tells the right story: lower layers define explicit behavior, higher layers compose that behavior into working surfaces, and apps stay thin.
Contracts and specs
The canonical product rules your team wants the system to keep respecting over time.
Generation and runtime bridges
The adapters that turn those rules into API, UI, data, event, MCP, and client-facing surfaces.
Harness and proof workflows
The inspection, replay, evaluation, and evidence surfaces that tell you whether automation is safe.
Studio operating product
The opinionated team workflow for running evidence, drafts, review, exports, and checks on top of the same foundation.
OSS/Core
Adopt the open foundation first
- You want explicit contracts, safe regeneration, and standards-first outputs.
- You need to stabilize an existing product incrementally.
- You want the foundation without being forced into a hosted product loop.
Studio
Add the operating product when the team is ready
- You want the operating surface for evidence, drafts, review, exports, and follow-up.
- You want packaged workflows and coordination on top of the same contract system.
- You want the product that absorbs more operational complexity for the team.
Proof points
What should feel different after adoption.
The point is not just faster output. The point is that regeneration, refactoring, and agent behavior stop feeling opaque because the team has an explicit layer it can inspect and trust.
Explicit contracts, not inferred conventions
Standard outputs the team can own and change
Multi-surface consistency across API, UI, data, and tools
Incremental adoption instead of rewrite-only adoption
Next step
Use the OSS layer when you want control. Use Studio when you want the operating loop.
That is the cleanest product split for both technical adopters and teams buying the packaged surface later.