loading…
Turn product intent into an executable contract for behavior, evidence, risk, and operations.
In ordinary software, a specification describes features. In a GenAI system, it must also define acceptable behavior across variable outputs. The goal is not to predict every sentence the model will produce; it is to make success, failure, and authority testable.
A useful GenAI specification connects five things:
| Area | What the spec must answer |
|---|---|
| Product behavior | What user problem is solved, for whom, and in which situations? |
| Architecture | Which pattern controls the flow—direct call, RAG, workflow, agent, or multi-agent? |
| Evidence | Which tests, evals, and acceptance thresholds prove the system is ready? |
| Authority | What data and actions may the system access, and where is approval required? |
| Operations | What latency, cost, availability, audit, and rollback requirements apply? |
Translate vague goals into concrete cases. "Answer support questions well" is not testable. "For billing-policy questions, retrieve an approved policy document, cite the source, avoid guessing when no policy is found, and escalate refund requests above $500" can become an eval suite and a runtime policy.
Every important requirement should map to evidence: a deterministic test, an eval case, an approval rule, an operational metric, or an audit event.
Use short architecture decision records for consequential choices: why RAG was selected over long context, why a deterministic workflow owns a payment path, or why one model is used for planning and another for extraction. Record the trade-off and the condition that would justify revisiting it.