Example 3: AI-First Feature Development

Domain: Loan origination feature in a fintech product
Stakes: Regulatory compliance, incorrect lending decisions, user trust
Context: Development team preparing to hand a feature spec to an AI coding agent

The Situation

A fintech team has a product requirement: build a loan eligibility check. The spec is two paragraphs. The instinct is to paste the spec into Claude Code and iterate until it works.

This is reasonable for a prototype. This is not reasonable for a lending decision that will be applied to real applicants.

GDD says: what does "correct" mean here — and who decided?

The ICR Cycle

FORMALIZE — stated assumptions

[1] We believe a loan is approved when DTI < 43% AND score > 680
    AND employment is verified.
[2] We believe DTI is calculated as monthly debt / monthly gross income.
[3] We believe "employment verified" means an active employment record
    in our database.
[4] We believe the eligibility check is deterministic — same inputs,
    same output, every time.
[5] We believe declined applicants receive a reason.
[6] We believe the check handles joint applications.
[7] We believe 680 is the minimum score for all loan products.
[8] We believe the eligibility check is the only gate before approval.

STRESS — what breaks each

[2] breaks if: income is variable (freelance, commission, seasonal)
              gross income is not available — net income is used instead

[3] breaks if: the employment record was last updated 18 months ago
              the applicant is self-employed — no employment record exists
              the applicant is on parental leave — record shows active
              but income is not current

[4] breaks if: credit bureau scores fluctuate between API calls
              the same applicant applies twice in one day with different
              scores returned — different outcomes for identical applicants

[5] breaks if: the decline reason must meet adverse action notice
              requirements (ECOA, FCRA) — plain language is not sufficient

[7] breaks if: personal loans and mortgage products have different
              risk profiles — 680 for a personal loan ≠ 680 for a mortgage

[8] breaks if: a manual review queue exists in the current process
              that the spec does not mention — the check may be a
              pre-filter, not a final gate

CHECK — internal consistency

[CONFLICT A] Statement [4] assumes determinism.
             Stress test on [4] shows bureau score variance.
             Determinism and live bureau score lookup are incompatible.

[CONFLICT B] Statement [3] assumes employment record = verified.
             Stress test on [3] shows self-employed have no record.
             Statement [1] requires employment verified.
             Self-employed applicants cannot pass a check that requires
             a record that does not exist for them.

[CONFLICT C] Statement [8] assumes this is the only gate.
             Stress test surfaces a manual review queue.
             If a manual queue exists, this check is a pre-filter —
             its decline decisions are not final.
             Adverse action notices cannot be triggered by a pre-filter.

SURFACE — unresolvable residue

ITEM 1: What is the definition of "employment verified" for self-employed?
  Cannot resolve from: spec (not mentioned)
  Decision required from: Product Owner + Compliance
  Options: exclude self-employed from this product,
           define an alternative verification path,
           flag for manual review (Synthesis Gate)
  Deadline: before agent writes the employment check logic

ITEM 2: Is this check a final gate or a pre-filter?
  Cannot resolve from: spec (ambiguous)
  Decision required from: Product Owner + Legal
  Consequence: adverse action notice requirements differ significantly
  Deadline: before agent writes the decline response logic

ITEM 3: Are score thresholds product-specific?
  Cannot resolve from: spec (states 680 without qualification)
  Decision required from: Risk Team
  Deadline: before agent writes threshold logic

ITEM 4: How is DTI calculated for variable income?
  Cannot resolve from: spec (assumes stable monthly income)
  Decision required from: Product Owner + Risk Team
  Options: use trailing 12-month average,
           exclude variable income applicants from this product version
  Deadline: before agent writes DTI calculation logic

GATE

Four decisions before the agent writes a line:

1. Product Owner + Compliance: self-employed applicants are out of scope for v1 — flagged in the spec, separate workstream
2. Legal confirms: this is a final gate — adverse action notices required, reason codes must meet ECOA/FCRA requirements
3. Risk Team confirms: 680 applies to personal loans only — mortgage threshold defined separately
4. Risk Team defines: variable income uses trailing 12-month average — documented in the constraint set

What Changed

The agent built an eligibility check with:

• Explicit handling of the self-employed exclusion (returns a specific code, not a generic decline)
• ECOA/FCRA compliant reason codes on all decline paths
• A personal-loan-specific threshold flag in configuration — not hardcoded
• A trailing 12-month income calculation for variable income applicants

None of this was in the original two-paragraph spec. All of it was in the Governed Constraint Set the GDD cycle produced.

The agent did not make these decisions. It executed against decisions that had already been made and governed. That is the difference.

---

See how GDD connects to the broader ecosystem → GDD in the SI Ecosystem