Product overview
How ContractSpec keeps AI-native products coherent.
ContractSpec is not one narrow generator. It is the explicit system model: contracts, registries, generated surfaces, runtime adapters, agent projections, and evidence all share one inspectable source of product intent.
What the category really is
Lead with contracts, then prove the surfaces.
Generation matters, but it is not the whole story. The real value is that contracts, registries, surfaces, adapters, agent tools, and evidence remain legible 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 so AI can change software without inventing rules.
Lower layers define explicit behavior; higher layers compose that behavior into working surfaces, agent operations, and evidence. The details live in docs and examples, not on the homepage.
Contracts and specs
The canonical product rules your team wants generated code, adapted interfaces, APIs, and agent tools to keep respecting.
Registries and ownership
Named domains, owners, lifecycle state, compatibility expectations, and review paths make contracts discoverable and governable.
Presentation, data, form, event, and operation surfaces
The same rules project into UI, schemas, forms, workflow events, commands, and operating screens.
Runtime adapters
Adapters bind contracts to REST, GraphQL, React, jobs, MCP, and client-facing runtimes without inventing parallel truths.
Agent and MCP projections
Agent-facing tools inherit explicit scope, inputs, outputs, policies, human approval points, and evidence obligations.
Evidence, policy, and replay
Policy checks, harness scenarios, evaluation, and replay show whether regeneration and automation are safe to expand.
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 already understand the OSS contract layer and 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.