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.
Location
Reach
What happens to it
Your head and a notebook
You
Leaves when you do. The next engineer relearns it from the same three conversations, or does not.
A prompt
One application
The second workflow does not get it, and the third copies a stale version. Common and quietly costly.
The integration layer
Every workflow
Testable, 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
The picture: three passes into one artefact
What the three acts of the lab build, in the claims vertical. Each pass needs the one before it: you cannot follow a workflow narrated in codes you do not know, and you cannot spot an exception until you know the normal path. The output is not your understanding but a file. Everything you learned lands in one place that every later workflow reads, and a wrong entry fails a test instead of a demo.
Worked example: week one at the insurer
The lab’s claims vertical, run as a real week: a mid-size insurer with 9,000 first notices of loss (FNOL) a month and a sponsor who wants “AI for claims”. The scale and the rules come from the lab; the day-by-day order is the method.
When
Move
Arithmetic or evidence
What you now have
Mon
Size the front door
9,000 FNOL a month ÷ 30 days
300 new claims a day reach triage
Mon
Size the money line
8% of 9,000 go to subrogation
720 recovery candidates a month
Mon
Learn the codes
ask what else counts as “closed”
7 settled, 9 withdrawn, 11 denied: three entries, not one
Tue
Watch an adjuster for an hour
ask “and then what happens?”
the six-step order, FNOL to close
Wed
Two adjusters label 40 old claims
31 agree; 31 ÷ 40
77.5%, the practical ceiling
Thu
Room with the split cases
40 − 31
9 disputed cases, each a candidate unwritten rule
Thu
Hunt exceptions
“ever a case you would not?”
“hire car → Priya”, written down with who said it
Fri
Show a rough triage prototype
target set against 77.5%, not 100%
specific objections, not polite generalities
Two numbers decide the rest of the engagement. 77.5% means no honest contract promises 90% on severity, because the experts do not agree with each other that often. And 40 cases is enough to find the rules but not to pin the ceiling: the 95% interval around 31 of 40 runs from 62.5% to 87.7%, so the target goes in the contract only after a larger labelled set. Triage is the first target because it is where the 300 a day arrive and a human still settles.
Trade-offs: what each way of learning costs
Here the columns are the approach, the time it takes, what it leaves behind, and why.
Case
Time
Space
Why
Read the documentation first
days
the system as designed
Misses the workarounds and every rule nobody wrote down, which are the ones that break a deployment.
Watch one person work, narrated
one hour
the real order, the workarounds, a first list of rules
The best return on time in the week. Pick a sceptic: they tell you what goes wrong.
Two experts label 40 cases
an afternoon each
a ceiling (77.5% here) and the split cases
Turns “accurate” into a number and the splits into a rule list.
Send a list of questions
a day of waiting
polite generalities
People answer what you asked, not what you missed.
Rough prototype, shown early
a day or two
specific, correctable objections
Being wrong in front of an expert is the cheapest correction you can buy.
Become an expert before building
weeks to a quarter
knowledge in your head only
The customer waits, and the parts that matter are still the ones nobody wrote down.
The cheap moves are the ones that put a practitioner in front of something concrete: their own work, their own disagreements, or your wrong prototype. Reading is the only expensive move that never involves them.
Where this shows up: real engagements and interviews
Insurance claims
The sponsor asks for automatic settlement. The defensible first target is triage: high volume, cheap to be wrong, and a human still decides the payout. Settlement and reserves carry financial and regulatory weight, so an insurer hands them to software last, after triage has produced evidence.
Hospital revenue cycle
Denial reports arrive as codes such as CO-45 (charge exceeds the fee schedule). The CFO says “fix denials”, but most preventable denials start at registration and eligibility, upstream of the appeal. The unwritten rule worth finding sounds like “we never appeal CO-97 under $400”, a cost judgement that lives in one person’s head.
Legal discovery
A matter with 2.1 million documents tempts a partner to ask for a model that “decides privilege”. The vocabulary (responsive, privileged, TAR) leads to the real constraint: defensibility. Every decision must be explainable to a court, which shapes the architecture before any accuracy target does.
A learning round drops you into a business you have never seen and scores the order of your questions, not prior knowledge. The same three passes work under a clock: ask what the codes mean, ask what happens next until someone says “usually”, then ask for the exception. The learning round lab on this site drills it.
Check yourself
A handler says “status 4 means it’s with the adjuster, usually.” What do you ask next?
What happens when it is not, and which other codes sit next to it. “Usually” marks a branch the code hides, exactly like status 7 turning out to be one of three closed codes. Writing 4 = with adjuster and moving on flattens a difference that will matter downstream.
Two adjusters agree on 31 of 40 claims. The sponsor wants “90% accuracy” in the contract. What do you propose?
A target written against the measured 77.5% expert agreement, a separate cap on the expensive errors, and a larger labelled set before signing, since 40 cases leave the ceiling anywhere from about 63% to 88%. Then put the experts in a room with the 9 split cases: their argument is the labelling guide.
You learn that hire-car claims always go to Priya. Where does that rule belong?
In the shared integration layer, as an entry in a file like domain.yaml, with Priya named as the source and a test that routes a hire-car claim. Not in one application’s prompt, where the next workflow will never see it, and not in your notebook, where it leaves with you.
In the lab, vocabulary answers score 2, workflow positions 1 and gate answers 3, out of 23. What is the lowest score that earns “Dangerous by Friday”?
19. The verdict needs a rounded 80%: 19 of 23 is 82.6%, while 18 of 23 rounds to 78%. Six of the 23 points come from ordering the workflow, which you cannot do while the steps are still unread codes: each pass builds on the one before.
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.