Learning Velocity — ตอบแปดคำถามด้วยหลักฐาน แล้วเริ่มแคบLearning Velocity — Answer the Eight Questions With Evidence, Then Start Narrow

🤔 If you have read nineteen posts and still cannot say how your organization will know it is getting better — have you transformed yet?

The previous post, #19 Days 91–180, closed with the day-180 review and its four-way verdict — scale, reshape, pause or stop — read off a six-column scorecard all at once. This is the last post of a twenty-part series, and I did not intend it as a summary, because a summary is the thing everyone nods at and nobody acts on. What I want to leave behind instead is four instruments you can pick up next week — an eight-question worksheet filled in with evidence, a map of the source masterclass, a deck of seventeen leader prompts, and a glossary card that makes six people in one meeting room mean the same thing by the same word.

The one-line answer to the question above is that you have transformed only when there is a nameable artifact — a real filename — behind all eight questions, and a date that says when the most recent learning cycle closed. Opinion, confidence and slides do not count. The rest of this post is how to audit yourself against that, and then start again from a single decision.

1. Governance Is Steering and Braking, Not a Wall

I want to open the final post with the sentence the playbook uses to close its treatment of governance, because it corrects a misunderstanding that has made a great many AI programmes slower without making them the slightest bit safer^[1]

"The episode also frames governance as steering and braking, not merely obstruction. Powerful systems scale harms as readily as value, so privacy, security, accountability, human oversight, and traceability must be built into architecture from the beginning. Sustainable scale requires knowing who is responsible, which decisions need human involvement, what data is permitted, and how failures will be reconstructed and remedied."

The metaphor works because it is honest about both halves. A steering wheel does not slow the car down; it is the only thing that makes driving fast meaningful at all. Brakes are not there to stop you reaching the destination, they are there so you can take the corner without having crawled along the straight. Organizations that treat governance as a wall usually get both outcomes at once — genuinely slower, and genuinely no safer — because what they added was an approval step rather than a control that the architecture enforces.

The sentence above also names five things that must be built into the architecture from the beginning rather than bolted on after release: privacy, security, accountability, human oversight and traceability. The four questions that follow it are the backbone of this entire series — who is responsible, which decisions need a human, what data is permitted, and how a failure will be reconstructed and remedied. If an organization cannot answer those four on one page per system, what it has is policy, not governance.

The gap the adoption numbers do not show

The reason this playbook spends more of its weight on organizational design than on model selection sits in a set of figures I quoted in the first post and want to close with unchanged. The AI Index 2026 report's chapter on the economy states that 88 percent of surveyed organizations used AI in 2025 and 70 percent used generative AI in at least one business function, while AI agent deployment remained in the single digits across nearly every function^[2]

The distance between 88 and single digits is what I call the authority gap. Almost every organization now has access to a model, but the number willing to let a system take real action inside a scope it can control still fits on one hand. That gap does not close with a better model, because it is not a model-capability problem. It is the question of whether the organization has steering and brakes good enough to dare touch the accelerator — and that is why this whole series spent its time on contracts, rails, release gates and incident loops rather than on benchmark comparisons.

The other half of "steering and braking" that people forget is that a good brake has a measurable stopping distance. Saying "we have a human in the loop" is not a control until you can say what that person sees, how much time they have, whether they hold real authority to stop, and where the work flows once they do. Those four answers are the difference between human oversight as a designed role and a ceremonial approval box — a failure pattern we meet again in section 7

2. The Eight Questions — Answered With Evidence, and the Artifact That Holds It

The playbook makes its promise on page two: by the time you have finished reading, a leadership team should be able to answer eight questions with evidence^[1] In #1 Six Layers, One Spine I set out all eight alongside a "gap" column, so a team could see what it was missing. Here I replace that column with evidence required and add the column that matters most in the whole series — the artifact that carries that evidence.

The reason for that column is straightforward. Evidence with no address disappears within a quarter. The person who could answer the question in today's meeting may move teams next month, and an answer that lives in one person's head is not an organizational capability. Appendix B of the playbook therefore supplies eight copy-ready artifacts that turn AI-as-a-Core assurance into an operating discipline — classify, contract, control, version, authorize, trace, release, and learn^[1]

Using this table differs from #1 in exactly one respect, and that one respect is decisive — this time you may not fill a cell with a descriptive sentence. Fill it with a filename, a wiki page title, or a ticket number that can be opened within thirty seconds. If it cannot be opened, leave the cell empty. I have run this with a team that was confident it could answer all eight, and we ended the hour with five empty cells — which turned into a sharper plan for the following quarter than the twenty slides they had prepared.

The other approach that works is to pick one real use case and walk all eight rows with that one alone. The playbook uses the refund assistant of Luma Commerce Thailand, reference CX-REFUND-01 (a fictional case from the playbook), as the thread running through all eight Appendix B artifacts, and it notes itself that every numeric value in that case is illustrative rather than a universal threshold^[1] The virtue of walking a single case is that it forces the answers to be consistent with one another. You cannot argue your way past a system with high authority in the Q4 row and paper-thin pre-release evidence in the Q6 row.

What the table still does not say is who owns the time between the gap and the closing of the gap — which is where one of Chapter 1's operating principles speaks most directly, and it is the principle I have chosen to close the series with.

💡 My view: the fifth of Chapter 1's five operating principles reads "Assign an owner to the loop — Someone must own the time from signal to verified improvement." I treat it as the principle the entire eight-question table stands on, because the first question asks how quickly we can learn and the last asks what deserves to scale. Both are measured in the same unit, time — and time with no owner is time that stretches out indefinitely with nobody at fault.

The other four principles of Chapter 1 form one set — learn from released behaviour, because a polished demonstration says very little about the variation in live cases · bind change to evidence, by stating the intended improvement, the affected slice, the threshold and the rollback condition in advance · treat traces as capability, because a decision that cannot be reconstructed is a decision the organization cannot reliably learn from · and keep value, quality, risk, cost and human load separate, because one aggregate score always conceals the tradeoff^[1]

3. The 52-Minute Masterclass Map — Five Paragraphs, Eleven Time Marks

This playbook has a source: a single Thai-language masterclass episode running 52 minutes 15 seconds, the figure Appendix A gives^[1] (the video page itself shows a round "52 minutes")^[3] Appendix A divides the episode into 17 sections with time ranges, and draws one map that pins 11 marks across the timeline. I reproduce that map here, because it is the single picture that explains why this series is ordered the way it is.

Paragraph one — the old organization (minutes 00–05). The through-line opens by reversing the order of the question. Many organizations begin a transformation with a procurement question: which model, chatbot, agent or licence should we buy. The appendix invites you to imagine that you already have the best AI in the world, but the roles are unchanged, executives decide the way they always did, the data is still scattered, and every request still passes through five handoffs. The technology may speed up individual tasks, but the organizational structure is still the old one. The factory analogy does the work here — dropping an intelligent robot onto an unchanged production line does not give you a modern factory. Then comes the five-stage maturity ladder in the masterclass's own wording, AI as a tool → AI in decisions → AI in workflows → AI operating model → AI-first organization, and the opening closes with the causal chain that runs from the falling price of prediction through decisions, workflows, authority and on to consequences for society^[1]

Paragraph two — maturity and the decision loop (minutes 05–13). This stretch lays down the economics of the whole argument. The economic answer to "what is AI" is prediction: using the information you have to estimate something you do not know, which covers demand, risk, machine failure, the best next action, the content of a document, or the answer a customer is likely to want. It need not be a numeric forecast at all. When one input becomes cheaper, organizations use more of it and redesign the complementary activities around it. But the next stretch warns that a falling price does not make judgment disappear. The decision is separated into a chain — data → prediction → judgment → action → outcome — and if leaders collapse prediction and judgment into one thing, they will expect the model to "decide" without ever having told it the priorities or the tradeoffs^[1]

Paragraph three — the decision inventory and the workflow (minutes 13–22). From economics to method. A technology-first search asks where a model could be plugged in; a decision-first search asks which recurring decisions determine value, cost, risk, experience or mission outcome. The appendix proposes building a decision inventory that covers both executive decisions and the small operational choices whose sheer volume makes them enormously valuable in aggregate. Good candidates usually carry four properties at once — frequent, high value, evidence rich, and able to produce feedback that tells you the result. Then comes allocating work by comparative advantage and consequence, and redesigning the workflow around the outcome rather than automating one task at a time along the old route^[1]

Paragraph four — oversight, the factory and the operating model (minutes 22–34). The later middle corrects the misunderstanding I meet most often in Thai meeting rooms. "Human in the loop" does not name a single control mode. A person may decide every case, may monitor the system and intervene when needed, or the system may operate inside an approved scope under policy, testing, monitoring and audit. The right mode depends on severity, reversibility, uncertainty and the effect on people, which is why a music recommender and a health or credit decision should not run under the same rule. Then comes the move from isolated projects to an AI and data factory that produces prediction, decision and learning repeatably, followed by the three powers of a digital operating model — scale, scope and learning — and the stretch closes by making AI a cross-organizational capability rather than a new department that takes requirements in and hands models back^[1]

Paragraph five — work, governance, six layers and the learning system (minutes 34–52). The closing stretch gathers everything up. It begins with accumulating capability instead of counting pilots, separating three levels — an AI project proves that one problem can be solved; an AI capability adds reusable data, model management, governance, expertise and experimentation; an AI operating model makes those capabilities part of how decisions and workflows are designed in the first place. Then converting data into a purposeful learning effect, designing the flywheel so that advantage compounds, and redesigning tasks, skills and responsibility together — which is the stretch where the "steering and braking" sentence in section 1 sits — and it closes by connecting the six layers and starting narrow, which is the entire subject of section 5^[1]

All 11 marks on the map — minutes 00, 02, 10, 14, 20, 24, 26, 32, 42, 47 and 50 — are approximate landmarks, not section boundaries. The mark at minute 24 labelled Oversight, for instance, falls in the middle of §9, which runs 22:16–25:53, and the mark at minute 26 labelled AI factory falls at the start of §10, which runs 25:53–28:24^[1] If you intend to use this map to open the video, use the time-range table in section 4 instead, because that table gives the real boundaries of all 17 sections.

4. Seventeen Leader Prompts — A Deck for One Working Session

Appendix A closes every one of its sections with a single leader prompt, 17 in all, one for each timed stretch of the video^[1] I reproduce the full set here as the book prints it, together with the source time range and the post in this series that turns each prompt into something you can act on. I call this table a "deck" because it is designed to be drawn from one card at a time, not read straight through.

How to run a working session with this deck

The playbook is very clear about how to use it, and everything it says matches my own experience. Read once for the whole argument, then come back to the section that matches the decision in front of your team. In a workshop, split three roles — one person plays the linked segment, another records the assumptions, and a third converts the leader prompt into an owner, an evidence request and a review date. The playbook ends that paragraph with a sentence I would like pinned to the meeting-room wall: the companion's value is not in producing a summary everyone agrees with, but in changing a decision and the way work is actually done^[1]

There is one caution I have to repeat. All 17 of these are the book's questions about the content of each stretch, not statements the presenter made. When you use them, do not write on a slide "the presenter asked…"; write "the companion playbook poses the question…". That level of precision is not academic fussiness. It is the difference between a citation that survives being checked and one that collapses the moment somebody opens the video.

5. Six Layers, and the Sequence That Starts Narrow

Section 17 of Appendix A is the stretch that pulls everything into a single picture, and it is the paragraph I quote at length because it is the answer to the whole series in four lines^[1]

"The practical sequence is narrow and evidence-led: find a valuable decision with feedback, redesign its workflow, create a suitable human-plus-AI arrangement, capture outcomes, close the learning loop, and only then scale the shared capability … Long-term advantage belongs to the organization that completes this cycle faster and more responsibly, not simply the one with the most AI."

Note the order carefully. Scaling is the last step, not the first, and what gets scaled is the "shared capability", not "usage". This is the point at which most organizations reverse the sequence — buy the platform first, then look for the decision to apply it to — which is the failure pattern Chapter 12 lists first of all: "beginning with a platform purchase".

Six layers and one spine, and the post that moved each

That last row is not a seventh layer. It is the vertical spine that crosses all six. The practical meaning is this: if you move one of the layers without touching the spine at all, you are adding capability without adding control, and that is the definition of authority debt — authority a system has already been granted without the evidence to support it. This particular debt is always expensive to repay, and it is usually called in on the worst possible day.

Why "shared capability" is the unit of advantage, not the pilot count

The proposal to start narrow and only then scale a shared capability has academic roots far older than the AI wave, and I think they are worth naming so a leadership team can see this is not a management fashion. James G. March's paper in Organization Science in 1991 set out the framework of exploration and exploitation: an organization must allocate resources between searching for new possibilities and improving the capabilities it already knows, and pouring everything into either one damages both^[4] The playbook takes the framework in the sense that a healthy portfolio funds both sides, without confusing the fact that the two sides carry different evidence standards^[1]

The second piece is Teece, Pisano and Shuen's 1997 paper in Strategic Management Journal on dynamic capabilities, which argues that advantage rests on distinctive internal processes, knowledge assets that are hard to trade, and the development path an organization has actually travelled^[5] Together the two papers explain why counting pilots is the wrong metric — a hundred pilots that leave nothing behind for one another is pure exploration that never converts into capability, whereas ten pieces of work sharing a platform, a feedback loop and a route to scale is capital accumulation.

The cadence the playbook gives therefore has three words — start narrow, with one to three decisions that are valuable, frequent, evidence rich and able to produce feedback · learn fast, by pre-declaring the baseline, the thresholds, the severe cases, the stop conditions and the first review date · scale deep, by reusing governed data, context, controls, evaluation assets, operating roles and incident learning across connected workflows^[1] The word doing the hardest work is "deep" — it means what can be reused, not how many users you have.

6. The Twenty Glossary Terms a Team Must Agree On First

The problem I meet most often in Thai organizations' AI programmes is not a technical problem. It is that six people in the room say the same word and mean six different things. "Governance" may mean a committee to one of them and code that blocks an API call to another. Appendix C of the playbook addresses this by defining 45 terms, each with a Thai rendering printed beside it^[1]

Forty-five is far too many to open a meeting with, so I have made an editorial selection of the 20 a team should agree on before anything else — this is my selection for this series, not a ranking by the book. The playbook states the principle behind its own glossary: the definitions are deliberately operational, and each term must be able to change a decision, an artifact, or a control^[1] If a term in the table below changes nothing at all in your organization, that means you are not using it yet. You are only talking about it.

The four pairs that break most often in translation

Let me press on four points where I repeatedly see the vocabulary drift far enough to change the meaning. One — AI-core is a diagnosis, not a position on an architecture diagram; the canonical Thai the playbook fixes reads as "the AI that is the principal core", while the near-miss most people reach for reads as "central AI", which sounds like a box in the middle of a systems drawing. The first is a verdict tied to the authority and indispensability of one declared task set. Two — indispensability is not "necessity"; necessity is a feeling an organization has about a system, whereas indispensability is an experimental question about how far performance drops when you take the component out.

Three — assurance envelope and assurance contract are not the same thing. The envelope is everything that surrounds the system; the contract is a testable statement about one property. An organization can have an envelope and not a single contract, and that is a state nobody can audit. Four — structural guarantee and semantic estimate must never be collapsed together, because this entire series rests on the difference. What code can enforce is a guarantee; what can only be scored is an estimate; and treating an estimate as a guarantee is the root of very nearly every accident.

Several terms I left off this card will still meet your team in practice. Model versus system, which separates the model that produces an estimate or a piece of content from the system that adds context, data, tools, rules, interfaces, people, controls and operational consequences · task decomposition · the incident-learning loop · impact assessment · and worker voice. All of them are in Appendix C in full^[1]

7. How Learning Velocity Is Measured, and Ten Failure Patterns to Watch

Across twenty posts I have returned to the phrase learning velocity again and again without ever setting out in full how to measure it. This section pays that debt. The playbook gives three values in the footer of Figure 1 on page 3 — feedback latency, decision adaptation time and time to scaled improvement^[1] Those three are the heart of it. The rest of the table below are supporting metrics that give the first three their context.

The important warning the playbook prints beneath its six-column scorecard applies to every row of the table above as well — never collapse them into one composite score. A faster process with rising severe errors is not progress. A safe system that produces no outcome value is not transformation. And a workflow with good throughput that exhausts its reviewers is not sustainable^[1]

Failure patterns

All twelve chapters of the playbook close with that chapter's list of failure patterns, and together they run far too long for a one-hour meeting. I have therefore selected ten that I would put in front of a board first — and I want to stress that this is this series' selection. The book publishes twelve lists with no ranking of any kind.

• Pilot theatre and dashboards with no decision owner — a beautiful screen that obliges nobody to change their behaviour when they read the number on it (Chapter 1 · #3)
• Counting pilots as maturity, and keeping a maturity label after the evidence behind it has decayed (Chapter 2 · #4)
• Letting pilots persist with no scale-or-stop decision, and ranking them only by savings that have not yet materialised (Chapter 3 · #5)
• Automating the old, unfixed process, then making one exhausted expert the universal reviewer until approval becomes a rubber stamp (Chapter 4 · #6)
• Calling a heap of pilots a factory, and building a data lake with no decision waiting at the other end (Chapter 5 · #9)
• The centre-of-excellence bottleneck, and a queue described as having a human in the loop with nobody actually staffing it (Chapter 6 · #10)
• Granting autonomous irreversible effects because semantic scores are high, and claiming zero risk because a fixed test suite found no failures (Chapter 8 · #12 · #13)
• Ceremonial approval, suppressed near misses, and closing an incident once service is restored without verifying that the corrective action worked (Chapter 9 · #14 · #15)
• Describing guidance or a certificate as proof of legal compliance, and copying principles across with no decision rules attached (Chapter 10 · #16)
• Confusing logins with adoption, omitting a Baseline, scaling before Feedback exists, and refusing to stop weak initiatives (Chapter 12 · #18 · #19)

Two chapters I did not pull into those ten should always be read alongside them. Chapter 7 collects the architectural patterns — bolted-on chatbots, prompts edited outside change control, and logs with no context, thresholds, versions or routes — all of which are in #11 — and Chapter 11 collects the workforce patterns, above all the one I consider most dangerous to trust: promising augmentation while pursuing an undisclosed automation target, which is in #8^[1]

My favourite way to use this list is to read it aloud one item at a time in a meeting and let everyone answer only "that's us" or "that's not us", with no explanation permitted. Any item where more than half the room says "that's us" is an item that needs an owner and a date before anybody leaves. A failure list earns its keep by saying the thing everyone can see and nobody wants to be first to say.

8. The Road Ahead — Update With a Dated Ledger, Then Go Back and Pick One Decision

This series and the playbook behind it both have an expiry date, not because the ideas are wrong but because legal status, model versions and the publication status of research can change in any given month. The playbook declares its own evidence snapshot at 5 September 2026 (Asia/Bangkok) and says plainly that legal and regulatory status can change after that date^[1] Appendix D.4 therefore gives a method for updating, and I think it is the part most worth copying into an organization's own internal documents.

"For any future edition, preserve the evidence cutoff and add a new dated ledger rather than silently replacing earlier claims. Recheck legal status, official implementation dates, model and system versions, study publication status, and URLs. For each quantitative claim, retain the original unit of analysis and denominator. For each local pilot, archive the evaluation set, runtime-context manifest, release decision, and outcome evidence so internal learning remains auditable."

The first sentence is the one that matters most — add a dated entry, do not delete the old one. Most internal documents do the opposite: they overwrite the number quietly and update the date at the foot of the file. The result is that six months later nobody can say whether a conclusion changed because new evidence arrived or because somebody disliked the old conclusion. A dated ledger fixes that for the cost of a few extra lines.

Three real entries, re-checked on the day I wrote this

To show what a dated ledger looks like, I followed D.4's instruction against the three statuses this series cites most often. All three were written on 5 September 2026, which happens to be exactly the playbook's own cutoff date — so this is a re-check, not a restatement.

The second half of D.4 concerns internal experiments, and it is the part organizations most often let slip. Every pilot must retain four things — the evaluation set actually used (not the name of the set, the file itself with its version) · the runtime-context manifest of the build that was released · the release decision with its reasons and the person who signed it · and the outcome evidence that actually materialised after release. With all four, you can explain two years later why the decision went the way it did. Missing any one of them, what remains is memory.

Then go back and pick one decision

If you have read this far and feel there is far too much to do, that is the correct reaction, and the way out is already in section 5 — start narrow. Go back to #1 Six Layers, One Spine for the six-layer table and the scorecard, then to #18 The First 90 Days for the sequence of the first three months, and pick one single decision that is valuable, frequent, and genuinely produces feedback. Take it around one full cycle. Then have the platform conversation.

The playbook closes with one sentence, which I will use to close this series too^[1]

"AI belongs at the organizational core only when evidence authority and learning mature together." — the playbook prints its Thai mirror directly beside it, and the Thai track of this post carries that wording.

The words doing the hardest work in that sentence are mature together. Authority that grows faster than evidence is debt. Evidence that grows with no decision authority behind it is a report nobody reads. And learning that grows without either is a review meeting that ends in agreement. All three have to move one step at a time, together — and that first step is very much smaller than most people imagine.