The ICR Cycle

Iterative Constraint Refinement — the operational core of GDD.

The ICR cycle is not a linear process. It is a cycle with a defined exit condition. Each iteration tightens the constraint set, surfaces new unknowns, and converges on an explicit acknowledgment of what is and is not resolved.

The Six Steps

╔══════════════════════════════════════════════════════╗
║          ITERATIVE CONSTRAINT REFINEMENT             ║
╠══════════════════════════════════════════════════════╣
║                                                      ║
║  1. FORMALIZE   propose domain expectations          ║
║                 as explicit constraints              ║
║                                                      ║
║  2. STRESS      generate the condition that          ║
║                 would break each constraint          ║
║                                                      ║
║  3. CHECK       verify internal consistency          ║
║                 across all constraints               ║
║                                                      ║
║  4. SURFACE     identify what cannot be resolved     ║
║                 without human input                  ║
║                                                      ║
║  5. GATE ──────────────────────────────────────────► ║
║     human reviews the unresolvable residue           ║
║       → resolved: absorb, continue cycle             ║
║       → unresolvable: escalate, defer, reframe       ║
║                                                      ║
║  6. CONVERGE    exit when constraint set is          ║
║                 internally consistent and all        ║
║                 unresolvable residue is explicitly   ║
║                 acknowledged                         ║
║                                                      ║
╚══════════════════════════════════════════════════════╝

Step 1 — FORMALIZE

Write every assumption the team holds about the domain as an explicit statement:

"We believe that X is true."

Do not filter. Do not qualify. Write the assumptions your team is making whether or not anyone has said them out loud.

We believe that a loan is approved when DTI is below 43%.
We believe that employment verification means a database flag.
We believe that two agents can safely write to the same order record.

Step 2 — STRESS

For each belief, write the condition that would break it:

"This breaks if..."

We believe DTI below 43% triggers approval.
→ This breaks if the threshold is regulatory (fixed) not policy (adjustable).
→ This breaks if DTI is calculated differently for joint applications.

Stress tests are the mechanism that surfaces the hidden complexity. The goal is not to prove the constraint wrong — it is to find the conditions under which it would fail.

Step 3 — CHECK

Look across all constraints for internal contradictions. Two constraints that cannot both be true represent a [CONFLICT]. Constraints that depend on each other need to be examined together.

Common patterns:

• Constraint A assumes sequential operation; Constraint B defines a locking model (implying concurrency)
• Constraint A assumes real-time data; stress test reveals a batch update cycle
• Constraint A defines a binary status; domain documentation reveals three states

Step 4 — SURFACE

Collect everything the cycle cannot resolve into the unresolvable residue:

## Unresolvable Residue

ITEM 1: [statement of what cannot be resolved]
  Cannot resolve because: [reason]
  Decision required from: [role / person]
  Options: [if known]
  Deadline: [before which phase]

Every [UNKNOWN] and [CONFLICT] belongs here.

Step 5 — GATE

Do not proceed until every item in the unresolvable residue is either:

• Resolved — absorbed into the constraint set with a documented decision and owner
• Acknowledged — explicitly accepted as a known risk with a named owner and a stated consequence if it surfaces later

This is the governance act

Proceeding past the gate without explicit acknowledgment is the failure mode GDD exists to prevent. An organization that proceeds with full awareness of its unresolved constraints is in a fundamentally different position than one that proceeds without knowing they exist.

The gate is the Synthesis Gate — placed upstream before any agent runs rather than encountered reactively mid-pipeline.

Step 6 — CONVERGE

The cycle terminates when:

1. The constraint set is internally consistent (no unexamined conflicts)
2. All unresolvable residue is explicitly acknowledged with an owner

The exit condition is not "all constraints resolved." It is "all residue explicitly acknowledged."

Many constraints will remain [ASSUMED] or [UNKNOWN] at exit. That is acceptable — and far preferable to proceeding without knowing they exist.

The Governed Constraint Set

The completed output of a GDD cycle is the Governed Constraint Set — a formally structured artifact stored in .gdd/CONSTRAINTS.md.

Every constraint follows this format:

## CONSTRAINT-001
Status: [RESOLVED / ASSUMED / UNKNOWN / CONFLICT]
Statement: [what must be true]
Stress: [what would break it]
Resolution: [decision made, who made it, when]  ← RESOLVED only
Owner: [person or role responsible]
Date: [YYYY-MM-DD]
Downstream: [src/path/to/file.ts]  ← fill in after implementation

Constraint Status Directives

When an AI agent reads the constraint set, each status carries a behavioral directive:

Status	Agent Directive
[RESOLVED]	Implement exactly as stated. Do not reinterpret.
[ASSUMED]	Implement but flag: // GDD:ASSUMED — verify before production
[UNKNOWN]	Stop. Surface to human before generating any dependent logic.
[CONFLICT]	Stop. Surface both sides. Do not silently pick one.

The Unresolvable Residue

The unresolvable residue is the most valuable output of a GDD cycle.

It is not a failure of the process. It is the process working correctly — surfacing decisions that genuinely require human judgment before they become expensive to discover in production.

The three categories:

• Genuinely unknown — nobody in the room has the answer. Requires escalation.
• Contested — two stakeholders have different answers. Requires a decision.
• Out of scope — acknowledged as real but explicitly deferred to a future cycle.

In all three cases, the discipline is the same: name it, own it, acknowledge it before execution proceeds.

---

See the ICR cycle in practice → Examples