FDE · Domain

Useful in a Week, in an Industry You Have Never Worked In.

This is the meta-skill. An FDE lands at an insurer, a hospital or a law firm on Monday and has to ask questions that reveal the real problem by Friday — with no time to become an expert and no permission to be useless. There is a method, and it runs in this order: the vocabulary (which in every enterprise domain turns out to be codes), the workflow (the one people actually follow, not the one on the process diagram), and the rules nobody wrote down. Pick a vertical and run all three.

3 verticals · vocabulary · workflow order · the undocumented rule
the codes

Their systems speak in status 7 and CO-45. Users and models speak in words. That map is your first deliverable.

the real workflow

What people do, including the workarounds. It never matches the diagram, and the gap is where the value is.

the undocumented rule

A threshold or exception living in one person’s head. Usually the actual business logic. Never in the requirements.

useful, not expert

The bar is holding a working conversation and knowing what you do not yet understand. A week, not a quarter.

domain-ramp — week one
Act 1 · Vocabulary
Pick a vertical, then learn its codes. Each one you get right goes into the glossary below — which is the artefact you would actually build in week one.
1/3
act
0
score
0
glossary

The method, in the order that works

People ramp badly by reading. Documentation describes the system as designed; you need the domain as operated, and those are different documents written by different people about different decades.

01

Learn the vocabulary first, because it is codes

Every enterprise domain runs on identifiers a practitioner reads fluently and you cannot: denial codes, status enums, product types, entity abbreviations. Build the map early — you cannot fill it in without asking exactly the right questions, so the artefact and the learning are the same activity.

02

Watch someone work for an hour

Then ask them to narrate their decisions. This is the highest-value hour available in a deployment and almost nobody asks for it. You will learn more than from any documentation, and you will collect the rules that are not written down — which are precisely the ones that will break your system.

03

Reconstruct the real workflow, including the workarounds

The process diagram shows six clean steps. The reality has a spreadsheet between steps three and four that four people treat as the source of truth. Ask “and then what happens?” until someone says “well, usually…” — that word is where the work is.

04

Hunt the undocumented rules deliberately

“Is there ever a case where you would not do that?” produces thresholds, exceptions and named people. Write each one down with attribution, because a disputed rule needs someone to ask, and because showing an operations director twelve undocumented rules their business depends on is frequently the moment you stop being a vendor.

05

Build something wrong, in front of someone who knows better

The fastest correction loop available. A rough prototype produces specific objections; a list of questions produces polite generalities. You are trying to be corrected cheaply, early and often — which is the same skill the learning round measures.

Where the domain knowledge should live

Two weeks in you will know what the codes mean. Where that knowledge goes decides whether it compounds or leaves with you.

LocationReachWhat happens to it
Your head and a notebookYouLeaves when you do. The next engineer relearns it from the same three conversations, or does not.
A promptOne applicationThe second workflow does not get it, and the third copies a stale version. Common and quietly costly.
The integration layerEvery workflowTestable, reviewable by their subject-matter expert, and a wrong entry breaks a test — so it stays true.
# domain.yaml — the artefact this lab is a drill for status: "7": { label: "closed — settled", terminal: true } "3": { label: "awaiting adjuster", sla_days: 5 } rules: - rule: "freight surcharge above £200 goes to a human" source: "Bella, exceptions team, 2026-07-14" # attribution matters written_down_anywhere_else: false # <- the high-value flag
learn first
the codes
best hour
watch someone
the real prize
undocumented rules
target
useful, not expert

Common questions

How do you learn an unfamiliar industry fast enough to be useful?

Three passes, in order. Vocabulary first, because in most enterprise domains it is really a set of codes and the translation layer is the first thing you will build. Then the actual operational workflow — not the one on the process diagram. Then the rules that exist only in a practitioner’s head, because those are simultaneously the highest-risk part of the deployment and the most valuable thing you can hand back.

What is the fastest legitimate way to learn a domain?

Ask to watch someone do the work for an hour, then ask them to narrate their decisions. A sceptical practitioner is the most valuable hour available — sceptics tell you what actually goes wrong, enthusiasts tell you what they hope.

Why does the vocabulary matter so much?

Because their systems speak in codes and the users and any model speak in words. That translation belongs in the shared integration layer rather than in a prompt, because a prompt is per-application while the integration layer serves every workflow you build afterwards.

What counts as an undocumented business rule?

A decision rule living in an experienced practitioner’s judgement — an amount threshold, an exception, a case that always goes to a named person. They are usually the actual business logic your system must reproduce, and they never appear in the requirements.

How long should a ramp take?

About a week to be useful, not to be an expert. The target is holding a working conversation, asking questions that reveal the real problem, and knowing which parts you do not understand well enough to design against. Trying to reach expertise before building is the more common failure.

Keep going

Finished this one? 0 / 58 Labs done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

More Labs