The judgment of this piece: the AI's job boundary is not drawn in the proposal — the business reality draws it. Reproduce the manual business flow first, and the AI seat is reproduction's output, not the kickoff meeting's input.
What this piece solves for you: at your next AI kickoff, the first move is still "list what the model can do and shop for a scenario." This piece swaps that move for "walk one real order end to end" — and it doesn't argue from rhetoric. It opens with two written crash records, one from the customer side and one from the vendor side, dying the same death; then examines the workflow questions each FDE addressed first; then distills the five-step reproduction routine — walk it, ask the six whos, freeze three questions, put a human gate at the costliest error, shrink before you expand — every step pinned to evidence from two live deployments.
Boundary first: both cases come from Datawhale's FDE Cases 100, first batch of 24 — one editorial project's interview compilation, not 24 independent causal experiments; every effect figure stops at interviewee self-report. The five-step routine is our distilled procedure: it helps make the questions concrete; it guarantees neither completeness nor success. And where the business flow itself doesn't exist, the routine fails — the failure conditions are stated at the end, not buried.
Two Failed Builds, on the Table First
Two crash records. Put them on the table before anything else.
One is recorded in the telecom case. A top-three US telecom carrier tried this before ever calling in the outside team — automated dashboard reports, then an agent framework: "even before we got involved, they had already built an agent of their own" (NO-16 txt L54-56). The build, as far as the FDE could tell, was one sentence handed to the model: "You are now a data analyst; I'm giving you this data, please analyze it." (L58-59) "It looks perfectly reasonable, but once it actually runs, the results are often unsatisfying. Even with a very good model underneath, nothing guarantees the final output meets the business's requirements." (L60-61) The interviewed FDE who worked this project put it even harder: "'It runs' and 'it can run in production' are two completely different things." (L57, print p. 161)
The other is recorded in the manufacturing case. A company doing made-to-order manufacturing — many varieties, small batches — ran a quoting AI project (by the company's own account in the interview: roughly two to three hundred people, business scale in the one-to-two-billion-yuan range, NO-17 txt L19, print p. 169), and the vendor team, replaying its own proposal, confessed in writing: "At first we thought about it the direct way: the model reads the drawing, extracts the fields, and the price falls out of a rule-based calculation. Only when it actually ran on the floor did we discover that end-to-end direct pricing kept producing numbers that didn't match the real cost." (NO-17 txt L111-113, print p. 174)
One company that wanted AI; one vendor whose entire job is installing AI for companies. Set the two records side by side and our comparative reading is that both accounts expose the risk of assigning AI a broad job before specifying its business constraints. The manufacturing team's initial design had the model read drawings and extract fields, followed by rule-based price calculation. The telecom FDE illustrates his conjecture about the customer's earlier version with a single prompt.
Both cases come from Datawhale's FDE Cases 100, first batch of 24, published September 2026 — an industry interview compilation (the telecom case body sits at print pages 160-166, the manufacturing case at 169-178; quotes here are anchored to the physical lines of the archived extraction files). FDE, Forward Deployed Engineer — the delivery role that installs AI into a company's front line; how that delivery role's own business model pencils out is a piece of its own, Your FDE Moved Into the Client's Building. How Do You Get Them Back Out?, and it isn't retold here. The two narrators appear below as the interviewed FDE of the telecom case and the interviewed FDE of the quoting case.
Two Records, One Job Description
First, where the telecom customer's version died.
What the analysts' day looked like before that prompt, the source describes concretely: data analysts and data scientists wrote their own SQL, even went further and built machine learning models, dug problems out of the data, and packaged the results for managers or leadership to read (NO-16 txt L28-30, print p. 160). SQL that runs to a hundred or several hundred lines can break somewhere in the middle — and the FDE later actually ran into cases that "looked correct but had queried the wrong data" (L34-35). Dashboards are better suited to questions defined in advance, while real analysis is often a chain of follow-up questions (L36-41). The floor had already laid the answer out: the middle steps err, the output has an audience, the questions never stop changing. That one-line prompt caught none of it.
The carrier wasn't missing anything either — in the telecom FDE's words, "the customer already has data, has analysts, has plenty of AI tools, but none of it has yet been combined into one reliable business process" (NO-16 txt L42-43, print p. 160). The missing thing is exactly what the prompt didn't contain: what caliber the input arrives in, which steps the middle passes through, what standard the output has to meet. The model received an appointment letter, not a process.
The manufacturing version is more interesting, because it came out of a project that was deliberate about method. The quoting FDE's self-described order of work: "I never took a model to the customer and asked 'what could this model do for you' — my order of work ran the other way around: understand the business first, break down the process, then judge which links should be AI." (NO-17 txt L79-80, print p. 172) "We first went and reproduced the traditional manual business flow and data flow, by restoring the actual SOP" (L81-82).
And even so, the first draft expected drawing recognition and field extraction to feed straight into rule-based pricing; the source does not say the model independently performed all pricing. It was the floor that sent that draft back — the numbers didn't match the real cost.
So these two records are actually two layers of lesson.
Layer one: a job title alone leaves the AI's working boundaries unspecified. The telecom prompt example illustrates that risk, but the source itself keeps it tentative: the customer "may simply have given the model a prompt" (NO-16 txt L58). That example does not specify input requirements, intermediate steps, or output standards; it does not establish that the customer's earlier system lacked all such design.
Layer two stings more: Reproducing the workflow first does not guarantee that the initial design will work. The manufacturing team's first design connected model-based drawing recognition and field extraction to rule-based pricing, but the numbers often did not match real costs. The revision is described in the same passage: "So we changed the design: the model would first be responsible only for structuring the drawing's information, pricing would return to the company's own materials and rules base for matching, and every single order would go through human calibration before going out the door." (L113-114)
Align the two records and what we see is one structure: the AI's job boundary is not slapped down in the proposal — the business reality draws it. That is our comparative conclusion, not either case's own words — but both cases left a written record of the same death, in black and white.
The two "job descriptions," side by side (our alignment; each case's facts taken only from that case's own source text):
| Telecom version: one appointment letter | Manufacturing version: end-to-end takeover | |
|---|---|---|
| Who wrote it | the customer itself — built its own agent before the outside team arrived (NO-16 txt L54-56) | the vendor team's first draft — inside a project that did reproduce first (NO-17 txt L79-82) |
| The seat AI received | the FDE's conjectural example: the entire "data analyst" role, via one prompt line (L58-59) | the whole quoting chain: read the drawing, extract the fields, run the rules, set the price (L111-112) |
| How it died | once running, results didn't meet business requirements; "it runs" ≠ "it can run in production" (L57, L60-61) | end-to-end pricing produced numbers that regularly didn't match real cost (L112-113) |
| What sent it back | the interviewed FDE named it in the replay — the project then went forward as system design | floor evidence — real costs didn't match; the vendor changed its own design (L113-114) |
| The shared death (our alignment) | the prompt example specifies no input requirements, middle steps, or output standard; the old system's full design is undisclosed | initial rule-based pricing did not match real costs; the revision explicitly used company materials and rules (L111-114) |
Both FDEs Started by Understanding the Work
Past the crash records, look at how each interviewed FDE describes the business analysis they did first.
The manufacturing FDE first investigated the workflow and handoffs on the workshop floor. "After entering the site I went to the workshop first, watched one order travel from drawing to delivery and noted every link it passed through, went through a stack of historical quotes, and talked separately with the business staff and the veteran masters" (NO-17 txt L91-92, print p. 173), and asked out a roster: "who reads the drawing, who breaks down the requirement, who decides the materials, who judges the process, who checks the cost, who sets the final price — and how the roles hand off to each other." (L93-94) Only then came the line: "Only when all of this is clear can you know where AI should sit." (L94-95)
The telecom FDE started with three questions. "What input does the customer actually need? What output do they need at the end? What actually happens in between?" (NO-16 txt L76-77, print p. 162) "Because if these three things aren't nailed down, no matter how beautifully you write the agent, it's meaningless." (L78)
What the three answers eventually got poured into, the telecom case states itself: "We didn't build it as a 'chatting analyst'; we designed it as a business system" (L85-86). Note the direction: the system form is where reproduction lands, not where it starts — first the three questions tear the work apart, and only then is there anything to pour into a system. Reproduction doesn't mean kicking the old way aside either; the telecom FDE paid the manual process its due first: "To be fair, the old manual analysis method worked — you can't simply call the traditional method 'bad,'" and for relatively fixed questions "it's actually very effective" (L50-53, print p. 161). Recognize which stretch of the existing flow is good before judging which stretch AI should take over.
One entered through the workshop, one entered through questions — different paths, the same order: walk how the humans do the work first — the AI's seat is what that walk produces, and no kickoff meeting can hand it out.
(One note on provenance: the order judgment itself has sources — "reproduce first, then place" is the quoting FDE's self-described working method, and the "three questions" is the telecom FDE's self-description; aligning the two into a single discipline is our cross-case decomposition.)
The requirements side runs on the same logic. The requester says "I need a quote," and it sounds like a one-line errand. The quoting FDE dismantled it himself: "Calling this scenario just 'quoting' isn't actually accurate. More precisely, it's a complete chain: drawing parsing, requirement breakdown, R&D collaboration, production planning, cost accounting, quoting." (NO-17 txt L24-25, print p. 169)
That chain isn't rhetoric — every link on it carries a real cost. People who understand the process, the materials, and manufacturing feasibility are scarce to begin with, and when a flood of made-to-order orders arrives, they have no choice but to burn their hours on pre-sales plans, reading drawings, breaking down requirements, and estimating costs (L31-33). Quote high and the order may be lost; quote low and production discovers mid-build that the cost isn't covered (L34-35). And inquiries don't wait: if a quote sits stuck for a few days, the pre-sales node jams solid and the order drains away (L36-37). Behind the two words "need a quote" stand six seats of work and a string of costs — and which seat could ever fall to the model before you've seen who holds each seat today?
And set the one-line requirement's two halves side by side — the chain's six links against the roster asked out on the floor (both columns are the source's own lists, NO-17 txt; the pairing is our arrangement — the source never pins the middle two links one-to-one, so those cells stay honestly blank):
| The six links of the quoting chain (L24-25, print p. 169) | The roster from the workshop (L93-94, print p. 173) |
|---|---|
| drawing parsing | who reads the drawing |
| requirement breakdown | who breaks down the requirement |
| R&D collaboration | — (the source never pairs the two columns link by link) |
| production planning | — (same) |
| cost accounting | who checks the cost |
| quoting | who sets the final price |
Plus, seat by seat, how the work changes hands (L94). A one-line requirement carries no placement decision — you don't even know the chain has six links, so what would "put it in the third seat" even mean?
Even the scenario selection step ran backwards: "We chose this scenario not by starting from 'AI can now recognize drawings.'" (L40, print p. 170) Reversed, the checks look at three things: is there a large volume of knowledge work; is there a meaningful base of historical data; is there a clearly defined efficiency bottleneck in the existing flow (L40-43). Not hunting the room for nails with the model's capability list in hand — as for what the chain actually looks like, that waits for the reproduction walk (L91-95).
The Hardest First Step, Never Solved by Anyone
Inside the manufacturing case, the thing most worth stopping for is a piece of background.
This company had digitized early — it had put in an ERP and quoting templates. Systems like those "are good at 'you fill in the fields, I run the rules downward'; the hardest first step — turning the customer's wildly varied inputs into standard data — was never solved by anyone" (NO-17 txt L66-67, print p. 172).
The fields entered the system, the results entered the system, and the hardest step stayed empty; the quoting logic "in many cases lives in the veteran masters' heads" (L62-63). Whether this company had ever fully mapped its own flow before, the source doesn't say; what can be said is that the veterans' experience kept underwriting the chain the whole time. Once the business grew, that underwriting became the bottleneck itself — the quoting FDE put the new problem bluntly: "As the business keeps scaling, can quoting capability hold up without adding ever more people, ever more veterans?" (L73-74, print p. 172)
This AI project brought the reproduction step into the company — reproducing exactly that manual business flow and data flow from the previous section (L81-82). By step four, the process knowledge living in veterans' heads had begun to be "gradually standardized and proceduralized" (L116-118, print p. 174). And the data pass couldn't be skipped: historical quotes, materials, supplier information "can rarely be handed to AI as-is" — cleaning alone isn't enough, you also have to restore "what the veteran was actually basing that judgment on" (L178-182, print p. 176). The FDE gave this step a near-exact name: "it's a lot like experience replay — dig the set of business rules that has genuinely run for years out of the company's existing data and its people's experience, then turn it back into something AI can use" (L186-187, print p. 177). What we read here is a byproduct: even before counting the AI itself, this reproduction step spread the quoting logic — previously scattered across individual heads — out on the table where it can finally be examined side by side.
This is also the place we paused first while reading the source. By inertia, an AI project should start from "what can AI do"; both surviving sites started from "how do the humans do the work."
One boundary straight from the source's own pages — the screenshot record. On print pages 170-171, the case inserts four interface screenshots: work-order recognition; AI process-sheet parsing with BOM generation and order-risk flagging (textile industry); an R&D collaboration platform; AI drawing parsing with process-route generation and tiered quoting (machining industry) (NO-17 txt L46-53). For two links of the six-link chain — R&D collaboration and production planning — the body text offers no prose at all; don't read those two links as already taken over by AI.
One line of division of labor: for the separate question of what can transfer from one site to another, see Find the Next Scenario by Analogy: What Transfers Is the Structure, Not the Ready-Made Solution; this piece governs only the order of the reproduction step.
Reproduction in Five Steps: The First Procedure of an AI Project
Take the two sites' actions apart, lay them against each other, and we've organized them into a procedure card — the first procedure of an AI project: the five steps of business-flow reproduction. Coordinates first: before the kickoff comes finding the loss worth fixing, which is the job of Find the Loss First, Then Talk AI; after the seat has grown out, translating it into the tier a kickoff meeting can approve is The Same Need, a Completely Different Place to Put the AI. This piece writes only the middle stretch — how the seat grows out of reproduction. Nor does this procedure decide scenario screening: whether it's worth doing at all, the quoting case's three checks answer first (knowledge-dense, historical data at scale, a clear bottleneck — NO-17 txt L40-43, print p. 170); the five steps govern where the seat comes from once "worth doing" has been answered.
Step one: walk it, don't guess. Follow one real order from start to finish: into the workshop, through the historical quotes, ask about the handoffs (L91-93, print p. 173). What you walk is the work, not the status report — and the capability-list shopping route is banned at the same time: "not by starting from 'AI can now recognize drawings'" (L40).
Step two: ask the "six whos." Who reads, who breaks down, who decides, who judges, who checks, who sets the final price (L93-94) — plus what each seat hands to the next. That roster is the AI's candidate seat chart.
Step three: freeze the three questions. What is the input, what is the output, what happens in between (NO-16 txt L76-78). If the three questions can't be answered, don't start building — the source's own words are already quoted above: however beautiful the agent, it's meaningless.
Step four: put the human gate where the error costs most. The seat where one wrong cell costs the most stays with a human. The quoting case's criterion: "pricing goes out the door — one extracted dimension error hits the cost directly" (NO-17 txt L174, print p. 176), so every single order passes human calibration before going out (L114). The telecom case's gate sits at the end: the analysis first produces "a fairly complete data-analysis result," then a human does the final quality confirmation (NO-16 txt L114-115, print p. 163). That analysis feeds management directly — and the SQL silent error is precisely the "looks correct" kind (source quoted in the previous section): the quieter the error, the more it needs one human pass.
Step five: shrink first, expand later. The first version of the AI is assigned exactly one seat from the roster (we summarize it as "repetitive and structurable"): the quoting case's model does only the structuring, and pricing returns to the company's own materials, suppliers, historical data, and rules base for matching (list at L107-110, the shrink move at L113-114); expand only after that runs. Rollout is graded too: key-person trial, business-team pilot, real-order validation, feedback adjustment, department-wide rollout (L135-141, print p. 175) — the trial period was "about one to two months," per the interviewee's self-report (L138).
Not one of the five steps asks "how strong is the model." The further down the steps you go, the clearer the AI's seat becomes — because it is picked out of the roster, not out of imagination.
Quick reference for the five steps (our decomposition; line anchors are the two cases' source txts):
| Step | Action | Source anchors |
|---|---|---|
| 1. Walk it, don't guess | follow one real order end to end; ban "capability list hunting for nails" | NO-17 txt L91-93, L40 |
| 2. Ask the "six whos" | who reads / breaks down / decides / judges / checks / prices, plus how they hand off | NO-17 txt L93-94 |
| 3. Freeze the three questions | input, output, middle process — no answers, no build | NO-16 txt L76-78 |
| 4. Human gate at the costliest error | every quote human-calibrated; end-stage human quality confirmation | NO-17 txt L174, L114; NO-16 txt L114-115 |
| 5. Shrink first, expand later | first version takes one seat; key persons → team → real orders → department | NO-17 txt L113-114, L135-141 |
After Reproduction, Which Seats the AI Actually Got
The procedure walked, look at what seats the two cases' AI actually received — the seat is grown, and these two passages are what "grown" looks like.
In the manufacturing case, the model's first seat was the entrance: using multimodal capability to pull materials, dimensions, and structural requirements out of PDFs and CAD drawings (NO-17 txt L97-99, print p. 173). But the goal didn't stop at recognizing drawings — "once recognized it must be structured, because only after structuring can this data flow into the business steps behind it" (L102-103, print p. 174). Pricing could not rely on the model's own knowledge: "after the AI extracts the customer's requirements, it cannot price directly out of the model's own knowledge" (L106); pricing returns to the company's own materials base, supplier system, and long-formed quoting logic for matching (L106-110, print p. 174). Calibration also builds reusable data: after business staff make corrections, the fixes are written back into the data, the vector database, or the relevant models — "AI generates, humans calibrate, data flows back, the next round comes out better" (L119-122); the judgment logic in the veterans' heads settles, along the way, into a data asset of the company's own (L116-119).
That seat chart wasn't picked off the model's capability list — it was picked off the workshop roster: the model takes the repetitive, structurable entrance seat; the veterans take the calibration and rules seats. Why split it this way? The quoting FDE grounded the reason in people: "reading drawings and breaking down requirements — this repetitive work eats up the veterans' and the technical backbone's time, yet their judgment of process, materials, and feasibility is precisely the capability hardest for the company to replicate" (L208-212). The scarcest judgment must not be spent on the cheapest links.
In the telecom case, the components the three questions tore apart were recombined into a pipeline: "we took the original data-analysis process apart into fairly fine-grained components, reconsidered for every link which method and which structure it should use, and finally recombined these components" (NO-16 txt L81-83, print p. 162). The agent took the production segment: understand the question, process the relevant network data, analyze, produce a structured result (L87-88); analysts no longer start from zero — "they can stand on the results the AI has already completed and keep judging" (L117-119, print p. 163). The FDE specifically blocked the misreading: "I don't think this can be simply understood as 'the AI replaced a few analysts'" (L116); the end-stage quality confirmation was not removed, because what the enterprise actually needs is to free human time out of the mass of repetitive work and "concentrate it where judgment is more needed" (L123-125, print p. 164).
Both sites showed the same restraint: embed, don't rebuild. The telecom case pushed the entrance into the customer's existing work habits — "however the customer used to work, that's how they keep working": web, Teams, and Slack are possible access methods in the FDE's explanation; chat is the actual interface confirmed for this case (L105-107, print p. 163). The manufacturing case anchored pricing back to the company's own materials and rules base; the AI took the seat that had stood empty in the chain — it didn't rebuild a chain.
The two cases' AI seat charts, laid together (our decomposition; each case's facts taken only from that case's own source text):
| Manufacturing case (NO-17) | Telecom case (NO-16) | |
|---|---|---|
| The seat AI got | the entrance seat: structuring drawing information (L97-103) | the production segment: understand the question, process network data, analyze, produce structured results (L87-88) |
| The seats AI didn't get | pricing from the model's own knowledge: quotes must use the company's materials, suppliers, historical data, and rules (L106-110) | end-stage quality confirmation (L114-115) |
| The seats humans kept | human calibration on every order before it goes out (L114); reviewing only the fields the model isn't confident about — mechanism per interviewee self-report (L174-176) | analysts stand on the AI's results and keep judging (L117-119) |
| How it embedded | pricing anchored back to the company's own materials and rules base | however the customer worked before, they keep working that way: chat is the confirmed interface; web, Teams, and Slack are examples of possible access methods (L105-107) |
| What grew out along the way | the veterans' judgment logic settled into a company data asset (L116-119) | human time shifted to where judgment is more needed (L123-125) |
Reproduction Helps Reduce Directional Rework
Pre-answering one objection: does reproduce-first mean waterfall-style, slow-and-careful craft?
The quoting FDE's own words run the other way: "I generally won't wait until every piece of information is fully in hand, then shut the door and work for months" (NO-17 txt L125-126, print p. 174). Work and adjust in parallel — with a partial input from the customer, the FDE ships a stage output first: maybe a demo, maybe a process, maybe a single feature, so the customer can check whether that's what they meant (L126-128, print p. 174); "it can go back and forth a few times, even a dozen or more times" (L131, print p. 175); because "sometimes the customers themselves don't know what they actually need," and stage results are how you keep clarifying the requirement with them (L132-133). What reproduction saves is mainly directional rework: the tear-down-and-restart after the requirement was called wrong or the boundary was called wrong.
Reproduction is walking the floor, not writing a document. And the checklist keeps growing after launch: at the recognition layer, "business staff only review the fields the model isn't confident about," and after review the corrections flow back — "the part humans have to review keeps shrinking" (L174-176, print p. 176, mechanism per interviewee's self-report). The graded rollout runs on the same logic — "far more reliable than finishing all development in one go and then announcing a launch" (L142, print p. 175).
The effect calibers, stated in one place: every effect figure in this piece is at interviewee self-report caliber. The quoting case is live, and the "first two months after launch were spent in a run-in and fine-tuning phase" (L145-146, print p. 175); "cuts at least 50%-plus of the related workload" is the interviewee's self-report, with no controlled comparison (L148); the current output is quotes the company "can genuinely take and use" — again self-report (L109-110, print p. 174). The telecom system was delivered and entered daily work — what was delivered is, per the narrator, "an agent system that can run long-term," gradually entering the customer's daily data-analysis work (NO-16 txt L132-133, print p. 164); "many analyses can finish within minutes to hours" is likewise self-report, with no query denominator (L114, print p. 163); how many people actually use the system, the source does not disclose.
When This Routine Fails
The failure conditions, up front.
When the business flow itself is unstable — everyone does the work differently, there is no SOP to reproduce — the five steps stall at step one. The right move then is not an AI kickoff; it is building the flow from nothing. The five reproduction steps govern the scenario where the flow already exists and only the map is missing; they do not govern sites where the flow itself doesn't exist.
One more limit on the timeline matters: the telecom customer's earlier version preceded the FDE's involvement, but the source does not disclose whether the customer had previously mapped the workflow. The quoting design changed within a project whose FDE describes reproducing the business flow first. These accounts are not a causal comparison showing that skipping reproduction guarantees failure or doing it guarantees success. Our proposed discipline is to break a job into inputs, steps, rules, and human checks, then use results from the floor to revise the boundary.
Steal These Five Lines
At your next kickoff, take the first move — "list the AI capability list and shop for scenarios" — and swap in these five lines:
- Follow one real order all the way to the end; don't guess the flow in a conference room.
- Ask out the "six whos" — the AI's seat is somewhere in that roster.
- Input, output, middle process: if the three questions can't be answered, don't start building.
- The seat where one wrong cell costs the most stays with a human.
- The first version takes exactly one seat; expand to the next only after it runs.
There is no AI seat inside a one-line requirement, and there is no AI seat inside the model's capability list. The seat comes from this procedure.
The AI seat is walked out, not slapped on.
Sources and Caliber Notes
- Case source: the first 24 cases of Datawhale's FDE Cases 100, published September 2026 — an L1 interview compilation from a single editorial project, not 24 independent causal experiments. This piece uses only NO-16 (telecom data analysis) and NO-17 (made-to-order quoting); each case's facts come only from that case's source text and breakdown card — nothing borrowed across cases.
- Quote anchors: (NO-XX txt L-n) = the physical line in
sources/fde-cases/pdf-text/NO-XX-*.txt, re-verified line-by-line for this draft. The quotes are English renderings of the Chinese-language source. Pages use printed-page numbering (printed page = PDF physical page − 1); page pins follow the master draft's frozen verification — the telecom crash record (L57-61) on p. 161, the three questions (L76-78) on p. 162, the end-stage human confirmation (L114-115) on p. 163, the six-link chain (L24-25) on p. 169, the workshop workflow investigation (L91-95) on p. 173, the extracted-dimension warning (L174) on p. 176 — plus one pin made in this draft straight off the txt's page-footer markers: the four interface screenshots (L46-53) sit on pp. 170-171. - Number calibers, marked inline: NO-17's "cuts at least 50%-plus of the related workload" = interviewee self-report, no controlled comparison; "the first two months after launch were a run-in and fine-tuning phase," the trial period of "about one to two months," and "back and forth a few times, even a dozen or more times" = self-reports of those involved; the output being quotes the company "can genuinely take and use" = self-report; the company's headcount and revenue figures = the company's own account in the interview. NO-16's "many analyses can finish within minutes to hours" = self-report, no query denominator; the system was delivered and entered daily work, and the actual number of users is not disclosed in the source. The phrase "verified" appears nowhere in this piece as a claim about either case's effects.
- Framework attribution: the five-step reproduction routine, the "two records, one job description" alignment, the two seat charts, and the five-step quick-reference table are our decomposition — our cross-case reading, not either case's self-description and not client-validated results. "Reproduce first, then place" and the "three questions" are themselves the two interviewed FDEs' self-described working methods; aligning them into one discipline is our conclusion.
- Geography, per source: NO-16 is a top-three US telecom carrier (the source's own wording); NO-17 is a made-to-order manufacturer whose country the source never names. Neither is flattened into "a Chinese company."
The five lines are the tool this piece hands over — copy them onto the first page of your kickoff agenda and take them to the floor. Each end of the procedure has an article already standing on this site: finding the loss worth fixing before the kickoff is the job of Find the Loss First, Then Talk AI — the five steps here govern where the seat comes from once "worth doing" has been answered, not whether it is worth doing; turning the seat that grew out into the tier a kickoff meeting can approve is handled in The Same Need, a Completely Different Place to Put the AI; and the question of which structures can transfer across sites, and which constraints must be rebuilt, is explored in Find the Next Scenario by Analogy: What Transfers Is the Structure, Not the Ready-Made Solution.
The five lines up top are the shortcut; the complete ledger rides in the body — both cases' case accounts, the line anchors, and the calibers all sit in the sections above, and the full procedure card is in "Reproduction in Five Steps." This piece is the ledger itself; copy the five lines, and the evidence travels with them.
I'm Uncle J. Eighteen years in HR is where I learned to read rosters like the six-whos list — who does what, where the work hands off, which seat quietly underwrites the chain — and this piece is that same move, pointed at the AI kickoff table. These days I run a one-person AI organization, and I work the way this piece does: start from what actually happened on real sites, draw the frame myself, and hand you the tool. The seat was never in the capability list. It's in the walk.