The system of concepts is written down, the vocabulary is agreed — now they can be turned into the product engineer's main working artifact: the specification an agent builds a feature from and you accept it against. Let's see how a concept model unfolds into a spec, and why without it a spec is just a long prompt with hope attached.

A spec is an ontology with obligations

Look at what a good feature specification consists of:

  • Entities and their attributes — the model's concepts: order, line item, payment.
  • State models — the concepts' states and allowed transitions: draft → placed → paid → shipped, "no transitions out of cancelled."
  • Commands — what can be done: "place an order," "cancel," "pay" — with preconditions ("only a placed order can be paid").
  • Events — what happens as a result: "order placed," "payment received" — what other parts of the system react to.
  • Invariants — rules that are never violated: "the sum of line items equals the order total," "an order has exactly one customer."
  • Acceptance criteria — verifiable scenarios: given → when → then.

Notice: the first five items are exactly the elements of an ontology (objects, states, events, relations, rules) — but with obligations: a spec doesn't just describe concepts, it fixes what the system guarantees about them. That's why trying to "write a spec" without a concept model fails: there's nothing to unfold. You get a retelling of wishes where the agent still has to guess what an "order" is and whether a cancelled one can be paid.

The order of work

The path from the problem to a spec looks like this:

  1. Concepts and relations — the domain model (how to build it): business nouns, cardinalities, boundaries.
  2. States — which concepts have a lifecycle; draw the transitions, the forbidden ones matter more than the allowed.
  3. Commands and events — the business verbs: what users and systems do (commands) and what happens (events). The vocabulary is ubiquitous: CancelOrder and OrderCancelled, not synonyms by mood.
  4. Invariants — what must always be true. The most valuable part for an agent: an invariant can't be "understood one's own way."
  5. Acceptance criteria — the scenarios you'll accept the result against. They're also the basis of the tests.

The output is a document of a few pages with not a word about frameworks or tables: domain only. The technology (which DB, which transport) is added as a separate section and never mixed into the model — we've seen what mixing leads to.

Why this works with an agent

A spec of this shape is an ideal input for AI for three reasons:

  • It's verifiable. Invariants and acceptance criteria are ready-made tests: accepting the result turns from "looks about right" into running the scenarios.
  • It removes guessing. The agent doesn't decide on its own whether a cancelled order can be paid — it's written down. The less freedom in meaning, the more value in the agent's speed: freedom remains where it belongs — in the implementation.
  • It survives sessions. Session context disappears; the spec stays. The next session (or another agent, or you in a month) starts from the same document — three sessions produce one solution, not three.

This discipline then scales: a spec per command/feature is the unit of work; a set of specs is the model of a service. This is the principle behind the Use Case Pattern methodology this whole site is built on: the specification lives next to the code, is executed by the agent, and is checked on every change. What matters here is the bridge itself: ontology → spec → agent's code → acceptance by criteria.

In short

  • A spec = an ontology with obligations: entities, states, commands, events, invariants + acceptance criteria. Without a concept model a spec degenerates into a retelling of wishes.
  • The order: concepts → states (forbidden matters more than allowed) → commands and events in the ubiquitous vocabulary → invariants → acceptance criteria.
  • Domain separately, technology separately — a spec isn't about tables and frameworks.
  • It works with an agent because the spec is verifiable (criteria = tests), removes guessing (invariants aren't interpretable), and survives sessions.
  • The product engineer's bridge: ontology → spec → agent's code → acceptance. This is the core of the Use Case Pattern approach.

Next — ontologies and knowledge graphs for LLMs: how a written system of concepts helps not only to build, but to ask — when vector search isn't enough.