The judgment of this piece: the minimal unit of an enterprise's AI capability is not "people who can use AI" — it is a method placed in a shared carrier, with someone responsible for it. "Everyone can use it" is not the pass mark for capability; it is exactly where the climb starts. Between personal productivity and organizational capability sit three thresholds — tool ownership, the form requirements travel in, and role structure — and not one of them is a skill, and not one of them can be delivered by training.
What this piece solves for you: a replacement ruler for management. To assess your own team's AI capability, stop counting "how many people can use it" and check three questions instead: whose computer do the methods and tools live on? What form do requirements travel in? Who is responsible for everyone using AI well? All three empty: everyone can use AI and you still hold only personal productivity — enterprise-level AI capability is zero. The training budget gets downgraded to an entry ticket; the goal of the next project shifts from "get everyone using it" to "build the shared carrier and assign the role ownership."
Boundary first: the case comes from the first twenty-four cases of FDE Cases 100, published September 2026 — interview write-ups from a single editorial project, not twenty-four independent causal experiments. This piece cuts vertically through one case, No. 7. It is an organizational-transformation practice, not a production-system go-live: the organizational change is the principal's own account of "fairly clear," with no ROI disclosed, and the piece's only quantified figures belong to a different manufacturing client's short in-house tally. The three questions audit the balance sheet, not the scoreboard.
A Team Where Everyone Already Uses AI
Every company fears the same thing: employees who can't use AI.
One fund company's field site is the exact opposite: everyone already can.
The company leans toward fund investment research, with an internal dev team whose requirements change constantly — nothing like the traditional team that spends months on one large software project (No. 7, L17-19, p. 69). Requirements are fragmented and high-frequency; internal product managers or business units "would raise several requirements in a single day" (No. 7, L20-21, p. 69). As for what AI is expected to be worth here, the material writes the expectation itself: raising what one developer can complete in a day "from three to ten." Pin the caliber first — that is a value expectation as written in the material, not a before-and-after measurement (No. 7, L21-22, p. 69). The original even carries its own contrast: "not the same as the traditional image of 'a project that took a year now taking half a year'" (No. 7, L22, p. 69). This is not a company waiting around for a traditional speed-up.
A word on where the material comes from. This is one case among the first twenty-four of Datawhale's FDE Cases 100 (No. 7, enterprise R&D transformation), published September 2026. All twenty-four are projects delivered hands-on by FDEs — the role that walks into a client's site and lands AI inside the business — as interview write-ups from one editorial project. Not twenty-four independent causal experiments. Everything below stops at "the principal's own account." The narrator is himself an FDE; what that delivery role means as a business is a separate piece, Your FDE Moved Into the Client's Building. How Do You Get Them Back Out?, and it will not be repeated here.
Before the narrator arrived, the team "had in fact already been using AI, and some were using it quite deeply" — some on Codex, some on Claude Code, others on an assortment of AI Coding tools (No. 7, L23-24, p. 69).
By the popular script, this is where the story ends. Tools in place, people fluent. Wait for the efficiency numbers.
The field went the other way: "everyone can use it, but the company can hardly get everyone to use it together." (No. 7, L24-25, p. 69)
Why is it hard? "Everyone thinks their own tool is the best." (No. 7, L26, p. 69) The case records one line from the floor: "I'm efficient with this tool — make me switch to another and I actually can't do my work." (No. 7, L26-27, p. 69; the source never identifies the speaker — relayed by the narrator) The narrator continues: "once personal habits mature, a company that tries to unify tools runs into fresh resistance." (No. 7, L27, p. 69)
Sit with that scene for a second, because it is the whole piece in miniature: a company full of fluent AI users, and the fluency itself is the wall. Training can produce skilled individuals. It cannot produce their shared carrier. (our decomposition)
Management's ask sits on a different level. The boss wants the whole R&D team transformed — wants "AI to become an organizational capability, no longer just a personal tool scattered across employees' computers" (No. 7, L28-30, p. 69).
Three Layers, and Not One of Them Says "Who Can't Use It"
The narrator split the problem in front of him into three layers (No. 7, L31-32, p. 69).
Layer one: no shared cognition. Everyone uses AI, "but there is no common standard for how far AI Coding can actually go, or where one's own ability stands" (No. 7, L34-35, p. 69). Notice what is missing: a standard. Not a skill.
Layer two: tools and methods not unified. Different people, different tools, different working habits — and "the original R&D collaboration practices did not change with the arrival of AI Coding" (No. 7, L37-38, p. 69).
Layer three: the organization itself starting to move. Management has seen the new R&D ideas and wants to adjust roles and process, "but there is no ready-made answer for how those ideas land in their own team" (No. 7, L40-43, pp. 69-70).
Not one of the three layers is about "who can't use it."
"Organizational capability" is a big phrase. Taken apart, it is something you can check (our decomposition, not the case's own wording): the minimal unit of an enterprise's AI capability is not "a person who can use AI." It is a method placed in a shared carrier, with someone responsible for it.
From personal productivity to organizational capability, three thresholds stand in between: tool ownership, the form requirements travel in, role structure. Not one is a skill. Not one can be delivered by training. "Everyone can use it" is not capability achieved. It is the starting line of the climb.
Threshold One: Whose Computer Do the Methods and Tools Live On?
The empty look, laid out neatly by the field itself. Someone finds a tool that works and uses it alone; someone masters a new method and practices it alone (No. 7, L50-51, p. 70). The narrator is fair about it: "at this stage there is really no problem, because the individual answers only for their own efficiency" (No. 7, L51-52, p. 70). In the personal-productivity phase, capability grows on the person, and that is exactly as it should be.
But this threshold has one measuring line and one only (our decomposition): whose name are the methods and tools under? Usage, prompts, and hard-won lessons scattered across some personal laptop walk out when the person walks out, and reset to zero when the person switches tools. It was never the company's.
AI on the Ground in Cross-Border Business covered half of this problem: images and videos likely scattered across employees' personal computers; the books broken into three disconnected pieces, invisible to the boss in any system; files all held by the company, yet not one of them retrievable. This piece supplies the other half: the working methods are not the company's either. Data plus methods — only together do they complete the picture of organizational assets.
There is also a piece of counter-evidence, hidden in the procurement action. On arrival, the client "had already decided to adopt Alibaba's capabilities, but there was no particularly clear answer to 'having bought it, what exactly do we do'" (No. 7, L72-73, p. 71). The invoice is made out to the company. The usage is not. Buying settles "whether it exists." The ownership threshold asks "whose it is" (our decomposition).
The crossed look, in the source's plain words: "later the company began to unify tools, and went further to unify R&D collaboration practices" (No. 7, L128, p. 73 — a self-described organizational action), after which AI "was no longer a question of 'whether this or that individual developer can use it' and began entering the team's shared R&D process" (No. 7, L128-129, p. 73).
And that crossing did not happen because anyone was persuaded (our reading — the source records the unification as an organizational action, not its trigger). Pulling tool choice out of individual hands is an organizational decision — only management can make that call. A trainer cannot.
Threshold Two: What Form Do Requirements Travel In?
The second threshold hides inside the collaboration carrier. It is the easiest one to miss.
The old world ran perfectly well: product managers wrote PRDs the old way, developers built from the documents, each role advanced along its original division of labor (No. 7, L48-49, p. 70). Once individuals picked up AI, each got faster on their own — quoted earlier — and nothing collided.
The break comes at the exact step from personal productivity to team productivity (No. 7, L53-54, p. 70). The whole team used to collaborate around a single Feishu PRD. AI Coding moved the work into Markdown and TXT files. One person maintaining one document: no problem. A whole team circling a dozen-plus files, and the new questions surface at once: "how should a dozen-plus documents be divided up?" (No. 7, L55-58, p. 70) "What does the product manager write? What does the frontend write? What does the backend write? What do testing and ops each own?" "If several people edit Markdown at the same time, how do you avoid conflicts? Can the old role boundaries still carry over?" (No. 7, L59-60, p. 70)
"None of these are problems that solve themselves once you have learned an AI tool." (No. 7, L61, p. 70)
The narrator adds a fairness that belongs in the record: "I did not define the old methods as 'wrong.' Quite the opposite — they were a mature set of methods, fitted to the old R&D mode." (No. 7, L62-63, p. 70) The PRD division of labor was not wrong — it fitted the old mode of production. The mode changed; the process, the documents, and the role divisions need re-adjusting to match (No. 7, L63-64, p. 70). And the case carries its own framing line: "once AI truly enters a company, what changes is often not just the tool, but the way of working behind the tool." (No. 7, L65-68, pp. 70-71)
At the point of hands-on customization he is blunter: R&D collaboration once ran around one PRD; now it moves to many documents, and "the role division cannot necessarily be applied directly anymore" (No. 7, L102-103, p. 72).
The crossed look is this case's most valuable deliverable: a Spec document system. At the time, the industry had "no particularly mature, unified standard to copy" (No. 7, L104-105, p. 72) — and the narrator drew his own boundary: AI moves too fast, "industry standards haven't caught up," and many methods "have not yet been validated at scale over a long enough time" (No. 7, L145-147, p. 74). So he did not throw it at the client as a standard answer. He "kept decomposing it, releasing it piece by piece, confirming with the client, then adjusting on the feedback" (No. 7, L106-107, p. 72), and built it from zero to one on site — the client initially assumed these were documents Alibaba had already refined internally (No. 7, L108-110, p. 72). Its quality has one hard criterion: "it no longer depends on one person demonstrating on site; it can keep being reused inside the enterprise." (No. 7, L130-131, p. 73)
Requirements scattered in chat follow the person. Requirements that land in a Spec follow the organization. (our decomposition)
Threshold Three: Who Is Responsible for Everyone Using It Well?
The third threshold is people: from "who can use it" to "who is responsible for everyone using it well."
The empty look: nobody responsible, and no ready-made standard. Four roles, each wanting something different. The narrator's first move on site was not preparing courseware — it was splitting the requirements apart: the boss cares about whether enterprise-wide transformation can actually happen; R&D cares whether the tool genuinely raises their own efficiency; product managers care how the existing R&D process will change; HR cares what each day of the training actually yields (No. 7, L75-77, p. 71).
The crossed look hides where this case is easiest to misread. The delivery form was a five-and-a-half-day in-person training; the narrator nonetheless "treated it, from the design stage on, as one complete enterprise AI transformation practice" (No. 7, L78-79, p. 71). He says "I did several things" (No. 7, L80, p. 71), and strung together they form exactly a transformation action line:
First: pin down the boundary of the problem. The company's own reported capability level does not count; verify through real operations, quick prototypes, and on-site conversation (No. 7, L82-87, p. 71).
Second: arrange the training as one complete business storyline — why the company must transform, why R&D staff should use this, how the tool enters the existing process, how roles change, and how it finally settles into the company's own methods (No. 7, L95-96, p. 72).
Third: customize against the real R&D process — the Spec system from threshold two (No. 7, L100-103, p. 72).
Fourth: let the plan follow field feedback. "In those five and a half days I was lecturing and observing at the same time; training and consulting at the same time." (No. 7, L97, p. 72) "Problems found on site, I keep adjusting further down the line." (No. 7, L98, p. 72)
Then came three phases. The first phase's value, he says, "was letting me truly see what the enterprise's field actually looks like" (No. 7, L114, p. 72); the second adjusted on what phase one had taught; by the later phases, "the client's business people and product managers gradually came in too, and the whole project turned from pure R&D training into a more complete organizational transformation" (No. 7, L113-116, p. 72).
Business people and product managers entering phase by phase is the principal's own self-described on-site signal — and our reading of it: training becomes transformation first in the composition of the people in the room. His footnote on the method: "get the whole chain running first, then iterate on real feedback; the first pass does not have to score 100." (No. 7, L120-121, p. 73)
But one honest boundary needs nailing down (our verification): this case's "someone responsible" delivered only half. The final duties of the new roles, whether assessments were adjusted to match, who signs off on the Spec, who carries the quality liability for AI-written code — the source discloses none of it. Roles entering is fact. Whether the responsibility mechanism closes the loop, the source does not say.
How the Results Get Told
The case pours its own cold water first: "the effect of this project cannot simply be read as 'the company earned more money after using AI.' This fund company did not open up complete ROI data that I could disclose externally." (No. 7, L124-125, p. 73)
What the evidence supports stops at the principal's own account: on organizational change, "the effect is fairly clear" (No. 7, L125-126, p. 73 — self-description, no numbers). Concretely, three organizational actions that did happen: unify the tools, unify R&D collaboration practices, settle the Spec documents and methods for internal reuse (No. 7, L127-131, p. 73).
The piece's only quantified figures do not belong to this case: "later, in practice at another manufacturing client," three teams used this Spec Coding method and its templates, and the client's own in-house tally — taken over a few short days — showed coding time down about one-third, documentation time down by more than half, testing roughly flat (No. 7, L132-134, p. 73). The principal himself supplies the warning: it "should not be read as a long-term, complete ROI conclusion," and "a genuinely valuable effect evaluation still needs to run two weeks, a month, even longer" (No. 7, L135-137, p. 73). It is a signal that the method transfers. It is not this case's report card.
The narrator's own positioning of projects like this one is steady: the most important result, "was completing one change: from 'everyone using AI on their own' toward 'the company starting to form a shared method for using AI.'" (No. 7, L138-139, p. 73)
Before You Run the Three Questions, Drive Four Nails
The ruler comes in the next section. Its own applicability boundary gets nailed down first (our decomposition).
Nail one: skill is a necessary condition, not a sufficient one, and it is not the bottleneck this case exposed. "Not one of the three thresholds is a skill" describes a field where everyone already uses AI. A team that has not even bought the entry ticket should close the skill gap first and discuss the thresholds after — the order does not swap. But do not mistake the entry ticket for the deliverable.
Nail two: the three questions get asked on site, not by survey. "The capability level a company describes for itself is often not its real capability level on the ground" (No. 7, L84-85, p. 71); the narrator's working discipline is "do not fully trust the upfront research — verify as far as possible through real operations, quick prototypes, and on-site conversation" (No. 7, L86-87, p. 71). The answers to the three questions are seen, not asked.
Nail three: with the goal unclear, no threshold gets crossed. "We want to do AI transformation" cannot guide implementation on its own — personal productivity, team productivity, or R&D process restructuring? "Different goals correspond to completely different plans" (No. 7, L181-182, p. 75). This client's want sat at layer three — role and process adjustment — while the procurement form stayed at layer one, a training purchase. That mismatch is precisely the jump to close first on arrival (our verification). And do not cross thresholds with heavy spending: buying an all-in-one model machine out of the gate, commissioning model fine-tuning, forcibly overturning the entire existing workflow — the case calls these approaches rather dangerous (No. 7, L168-169, p. 75); "investment should go from light to heavy — verify the business value first, then deepen step by step" (No. 7, L173, p. 75).
Nail four: the answers are run out, not discussed out. "AI usage levels are very hard to judge accurately through questionnaires" (No. 7, L185, p. 75); "even if the first pass only scores seventy or eighty, that beats sitting there debating the plan to a perfect 100 before starting" (No. 7, L186-187, p. 75) — "once it is genuinely running, the background, the pain points, the plan, and the constraints all become clearer" (No. 7, L188, p. 75). Do not answer the three questions in a meeting room. Pick one real requirements stream and run it end to end; only then do the three questions have answers to give (our decomposition).
The Three-Question Ruler: All Three Empty, Capability Is Zero
To assess a team's AI capability, stop counting "how many people can use it." Ask three things (our decomposition):
| Three questions | The empty look (threshold not yet crossed) | The crossed look |
|---|---|---|
| ① Whose computer do the methods and tools live on? | everyone on their own, locked to individuals, unification meets resistance | unified tools plus unified collaboration practices, manageable on the company side |
| ② What form do requirements travel in? | scattered across chats and conversation, collaboration depends on one person demoing live | Spec'd into documents — multiple people can pick them up, hand them over, reuse them |
| ③ Who is responsible for everyone using it well? | each fends for themselves, nobody responsible | business people and product managers enter phase by phase (responsibility mechanism not disclosed in the source) |
All three empty: everyone can use AI, and what you have is personal productivity — enterprise-level AI capability, zero.
All three answered: now the words "organizational capability" mean something.
Close out the evidence boundary while we are here: this piece's three questions come from an organizational-transformation practice, not a scoreboard — five and a half days and three phases are delivery facts; the organizational change is the principal's own "fairly clear," no numbers; this case disclosed no externally shareable ROI; the piece's only quantified figures belong to another manufacturing client's three-team, short-days in-house tally, which the principal himself warns should not be read as a long-term, complete ROI conclusion. The three questions audit the balance sheet. The case itself never filed a score.
Appendix: Line Anchors for Direct Quotes
| Quote (English rendering) | Anchor | Print page | Speaker |
|---|---|---|---|
| "would raise several requirements in a single day" | No. 7, L20-21 | p. 69 | Narrator (interviewed FDE, first person) |
| "from three to ten" | No. 7, L21-22 | p. 69 | Same (the material's written value expectation, not a before-and-after measurement) |
| "not the same as the traditional image of 'a project that took a year now taking half a year'" | No. 7, L22 | p. 69 | Same |
| "had in fact already been using AI, and some were using it quite deeply" | No. 7, L23 | p. 69 | Same |
| "some on Codex, some on Claude Code, others using other AI Coding tools" | No. 7, L23-24 | p. 69 | Same |
| "everyone can use it, but the company can hardly get everyone to use it together" | No. 7, L24-25 | p. 69 | Same |
| "Everyone thinks their own tool is the best" | No. 7, L26 | p. 69 | Narrator (field summary) |
| "I'm efficient with this tool — make me switch to another and I actually can't do my work" | No. 7, L26-27 | p. 69 | Floor quote; speaker not identified in the source (relayed by the narrator) |
| "once personal habits mature, a company that tries to unify tools runs into fresh resistance" | No. 7, L27 | p. 69 | Narrator |
| "AI to become an organizational capability, no longer just a personal tool scattered across employees' computers" | No. 7, L28-30 | p. 69 | Same (management's ask, as relayed) |
| "no common standard for how far AI Coding can actually go, or where one's own ability stands" | No. 7, L34-35 | p. 69 | Same |
| "the original R&D collaboration practices did not change with the arrival of AI Coding" | No. 7, L37-38 | p. 69 | Same |
| "no ready-made answer for how those ideas land in their own team" | No. 7, L40-43 | pp. 69-70 | Same (quote spans a page-footer marker) |
| "someone finds a tool that works and uses it alone; someone masters a new method and practices it alone" | No. 7, L50-51 | p. 70 | Same |
| "at this stage there is really no problem, because the individual answers only for their own efficiency" | No. 7, L51-52 | p. 70 | Same |
| "how should a dozen-plus documents be divided up?" | No. 7, L55-58 | p. 70 | Same |
| "What does the product manager write? What does the frontend write? What does the backend write? What do testing and ops each own?" | No. 7, L59 | p. 70 | Same |
| "If several people edit Markdown at the same time, how do you avoid conflicts? Can the old role boundaries still carry over?" | No. 7, L59-60 | p. 70 | Same |
| "None of these are problems that solve themselves once you have learned an AI tool" | No. 7, L61 | p. 70 | Same |
| "I did not define the old methods as 'wrong.' Quite the opposite — they were a mature set of methods fitted to the old R&D mode" | No. 7, L62-63 | p. 70 | Same (quote starts mid-sentence; the opening "so," omitted) |
| "once AI truly enters a company, what changes is often not just the tool, but the way of working behind the tool" | No. 7, L65-68 | pp. 70-71 | Same (quote spans a page break: L67 blank, L68 opens the new page) |
| "had already decided to adopt Alibaba's capabilities, but no particularly clear answer to 'having bought it, what exactly do we do'" | No. 7, L72-73 | p. 71 | Same |
| The four roles' concerns — the boss on whether transformation can happen, R&D on personal efficiency, PMs on process change, HR on daily yield | No. 7, L75-77 | p. 71 | Same (compressed paraphrase in the body, not verbatim) |
| "treated it, from the design stage on, as one complete enterprise AI transformation practice" | No. 7, L78-79 | p. 71 | Same |
| "I did several things" | No. 7, L80 | p. 71 | Same |
| "the capability level a company describes for itself is often not its real capability level on the ground" | No. 7, L84-85 | p. 71 | Same |
| "do not fully trust the upfront research — verify as far as possible through real operations, quick prototypes, and on-site conversation" | No. 7, L86-87 | p. 71 | Same |
| "why the company must transform, why R&D staff should use this, how the tool enters the original process, how roles change, and how it finally settles into the company's own methods" | No. 7, L95-96 | p. 72 | Same ("original process" broken across L95/L96) |
| "In those five and a half days I was lecturing and observing at the same time; training and consulting at the same time" | No. 7, L97 | p. 72 | Same |
| "Problems found on site, I keep adjusting further down the line" | No. 7, L98 | p. 72 | Same |
| "R&D collaboration once ran around one PRD; now it moves to many documents, and the role division cannot necessarily be applied directly anymore" | No. 7, L102-103 | p. 72 | Same (first half compressed paraphrase; "the role division…" verbatim) |
| "no particularly mature, unified standard to copy" | No. 7, L104-105 | p. 72 | Same |
| "kept decomposing it, releasing it piece by piece, confirming with the client, then adjusting on the feedback" | No. 7, L106-107 | p. 72 | Same |
| "built a set of Spec documents from zero to one. The client initially assumed these were documents Alibaba had already refined internally" | No. 7, L108-110 | p. 72 | Same |
| "the client's business people and product managers gradually came in too, and the whole project turned from pure R&D training into a more complete organizational transformation" | No. 7, L113-116 | p. 72 | Same |
| "was letting me truly see what the enterprise's field actually looks like" (the first phase's most important value) | No. 7, L114 | p. 72 | Same |
| "get the whole chain running first, then iterate on real feedback; the first pass does not have to score 100" | No. 7, L120-121 | p. 73 | Same |
| "the effect of this project cannot simply be read as 'the company earned more money after using AI.' This fund company did not open up complete ROI data that I could disclose externally" | No. 7, L124-125 | p. 73 | Same |
| "the effect is fairly clear" | No. 7, L125-126 | p. 73 | Same (self-description, no numbers) |
| "later the company began to unify tools, and went further to unify R&D collaboration practices" | No. 7, L128 | p. 73 | Same |
| "no longer a question of 'whether this or that individual developer can use it' and began entering the team's shared R&D process" | No. 7, L128-129 | p. 73 | Same |
| "it no longer depends on one person demonstrating on site; it can keep being reused inside the enterprise" | No. 7, L130-131 | p. 73 | Same |
| "coding time saved about one-third, documentation time more than half, testing time roughly flat" | No. 7, L132-134 | p. 73 | Same (another manufacturing client's short in-house tally, not this case) |
| "should not be read as a long-term, complete ROI conclusion" / "a genuinely valuable effect evaluation still needs to run two weeks, a month, even longer" | No. 7, L135-137 | p. 73 | Same (the principal's own warning) |
| "was completing one change: from 'everyone using AI on their own' toward 'the company starting to form a shared method for using AI'" | No. 7, L138-139 | p. 73 | Same |
| "AI moves too fast, and industry standards haven't caught up" / "not yet validated at scale over a long enough time" | No. 7, L145-147 | p. 74 | Same |
| "buying an all-in-one model machine out of the gate, commissioning model fine-tuning, or forcibly overturning the entire existing workflow" | No. 7, L168-169 | p. 75 | Same (self-stated judgment) |
| "investment should go from light to heavy — verify the business value first, then deepen step by step" | No. 7, L173 | p. 75 | Same |
| "the sentence itself cannot guide implementation" / "different goals correspond to completely different plans" | No. 7, L181-182 | p. 75 | Same |
| "AI usage levels are very hard to judge accurately through questionnaires" | No. 7, L185 | p. 75 | Same |
| "even if the first pass only scores seventy or eighty, that beats sitting there debating the plan to a perfect 100 before starting" | No. 7, L186-187 | p. 75 | Same |
| "once it is genuinely running, the background, the pain points, the plan, and the constraints all become clearer" | No. 7, L188 | p. 75 | Same |
Calibers. The source case is Chinese-language; the quotes above are the author's English renderings, each anchored to the physical line of its extraction file at
sources/fde-cases/pdf-text/NO-07-企业研发转型.txt, re-verified line by line for this piece. Print page = the nearest "M/245" marker appearing after the quoted lines (print page = PDF physical page − 1; footer markers measured at L13=67, L41=69, L66=70, L92=71, L118=72, L141=73, L166=74, L193=75). Number calibers: "from three to ten" = the material's written value expectation, not a before-and-after measurement; no ROI for this case = the source explicitly states complete ROI data was not opened for external disclosure (No. 7, L124-125); "fairly clear" organizational change = the principal's own account, no numbers (L125-126); about one-third / more than half / roughly flat = another manufacturing client's three-team in-house tally taken over a few short days (L132-134), with the principal's own warning that it should not be read as a long-term, complete ROI conclusion (L135-137); "two weeks, a month, even longer" = the principal's own suggested horizon for effect evaluation; five and a half days, three phases = delivery facts; "seventy or eighty / a perfect 100" = the principal's method metaphor, not measured numbers. Every effect statement stops at the principal's own account; the piece contains no "research shows / data proves" formulations. Speaker boundary: "I'm efficient with this tool…" — the source does not identify the speaker (relayed by the narrator); "once personal habits mature…" sits outside the source's quotation marks and belongs to the narrator's own commentary; "business people and product managers entering phase by phase" is the principal's self-described on-site signal — the landing of role redefinition and its responsibility mechanism are not shown in the source, and nothing in the piece is written as "verified in production / already institutionalized." Numbers from other cases in the series (No. 1, No. 6, No. 9, No. 13, No. 24, and so on) do not appear in this piece.
Source and Caliber Notes
- Case source: Datawhale's FDE Cases 100, first twenty-four cases, published September 2026 — interview write-ups from a single editorial project, not twenty-four independent causal experiments. This piece uses only No. 7; every fact comes from this case's own source text and decomposition card, with nothing borrowed across cases, and no client-revocation episode appears anywhere.
- Our frameworks, signed: the three thresholds; the three-question ruler; "the minimal unit is a method placed in a shared carrier, with someone responsible for it"; "training can produce skilled individuals, not their shared carrier"; "requirements scattered in chat follow the person; requirements in a Spec follow the organization"; "data plus methods complete the picture of organizational assets"; "buying settles whether it exists — the ownership threshold asks whose it is"; "the goal-form and procurement-form mismatch"; "'someone responsible' delivered only half"; "training becomes transformation first in who is in the room"; "the answers are seen, not asked"; "the answers are run out, not discussed out" — all our decomposition, not the case's self-report and not customer-validated results.
- Geography: the source says "a fund company" and states no country, so no country is claimed; the same holds for the other manufacturing client. Nothing is repackaged into a "Chinese companies" story.
- Time anchor: written 2026-10-12; the only year appearing in the piece is September 2026, the case collection's publication date — no "this year / last year" drift words.
Two companion rulers from the same case batch are already on this site. AI on the Ground in Cross-Border Business: The Bottleneck Isn't the Model — It's That the Output Doesn't Belong to the Company carries the data-and-assets half of ownership — images, video, the books. This piece carries the working-methods half. Data plus methods is the complete picture of organizational assets, one half apiece. AI Adoption Has Six Levels is another ruler cut from the same twenty-four cases: that one measures how far AI adoption has actually landed; this one measures whose name the capability is recorded under. Two rulers, two different things to check.
I'm Uncle J. Eighteen years in HR — and the "proof of capability" I saw most often was the training sign-in sheet: everyone arrived, everyone signed, and the capability was judged to have stayed behind; the person walked out, and what the company kept was the sheet. AI has set the same old exam on new paper, and it is still testing the same old things: whose name the methods are filed under, whether the requirements ever made it into a carrier, whether anyone claimed the responsibility. These days I run a one-person AI organization on exactly that craft — and the three questions were never written for AI. They were written for organization design. The trade is old. The material is new.