Structured specs as the new abstraction level for building with AI.
Intent and business knowledge is trapped in code, people heads, and scattered docs. Specy captures product intent, system behavior, domain, architecture, and data as structured specs that your team work with and share with agents.
A structured spec for every level of intent
Specy defines five metamodels, one per level of intent. A spec is a plain-text artifact:
- precise enough for an agent to build from and work with
- readable and at the right abstraction level for a human
- versioned and diffed like code
Prose, human-agent conversations, workshops, human thoughts
- 01 Product Requirements Document (.prd) What the product should be ↓ design dialogue
- 02 System Requirements (.sysreq) What the system shall do ↓ design ↑ extract dialogue
- 03 Domain Model (.domain) How the system realizes the intent ↓ design ↑ extract refactor ↓ generate dialogue
- 04 Software Architecture (.arch) How the system is structured ↓ design ↑ extract ↓ generate dialogue
- 05 Data & Operation (.dataop) What data exists and what operates on it — no algorithms or programming language details ↓ design ↑ extract ↓ generate dialogue
Each level traces to the one above. All five stay independent of any language or platform.
Java, TypeScript, Go, Rust, Python, etc. — repos, frameworks, production
↓ works down from intent ↑ works up from code works on the spec itself
Specs are living artifacts your team keeps shaping using skills:
Turn prose, agent-human conversations, or a workshop into a spec.
↓ Top-down
Reverse-engineer the specs from an existing codebase.
↑ Bottom-up
Redesign an extracted spec from first principles, without losing its language.
In place
Scaffold idiomatic code straight from the spec.
↓ Top-down
Question the spec; every answer cites it, not someone's memory.
In place
Data verifies Behavior
A business rule becomes real when example data proves it. Specy treats data as intent: versioned, reviewed, and owned like the rules it verifies. Every behavior names the state it expects in and the state it must produce out.
Every rule ships with its fixture
Canonical examples, named in the domain language and validated with your experts, plus a generator that generalizes them. They are versioned with the rule.
Right state in, right state out
Agents write code against reproducible oracles: seeded generators, versioned datasets, controlled clocks. Deterministic feedback keeps an agent correcting in the right direction.
Production closes the loop
Outliers and incidents, pseudonymized at the source, come back as named examples and generator constraints. Specy measures fixture drift against reality.
model orders implements sales {
module orders {
struct Money {
schema {
amount: number
currency: string
}
}
struct OrderLine {
schema {
sku: string
quantity: number
unitPrice: Money
}
}
struct Order {
schema {
id: string
lines: vector<OrderLine>
total: Money
status: string
}
// named conditions over the data,
// in the domain's own language
state {
"a draft order" : _.status = "draft"
"a shipped order" : _.status = "shipped"
"a cancelled order" : _.status = "cancelled"
"a cancellable order" : _.status in { "draft", "confirmed" }
}
}
global orderBook: vector<Order> = []
operation findOrder(orderId: string): Order
errors { UnknownOrder }
reads { orderBook }
operation cancelOrder(orderId: string): Order
errors {
UnknownOrder
NotCancellable(status: string)
}
depends on { findOrder }
writes { orderBook }
implements sales.CancelOrder
// right state in, right state out:
// examples speak the states' language
example "cancel while still open" {
given Order is "a cancellable order"
when cancelOrder
then Order is "a cancelled order"
}
example "too late after shipping" {
given Order is "a shipped order"
when cancelOrder
then error NotCancellable
}
}
}
Greenfield or brownfield, same specs
Create a complex app with structure from day one, or reclaim a legacy you no longer understand. Only the direction changes: design top-down, or extract bottom-up into a digital twin.
Greenfield — structure from day one
Design the specs first, let agents build against them.
Brownfield — reclaim with a digital twin
Extract the specs from the code and its production data.
You're building a new product. Everyone is aligned — for now. By sprint three, the rules live wherever they landed — a head, a doc, a thread — and your agents generate plausible code from ambiguous stories. Ambiguous specs produce ambiguous software, whoever writes it.
Design the stack top-down: PRD, system requirements, domain, architecture, data and operations. Every rule is born with its canonical examples and generator. Agents build from the specs and verify against the data; your team reviews specs and judgment calls, not thousand-line diffs.
A 15-year-old monolith processes 200K transactions a day. The people who understood the payment rules are gone. You need to modernize, but nobody can say what the system actually does — the code and its production data are the only truth left.
Extract the specs from the code and its data: a digital twin of your system — concepts, rules, requirements, architecture, data shapes. Production data calibrates the twin and keeps it honest as the system evolves. Review it in hours. Refactor the twin, not the code, then regenerate and verify against the data the legacy handled.
See what your system knows.
We'll run Specy on one of your modules.
One hour. No commitment. You keep the spec.