Chapter 2. 19:57:11

Nineteen hours, fifty-seven minutes, eleven seconds. This is not the "about twenty hours of interviews" from the presentation — it is the sum of the timecodes of thirty-four audio files, computed from the master registry of recordings. We could have rounded it, and no one would have noticed. But a rounded number cannot be checked, and 19:57:11 can: take the registry, add up the durations, and you get exactly this sum.

More than that, this figure has a twin, computed by an independent method. Run all thirty-four transcripts through a word-count utility and you get 218,822 words. On the order of two hundred and twenty thousand words of spoken language over just under twenty hours of recording — the pace checks out. Two different measurements of the same volume, taken with different instruments, confirm each other. That — not a round number on a slide — is what we call an impressive result. The entire style of this edition is built the same way: what should surprise is convergence, not magnitude.

Now — where those twenty hours came from and what they turned into.

The Field Shop

A large manufacturer of structural building components, four months of fieldwork. A team of three, 24 respondents — from top executives down to operators and the batching-plant technologist. The interviews are grouped not chronologically but into five packages running from strategy to operations: leadership, engineers, production, procurement with logistics, services with IT. The order is not cosmetic: each subsequent package is read with the accumulated context of the previous ones, and a later respondent, without knowing it, verifies an earlier one.

The field stage begins before the first question — with a kickoff meeting whose whole job is to remove fear. The script is well-rehearsed: a word from management with an explicit guarantee that "everything you say will go toward improvement, not punishment"; an explanation, in shop-floor language, that the team has come to remove drudgery, not people; the logistics of self-recording. This is not a courtesy ritual but data-quality engineering: across all our practice, seventy percent of a transformation's success is people, and a frightened respondent gives you testimony, not data. Incidentally, about the figure of "24 respondents" against 23 profiles: we interviewed the accounting department as a group, and that is a protocol of its own — a group profile plus observing who interrupts whom: the interruption dynamics turned out to be an honest proxy for the real hierarchy.

Two episodes from this shop explain more about fieldwork than any handbook.

Episode one. A respondent describes how everything in her unit is digitized: the software is installed, the data gets entered, nothing is done by hand. The words are recorded, the timecode is in place. The interviewer asks: show me on the screen. And on the way to the screen, paper slips on a clothespin turn up — a living workflow that, in words, had just not existed. No malice involved: the person was sincerely describing how things are "supposed to be," not how they are. The request "show me on the screen" — the rule whose birth is described in Chapter 1 — did its routine protocol work here: a verbal answer and an observed process are two different data sources, and they coincide far less often than you'd like.

Episode two is about the price of an interviewer's mistake, and here I have to talk about myself. One of the key interviews — with the head of the IT function — I wrecked. I tried to sell and diagnose at the same time: instead of questions came a self-promotional monologue, then an accusation that my interlocutor was complicit in "digital backwardness," then I relayed unverified third-party negativity to his face and failed to introduce myself when he asked me directly. The respondent ended the conversation for me: "That's it. I have no time. Goodbye." Verbatim. That minute was bought at a high price, and from it a hard pipeline rule was derived: the diagnostician's and the salesman's roles are never combined in a single conversation, and the interviewer speaks no more than a third of the time. The interview simulator on the portal is a direct descendant of that minute: it is cheaper to rehearse a blown interview in simulation than on a live key respondent.

Between these two poles lies the routine repertoire of field techniques, each one bought with practice. Ending on saturation: one interview lasted twelve minutes, because the pattern had repeated three times, and beyond that point time is worth more than politeness. Quantitative calibration before any proposal: first "how much time does contract review take you?" — an hour and a half to two — and only then a conversation about cutting it; a figure named by the respondent themselves does not get disputed at the defense. Counter-hypotheses — "trial balloons" — for the operational tier: the open question "what would you automate?" brings from line staff only what they already know; it is more productive to present a concrete hypothesis and let them tear it apart. And plain observation: icicles on the heating main — a question about heat losses that was in no guide.

The field data also includes what is not in it. Across 27 interviews — fewer sessions than the 34 audio files, because some respondents were interviewed twice and long recordings were split into parts — not a single respondent ever mentioned the head of the IT function — zero mentions of the person formally responsible for all of the enterprise's systems. Silence on that scale is not a gap in the data; it is data in itself: for the shops, IT physically does not exist. The pipeline has a dedicated step for this — the omissions audit: for every respondent, a list is kept of the topics they should have touched and did not.

The Compression Pipeline

Next, the twenty hours of speech enter the pipeline. The transcripts are dirty: machine diarization attributes one respondent's lines to another — caught only by hand, by content; interviews are sliced into files that break off mid-sentence exactly at the key grievance; one service registry would not parse at all because of an unescaped quotation mark; timecodes jump around. So the corpus has input control — speaker validation, format linting, splicing the parts back together — and a freeze rule: the corpus is locked before synthesis starts, so that every conclusion can be tied to the version of the data it was made on.

The pipeline itself is five stages. The first is normalization: every fragment becomes a structured record with a verbatim quote, a timecode, a severity, a link to hypotheses. The second is synthesis with deduplication and cross-verification. The third is chapter writing. The fourth is verification by an outside pair of eyes (its anatomy is in Chapter 3). The fifth is finalization and assembly. The canonical breakdown of this pipeline's six agent roles lives in the agent swarm playbook — here we are showing the shop floor, not the org chart.

The pipeline is driven by a corpus of twenty-one prompt files, and it has a non-obvious property: the prompts evolve from package to package. The model has no memory between sessions, so each subsequent prompt opens with a summary of the previous one's results — a manual transfer of context — and fresh lessons get appended there too: after the agents started paraphrasing quotes, a verbatim requirement appeared; after a numbering collision — pre-assigned ID ranges. The pipeline learns in writing, and the trace of that learning can be read in the prompts like growth rings.

The output is a package of eight client documents: diagnostics, roadmap, strategy, financial model, first-priority measures. The flagship report runs 2,279 lines, roughly ninety pages. All of it took sixteen working sessions over two days — against the fourteen days budgeted in the plan. The plan was built on human labor norms; the agents' parallel work broke the norm by a factor of seven, and this is the only line in this chapter where the divergence between plan and fact makes us happy.

What does an atom of this pipeline look like? Here is a real record from the pain-point registry — the very structured unit an interview fragment turns into. The record is sanitized under clean-lab rules: a role instead of a name, enterprise details stripped; the field structure and the quote are real:

- id: PP-003-041
  severity: high
  block: operations
  quote: "We used to hand in the report on the 3rd to the 5th. Now it's
    the 15th to the 18th. Fewer people, more paperwork."
  timestamp: "00:41:37"
  respondent: "head of the fabrication shop"
  department: production
  theme: "reporting-cycle degradation"
  codes: [reporting-lag, workload, degradation-trend]
  related_hypotheses: [H12]
  business_impact: "period close slips toward the 20th of the following
    month; management by fact becomes post-mortem"
  quick_win_potential: medium
  cross_reference: [PP-001-017, PP-004-052]
  confidence: corroborated # 2 independent sources
  verified_by: synthesis-moderator

Fifteen fields per single complaint looks like bureaucracy right up until the moment such records number in the hundreds. Then the fields become the only way to filter, deduplicate, and trace: from a quote with a timecode to a pain point, from a pain point to an initiative, from an initiative to a page of the report. Note the confidence field: the strength of a claim depends not on the vividness of the quote but on the number of independent corroborations from different departments.

And here is what drives that extraction — a fragment of the real normalization-stage prompt, from the twenty-one-file corpus the pilot ran on:

IMPORTANT: VERBATIM quotes, EXACT timecodes in HH:MM:SS format — the lesson of the previous package: agents produce approximate paraphrase, paraphrase = defect. Every code is backed by a direct quote; do not interpret on the respondent's behalf; distinguish facts, opinions, and emotions. Mark the unintelligible with an [inaudible] tag; above a 30% share — escalate. ID ranges are pre-assigned: agent A — PP-003-001…030, agent B — …031…060, agent C — …061…090; self-assigned numbering is forbidden.

Every line of this instruction is a scar. "Verbatim quotes" appeared after the agents started paraphrasing; the pre-assigned ID ranges — after one agent numbered its records on its own and the merge had to be redone by hand. A prompt is not an incantation; it is an error log rewritten in the imperative mood.

88 Instead of 156

Now the main story of this chapter — about the number we did not take to the client.

The header block of the final pain-point registry stated: after deduplication, 156 records. A handsome number; it had already spread through the drafts and was begging to go into the report. But while preparing the case showcase we did what we do with any figure: we recounted it from the body of the file, not from the header. And the header fell apart. Its three internal totals contradicted one another: the breakdown by severity gave 156, by blocks — 172, by categories — 176. A neighboring document cited a fourth version — 239. And the body of the registry itself held exactly 88 records, consecutive, with no gaps.

The explanation is prosaic: the header had been written at the planning stage and never recounted, while the body lived a life of its own. The divergence ran all the way through: even the "raw" pre-deduplication number did not reconcile — the documentation promised 264 source records, a recount across the five package files gave 268, and eight records had been dropped during the merge silently, with no annotation. Nobody lied — the header and the data simply drifted apart, like the report and the sensor in Chapter 1. But for the report's reader there is no difference: an unverifiable number is a landmine, and it goes off at the worst possible moment — at the defense, in front of a skeptic. The only defensible number is 88, and that is the one that went into the work. Hence the rule now wired into the pipeline as a dedicated script: don't trust the registry header — trust the recount of the body. Any YAML with a counter in its header goes through an automatic "claimed vs. actual" reconciliation before it reaches a document.

The same discipline ate one more handsome formula. The pilot summary read "17 of 17 hypotheses confirmed" — a perfect score that begs to be printed in large type. A recount against the summary table gave: 15 strictly confirmed, one hypothesis — partially, one — reformulated. "15 of 17" sells worse than "17 of 17." But the first figure can be defended under cross-examination, while the second breaks at a single glance into the table. We kept the first — because a study caught on one inflated number loses the right to be trusted on all the others.

I'll admit: removing 156 from the drafts was unpleasant. The number already lived in the texts, wordings leaned on it, and next to it "88" looked modest. But this is exactly the fork where it is decided what separates a factory from a report generator: a generator optimizes for impression, a factory — for verifiability.

The rule "don't trust the header — trust the recount of the body" also has a public version you can run right now: the /gate tool on the portal recounts what a document's header claims against its body, in your browser — paste your own report and see whether its header drifts apart the way ours did.

What the Header Promised and What Survived the Recount

This table is a portrait of the method in three rows. The first two are about the claimed being systematically larger than the measured — and the factory exists to expose that gap before the client does, not after. The third is about why the factory is possible at all: where weeks were the norm, the pipeline fits into days, and the freed-up time is spent not on "even more text" but on recounting every header.

Who exactly inside the pipeline keeps the author from believing their own header — that is the next chapter: every role there has a name of its own, and not one of them checks itself.