The AI and Data Factory — หกบริการที่ทำให้ use case ถัดไปถูกลงThe AI and Data Factory — Six Services That Make the Next Use Case Cheaper

🤔 If the second use case costs as much as the first, does the organization have a factory, or just projects?

The previous post, Redesign Tasks Before Headcount, ended on the conclusion that once work has been redesigned at task level, the next question is which components should be built once and reused across the whole organization, instead of every team rebuilding the same foundations on its own schedule. This post is the answer to that question, and it is the chapter I find technical and business readers most often finish holding two different pictures of — which is exactly why they should read it together.

The short answer to the whole article is that the AI and data factory does not produce a model. It produces reusable components: governed data, versioned context, evaluation sets, tool contracts, release manifests, operating procedures, and feedback converted into regression tests — and it begins with demand, meaning the decision that has to get better, not with a campaign to collect all the data first.

1. The Factory's Output Is Not a Model

Chapter 5 of the playbook opens with a negative definition, and I like that opening a great deal, because it throws out the two most common misunderstandings in its very first sentence. An AI and data factory^[1] is not a room full of data scientists, and it is not a queue of disconnected pilots. Both of those are things organizations genuinely build and then call a factory, when the first is a skills pool and the second is a pile of work that happens to share tooling.

The book's positive definition is that a factory is a repeatable production system for turning one business decision into governed data products, workflows with AI as a component, measurable evidence, and services that somebody is actually monitoring. The load-bearing word in that definition is "repeatable" — not "modern", not "large", and not "has a model of its own".

So what does the factory actually produce? The book states it directly: its output is not merely a model, but includes all of the following^[1]

• Trusted source data — not a database dump, but datasets with an accountable owner and definitions that have been agreed
• Retrieval corpora — knowledge deliberately curated for retrieval, not every file in the organization poured into a vector database
• Context templates — templates that assemble instructions, evidence and state in a disciplined way
• Tool contracts — the scope, the schema, and the effects a tool is allowed to cause
• Evaluation sets — labeled test cases that decide whether a new version is better or worse
• Release manifests — the document that binds every component of one version together
• Operating procedures — what the people on the floor do when the system proposes the wrong thing, or fails to answer at all
• Feedback converted into regression tests — customer and reviewer corrections that become the system's permanent exam

Read that list slowly and you will notice that hardly any item on it is a "model" in the everyday sense of the word. Every item is something that sits around the model, and is what makes the same model behave completely differently in two organizations. This is why comparing organizations by asking "which model do you use?" tells you almost nothing. The question that does tell you something is: "of the components in the list above, how many have an owner, and how many have a version number?"

What actually separates a project from a factory

The source video for this series draws the distinction clearly in §10 (25:53–28:24)^[2]: the common organizational pattern is to do AI as a project — one problem, one team, collect data, build a model, run the trial, finish. The problem is not that this fails to work; plenty of projects work. The problem is that when the project closes, very little is left behind with the organization, and the next project starts from zero again. The video compresses the principle into a single sentence: reuse lowers the marginal cost of the next use case.

That table is my reading of the chapter, not a table printed in the book, but the last row is the one I use most often when auditing a real organization, because it resolves to a single question: three months ago there was a case where the system answered wrongly enough that somebody had to apologize to a customer — is that case in the test set that runs before every release today? If the answer is "it is in the team lead's inbox", that organization is still working as a project, however good its platform is.

2. The Factory Begins with Demand, Not with Data Collection

The most expensive sentence in this chapter is a short one: the factory begins with demand^[1]. Identify the decision to improve, who is accountable for that decision, what role AI is permitted to play in the process, and how the outcome will be measured — all four before going out to collect more data.

Why does the order matter? Because the reverse order is the first failure pattern the chapter names outright: building a data lake without knowing which decision it improves. I meet this pattern often enough to predict it. An organization invests in a data platform for several years, ends up with a genuinely complete warehouse, and only then asks "so what should we do with it?" The answer is usually a list of use cases with no owner, because the people who actually own the decisions were never in the room while the warehouse was being designed.

"What role AI is permitted to play" is decision authority, which this series has treated as an independent dimension since #5 Decision Portfolio — a system that only drafts an answer for a person to check, and a system that can release a real effect on its own, are different pieces of work needing different components from the factory, even when the decision itself is the same. The same holds for consequence, which returns later as the metric "evaluation coverage by consequence" in section 7.

Once you know which decision you are improving, the book's next step is to shape the critical data into products the domain owns, with defined provenance, quality thresholds, access rules, and a service commitment. Notice that these five are not purely data-engineering work — "definitions" and "quality thresholds" are business decisions that a data team cannot make on the business's behalf.

The three-rung ladder: project → capability → operating model

The source video separates three levels in §13 (34:04–37:18), and the book restates them^[2]. The value of this ladder is not that it ranks organizations; it is that it explains why counting use cases is the easiest metric to fool yourself with. The video uses the illustration that an organization with a great many disconnected pilots may be further from transformation than one with only a handful of uses that share a platform, a feedback loop and an expansion path — that is a rhetorical illustration, not a measurement, and it should never be transplanted into a metrics table.

Three powers that do not come for free

Another frame the book takes from the video, at §11 (28:24–31:13), is the three powers of a digital operating model^[2]: Scale — serving more customers, transactions or decisions without a proportional growth in resources; Scope — reusing data and AI capabilities across products, services and contexts; and Learning — turning interactions into better understanding and better future performance.

The sentence that must always be read alongside them is that these three powers are not automatic properties of a model. They are the result of organizational design. I emphasize that sentence because it is the reason this whole chapter exists: if the three powers arrived with the model, buying an API would be sufficient and nobody would need to build a factory. The economic loop the book describes is use → evidence → learning → a better product or process → more valuable use, with quality and harm measured at every step — which is the learning loop that #3 The Learning Engine already examined. The factory is the engineering form of that loop.

3. Six Reusable Services, and the Shared Control Band

This is the heart of the chapter, and the one picture I recommend executives carry away from this post. Factory capability consists of six reusable services — data products, context services, model services, evaluation services, tool registry services and observability services — with four shared controls, security, privacy, FinOps and sustainability, spanning all six^[1].

What makes this six-way split useful is not the number six; it is what each tile owns and versions. I have therefore arranged the table below around three questions: what does this service own, who consumes it, and what evidence does it emit for others to inspect? Any tile that cannot answer all three is still a team, not a service.

Provenance already has a shared vocabulary

In the table above, provenance appears twice — under data products and under observability — and that is not a coincidence. The origin of data and of results has to be recorded at the source and be readable in reverse at the far end. The good news is that nobody has to invent the vocabulary. W3C PROV-O is a W3C Recommendation published on 30 April 2013, and as of 5 September 2026 it holds that status with nothing superseding it^[3]. It supplies a set of classes and properties for representing and interchanging provenance generated in different systems and different contexts, built around entities, activities, agents and derivation relationships.

What PROV-O does not give — and this needs saying plainly — is that it is a vocabulary, not an audit policy, not a storage design, and not a statement of how long an organization must retain anything. Those questions belong to internal policy and to applicable law. The real benefit of adopting a shared vocabulary is that when data products and observability speak the same language, the "provenance coverage" metric in section 7 becomes genuinely countable instead of a feeling.

The four shared controls

The dark band beneath all six tiles in the figure is the part I see organizations miss most often, because it is the part "everyone is responsible for", which usually translates to nobody. The book names four shared controls — security, privacy, FinOps and sustainability^[1] — spanning all six services, rather than sitting as a checkpoint at the end.

Security — the thing I want remembered is that the security of an AI system does not begin at the point of going to production. NIST SP 800-218A, the SSDF Community Profile for generative AI and dual-use foundation models, was published on 26 July 2024 and, as of 5 September 2026, remains Final with no superseding revision^[4]. The part that bears directly on the factory is that its stated audience includes the acquirers of AI systems, not only their developers. Buying a model or a service from outside does not make this concern disappear; it moves it into the contract and into the evidence you have to demand from the supplier — and, as the book is careful to note, a secure-development profile reduces risk but does not guarantee secure behavior in deployment.

Privacy — in this chapter privacy is named as a control family that must span every service, not as a legal requirement. I will therefore not interpret PDPA here; that belongs to the post devoted to governance. What has to be decided at factory level is which data may enter a corpus, what memory context services retain and for how long, and whether the traces observability keeps contain personal data.

FinOps — the FinOps Foundation treats FinOps for AI as a technology category of the FinOps Framework, and its FinOps for AI Overview page was last updated on 17 February 2026^[5]. What this band does in practice is allocation, being able to say who consumes a model's output; forecasting, which the FinOps Foundation itself describes as less predictable than ordinary cloud and as requiring more experience; optimization; and unit economics with token-based units added, such as cost per call or per successful outcome, together with governance through quotas, reserved capacity and throttles. Actual prices and energy figures belong to #17 Suppliers, Cost and Footprint; here I am describing only what the band does.

Sustainability — the word the book uses is sustainability, or sustainable AI, and not GreenOps. The GREENOPS label that appears on the dark band in the figure is this series' own abbreviation, used to keep the label short enough to draw; it is not the book's wording. I flag it here because this series has an agreement not to put words in a source's mouth that the source did not use.

Ownership and continual improvement are a process, not a one-time checklist

The question that follows immediately from the six-service table is who ensures those services are still working well in year two. Structurally, there is already an international standard for that answer. ISO/IEC 42001:2023 covers the AI management system; it is edition 1, dated December 2023, and as of 5 September 2026 it is Published at stage 60.60 with no revision, amendment or new edition listed on its ISO catalogue page^[6]. The standard's public description states that it specifies requirements for establishing, implementing, maintaining and continually improving an AI management system within an organization.

It also has to be stressed that these four documents do different jobs and must never be substituted for one another: PROV-O supplies a vocabulary for provenance; ISO/IEC 42001 supplies lifecycle management processes; NIST SP 800-218A supplies secure-development and supplier-side practices; and FinOps for AI says what the cost band does in practice. An organization that picks up one of them and declares itself covered has closed one gap and left the other three open.

4. Context Engineering — Context Is Part of the Release

If I had to choose one paragraph from Chapter 5 as the one most likely to change how an engineering team works, I would choose this one. The book writes, on page 23^[1]

For generative systems, this continues into context engineering. Retrieved passages, instructions, session state, tool semantics, and policy thresholds all influence behavior. They belong to the release process rather than invisible plumbing.

The phrase that gives the sentence its edge is the last one: these things "belong to the release process rather than invisible plumbing". I like that phrase because it describes the real state of most organizations exactly: the prompt lives in a file nobody reviews, the corpus is updated by someone with good intentions, the threshold is changed on a config page at two in the morning — and not one of those three appears in the release record.

The five things that sentence puts inside the release process have precise names, and I recommend teams print these five lines and tape them beside the screen.

• Retrieved passages — which corpus snapshot, effective from what date, carrying which passage ids
• Instructions — the system prompt and every template layer that composes the instruction the model actually receives
• Session state — what the system remembers across turns and across channels
• Tool semantics — what the tool with this name really does, and whether the description the model sees matches its actual behavior
• Policy thresholds — the lines that make the system hand off to a person, or stop

These five can change a system's behavior as much as changing the model does. Yet in most organizations changing the model requires several layers of approval, while editing a prompt takes one commit. That asymmetry is what this chapter is trying to close.

💡 My view: the chapter's third operating principle is written briefly and binds hardest — "Treat context as a release artifact — version prompts, templates, corpus, ranking, memory, and tools together."^[1] The word to read slowly is "together". Plenty of teams version their prompts by now, but the corpus is updated separately, the ranking config is updated separately, and memory has no version at all. The result is that when the system starts answering oddly some weeks after a release, nobody can reconstruct what changed, because no single point recorded the whole set at once.

The chapter's other four principles^[1] are: principle 1, start with the decision — define outcome, user, authority and consequence before building pipelines, which is what the whole of section 2 unpacked; principle 2, treat data as a product — give every critical set an owner, a semantic contract, lineage, an access policy and a lifecycle; principle 4, move evidence with the product — a candidate without test results, limitations and rollback is incomplete; and principle 5, turn feedback into governed learning — validate corrections, add neighboring cases, and rerun the gate.

Principle 4 contains a word worth reading twice: "incomplete" — not "could be improved". Incomplete means a required part is missing, which is a different state from "approved with observations". In practice, that is the difference between an organization that has a real release gate and one that merely holds a meeting before shipping.

The question many people ask next is what document context should be recorded in. The answer is the runtime-context manifest, a tool that #11 When Is AI the Core? owns and will take field by field. Here I will stop at the principle: if the five items above are not bound into one versioned document, we will never be able to answer the question "which version was it that answered wrongly yesterday?"

5. CX-REFUND-01 — One Case Every Service Must Touch

From this section onward, through the engineering half of the series, the book uses a single case so that chapters can be compared against one another. It is called CX-REFUND-01, the customer refund companion of Luma Commerce Thailand (a fictional case from the playbook)^[1] — the company does not exist, and every number in the case is an illustrative value, not a universal threshold for anyone to copy.

Its scope is to answer refund-policy questions, route cases, draft replies, propose refunds and create CRM notes, handling questions in two languages. The only financial tool it may propose is issue_refund, and an external guard may execute exactly one eligible refund, no greater than THB 2,000, and only after confirmation. Every other financial action goes to a person.

The best-designed part of this case is not the capability but the exclusion list. Its scope explicitly cuts out six things: cases with fraud flags, subscription products, marketplace orders, legal complaints, non-THB payments, and amounts above THB 2,000^[1]. Writing the exclusions clearly at the outset is what separates a system that has been designed from one that is merely "seeing how much it can answer".

How the six factory services touch this case

The value of a shared case is that it forces all six tiles to deliver something real rather than merely exist on a diagram. The table below is what each service has to hand to CX-REFUND-01, as the book describes it on page 23.

Two sentences from page 23 deserve particular emphasis. The first is that each candidate version binds the corpus, the context builder, the tools, the evaluators and the thresholds into a single manifest — this is principle 3 from the previous section made concrete. The second is that customer corrections must be validated and become recorded failure cases, rather than becoming training data automatically.

One last observation for this section: the THB 2,000 figure and all six exclusions come from no research, and should not be adopted as another organization's defaults. What is worth copying is the form — writing out the scope, the limit, the exclusion list and the paths that must go to a person, in full, before the first line of the prompt is written.

6. The Factory Value Stream Design Workshop

The book gives one working session per chapter, and this chapter's is called Factory value stream design. Its shape is: run two hours with the owners of six roles — product, domain, data, platform, operations and risk — and trace one single request from business intent to released outcome^[1].

Two requirements inside that sentence are routinely skipped. The first is "six roles" — not six people and not six teams, but the actual owners who can decide on behalf of that role in the room. If risk sends a delegate who has to go and ask before answering anything, the workshop ends with a list of open questions rather than a map. The second is "one single request" — the urge to trace three cases at once is a trap I see every time, because as soon as you trace several, everything gets described at a level general enough to cover them all, which is exactly the level at which no problem is ever found.

The things to identify while tracing the path number eight in the book: authoritative sources, transformations, context assembly, model decisions, tool effects, human handoffs, evidence, and feedback. And there are four things to mark: queues, reconciliation work, ambiguous definitions, and ownerless points.

The table below is how I actually slice those two hours when I run a session like this. It has to be flagged clearly that the book supplies no segment-by-segment agenda — it gives only the two-hour duration, the six roles, and the things to identify and to mark. The time split below is mine, and the book does not claim two hours is optimal or measured. It is a scheduling default, nothing more.

Minimum production package — the seven items required before release

The workshop ends with a single artifact. The book calls it the minimum production package and names seven items: data contract, context manifest, golden-set plan, effect boundaries, owners, acceptance metrics and rollback^[1]. The word "minimum" has to be read literally — it is a floor, not a sufficiency test. Having all seven does not mean the system is ready; it means the system is ready to be examined.

I add three columns to those seven, following this series' convention: owner, version, and evidence — because an item without those three turns into a slide heading very quickly.

The field I always check first is the last one, because rollback is the only one of the seven that cannot be proved on paper. If it has never been rehearsed, "we can be back within ten minutes" is a hope, not evidence — and by this chapter's fourth principle, a version without a working rollback does not yet count as ready.

7. Metrics That Matter, and Failure Patterns

The chapter opens its metrics section with the single most valuable instruction in it: separate outcome improvement from factory health^[1]. They have to be separated because the two move on different clocks. The factory can strengthen every quarter while business outcomes stay flat, because the decisions chosen for improvement were not the ones creating value; and conversely, business outcomes can improve temporarily for external reasons while the factory rots. An organization that merges the two into one dashboard will always see the signal later than it should.

The book lists twelve measures^[1], and the point to stress is that it sets no target value for any of them. It is a vocabulary for measurement, not a pass mark. I have added a Scorecard column, as this series does, so it is visible which column of the organizational scorecard each measure lands in, and so the whole factory is not judged on a single dimension called speed.

Failure patterns

The chapter names eight failure patterns^[1]. I keep the book's order and add a note on what each one looks like when you meet it in the wild.

• Building a data lake without knowing which decision it improves — recognizable because the project documentation describes the architecture in exquisite detail but cannot say who will decide differently once the system exists
• Calling a group of pilots a factory — several pilots sharing no components are still several pilots, not one factory. The metric that exposes this is reuse of approved components
• Shadow corpora — a knowledge store one team built alongside the shared one because the shared one was too slow to wait for. The problem is not that the team was wrong; it is that the shared service was unresponsive, and the organization now has two truths
• Unversioned prompts — editable without leaving a trace, so nobody can reconstruct what caused yesterday's change in behavior. This is the pattern principle 3 is designed to close
• Measuring uptime while ignoring semantic quality — the system answers every question fast, and answers wrongly with great consistency. The dashboard is entirely green
• Treating all user feedback as truth — unvalidated corrections become training data, and one person's misunderstanding becomes the behavior the system shows everybody
• Optimizing retrieval without post-state checks — retrieval scores improve, but nobody verifies that once the system has acted, the resulting state is actually correct
• Centralizing every delivery choice in one specialist queue — safer at first, then a bottleneck that every team starts finding ways around, which is more dangerous than the original state. This is the bridge straight into the next post

8. The Road Ahead

If the whole chapter had to be compressed into one change of practice, I would choose this: change the question asked when an AI project is approved, from "what will this project build?" to "what components will this project leave behind for the next project to use, and will those components have an owner, a version and evidence?" The first question buys you an output. The second buys you a capability.

There are three things you can do next week. One, open your organization's most recent AI project approval document and count how many of the seven items in the minimum production package actually appear in it — in my experience the answer is usually fewer than half, and the two most often missing are the context manifest and a rehearsed rollback. Two, run the two-hour workshop with the six roles on one single request, and count the ownerless points that surface. Three, pick three metrics from the table in section 7, drawn from three different Scorecard columns, and measure a baseline without setting any target yet.

What this chapter cannot answer, and what the next one is for, follows from the last failure pattern. A factory with six services and a shared control band needs people who set the standards, people who build, people who approve and people who operate — and if all four roles sit with one central team, the factory becomes the bottleneck, while if every domain chooses everything for itself, the organization is back to holding several versions of the truth. Where that line falls is the content of Chapter 6.