Should I Use GDD?

GDD is not for every project. It is available when the stakes warrant it.

The Master Filter

Before running through the five questions, apply the single filter beneath all of them:

The real question

Would a wrong assumption, discovered after build, cost more than a GDD cycle?

If no — prototype freely. Come back to GDD when the stakes rise.

If yes — run through the five questions below to understand where the risk lives.

The Five Questions

If you answer yes to three or more, the risk is distributed enough that a cycle belongs before your next project phase.

1. Are there business rules in this domain that exist in someone's head but not in a document?

2. Would a wrong assumption, discovered after build, cost more than a week to fix?

3. Are multiple agents or systems going to touch shared state?

4. Is there a regulatory or compliance dimension where "we didn't know" is not an acceptable answer?

5. Has this domain been through a previous modernization that didn't fully succeed?

Three Entry Points

Entry Point 1 — The Thinker

You want to understand GDD before committing to anything.

A GDD cycle produces one artifact: a Governed Constraint Set.

It is not a requirements document. It is not a test plan. It is not a specification.

It is a structured answer to the question: what do we know, what do we assume, and what do we genuinely not know — before anything is built?

The most valuable part of a Governed Constraint Set is not what it resolves. It is what it surfaces as unresolvable residue — the decisions that genuinely require human judgment before any agent runs.

Entry Point 2 — The Practitioner

You want to run an ICR cycle. Here is the starter ritual.

Step 1 — Open a blank document. Title it:

GDD — [Project Name] — [Date]
Domain: [the business area you are formalizing]
Stakes: [what goes wrong if an assumption is wrong]

Step 2 — Write every assumption as a statement:

We believe that X is true.

Do not filter. Write every assumption whether or not anyone has said it out loud.

Step 3 — Stress each statement:

This breaks if...

Step 4 — Mark each statement:

[RESOLVED]   we have evidence this holds — source documented
[ASSUMED]    we believe it but have not verified
[UNKNOWN]    we genuinely do not know
[CONFLICT]   this contradicts another statement in this document

Step 5 — Collect every [UNKNOWN] and [CONFLICT] into the Unresolvable Residue section. For each item: state what cannot be resolved, why, who can resolve it, and the deadline.

Step 6 — Gate. Do not proceed until every item is either resolved or explicitly acknowledged with an owner.

Step 7 — Name the completed document your Governed Constraint Set. Version it. Store it. Reference it in every downstream artifact.

Entry Point 3 — The Ecosystem User

Already using Semantic Intent tools?

If you use...	GDD adds value here
Phoenix Runtime	Run an ICR cycle before the first agent pass. Unresolvable residue becomes the human gate checklist.
Strata Runtime	Surface what the schema can't reveal — why a column exists, what a nullable field means. Gate before the Classifier runs.
REACH + OCTO	Define constraint boundaries per arm before orchestration is designed. Surface arm conflicts before they're baked in.
RECALL	The .rcl source file is the formalized output of a GDD cycle. Governed intent that travels.

---

Ready to add GDD to a project? → Project Initialization