Across eight repeating weeks we cover scope, requirements, architecture, vertical slice, evaluation, production readiness, ownership, and improvement. The same sequence used to build 77 Rules.
Free FDE Lab · 77 Rules production case
What does a Forward-Deployed AI Engineer actually do?
Follow one real AI system from business decision through production ownership. The Lab shows the decisions, real build work, failures, and role overlaps that make the difference between a working demo and a system people can actually run.
Live, not recorded
Two sessions a week
Bring your own system
Not ready to buy? The seven-part Lab below is free and always will be. See the 77 Rules system ↓
~40people in the SAS development organization I led, spanning engineering, UX, testing, documentation, and management
~$100Min product revenue responsibility during my SAS R&D leadership work
4major software companies in product roles: Brio, SAS, Yahoo, and Tableau
30,000+working professionals trained in analytics, visualization, and data systems
When your work changes how experts think
Pat Hanrahan said our work changed how he thought about analytics.
Pat Hanrahan co-founded Tableau, was a founding employee at Pixar, became a Stanford computer science professor, and later received the ACM A.M. Turing Award, computing's highest honor.
In his only talk at the 2012 Tableau Customer Conference, Hanrahan used The Accidental Analyst as a foundation for his presentation. He said the book changed how he thought about analytics and influenced how he approached teaching analytics at Stanford.
That matters here because the central idea has remained remarkably consistent: start with the decision, make the reasoning visible, and build a process a person can understand, challenge, and improve. FDE Lab applies that discipline to production AI systems.
The system this Lab is built on
This is not a slide deck. It is a running production system.
77 Rules audits data dashboards against company standards, design standards, and data-integrity rules. Multiple AI models examine the same artifact. When they disagree, explicit reconciliation logic decides. A human accepts or rejects every finding, the dashboard gets fixed, and the audit reruns until it passes. Every screen below is the real product.
Why this matters to you
Production Reviews comes directly from work like this. Building 77 Rules required decisions about architecture, model boundaries, reconciliation, human review, scoring, evidence, versioning, deployment, and ownership. Those are the production decisions we work through together.
01 · IngestDashboard captured with its update history and context.
02 · Multi-model reviewSeveral AI models examine the same artifact independently.
03 · ReconcileExplicit logic resolves disagreement instead of averaging it away.
04 · Human accept or rejectA person confirms or overrides each finding, with the evidence in view.
05 · Fix and re-auditThe loop repeats until the updated dashboard passes every check.
Building something now?
Live help while you ship.
Production Reviews is where you apply the FDE method to the system you are building now. There is no cohort and no recorded course to work through first. Join during the current week, participate live, and continue through the repeating eight-week production cycle.
Bring the architecture, code, evaluation, requirement, deployment problem, or production decision you need to resolve now.
Wednesday is the structured workshop. Friday is open office hours. Both are live and interactive, built around real questions and real tradeoffs.
Every review is boxed around a specific problem, decision, or artifact so you leave knowing what to change, test, build, or investigate next.
Seven production decisions · free
The series follows the work, not a software-development waterfall.
Each episode answers one production question, shows the relevant 77 Rules evidence, and ends with a decision about what happens next.
Publishing schedule: Episode 1 is live now. The remaining six publish in sequence as the corresponding 77 Rules work is documented. Every episode is covered live and in full inside Production Reviews, in the same eight-week cycle, without waiting for the written version.
Decide What Deserves to Be Built
Define the recurring decision, consequence, owner, proof of success, and Version 1 limits before code becomes the plan.
Turn Expert Judgment Into System Requirements
Convert domain expertise into explicit rules, evidence, context, workflow steps, exceptions, and clear definitions that software and tests can check.
Design the Production System and the Work
Make the workflow, system design, handoffs between parts, where and how it will run, and role ownership one executable plan.
Build the Production-Shaped Vertical Slice
Move one real transaction through every critical layer before broadening the backlog.
Make the AI Earn the Right to Be Trusted
Test the AI on the actual task, deliberately test how it can fail, control how uncertainty is shown, and verify human override.
Turn the Working Slice Into a Production System
Add input checks, repeat testing, version tracking, monitoring, recovery, security, and release evidence that a demo does not need.
Transfer Ownership and Improve the System
Finish when another organization can operate, recover, extend, evaluate, and improve the capability without the original builder.
Why 77 Rules
One case, enough complexity to expose the real job.
77 Rules is useful because you can see what each part of the system is responsible for. The AI interprets evidence, explicit rules preserve expert judgment, fixed scoring logic controls the final score, and the user can inspect, reject, correct, and rerun.
Image-and-text AI analysis is separated from the explicit rules and scoring.
The system distinguishes what can be observed from what requires context or should remain uncertain.
The system design supports client-specific rules without creating a separate version that becomes hard to maintain.
Responsibility lanes
The work overlaps. One person keeps it connected.
Product, user experience, frontend, backend, and testing are responsibility lanes, not a waterfall. You do some of it yourself and bring in specialists where depth matters.
The forward-deployed engineer keeps the lanes connected. The job is not to be the best specialist in every lane. The job is to keep the business outcome, the system, the tests, and the operating reality connected.
Why learn FDE work from me?
I have spent decades working across the disciplines an FDE has to combine.
A strong Forward-Deployed AI Engineer cannot disappear into one specialty. The job crosses product judgment, UX, frontend and backend engineering, testing, architecture, client work, and production ownership. I have worked across those disciplines as an individual builder, product leader, architect, consultant, and leader of a roughly 40-person software development organization.
Deciding what should be built
Product leadership at Brio, SAS, Yahoo Advertising, and Tableau, from new products to established products generating tens of millions in annual revenue. The work was deciding what mattered, translating customer problems into product requirements, setting priorities, and making tradeoffs.
Making sophisticated software understandable
I worked closely with usability and design teams at Brio, SAS, and Tableau, including Tableau's pioneering visual-analysis organization. I also developed and taught practical systems for dashboard and analytical-interface design.
Building the part people actually use
I have built clinical-trial applications, automated reporting systems, interactive web applications, desktop software for Mac and Windows, analytical applications in Streamlit and R Shiny, and thousands of dashboards and BI interfaces.
Building the systems underneath
My backend work includes regulated pharmaceutical data warehouses, Oracle consulting, building the data warehouse capability at Opsware, re-architecting worldwide data ingestion for Navy Cyber Defense, server-side software, scalability, security, and production data systems.
Proving that the system works
As a product leader, development leader, and hands-on builder, I have worked extensively with QA and release organizations across unit testing, functional testing, integration testing, regression testing, security testing, acceptance criteria, and production validation.
Keeping the whole system coherent
For five years I led a multidisciplinary SAS software organization of roughly 40 people across engineering, management, UX, testing, and documentation. The central responsibility was the same one an FDE assumes today: connect the business problem to the product, architecture, implementation, testing, release, and user outcome.
Professional faculty
Faculty at
INFORMS · American Marketing Association · TDWI
Invited university lecturer
Invited to lecture at
Princeton University · Brown University · University of Chicago · University of Washington, Seattle · North Carolina State University
The evidence
There is a long paper trail.
Books, product work, teaching materials, course evaluations, conference reactions, and recommendations from people who worked with me provide independent evidence of both sides of the equation: technical breadth and the ability to teach complicated work clearly.
Built, simplified, and published
Teaching that working professionals remember
Colleagues and clients on the work itself
That is the experience FDE Lab is built on: decades of building, leading, simplifying, and teaching across the same technical and organizational boundaries a Forward-Deployed AI Engineer has to cross.
What 77 Rules taught us
Five production lessons to carry into your own system.
Do not let free-form AI text directly control what the app does. Check the format and allowed values first.
The model is one component. Business-critical scoring and control rules should stay visible and produce the same result from the same inputs where correctness matters.
If the evidence does not prove a claim, ask for context, show lower confidence, or say there is not enough evidence instead of inventing certainty.
Verification and override need visible evidence and a record of what changed and why, not a sentence in a policy document.
A system is not finished until another organization can operate, recover, extend, and improve it.
What you learn to do
Use the case to improve the decisions on systems you already own.
- Define the decision and the success standard before building broadly.
- Turn expert judgment into rules, evidence, context, and clear handoffs.
- Design and build one complete production path from input to useful result.
- Evaluate reliability, failures, cost, confidence, and human control.
- Release, monitor, recover from failures, and transfer ownership deliberately.
Follow 77 Rules from decision through production ownership and see the operating method before you spend anything.
Start with the free Lab →Twelve weeks, two live sessions a week, your system on the screen. Join immediately and enter wherever the eight-week cycle is now.
Enroll now →Bring the system you are trying to ship. We will determine whether the live review format is a good fit before you spend $3,500.
Book the scope chat →Before you decide
The questions people actually ask.
If your objection is not answered here, email it. A program that teaches evidence-based systems should be able to answer a direct question directly.
Who this is not for
- People looking for a prompt-engineering course
- People wanting to train or fine-tune models
- People learning to program for the first time
- People who want recorded lessons to binge alone
- People who cannot make either live session most weeks
Is this recorded, or do I have to show up?
Both weekly sessions are live. Wednesday is a structured Production Workshop with teaching and live reviews of member work. Friday is open office hours. The value is the interaction, so the program is built around your attendance, not a video library.
Do I have to wait for a cohort?
No. The eight-week production cycle repeats continuously. You join at whatever week the cycle is on and cover the complete sequence from there. Twelve weeks means you see the full cycle plus four weeks of overlap on the topics you most need to revisit.
What if I do not have a system in flight yet?
Bring the one you are about to build. Scope, requirements, and architecture are the first three weeks of the cycle and they are the cheapest place in the entire lifecycle to fix a mistake. Showing up before you write code is an advantage, not a disqualification.
Can I bring proprietary or client work?
Yes. You control what you put on screen. Redact names and sensitive values, show architecture without underlying data, or describe the system and decision at the level necessary to get useful feedback. Nothing is recorded for distribution.
What is the difference between this and a private engagement?
In Production Reviews I advise while you build. In a private engagement, starting at $38,000, I build with your team inside your environment and hand back a working production path. Reviews teaches you to do the work. A private engagement gets the work done.
Fifteen slots a week across the group. Will I actually get time?
Seven-minute boxes are deliberate. They force a specific question and a specific answer, which is how most production blockers get resolved. Watching another member's architecture get taken apart is frequently more useful than your own turn, because the failure modes repeat.
Is $3,500 the whole cost?
Yes. $3,500 covers the full 12 weeks and both live sessions each week. There are no additional program tiers or required add-ons.
Can I talk with you before I enroll?
Yes. If you are seriously considering Production Reviews but want to verify that your system fits the live review format, book a 15-minute FDE Lab Scope Chat.
What if it is not what I expected?
Attend the first Wednesday workshop and the first Friday office hours. If it is not what you expected, tell me before the second Wednesday and I refund you in full. You will have seen the actual product, not a sales page, before you commit.
The decision
The model was not the hard part.
Everything after the demo is the hard part: requirements, evaluation, failure handling, human control, release, monitoring, and handing it to people who have to live with it. That is the work Production Reviews covers, live, every week, on your system.
Two live sessions a week for twelve weeks. Not sure your system fits? Use the scope chat. If you enroll, you are still protected by the full refund before the second Wednesday.
Not ready for Production Reviews yet?
Take the Production Readiness Checklist with you.
Get the checklist now, plus new FDE Lab episodes, production lessons, and selected real build examples as they are published.
Readiness checklistProduction lessonsReal build examples
Check your email to confirm.
Please find the email from hello@fastdatasecrets and ensure it isn't on your Spam list, and confirm your subscription.
Download the readiness checklist
Free asset
FDE Production Readiness Checklist
Download the readiness checklist
By subscribing, you agree to receive FDE Lab email from YakData. See Privacy.