Find the Next Scenario by Analogy: What Transfers Is the Structure, Not the Ready-Made Solution
The judgment of this piece: what you extrapolate is the act of taking the problem apart. The layer of structure — finite capacity, discrete choices, competing claims on resources — travels. Every constraint in the right-hand column stays behind and has to be rebuilt, piece by piece, at the new site. What transfers is the structure, not the ready-made solution — and copying a ready-made solution is the most expensive way to lose inside the "replicate a success story" genre.
What this piece solves for you: the moment one AI deployment case finishes, the boss of the next site shows up holding "isn't it all the same?" This piece turns "extrapolation" from the last-page rhetoric of a consulting deck into a craft you can hand over: take the site apart into three problems — allocation, placement, scheduling — carry those problems to each neighbor and write down what is shared and what must be rebuilt, land the verification on paper with two checklists and a minimal comparison pack, and then state, item by item, when the whole method breaks.
Boundary first: case facts come from one case only — the Heihe cross-border truck-loading case (No. 6) — and every effect figure is an interviewee self-report, a simulation, or a projection. The five neighboring directions are leads for finding the next batch of real samples under our decomposition framework: no matching client, no computed payoff, no validated willingness to pay. The two checklists are a decomposition framework, not a repeatedly verified law — they guarantee the questions get asked right; they do not guarantee the migration lands.
The Opening Move Is Admitting the Misread: Everyone Arrives Holding "Packing"
"When I first got involved, most people treated this as a simple packing problem — just compute how the goods should sit and the load rate goes up. But once I was actually on site, I found things far more tangled than I had imagined." (NO-06 txt L32-33, print p. 57)
The speaker is the interviewed forward deployed engineer of the Heihe loading case. The case opens as an admission of a misread: everyone arrives holding the ready-made solution attached to the word "packing," ready to start computing.
Misreading the problem doesn't only happen before a project starts. It can happen again the moment one case ends — and the ugly part goes first: the scene below is imagined. The Heihe material contains no such scene. The source text stops at "the project has completed prototype validation" (NO-06 txt L115, print p. 62), and the five neighboring directions have yet to find a matching client or validate anyone's willingness to pay (our decomposition caliber). The imagination mirrors human nature, not anyone's record.
Picture the prototype done and the next site showing up, opening with the sentence you can already hear: "Your loading thing worked well. Our containers, our panel cutting, our crew scheduling — isn't it all the same? Build us one too." The lines are invented. The positions of the people around that table are not:
The one carrying the load is a delivery engineer who has to walk into a new site carrying a solution document. The one who decides is the boss of the new site — because he has judged it "similar," budget and time get allocated on copy-it terms: one person, a few months, enough for exactly one attempt. The failure mode needs no imagining at all, because the Heihe case recorded it in black and white: "the system produced an elaborate three-dimensional plan, the workers on site couldn't read it, and in the end the work went back to manual experience." (NO-06 txt L82, print p. 60) When a re-skinned ready-made solution fails, what burns is not just a few months of schedule — it is that site's remaining trust in the words "AI deployment" for years afterward.
Lay the material base on the table first: Datawhale's FDE Cases 100, first batch of 24 cases, published September 2026, is a set of 24 interview write-ups from AI deployment practitioners — not 24 independent causal experiments. This piece takes its case facts from one source text only, the No. 6 cross-border logistics loading case; every effect is an interviewee self-report or a projected caliber; anything marked "our decomposition" is our framework — not the original case's self-report, and certainly not a customer-validated result.
After Heihe, What Exactly Is in Your Hands
Before any migration, complete the ledger — what do you actually hold, and which column of it is the valuable one.
The money line. The business is cross-border road freight out of the Heihe free trade zone, exporting electromechanical products to Russia, with freight priced by the cubic meter. A truck of roughly 110 cubic meters takes a veteran loader about five hours to fill by hand, and he typically reaches 95–98; 98 is the break-even line, and every cubic meter past it earns roughly 100 dollars more — the material's self-stated historical baseline and business mechanics (NO-06 txt L21-24, print p. 57). The same stretch of material offers a second number: overall space utilization used to sit around 60–65% (NO-06 txt L46-48, print p. 58). One caution: the material never explains how these denominators relate to each other. Each is its own self-reported caliber, and they do not assemble into a pretty improvement curve.
The human column. Loaders earn their income with muscle and hours (NO-06 txt L70-71, print p. 60), and the manual for their experience runs half a page: "First, experience cannot be copied. A skilled loader's know-how takes years to build; a new hand can't pick it up quickly." (NO-06 txt L75-76, print p. 60) That experience is the loader's rice bowl and the quietest column in the case — the source gives it half a sentence of background. Yet the moment you migrate to the next site, whose experience gets re-priced is the first entry that belongs on the project table.
The built thing deserves an item-by-item inspection. The workflow was split into seven steps: acquiring the vehicle's true dimensions, organizing cargo information, computing the loading plan, multi-truck scheduling optimization, generating the loading guide, on-site execution, results feedback — "the planning and computation at the front suit AI's involvement, but the end must return to human execution" (NO-06 txt L94-96, print p. 61). The implementation runs on "the large model handles orchestration, specialized algorithms handle computation" (NO-06 txt L97): the model understands the request, parses the task, calls the algorithms, explains the results; the three-dimensional spatial computation goes to Python — heightmap tracking, greedy placement, multi-strategy sorting, a genetic algorithm (NO-06 txt L102-105). Workers inside a loading environment can't keep picking up a phone or a laptop (NO-06 txt L108), so the algorithm's output was flattened into a loading guide a worker can use directly: item numbers, orientations, cross-section sketches, loading order (NO-06 txt L109-110). And when mathematical optimality fought the yard's habits, the "cross-section method" rewrote the plan — sequence the loading by trailer cross-section, from the front wall outward, so the worker stands at the door position and never steps on cargo (NO-06 txt L154-155). Every one of these answers the same question: by what right does a plan on paper get executed by the pair of hands at the trailer door.
Stage calibers, separated exactly as the source states them. The project stands at prototype validation: the loading run was a simulation against a real vehicle — 16.4 meters long, 2.47 wide, 2.67 high, roughly 108 cubic meters net — combined with a catalog of eleven electric-vehicle product specs, and the author self-reports "stably reaching about 99 cubic meters" (NO-06 txt L115-118, print p. 62). A simulation self-report, not a measured real-world load. The book's interface screenshot shows 98.7 cubic meters used, 91.2% utilization (print p. 65); that too is a simulated demo screen. Every on-site execution gain is projected: loading one truck from about five hours "is projected to compress to about 2 hours, a load-efficiency gain of about 100%" (projected caliber, NO-06 txt L122-123, print p. 62). Multi-truck scheduling was written into the seven-step process, yet the interface screenshot on print page 63 labels itself "current version: single truck, multiple orders" — that step is still in the blueprint, never integrated.
Inventory finished, thick and thin lie exposed. What gets carried over is a prototype, and the prototype is thin: one particular truck, one particular cargo list, a time ledger that never touched a real yard. The real asset is what this case forced everyone to think through — how many separate problems press down under the two words "packing."
One Site, Three Problems
"Packing" is a name. The spoken complaint that business people hand over is a single phrase — "it never fills up" (NO-06 txt L180, print p. 66); the interviewed FDE broke it downward into three questions himself — data, planning, execution, one each (NO-06 txt L181-182, print p. 66). How the split works has already been laid out on this site in Find the Loss First, Then Talk AI, so this piece won't split it a second time; it asks one thing only: which of the three problems still know the way at the next site. The site actually supplied the words itself: "when a company faces different vehicle types, different cargo sizes, and several trucks moving at once, it has to weigh space, weight, transport efficiency and more at the same time" (NO-06 txt L51-52, print p. 58) — the problems were stacked on the site all along. "How many to split them into" is our move.
First problem, allocation — which goods onto which truck. Cargo gets approximated into two numbers, volume and weight; the shape is an integer model. This is the problem that changes face first at the neighbor's: if every order must ship, you are minimizing the trucks dispatched; if trucks are fixed and cargo is optional, you are maximizing the value carried. Change the objective and you have changed the problem — save-trucks and pick-cargo are separate problems to file (our decomposition).
Second problem, placement — only once cargo is in the trailer does the second problem exist: position, orientation, nothing overlapping — geometric feasibility. Then the site stacks on load-bearing red lines, what may carry weight and what may not, whether a stack stands stable, and loading order. Which of those actually exist, only the site knows. The cubic meters can hold and the geometry can still fail — there is no conveyor belt between those two facts (our decomposition).
Third problem, scheduling — more trucks, more batches, and time windows, loading crews and docks all become contested resources; at this layer capacity is measured in hours, not cubic meters. In Heihe this problem stayed on the list: the process wrote "multi-truck scheduling optimization," and the interface confessed "current version: single truck, multiple orders" — recognized, not yet computed (our decomposition).
Three problems, and data, algorithms and validation each want their own. The most revealing shared word is "vehicle capacity": at the allocation layer it is a constraint term; at the placement layer, a geometric boundary; at the scheduling layer, the unit has become time. One site splits into three problems that cannot even share the word "capacity" — the same word is three different things across the three problems.
Technology choice runs along the same line. The original case never mentions MIP; what it names is the large-model-plus-Python combination. Putting MIP into the first-round baseline is a reasonable move — but that is our recommendation, not a fact about what the case adopted. As for whether "a mixed-integer solve will do" — the "will do" gets judged by the same four measures: instance scale, constraint completeness, computation deadline, on-site executability (named in Find the Loss First; the ruler itself is our decomposition of this case batch). The name doesn't change, because it is the ruler's name — but at a new site, all four get re-measured. All four pass: MIP is enough. Some fail, and the honest conclusion may be "rules are already enough," or "the bottleneck is the input." When you migrate to a new site, you do not presuppose that AI must prove useful — that discipline is worth as much as the choice of algorithm.
The reusable estate actually has two layers: tools you can call, and the way you ask questions. Which layer is worth codifying, Building with AI Is Not Running on AI already argued to the end; this piece handles one thing only — once you have judged that the structure can migrate, how to migrate it without falling into a pit.
Take the Problems to the Neighbors: What Is Shared, What Gets Rebuilt
The first move of migration is not hunting for a "similar industry." It is carrying the three problems, one by one, to each neighbor. We arrayed five commonly named neighboring directions into a table (our decomposition; directional hypotheses):
| Neighboring direction | What is shared | What must be rebuilt |
|---|---|---|
| Pallet / container loading | finite space, discrete cargo, orientation, handling moves | pallet edges, stacking strength, in-transit stability, unloading-stop sequence |
| Bin / slot allocation | finite locations, fit constraints between goods and locations | the objective flips to less carrying and less walking — not "fullest"; add turnover frequency and replenishment |
| Panel cutting | choosing discrete combinations inside finite material; every offcut is loss | kerf width, grain direction, cutting process — not renaming the truck's 3-D parameters into panel dimensions |
| Workstation / equipment scheduling | many tasks competing for finite resources, no double occupancy | capacity's unit becomes time and equipment; add task precedence, changeovers, due dates; 3-D geometry usually drops out |
| Rental / engineering resource allocation | orders occupy vehicles, equipment, crews | equipment qualification, date conflicts, travel time, promise-ability; pricing rules are not resource scheduling itself |
The reading of this table is one sentence: the layer of "finite capacity + discrete choices + competing resources" is shared; the constraints in the right column come with the new site and must be rebuilt one by one.
Two hard characters in that right column deserve a closer look. Panel cutting: the kerf eats material, and grain has direction — the same board cut with the grain and across it are two different jobs, and none of those constraints exist inside a trailer. Reverse it, and the trailer's load-bearing and orientation rules all expire at the saw bench. Workstation scheduling: capacity switches from cubic meters to hours, and you still owe answers to which task must precede which, what a changeover costs, what a missed due date penalizes. Renaming truck parameters into a schedule grid is not extrapolating. It is re-skinning.
The ugly truth goes first: these five directions are currently leads for finding the next batch of real samples — no matching client, no computed payoff, no validated willingness to pay (our decomposition caliber). The table is a signpost, not a passbook.
Cold Water First: Right Structure, Wrong Location, Still a Total Loss
Before any table gets matched, one more negation has to be passed. Both of the following are our cross-case hypotheses; no case in the set backs either one. First: if trucks ride empty because upstream has no cargo to load, the defect is in the supply, not the stacking — however refined the loading optimization, it circles beside a main loss you cannot reach. Second: if cargo types cannot be mixed and orders must move in whole batches, the option space is mathematically locked, and the optimizable room is far smaller than intuition promises. Neither is Heihe-specific. They travel with every neighboring table and belong pinned to the first screen of any migration self-check — right structure, wrong location is the most expensive way to lose in the "replicate a success story" genre: the paper is all correct, and the ledger is all loss.
So at the neighbor's door, don't unfold the proposal. Re-ask first: which ledger carries this loss? Which step of today's work can actually change? — how to ask, the five steps in Find the Loss First, Then Talk AI give the full chain (an observable loss → a changeable decision → required inputs and hard constraints → a testable output → minimum sufficient technology); not repeating it here. That piece governs finding the loss; this one governs moving the structure. Two gates. Neither is optional.
Two Checklists: Making Analogy an Organizational Craft
In AI-deployment contexts, "extrapolation" slides easily into the last page of a consulting deck — "this solution replicates quickly across multiple industries." The structure we see is different: it is not rhetoric. It is a craft that can be written down as two checklists and handed to whoever runs the next site.
Checklist one, the shared-structure list: state at which layer the current case holds — what the finite capacity holds, what the discrete choices choose, who competes for what; plus each problem's objective function, validation progress, and evidence caliber.
Checklist two, the must-rebuild constraints list: state what this site carries that cannot be inherited — physical conditions (can those hands free themselves to hold anything), safety rules, craft temperament (kerf, grain, stacking), the objective function (fullest truck or least carrying), and data gaps (the Russian side reported only the vehicle's exterior dimensions; the true net interior had to be measured — the case bought an iPad LiDAR rig for exactly that, hardware cost about RMB 8,500, a procurement self-report, NO-06 txt L159-160, print p. 64). Data gaps are the easiest line on this list to forget, because they hurt on no budget line.
For these two checklists, the veteran's three lines are a ready-made practice set: "which goods should go on the bottom; which goods can be combined; which pockets of space can be used." (NO-06 txt L72-73, print p. 60) By our reading: the second line is structure-layer speech, a combination choice every site recognizes; the first is a stability constraint, and "the bottom" depends on this truck's and this cargo's temperament; the third is geometry, growing on this trailer's walls. A single line of experience already mixes both checklists' vocabulary. The source never says how these lines were later extracted into the algorithm — but if the extraction can't tell the checklists apart, the migration can't tell what carries over.
Checklists written, only then comes verification. By our decomposition, the next site owes at minimum a minimal comparison pack: pin the site down first — same truck, same cargo, constraints verified — then put three answers on the same stage: today's manual loading, the dumbest rule-based version, and an optimized solver version. What gets compared is not whose math is prettier. It is feasibility rate, loaded volume, how long one solve takes, how many placements the worker's hands changed, and how long a real load actually took. And one legitimate conclusion after the run is precisely "no complex algorithm needed" — in this problem, whether AI wins is not the premise; it is one of the possible outcomes (our decomposition).
I spent eighteen years in HR, and I have read a lot of handover documents: when the best hands on the floor quit, the craft walks out with them and the handover doc stays — and the best handover docs never contain answers. They contain "here is where this job bites." These two checklists are the handover doc for the craft of AI deployment. The place you can train people is the pen that writes them; the place you can examine them is the bites the next person never takes.
When the Two Checklists Fail
A method without its boundary is a sales pitch. Four ways this one fails:
Using the checklist instead of the site. The checklist is a questioning frame, not the constraints themselves; Heihe's checklist must be re-verified line by line at the new site. The last site's answer was "a printed guidance sheet"; the next site's answer may have to be "a screen that works below freezing." Skip the site and copy the answer, and you get the parameters wrong — and the medium too.
The structure layer doesn't actually match. Tasks don't contest one resource pool; they run in a strict handoff sequence. Or the bottleneck isn't capacity at all — it is the supply, or the input data. The negation self-check is not Heihe's property. It belongs to every neighbor.
The shared layer written as an industry label. "Both are logistics," "both have scheduling" — that is not shared structure, it is shared nouns. If the checklist cannot state what capacity, choosing what, who contests whom, the table is already void.
The evidence boundary gets forgotten. The 24 cases are interview write-ups from one editorial project; the five neighboring directions have found no client and computed no payoff; the two checklists are a decomposition framework, not a repeatedly verified law. They guarantee the questions get asked right. They do not guarantee the migration lands.
The Next Time Someone Shows Up Holding "Isn't It All the Same?"
Don't rush to answer same or different. Do three things first: take this site apart into its problems; carry the problems to the neighbor and write down, one by one, what is shared and what gets rebuilt; put the two checklists into the hands of whoever runs the next site.
The veteran's three lines took years to accumulate, and no new hand can copy them. What the two checklists catch is precisely the layer inside that uncopyable experience which does travel.
What you extrapolate is the act of taking the problem apart. The solution stays in Heihe; the checklists travel.
Migration runs through two gates, and each gate has its own article on this site: how the three problems come out of the three words "it never fills up," and how the five-step audit walks end to end — Find the Loss First, Then Talk AI carries the Heihe case's complete ledger; and the reusable estate splits into "tools" versus "the way you ask," with the argument over which layer is worth codifying settled in Building with AI Is Not Running on AI. A checklist is where the handover starts, not where its guarantees end — the four failure modes above travel with the checklists, or nothing travels at all. I run AI deployments as a one-person organization now, so the "next site" is usually me, months from now, holding a proposal I no longer remember the edges of. These two checklists, failure modes attached, are the handover doc I write to that stranger.