Template 6 · Field Archaeology Kit

Companion chapter(s): Chapter 6. The three tools are in order of use. Use the half-day guide to book and complete one shadowing session, keep the friction log throughout, and switch on the three-layer probing script when you hear "I can tell at a glance." License: Every template in this book may be modified freely and used in your work, no attribution needed.

6.1 Half-Day Shadowing Guide

Booking It

Who to book: the actual user, the person whose daily moves the system will change after launch, not their supervisor. If the supervisor arranges it, name the person explicitly.
Opening script (three elements: apprentice posture + capped duration + zero-interruption promise):

"I would like to sit with you for half a day and watch how you normally handle these claims. I am here to learn. I am not here to evaluate you, and I am not here to sell a system. Work as you normally do, no need to explain anything to me. I will sit to the side and take notes, save my questions, and ask when you have a free moment. I will take at most 30 minutes of your wrap-up time."
When you get rescheduled: wait, book again, do not escalate to a superior to apply pressure. The reschedule itself is information, and front-line time is the most expensive. The test is the reason, not the count. If the reason changes every time, you are being brushed off and escalation is warranted. If the reason is backlog every time, the place you want to look is exactly where it hurts most, so wait. Consider escalating only after three or more in a row, and when you do, talk about schedule protection, not attitude, and land it in the business-side commitment line of the charter (Chapter 4).

Prep Checklist for the Day Before

[ ] Print one copy of the official flowchart / SOP (your dig map, for marking differences)
[ ] Print a blank friction log (see 6.2)
[ ] Confirm with the person: may I look at your screen? May I take notes? Where sensitive data is involved, the default is no recording, no screen photos (notes are enough, trust is worth more; having permission does not mean you should use it)
[ ] Think through your red lines and keep them: no promising features, no judging how they work, no suggestions on the spot
[ ] Prepare 1–2 candidate claims to trace: after following the person, pick one claim and follow it end to end

Half-Day Schedule (4 Hours as an Example)

Slot	Action	Discipline
0:00–0:10	Opening (repeat the script above)	Make the role clear: apprentice, not audit
0:10–2:00	Pure observation	No interruptions; write every question down and save it
2:00–2:15	Tea-break question window	Ask only about actions you observed, no more than 3 questions at a time
2:15–3:30	Continue observing + pick a claim to trace	Count steps, count tool switches, note off-screen actions (phone calls, calling over a colleague)
3:30–4:00	Wrap-up questions	The three-layer probing method (6.3); the three closing questions (below)

What to Count While Observing

Step count: real steps vs. official process steps (the difference is the width of the workflow gap)
Tool switches: core system / inbox / spreadsheet / phone / chat tool, how many switches to each
Off-screen actions: phone calls, calling over a colleague, leafing through paper files (the easiest to miss, and often the most valuable)
Workaround tools: anything open on the screen that is not on the IT asset register (private spreadsheets, sticky notes, personal folders, small group chats)
Ten-second judgments: the moments the person pauses and then decides outright (mark the time, save for the three-layer probe)

Code of Conduct (Break Any One and the Half Day Is Wasted)

No suggesting ("actually, you could...", you are teaching the master their craft)
No correcting (see a "noncompliant" workaround, note it, do not call it out)
No selling the system (not even one "the system will be able to do this for you later")
No promising features (a promise makes everyone you observe from then on start performing)
Noting without calling out is not permanent secrecy (not correcting on the spot governs this half day; whether to report is a separate question; if you really must report, tell the person first, face to face)

The Three Closing Questions

"Was today a typical day? What was not typical about it?"
"If you took a week off, who would do this work? Which step would they get stuck on?"
"Of everything in this half day, which thing did you feel was least worth your time?"

6.2 Friction Log Template

friction log (defined in Chapter 0): a running list of friction, "the places where reality and paper do not match." During shadowing it is the main recording tool. After discovery it is the upstream of the data reconciliation checklist and the eval material.

#	Time	Paper version (what the SOP / system / report says)	Field version (what actually happened)	Type	Follow-up
1				data / tool / process / judgment	reconcile / probe / into eval / report risk

The four-way type split:

Data: a field does not match reality (status "in progress," actually "waiting two weeks for documents") → follow-up is usually reconciliation
Tool: a workaround tool carries the function of the formal system (Excel is the source of truth) → follow-up is usually bringing it into the data source inventory
Process: real steps added to, removed from, or changed against the SOP (official 5 steps, actual 14) → goes into the real flowchart
Judgment: a human judgment that cannot be derived from rules (the ten-second red flag) → switch on the three-layer probe

Recording rules:

One line per friction. Write keywords on the spot, complete within 24 hours. Details recalled the next day are invented.
Record facts, not conclusions ("status field lags on 3 claims" is fine, "their system is terrible" is not).
Every line must have a follow-up entry, or the log becomes a gripe list.
AI use: dictating or photographing your notes and feeding them to AI for structuring and clustering is fine, but the raw observation must be what you wrote down while present. AI organizes archaeology notes. It does not produce archaeology facts.

6.3 Tacit Knowledge Probing Script (the Three-Layer Probing Method for "I Can Tell at a Glance")

Trigger Phrase List (Switch On When Heard, Mark the Time on the Spot, Probe in the Wrap-up Window)

"I can tell at a glance" / "obviously fake" / "gut feeling" / "from experience"
"Hard to say" / "I cannot explain it, it just feels off"
"Cases like this are always like that" / "Do it long enough and you get it"
And any judgment made within ten seconds whose reason you cannot derive yourself

Layer One: Anchor on an Instance, Replay the Actions, Do Not Ask Why

"That claim just now, you looked at [action 1] first, then went through [action 2], and then you [judgment]. Right?"

Principle: ask "why" straight out and you get an on-the-spot rationalization or "I can tell at a glance." Replay the concrete action that just happened and the person cannot answer with a stock phrase. A stock phrase does not match actions.
Key points: it must be a real instance observed in this session; hypothetical questions ("if one came in that was..., how would you judge it?") are banned throughout the script.

Layer Two: Compare, Find the Difference Between Two Similar Claims

"This one and the one just now are both [same type], and the [surface indicator] is about the same. Why did you [flag] this one and not that one?"

Principle: a single instance gets you a general description; a pair of minimally different instances forces out the boundary condition. The real shape of the rule is in the difference.
Key points: best to pick the comparison claim on the spot from the ones they handled today; once the difference comes out, follow with "any other difference?", the second answer is often worth more than the first.

Layer Three: Boundary Counterexamples, When Does It Not Hold

"When would you not [judge it this way], no matter how [extreme the indicator]?" "Have you ever [judged it this way] and then found you were wrong? What did you change after that?"

Principle: the boundary of a rule and its failure cases are the part experts themselves are rarely asked about; "what did you change after that" also digs out the rule's update mechanism. That is the key evidence against hardcoding a snapshot.
Key points: when asking for counterexamples the tone is curiosity, not challenge; if the person answers "never been wrong," switch to "when you train new people, what mistake do they make most often on this kind of claim?"

Wrap-up: Restate as Rule Sentences, Have the Person Correct Them

Write every judgment you dig out in one uniform sentence form:

When [observable signal] appears, I [action], because the risk of not doing so is [consequence]. (Boundary: [when it does not apply]; source: [name + date + instance claim number]; stability: stable / changes with [X])

Three disciplines:

Verify back: take the write-up back within 48 hours for the person to circle the mistakes. Ask "where is it written wrong," not "is it right."
Mark stability: rules that drift (list types, threshold types) must have their drift source marked; this entry directly decides how the rule enters the system. Stable rules can be made explicit as suggestion logic. Drifting rules must keep the Human Call and a decision trail for overrides (Chapter 6 failure mode 4, Chapter 17 mechanism).
Mark destination: every rule notes its downstream use, into the real flowchart / into an eval error category (Chapter 11) / into the risk list. A rule with no destination dies in the notes.

Code Hooks

The companion repo provides (this repository's repo/ directory):

templates/field-archaeology/: structured friction log template and AI cleanup prompt scripts (transcribe → structure → cluster)