ContractSpec for AI-native teams
Build and run AI-native systems on explicit contracts.
ContractSpec gives teams an open spec system for defining behavior, aligning every surface, and regenerating safely. The OSS foundation stays yours. Studio is the operating layer when you want a product on top.
What the site should make clear
This is not “yet another AI builder.”
ContractSpec exists for teams that already know AI can write a lot of software, but need explicit control over what that software is allowed to become over time.
- Keep the code and the standards you already use.
- Stabilize one module at a time instead of rewriting your app.
- Move into Studio only when you want the operating product.
Why teams end up here
AI speed is not the problem. Implicit systems are.
Once a team depends on prompts, AI edits, and generated code across multiple surfaces, the real failure mode is not “AI wrote bad code.” It is that nobody can state the system rules precisely enough to keep regeneration safe.
Implicit rules drift first
Prompt chains and AI edits move faster than the product rules they are supposed to respect.
Surfaces stop agreeing
API, UI, database, events, and MCP tools evolve independently unless something explicit keeps them aligned.
Teams lose safe regeneration
Without a stable contract layer, every regeneration feels like rewriting production in the dark.
The open system
One explicit layer that keeps the whole stack honest.
ContractSpec is broader than generation. It is the contract layer, the runtime bridges, the proof surfaces, and the adoption path that lets teams move from OSS control to an operating product without pretending they are different systems.
Contracts and generation
Define the canonical behavior once and derive the implementation surfaces from it.
Runtime adapters
Bind the same source of truth to REST, GraphQL, React, MCP, and operational flows.
Harness and proof
Replay, evaluate, inspect, and verify how the system behaves before you trust automation with more.
Studio operating layer
Run the opinionated product loop when you want coordination, governance, and a packaged operating surface.
What the OSS layer actually gives you
Explicit contracts show up where teams usually lose control.
The promise is not magic generation. The promise is that the same product rules can shape APIs, data, interfaces, and agent tools without each surface inventing its own truth.
APIs
Typed endpoints and schemas stay aligned with the same contract language the team edits.
Data
Schema, validation, and migrations are shaped by the same product rules instead of scattered implementations.
Interfaces
Forms, presentations, and client types inherit the same system boundaries instead of drifting from the backend.
Agents and tools
MCP tools and agent-facing surfaces are generated from explicit contracts rather than guessed from code.
Adoption path
Start where the risk is highest, not where the marketing says to start.
- 01
Start with one module that is already drifting or feels unsafe to regenerate.
- 02
Define explicit contracts, then bring API, UI, data, and tools back into alignment.
- 03
Adopt Studio when the team wants an operating surface on top of the open system.
Studio on top
Studio is the operating surface, not a replacement identity.
Use Studio when your team wants a packaged loop for evidence, drafting, review, export, and follow-up. The relationship should feel like the best application built on top of the same open system, not a bait-and-switch away from it.
OSS/Core: contracts, generation, runtimes, harnesses, agent tooling.
Studio: the opinionated operating loop when a team wants the product.
Choose your path
Adopt the open system first. Evaluate Studio when the team is ready for the operating layer.
That is the product story the site should tell everywhere: open foundation, explicit contracts, safe regeneration, then an opinionated surface on top for teams that want it.