Earn the Right to Increase Authority — วุฒิภาวะวัดที่ WorkflowEarn the Right to Increase Authority — Maturity Belongs to a Workflow, Not a Logo

🤔 An organization searches its documents with AI brilliantly — the team is fluent, the results are good — yet it is not ready to let AI approve a single loan. So what level of AI maturity is that organization at?

The previous post in this series — Build a Learning System — The Loop Your Competitors Cannot Buy — closed on the conclusion that what an organization actually builds is a learning loop that turns faster than its environment changes, not a pile of models or a pile of tools. The question that follows immediately is the one every executive must answer before signing off the next tranche of budget: so where are we now, and are we ready to let AI do more than it is doing today?

This chapter's answer is short, and it cuts against the grain of almost every executive dashboard: maturity is not a score for an organization; it is a property of each individual workflow. It is measured by evidence that you have demonstrated control of that particular piece of work at the level of authority, consequence and dependency you declared — not by the number of Pilots, the number of Licenses, or the number of people who sat through Prompt training.

1. Why Pilot Count Is Not Maturity

Picture the slide we have all seen too many times: Pilots closed this quarter, Licenses bought for staff, headcount through the Prompt engineering course, and the whole thing compressed into a single number — "we are middling-to-good". The problem with that slide is not that it lies. The problem is that it measures the wrong thing: it measures activity, not demonstrated capability.

The playbook this series follows^[1] sets its definition squarely against that convention: AI maturity is not the number of Pilots, Licenses or people who attended Prompt training. It is the demonstrated ability to operate AI at a declared level of authority, consequence and dependency. Three of those words deserve to be read slowly.

• Decision authority — how much weight the model's output carries in that decision. Is it a suggestion a human skims, a draft someone signs and owns, or an action that produces a real effect in an external system?
• Consequence — if the output is wrong, is the damage reversible, who absorbs it, and within what window? A document search that misses and sends the user back to the search box, and a loan approval that misfires and costs someone a right, are not the same class of problem.
• Dependency — if you removed the model today, would the process still run? How much slower? And is there a fallback path that has actually been rehearsed?

Once those three dimensions are on the table the conclusion is unavoidable — and the playbook states it plainly: "An organization can be mature in document search and immature in credit decisions. Maturity belongs to a workflow, not to a logo or enterprise score."^[1] An organization that publishes a single maturity score is averaging work it controls very well together with work that does not even have an owner, and arriving at a number that is not true of any single workflow it holds.

There is another face of the same problem that I hear constantly from Thai executives — buying Licenses for the whole organization and counting that as the transformation. The Masterclass EP01 lecture that the playbook cites^[2] makes the same point (I am paraphrasing rather than quoting, because the episode's Thai automatic captions carry speech-recognition errors in several places): buying Licenses for everyone is the starting line, not the finish line, and the fact that many organizations still sit in the early stages of the path is not a failure — what is a failure is mistaking possession of a tool for change in an organization.

Let me add something from the audits I actually run: the symptom is visible with a single question. Show me the evidence for one workflow you have declared "done" — who owns it, where is the evaluation set, what was the pre-AI baseline, and when was Rollback last rehearsed? If all four answers are silence, the Pilot count on the slide is a record of what we once tried, not a record of what we can now control.

2. Five Levels, and the Evidence Each One Actually Requires

Once you stop scoring the enterprise, you need an instrument that works on a single workflow. The playbook offers a five-rung ladder, together with a warning that must be read before it is ever used — "This playbook uses five practical levels. They are an author synthesis, not a validated industry standard."^[1] That sentence matters enough that I quote it whole, because a maturity ladder is the single easiest artifact in this field to misuse. The moment it looks like a standard, people start using it as a procurement criterion, a figure for the shareholder report, or a comparison against a competitor — when it was designed to do exactly one thing: help a team answer whether the work in front of them has enough evidence to be given more authority.

What makes this ladder usable is not the names of the levels. It is the right-hand column — the evidence that must exist and be inspectable before you may claim that level.

Notice that level 3, Manage, grants AI no additional authority whatsoever. It adds only repeatability and inspectability. This is the rung most Thai organizations skip, because it has nothing new to show — no feature, no demo, just registries, evaluation sets and change history. And it is the only rung that makes levels 4 and 5 safely reachable.

The phrase "the documented level" in the paragraph above is not a figure of speech. It is a real document with an owner and a review date, and the idea already has a home in the world of standards: an AI management system under ISO/IEC 42001^[3] specifies the requirements and guidance for establishing, implementing, maintaining and continually improving an AI management system within the context of an organization — which means policy, objectives, responsibilities, lifecycle processes and monitoring must be recorded in a form that can be audited after the fact. As of 5 September 2026, ISO/IEC 42001 is still at its first edition, ISO/IEC 42001:2023, published 18 December 2023 by ISO/IEC JTC 1/SC 42; the IEC catalogue record lists its status as published with no amendment or superseding edition.

One last terminological caution. AI-core in this series means the state in which a model carries high authority in a predeclared task and removing it pushes performance below an agreed threshold — it describes the condition of one piece of work, not an honorific for an organization, and it is not a word that belongs on a strategy slide before a single workflow has cleanly passed level 4.

3. Exit Gate — Advance on Evidence, Not on Time

The five-rung ladder becomes wall decoration unless something defines when you may move up. The playbook's mechanism is the Exit Gate — a checkpoint passed with evidence, not with the calendar, not with executive pressure, and not with the fact that another team has already done it.

The only gate the playbook enumerates in full is Assist → Manage, and it requires five things: representative cases, baseline comparison, an owner, reviewer guidance, and Rollback^[1]. Those five are not supporting paperwork; they are logical preconditions. Without representative cases you do not know what you are measuring. Without a baseline you do not know whether you improved or regressed. Without an owner nobody is woken in the middle of the night when the system misbehaves. Without reviewer guidance every reviewer applies a private standard. And without Rollback the approval you just gave is a one-way bet.

On the gate that leads into AI-core the playbook is brief but sharp: "Moving into AI-core demands more evidence. It is not the preferred destination for every use case. A high-consequence workflow may be most mature when it remains advisory."^[1]

That last sentence is the one I want every executive to read twice, because every maturity ladder ever drawn carries its own gravity. Draw it as a staircase and everyone concludes automatically that the top step is the goal and the lower steps are failure — when in reality a high-consequence workflow may already be fully mature with AI still in an advisory role. Pushing loan approval up to level 5 does not mean the organization has grown up. It means the organization has just moved a risk it cannot control into the middle of a core process.

💡 My view: the second of this chapter's operating principles is the sentence I use most often when deciding — "Let evidence lead authority. A higher level follows demonstrated control." In practice it means reversing the order of sentences in the meeting. Instead of "what more could we let AI do, and then we will go find evidence to support it," you ask "what does the evidence we already hold permit AI to do?" The two questions differ only in order, and they never return the same answer.

The chapter's remaining four principles all point the same way^[1]. The first, assess by workflow and consequence, because enterprise averages are too coarse for decisions about authority. The third, standardize portable assets — Evaluation, Trace, Schema, Policy and Decision Rights — because those are the parts that survive a change of model. The fourth, progress reversibly: every level needs a Fallback and conditions for stepping back. And the fifth, let value and risk determine the target, because advisory and excellent may be more mature than autonomous and fragile.

Why "push every workflow to the top" is the wrong default

The argument above is not merely a counsel of caution; it has a foundation in organization theory. James G. March's classic paper Exploration and Exploitation in Organizational Learning^[4] models exploration and exploitation in organizational learning, and its abstract concludes that adaptive processes which refine exploitation more rapidly than exploration are likely to become effective in the short run but self-destructive in the long run.

What I take from that paper in this context is a budgetary warning: an organization's capacity to produce evidence is finite. Every time we push one workflow up another rung we spend reviewer time, system-owner time, and the patience of the operations team on that work. Do it to every workflow at once and the result is not an organization that grew across the board — it is evidence that has grown uniformly thin everywhere. And evidence that thin decays faster than we can review it.

4. Kiri Foods — From Explore to Integrate, Then a Deliberate Stop

The playbook uses the case of Kiri Foods (a fictional case from the playbook) to show how this ladder is actually walked^[1], and I like it because it does not end the way case studies usually end — it ends by not doing the thing it could have done.

It begins with the planning team at a food company using a public assistant to explain weekly demand variance. The company classified this work at Explore and prohibited customer and supplier data outright. That is the boringly correct decision: a public tool plus real data equals a problem nobody counts as an incident until it is too late.

Moving to Assist, the company switched to an approved model and had it draft the planning narrative — but the planners signed the forecast themselves. This is the heart of level 2 and the part most often misread: AI is not forecasting on the planner's behalf; it is writing the explanation for a person who still owns the number.

At Manage, the team built evaluation cases covering promotions, holidays, stockouts and new products. Notice that all four are precisely the situations where the average tells you nothing — they are the periods when demand behaviour changes shape, and the periods where a model trained and measured only on ordinary weeks will fail. Building an evaluation set like that is what gives level 3 its value, even though it grants AI no additional authority at all.

At Integrate, AI began proposing purchase-order changes through a read-only interface, and every actual write required a planner's approval. That structure is the concrete form of separating a proposal from an effect — the model has the right to propose but not the right to cause, and the channel it reaches is constrained to reading at the architectural level, not at the level of a policy on paper.

And there the story stops. Kiri declined fully autonomous supplier ordering, because cancellation cost and seasonal uncertainty remained high. The playbook closes with one line: "Maturity meant knowing where to stop."^[1]

Let me add an observation from working with Thai organizations: the decision to "stop at level 4" survives only if it is recorded, with its reasoning and a review date. Without that record, someone will ask a few months from now "why haven't we automated this yet?" and nobody in the room will remember the original reason. A correct stop with no documentation has the same lifespan as the memory of the people who decided it.

5. Authority Debt — The Liability Nobody Records

Of all the metrics this chapter proposes there is one that I believe most organizations have never measured, and it is the one that best explains incidents when they actually happen — Authority debt, or in Thai a debt of authority. The playbook defines it in a single, very clear line: real permissions exceed the documented level^[1].

Concretely: the document says this workflow sits at Assist — AI drafts, a human decides. But in the live system the service account the agent runs under has write access to the database, or the right to call an API that really does send email to customers. The difference between those two is the debt, and like every debt it causes no trouble on the day it is taken on. It causes trouble on the day something triggers it.

This debt accrues alarmingly easily. I see the same four routes over and over.

• Permissions granted for testing and never withdrawn — during Explore the team opens access wide so experiments move fast; when the work goes live nobody goes back to collect them, because there is no list to go back to.
• New tools bolted onto an existing agent — the documented level was assessed against one toolset, and tools were added afterwards without anyone re-reviewing the level.
• Indirect effects — AI writes nothing into any system, but its output is passed automatically to a downstream system, which turns a "proposal" into an "effect" with no human genuinely in the middle.
• Approval as a rubber stamp — on paper a human still decides, but the volume of work has turned approval into ritual. The documented level says Assist; the actual behaviour is Integrate.

The fourth route is the hardest to detect, because there is no technical change to find — permissions are unchanged, architecture is unchanged, and the only thing that moved was the reviewer's workload. That is why the playbook makes "human review load" a metric in its own right, and why the People column on the scorecard is not a welfare question but a question about whether the control is real.

This is where the management-system framing of ISO/IEC 42001^[3] earns its keep in practice — not because it tells you what level you should be at (it does not), but because it makes "the documented level" a document with an owner, a review cycle and an audit trail. Without a documented side to compare against, authority debt cannot be measured at all: you have the subtrahend but no minuend.

The authority-debt register — the frame I use

The playbook gives a one-sentence definition and prints no table. The table below is therefore a frame I assembled from that definition so it can be used in a real meeting — read it as a template, not as content from the book.

The point to stress: authority debt can always be closed in two directions — lower the real permissions to match the document, or raise the document to match the real permissions. The second is not cheating, if and only if the team produces the full evidence of the new level first. In practice, though, I find the first is faster, safer, and usually reveals that the excess permission was not being used by anyone anyway.

6. The Six-Step Maturity Evidence Review

All the theory above is worth something only when it becomes a single meeting that ends in a decision. The playbook proposes a working session called the maturity evidence review: six steps, one workflow per round^[1]. I have run this frame with teams many times, and its greatest virtue is that it does not permit the room to talk about the organization in general — every question is tied to the one workflow chosen in step one.

Step 3 is the one people skip — and the clause "record disagreement" is not meeting etiquette, it is a piece of evidence. When an incident happens later, the first thing worth opening is the record of who warned about what, and on what grounds we chose to proceed anyway. An organization that records dissent can learn from an incident. An organization that records only the verdict learns only what it once decided.

On step 5, I want to insist that it has four ways out, not two. Step back and retire are decisions every bit as correct as advancing, and in a healthy organization we should see both appear in some quarter of every year. If no workflow was stepped back or retired in the past twelve months, that is not a sign we got it right every time. It is a sign we were not really reviewing.

Per-level exit gates — a frame extended from each level's definition

The playbook prints the full list for exactly one gate, Assist → Manage (the second row of the table below). The other rows are my extension from the evidence definitions of each level in section 2 — usable as a team's starting point, but do not claim they are text from the book.

There is one question worth asking at every gate that is not in the table, because it is cultural rather than documentary: who in this organization has the standing to say "not passed" and still get promoted? If the answer is nobody, every gate we designed is a ritual.

7. Metrics That Matter, and the Failure Patterns

The playbook lists this chapter's metrics in a single paragraph^[1]. I have broken them into a table with a Scorecard column so each one lands directly in a column of the executive scorecard. What I have deliberately not included is a numeric target, because the right target depends on that work's consequence, and a number borrowed from somebody else's workflow is where self-deception begins.

If you were only going to start measuring three of these next quarter, I would take Authority debt, human review load and Rollback rehearsal, because those three explain nearly every incident I have ever seen, and not one of them has to wait for a new system before it can be measured.

Failure patterns

The playbook names six^[1], and I have appended the symptom you can actually observe in a real organization to each.

• Counting Pilots as maturity — symptom: the executive report carries a Pilot count and not one owner's name.
• Forcing every workflow toward autonomy — symptom: not a single workflow has ever been judged "fully mature in an advisory role".
• Skipping from Sandbox straight to integration — symptom: there is no Manage phase in the timeline, because it has nothing to demo.
• Adding Governance after deployment — symptom: the policy document is dated after the system went live.
• Treating training attendance as competence — symptom: high headcount through the course, and reviewer guidance for no workflow at all.
• Retaining a maturity label after the evidence decays — symptom: the level label was set once and given no expiry.

8. The Road Ahead — From Levels to a Decision Portfolio

If I had to reduce this chapter to a single action you could take next week, it would be this: pick one workflow that genuinely uses AI, convene one meeting, walk the six steps of the maturity evidence review, and write down three things — the level this work really sits at on the evidence, the gap between real permissions and the documented level, and the date of the next review. Those three lines are worth more than a multi-year transformation plan with no real workflow named anywhere in it.

What this chapter has not answered is which work should receive our finite time and evidence-producing capacity first. Knowing what level each workflow sits at does not tell you which one is worth pushing to the next rung — and that is the point at which the playbook takes us back to the decisions layer.