YakData FDE Project Files

FDE Project Files · Project File 001

How to Become a Forward-Deployed AI Engineer

What does a Forward-Deployed AI Engineer actually do?

Starting August 19, follow 77 Rules from the business problem through deployment and handoff to the people who run it. The series shows the requirements, architecture, implementation, evaluation, failure handling, and handoff work that production AI actually requires.

Preview Episode 1 See the 7-episode journey

Episode 1 publishes Wednesday, August 19, 2026. The full seven-part series is expected to total approximately 5.5 to 6.5 hours when complete.

Designed for experienced hands-on builders and technical leaders who need to connect more of the production path.

01 · Who this is for

You do not need to become five engineers.

FDE Project Files is for experienced practitioners who need to connect business, product, architecture, engineering, evaluation, deployment, and handoff.

Path 01 · Hands-on buildersFrom strong specialist to end-to-end production owner.

Best fit: senior/staff software engineers, AI/ML engineers, data engineers, and solutions architects building real systems.

The question this path answers

“How do I stop thinking only about my component and make the whole production system work?”

By the end, you should be able to

  • Frame the decision, owner, scope, and definition of done before broad implementation.
  • Turn expertise into contracts and design a vertical slice across every critical layer.
  • Evaluate, harden, deploy, recover, and hand over the complete system.
Path 02 · Technical leadersLead production AI without becoming the deepest specialist in every lane.

Best fit: engineering managers, technical PMs, data/AI leaders, architects, and experienced cross-functional practitioners.

The question this path answers

“How do I know whether the team is making the right decisions across product, UX, frontend, backend, AI, and QA?”

By the end, you should be able to

  • Give specialists one decision, one definition of done, and clear ownership.
  • Challenge architecture, evaluation, human review, release, telemetry, and recovery decisions.
  • Recognize cross-team dependencies early and make evidence-based build, narrow, release, or stop decisions.
Probably not the right starting point if…You want beginner coding, prompt tricks, or a certification credential. FDE Project Files assumes working technical experience.

02 · What you’ll be able to do

Own the decisions that move an AI system into production.

Leave with practical judgment about what to decide next, what proof you need, and when to continue, redesign, narrow, or stop.

01Decide what deserves to be built

Tie the system to a recurring decision, owner, scope, and definition of done.

02Turn expert judgment into contracts

Convert expertise into rules, evidence, context, schemas, exceptions, and testable behavior.

03Design the system and vertical slice

Set the boundaries among interface, backend, AI, deterministic logic, data, security, and human review.

04Evaluate the AI on the real work

Test known cases, critical misses, false alarms, confidence limits, failures, cost, and latency.

05Make it ready for real users

Harden validation, retries, versions, regression, telemetry, deployment, and recovery.

06Transfer ownership

Hand over architecture, tests, access, recovery knowledge, and the evidence for what happens next.

77 Rules carries all six decisions through one continuous production case.

03 · Three ways to use this

Watch it. Build alongside it. Bring your own work.

The public series is complete on its own. The optional Production Reviews layer is for people who want live judgment on what they are building now.

01 · Observe

Calibrate your judgment.

Technical leaders can watch the case and live reviews to see what questions expose weak requirements, architecture, evaluation, UX, or handoff.

02 · Build

Apply each decision to your own system.

Developing FDEs can move at their own pace. There is no cohort deadline and no requirement to clone 77 Rules.

03 · Review

Bring the part that is stuck.

Active builders can submit a sanitized artifact and one decision for live cross-functional review with Stephen.

See Production Reviews →
Planned founding round$2,000 for six months · weekly live sessions · no cohort pace · not a certification
Review the offer
Stephen McDaniel, founder of YakData and creator of FDE Project Files
Stephen McDaniel · FDE Project Files

How I teach this

You’re not watching me narrate a finished slide deck.

I show the architecture, contracts, tests, failures, and revisions as they change. The point is to learn how to reason across product, UX, frontend, backend, AI, QA, deployment, and ownership without losing the business decision.

Stephen McDaniel · Builder and instructor

04 · The proof standard

Every episode has to earn its conclusion.

This is not a lecture sequence with production vocabulary added afterward. A claim belongs in an episode only when the viewer can see the evidence, the constraint, what changed, and the decision that followed.

01Real artifact

Show the system state, architecture, contract, test, benchmark, runbook, or other working object.

02Failure or constraint

Expose what can break, what is missing, or what makes the obvious approach unsafe or incomplete.

03Decision at stake

Name the production choice the evidence is supposed to support.

04Changed assumption

Show a before/after when evidence changes scope, architecture, workflow, test strategy, or backlog.

05Role ownership

Make the PM, UX, FEE, BEE, Test/QA, and FDE responsibilities visible where they overlap.

06Number or observable result

Use a count, score, timing, cost, latency, test result, or directly observable state only when the source supports it.

07Production consequence

Connect the technical evidence to reliability, user behavior, risk, cost, release, recovery, or ownership.

08Next action

Close with continue, redesign, narrow, defer, remediate, deploy, transfer, expand, or stop.

No invented specificity.If a useful number, failure, or before/after state is not documented, I will say what needs to be tested rather than pretend it happened.

05 · The 7-episode journey

Follow the system from decision to ownership.

Each episode starts with visible proof, shows what can go wrong, and ends with the next decision.

Episode01
45 to 50 minPublishes Aug 19, 2026

Decide What Deserves to Be Built

Define the recurring decision, owner, failure cost, scope, and proof of success.

Production moment: An “AI dashboard checker” sounds useful until nobody can say which decision it improves or which miss makes it unsafe.

Episode02
45 to 55 minComing weekly after Episode 1

Turn Expert Judgment Into System Requirements

Turn expertise into rules, evidence, context, workflow states, error behavior, and testable contracts.

Production moment: The screenshot suggests a problem, but the pixels cannot prove the business context. The system needs a rule for asking or abstaining.

Episode03
45 to 55 minComing weekly after Episode 1

Design the Production System and the Work

Join workflow, data, models, rules, UI, controls, deployment, and ownership into one executable architecture.

Production moment: Frontend needs evidence and review state while backend thinks in model responses. The contract has to define what a finding actually is.

Episode04
50 to 60 minComing weekly after Episode 1

Build the Production-Shaped Vertical Slice

Move one representative case through input, AI, rules, scoring, review, failures, and useful output.

Production moment: The first real end-to-end case exposes an assumption that looked harmless on the architecture diagram.

Episode05
50 to 60 minComing weekly after Episode 1

Make the AI Earn the Right to Be Trusted

Benchmark the real task, test critical failure modes, define confidence behavior, and verify human override.

Production moment: A strong average can still hide a critical miss, false alarm, malformed output, or unsafe response to missing context.

Episode06
50 to 60 minComing weekly after Episode 1

Turn the Working Slice Into a Production System

Add the states, validation, versions, regression, telemetry, deployment, and recovery real users require.

Production moment: A timeout, retry, or rule-version change has to be recoverable and explainable after the fact.

Episode07
40 to 50 minComing weekly after Episode 1

Transfer Ownership and Improve the System

Package the architecture and test evidence, transfer access and recovery knowledge, and measure adoption.

Production moment: Can the client add a rule, explain a changed result, recover a failure, and decide what to improve without the original builder?

06 · Production map

Keep the whole production path in view.

You do not need to memorize fourteen steps before you start. Keep the map nearby so every architecture choice, test, deployment task, and handoff stays connected to the full path from business decision to client ownership.

Define
01Define the decision
02Frame the consequence
03Map ownership
04Gather operating evidence
05Assess data reality
Design + Build
06Design the system
07Build the vertical slice
08Evaluate performance
09Test failure modes
10Design and verify human review
Operate + Transfer
11Deploy into the operating boundary
12Monitor the live system
13Transfer ownership
14Make the next decision

07 · Responsibility lanes

Real production work overlaps almost immediately.

PM, UX, frontend, backend, and Test/QA are responsibility lanes, not sequential departments. The FDE spans and integrates them while preserving clarity about who owns each kind of work.

PM

Outcome, workflow, requirements, scope, priority, decision rights, and acceptance.

UX

User flow, information architecture, review behavior, exceptions, confidence communication, and human control.

FEE

Browser and application behavior, interaction state, rendering, user-facing failures, and review surfaces.

BEE

Schemas, APIs, orchestration, rules and models, persistence, security, observability, and operational services.

Test/QA

Acceptance harness, regression, edge cases, failure behavior, release evidence, and production-quality gates.

FDE integration

Business-to-production integration, architecture, tradeoffs, critical-path engineering, and technical/business synthesis across the five lanes.

08 · Project Files

The artifacts behind the lessons.

Start with the free map and Starter Pack. The $99 Field Library adds the complete case plus four specialist working packs.

Free · No email

FDE Production Map

The high-level path from business decision to handoff, with the responsibility lanes shown together.

View Production Map →
Free · Email

Project File 001

Expanded map, 14-step production flow, role matrix, scope and definition-of-done structure, vertical-slice checklist, production-readiness checklist, and QA/failure checklist.

Get the free Starter Pack →

For teams building this now

Does this look like your team’s deployment problem?

FDE Project Files shows the work. YakData applies it with client teams on qualified deployments.

Request a Fit Review Review Production Proof