Can the team distinguish what the system can observe from what it must infer?
FDE Project Files · Episode 02
Turn Expert Judgment Into System Requirements
Turn expert judgment into explicit rules, evidence requirements, context fields, workflow states, exceptions, and contracts that software and QA can test.
Coming weekly after Episode 1. Target runtime: 45 to 55 minutes.
Questions this episode answers
Make expert judgment explicit enough for software to test.
These are the questions the episode keeps returning to across product, engineering, evaluation, and ownership.
Does the workflow collect the context needed before the system makes an important claim?
Are rules, evidence, error states, and interfaces explicit enough to test?
What you’ll see
What Episode 2 shows.
The walkthrough stays anchored to real artifacts and the decision each one supports.
The checklist, examples, and domain rules before they are normalized for software.
Identifier, condition, evidence, severity, confidence behavior, and outcome.
Examples that separate directly observable facts from claims that need context or should remain uncertain.
The structured information the system asks for instead of inventing missing business context.
Artifact → context → evaluate → inspect → verify or reject → rerun.
Structured request, response, evidence, progress, review, and error states shared by frontend, backend, and QA.
Concrete 77 Rules evidence
A rule is only useful when the system knows what evidence makes it true.
Rules 77, 78, and 86 are public examples of expert judgment expressed as explicit checks: comparative context, reporting time range, and consistent monetary units. The episode uses examples like these to show how domain knowledge becomes software behavior.
Review the 77 Rules case boundary and evidence →
Start here
Use the same production map with your own system.
The free Starter Pack gives you the shared production map, role structure, definition-of-done framework, and core checklists used across the series.