YakData

YakData production AI method

The FDE Control Loop

A working prototype proves that something can work once. The FDE Control Loop is the production discipline that exposes what must be true for the system to survive real data, real users, failures, security constraints, and business rules.

Explore the loop See it on a real production case →

The operating question is ownership. Someone has to connect business value, context, architecture, evaluation, release evidence, recovery, and real-user behavior into one decision path. AI accelerates implementation. It does not make those production decisions for you.

ArchitectureProduction ReadinessOperational RiskDecision Ownership

The system design rule

AI is one part of the system. It is not the whole system.

Use AI for interpretation, extraction, ranking, and drafting. Keep rules, calculations, permissions, saved information, and human decisions explicit around it. If fixing every problem means rewriting one giant prompt, split the system into clear parts.

DataInputs, structure, transformations, quality
AIInterpret, extract, rank, draft
Rules and logicScoring, thresholds, calculations, business logic
Behind-the-scenes logicServices, connections, saved data
InterfaceWorkflow, review, evidence, override
PeopleJudgment, verification, accountability

The FDE Control Loop

Seven stages. One closed loop.

Each stage answers one question and produces something concrete. Real use produces evidence, and the evidence takes you back to value.

Eight stops including the return to value.

The loop closes here. Evidence from real use goes back to the value, not to the backlog.

Testing runs across the entire loop
Meets the goal Parts agree Small parts Major parts Features work Parts work together Whole path Old fixes stay fixed Failure behavior
1

Value

What is worth changing, who owns it, and how will we know it worked?

Stage 1

What you leave with

  • A specific business outcome or recurring decision
  • A named owner who cares about the result
  • The consequence in money, risk, time, or quality
  • Acceptance evidence agreed before broad implementation
  • A clear Version 1 boundary

If you skip it

You can build good software for a weak problem. The engineering works and the business still has no reason to adopt it.

2

Context

How does the work happen today, and where must the system fit?

Stage 2

What you leave with

  • The current workflow before and after the system
  • Who uses it, reviews it, and acts on it
  • The inputs people already rely on
  • The actual environment: office, field, shared, executive, or individual
  • The constraints nobody wrote down

If you skip it

A technically correct system that fights the way people work. The demo goes well and nobody uses it.

3

System

What are the parts, what belongs in AI, and what must stay explicit?

Stage 3

What you leave with

  • A map of the important parts of the system
  • A clear boundary around what AI should and should not decide
  • Explicit rules, calculations, thresholds, and permissions
  • Clear rules for what each part sends and receives
  • A decision about what must be saved and what can remain temporary

If you skip it

The model becomes the architecture. Every problem turns into a prompt change, and the business logic ends up somewhere you cannot test it.

Implementation discipline. Define a predictable AI output format, validate it before use, and keep tool choices and handoffs explicit. AI should have one defined role in the system, not control the whole design.

4

Complete path

Can one real case travel through the entire system?

Stage 4
  1. Input
  2. Context
  3. AI / logic
  4. Backend
  5. Interface
  6. Human action
  7. Output

What you leave with

  • One real case on representative data
  • The smallest complete end-to-end path
  • Enough interface to use the path, not a polished product
  • A first end-to-end test that already passes

If you skip it

You get impressive pieces that have never worked together. Making the parts work together stops being a step in the plan and becomes the project.

Complete does not mean finished. A first path is usually a minimal interface, one working connection to the system logic, one place where results are saved, and one real case from start to finish. Cross every important layer before adding breadth.

5

Build out

Now that one complete path works, what do we add?

Stage 5
DataCollecting, cleaning, structuring, quality
IntelligenceModels, context, tools, rules, calculations
ApplicationBehind-the-scenes logic, interface, workflow, saved information
ConnectionsCompany systems, outside tools, internal services

What you leave with

  • More capability built against a working spine
  • Different parts moving in parallel where dependencies allow
  • Tests that grow with the code instead of appearing at the end

If you skip it

The lanes run in sequence and each one waits on the last. The risk that the parts will not work together stays hidden until the end, where it costs the most to fix.

6

Production

What does this system actually need to run reliably for real users?

Stage 6
User identityPermissionsConnectivitySaved dataHistoryFilesSafe updatesScheduled data loadsLive eventsAPI keys + secretsSecurityAI quality checksUsage limitsBackup behaviorLogsHealth metricsRecoveryRelease

What you leave with

  • Only the production capabilities the system truly requires
  • A reason for each important capability included or left out
  • Known failure behavior and a recovery path that has been tested

If you skip it

One of two bad outcomes. A prototype pretending to be production, or an enterprise stack that delays a simple system for months.

Production is not a bigger prompt. It is the right mix of access, secrets, input checks, monitoring, backup behavior, recovery, and human override for the consequence this system carries.

7

Real users

What do real users teach us that tests cannot?

Stage 7
Testing asks

Does the system behave the way we expect?

Real use asks

What did we not know?

What you leave with

  • A small group of real users doing real work
  • Usage signals, defects, workflow friction, and model failures
  • Rapid feedback on what helps and what gets in the way
  • A short observation window, often two to four weeks
  • Expansion and deferred features decided from evidence

If you skip it

You discover the unknown problems at full scale, in front of the whole organization, when learning costs the most.

Return to value

Did the system create the value we started with?

Close the loop
ExpandImproveRedesignNarrowReplaceStop

What you decide

  • What changed in the real business outcome
  • What the evidence says about the original assumptions
  • Which of the six next moves is justified

Why the loop matters

A backlog always wants more work. The loop makes the next move, including stopping, compete against business value again.

Stage 1 of 7

When the prototype becomes a system

The prototype is not the problem. Keeping the prototype design for production is.

AI tools make the first working version far faster. Production begins when you separate responsibilities, validate outputs, test failures, and put the system in front of real users.

Fast prototype pattern
  1. Giant prompt
  2. Prompt tweaks
  3. Raw model output
  4. Features first
  5. Happy path

Fast to create and useful for learning, but fragile once messy data, unusual cases, permissions, and real users arrive.

FDE production response
  1. Separate responsibilities
  2. Validate outputs
  3. Complete path
  4. Failure tests
  5. Limited release

Keep the speed. Add explicit logic, clear handoffs, tests, recovery, and real-user evidence before you broaden the system.

Responsibility lanes

The work overlaps. One accountable owner keeps it moving.

Product, user experience, frontend, backend, and testing are responsibility lanes, not a waterfall. They operate concurrently, with one accountable owner keeping decisions, interfaces, and handoffs coherent while specialists add depth where required.

ProductOutcome, scope, workflow, acceptance
User experienceReview behavior, exceptions, human control
FrontendWhat users see, click, and experience when things fail
BackendData flow, rules, AI connections, saved results, monitoring
TestingWhat must work, edge cases, repeat tests, release evidence

The forward-deployed engineer keeps the lanes connected and moving. The job is not to replace every specialist. It is to keep the business outcome, system decisions, tests, implementation, and operating reality coherent from end to end.

Decision ownership

The production system needs owners for more than the model.

The exact titles vary. The responsibilities do not. A consequential AI system needs clear ownership across business outcome, system behavior, technical operation, and release evidence.

Business and product ownershipDefines the consequential decision, acceptable outcome, workflow, failure consequence, and what evidence is enough to proceed.
System and engineering ownershipOwns architecture, context, rules, interfaces, model integration, security boundaries, recovery, observability, and the complete production path.
Evaluation and operating ownershipDefines acceptance tests, failure cases, human review, monitoring thresholds, escalation, and what happens when real behavior differs from the original assumptions.
Production implication

If nobody can name who owns each of these decisions, the system is not production-ready no matter how strong the model demo looks.

Before you put it in front of users

Audit your system against the FDE Control Loop.

The one-page FDE Production Readiness Checklist finds missing handoffs, tests, operating controls, and real-user evidence before they turn into production failures.

Download the checklist
1-page checklistMarkdown + spreadsheetUse it on your current build
Free asset FDE Production Readiness Checklist Download the readiness checklist

Email only. No account required. Unsubscribe anytime.

By subscribing, you agree to receive YakData production AI updates from YakData. See Privacy.

Have a consequential AI decision in front of you?

Get clear on what is blocking the system and move it forward.

Bring the architecture, evaluation, economics, context, production-readiness, risk, or ownership question. YakData will get to the governing issue, show what evidence matters, and recommend the smallest next step that moves the work forward.

Discuss Your AI System Start With a Private Review Private Analysis Review: $2,500. Private Engagements: from $38,000.