pernix.· Spec-Driven Development Canvas · v1.0 · Free to use, free to share
← Back to article
pernix.
Spec-Driven Development Canvas
One spec. One sprint. One outcome.Designed for engineering + product, filled in together, in 60 minutes.

Specification Canvas

A single page that captures everything an engineering team needs to build the right thing — and nothing more. Fill it in once, refer to it daily, ship with confidence.

1 Outcome
What changes for the user, system, or business when this is shipped? One sentence. Observable. NOT activities ("build X"), but outcomes ("users can do X reliably").
ExampleCustomers whose initial payment fails can complete checkout via automatic retry within 4 hours, without losing the original session or cart.
2 In Scope
The behaviors, systems, and surfaces this spec covers.
3 Out of Scope
Things this spec explicitly does not cover. Be specific — this prevents 80% of scope creep.
4 System Invariants (things that must always hold)
Properties the system must guarantee at all times after this ships — even under partial failure, retries, or concurrent operations.
ExampleNo payment is ever processed twice for the same cart. No user is ever shown stale order state. All retries are idempotent on the gateway side.
5 Acceptance Criteria
Specific, testable assertions. Each must be verifiable. Each becomes a test case.
Example1. A failed payment triggers a retry after 5 min, 15 min, 60 min. 2. After 3 retries, customer receives an email with a manual link. 3. Cart state persists for 24 hours. 4. Retry events are logged with traceable IDs. 5. No retry occurs after manual completion.
6 Known Risks
Specific risks to delivery, behavior, performance, or security. Mark severity.
7 Validation Strategy
How will you prove acceptance criteria are met before shipping? Tests, manual QA, staging soak, monitoring.
8 AI Usage Plan (for AI-assisted delivery)
Which AI tools will be used? On which surfaces? Who reviews the output? What is explicitly not AI-generated (architecture, security-critical code, etc.)?
ExampleAI used for: test scaffold drafts, refactoring proposals, doc generation. Human-only: idempotency logic, retry algorithm, security review. All AI output reviewed by senior engineer before merge. No client code sent to public LLMs without written approval.
Pernix Solutions · pernix-solutions.com · We stabilize your code, accelerate delivery, and unlock AI — in that order.v1.0 · Free under CC BY

How to use the Spec-Driven Development Canvas

This canvas is the same template Pernix uses internally to draft every engagement specification. It is short by design. A spec longer than two pages usually means the work is not yet understood. A spec shorter than this page usually means the work has not been thought through.

Who fills it in

Two people: a product owner and a tech lead. Together. In one sitting of 60–90 minutes. If you cannot agree on what goes in a section, the spec is not ready — keep talking, don't ship yet.

How long it should take

  • First spec: 90 minutes. You will argue about scope. That is the point.
  • Tenth spec: 30 minutes. You will have shared language.
  • Hundredth spec: 15 minutes. You will catch ambiguity in seconds.

How to use it with AI tools

Once filled in, the canvas becomes the prompt that grounds AI-assisted work. Feed it (or relevant sections) to Cursor, Copilot, Claude Code, or your agent of choice as system context. The acceptance criteria become test scaffolds. The invariants become assertions. The out-of-scope list becomes guardrails. This is what turns "AI codegen" into "AI-assisted delivery."

What good looks like

  • You can read the Outcome line aloud to a stakeholder and they understand it in one breath.
  • The Acceptance Criteria can be turned into test cases without further interpretation.
  • Out of Scope is specific, not vague ("we will not change the database schema" — not "we will keep it simple").
  • The Risks section names real, concrete risks — not "things might go wrong."
  • The AI Usage Plan is specific about what humans will own.

What this canvas is NOT

  • It is not a technical design document. Design happens after the spec is approved.
  • It is not a project plan. The spec defines what; the plan defines how and when.
  • It is not a substitute for code review, testing, or QA. It is the foundation that makes them effective.

Want help applying SDD to your team?

Pernix runs a 14-Day Engineering Sprint built on this exact canvas. We use it to scope, deliver, and validate a working milestone in 14 days — risk-free.

Learn about the 14-Day Sprint →

Spec-Driven Development Canvas v1.0 · © 2026 Pernix Solutions · Free to use, copy, adapt, and share under Creative Commons Attribution 4.0 International. Attribution: "Adapted from the Pernix Spec-Driven Development Canvas, pernix-solutions.com."