What Is an AI-Core System? — ระบบแบบไหนที่ AI เป็นแกนจริงWhat Is an AI-Core System? — When Is the Model Truly Load-Bearing?

🤔 If you switched your system's model off tonight, whose work would be broken tomorrow morning — and can you answer that with evidence, or only with a feeling?

This is the first post of Engineering AI-Core Systems, a ten-part series I have written as a hands-on manual from zero to a shipped system: it begins by classifying what you already have (this post) and ends at a go-live review with an assurance contract, five control rails, and a validation harness that proves what it claims (post #10). The whole series follows my own paper, Engineering AI-Core Systems: A Reference Architecture and Assurance Contract for Software 3.0^[1], and every post shares one skeleton: two concepts from the paper, a seven-step how-to, one running example application built across all ten posts, and a self-audit table you pass before moving on.

The whole post fits in one paragraph: not every system that "uses AI" is an AI-core system — the label has a measurable definition with two conditions. First, model output must control a predeclared, high-authority share of the content released to users, the external actions taken, or the runtime branches followed. Second, when the model is removed and replaced by the declared fallback, task success must fall below a threshold that was likewise predeclared. Those two conditions are two orthogonal axes; they intersect in four quadrants, and each quadrant carries a different engineering burden. By the end of this post you will hold a one-page worksheet stating which quadrant your system sits in — and what that quadrant demands of you.

1. Four Terms, Habitually Conflated — and What the Conflation Costs

The point of this section is blunt: "AI system" is not one category but at least four, each with risk of a different nature, and most organisations use a single word for all four. The result is risk mis-priced in both directions — excessive rigour applied to things that are not dangerous, and a free pass given to things that are.

Part of the confusion comes from the speed of the era itself — the moment Karpathy described in his 2025 talk as software changing once again^[2]. When everything gets called "AI" at once, the vocabulary flattens until nobody can say where the model actually sits in the system. That is why the paper opens its Section 1 by pulling these four terms apart before defining anything at all^[1].

The point the paper insists on is that these four categories are orthogonal — not a ladder to be climbed in order. A system built end to end by a coding agent can ship without a single model inside it: intensely AI-assisted, not remotely AI-core. Conversely, a system whose every line was written by hand can have a model determining every message released to customers. "Built with AI" and "has AI at its core" are different facts, and they answer different sets of risk questions.

The cost of conflation is most visible in the risk-review room. Upward: a committee sees the word AI and applies the controls of a fully autonomous system to an internal summarize button — a small feature frozen with no actual risk reduced. Downward is more dangerous: a team says "we just use AI to help answer chat" while the message goes out to the customer with no human reading it first — that is the model holding authority over the system's actually-released output, and the risk has to be priced that way.

Meet KramKraft — the running example for the whole series

So this series does not float on principle alone, I will build one system across all ten posts: a small online ceramics shop, "KramKraft", selling handmade indigo-glaze ware through its website and LINE. The owner has two staff and cannot keep up with chat, so the shop built an assistant named "Nong Kram" to take that job. At the start of the series, Nong Kram consists of exactly this:

• Work — answering order-status, product, and returns/shipping-policy questions over chat
• Knowledge — retrieval over two document stores: policy/ (return policy, shipping terms) and catalog/ (product pages)
• Tools — one, and effectful: refund(order_id, amount, reason) against the shop's order store — irreversible from the moment the payment processor accepts the transaction
• Model — a frozen hosted LLM with a pinned version, which I will call M_v abstractly throughout the series

The first question the KramKraft team must answer is not "how do we block prompt injection" but the classification question: which of the four rows above is Nong Kram? The team had been calling it an "AI chatbot", which is not even a category in the table. What is certain: it is AI-enabled, since it is deployed with a model in the runtime. Whether it is AI-core cannot be answered by feel — it has to be measured against the definition in the next section.

💡 My view: the first question I ask in every AI system review is not "which model do you use" but "if the model went dark tonight, whose work is broken tomorrow morning" — an AI-assisted system answers "nothing breaks, the dev team just slows down"; an AI-enabled system answers "one feature disappears"; the system that silences an entire department is the AI-core contender that has never actually been measured.

2. Definition 1 — Two Axes, Four Quadrants

The heart of this post is one genuinely measurable definition: the AI-core label does not attach to a model's brand or to the amount of AI in an investor deck, but to the measurable behaviour of one system, on one task set, under one manifest. The paper states it as Definition 1, and I quote both conditions:

For a predeclared task set and release manifest, a deployed system is an AI-core system when (i) model output controls a predeclared, high-authority share of released user-visible content, external actions, or runtime branches, and (ii) replacing the model with the declared non-model fallback causes task success to fall below a predeclared indispensability threshold.^[1]

Read slowly, this definition is doing heavy work in three places. One, it opens with "predeclared task set and release manifest" — the classification is bound to a declared set of tasks and the release manifest of one specific release, not a permanent property of a vendor, a model family, or an entire organisation — so the same system may be AI-core for one task set and not for another, matching the NIST AI RMF principle that AI risk is assessed in the context of use^[3]. Two, both conditions must hold simultaneously. Three, the word "predeclared" appears twice, and that is no accident — it is the rule that makes the classification mean anything.

Axis one — decision authority

Decision authority measures how much of what the system actually releases is determined by model output. The scale runs from advisory — the model proposes, a human or code decides — to autonomous — what the model produces is what the outside world receives, with nobody in between. The point people miss most often, and the paper deliberately closes off: user-facing generation with no tool call still counts, because released text IS a released system output. A wrong returns instruction that a customer reads and acts on causes real harm without a single API being called. Authority is therefore not about "does it have tools" — it is about "who determines what leaves the system".

Axis two — model indispensability

Model indispensability measures whether the work still runs without the model. The scale runs from optional to indispensable, and the paper refuses to let this axis be answered by opinion: it is operationalised by a removal ablation on a fixed golden set — replace the model with the declared non-model fallback, re-run every case in the same fixed suite, and see whether task success falls below the predeclared threshold. If it does not fall — your system may already be fine without carrying the AI-core burden, which is good news, not an embarrassment.

The rule that makes the numbers mean anything — predeclare before selecting cases

Both the authority share in (i) and the indispensability threshold in (ii) must be declared before test cases are selected — the paper goes as far as saying that declared afterwards, the classification carries no meaning^[1]. The reason is elementary statistics: see the results first and you will always draw the line where the answer you wanted lands — want to dodge the burden, pick cases the fallback handles; want budget, pick cases where it collapses. A threshold document dated before the day the cases were chosen is therefore the first artifact of the entire series, and the first row the table in section 5 will demand.

The two axes intersect in four quadrants — the paper's Table 1 binds a governing obligation to every one of them:

Notice two things. One: only a single cell earns the AI-core label, and it pays for it with the heaviest burden of the four — the rest of the series is the construction of that burden, piece by piece. Two: the other three cells are not "burden-free"; their burdens are differently shaped. A bounded agent must still fully fence its effects even though the model could be swapped out, and an indispensable advisor has no tools to fence — but the text it releases is exactly the frontier that must be guarded. Knowing your quadrant is how you read off which block of engineering work is yours, and which one you do not have to pay for.

3. The Seven Steps

The seven steps below turn the definition above into a one-page worksheet with a date and a signature on it. In practice they take half a day to a day for a single system, and every step ends with the KramKraft team making the same move — so you can see what the work actually looks like on the ground.

Step 1 — Separate the four terms for your own system

Write one paragraph answering two questions separately: to what extent was this system built with AI (AI-assisted / coding agent), and where does this system contain a model at runtime (AI-enabled / AI-core contender)? Do not let the two answers share a sentence, because they are orthogonal per section 1 — and the classification target for this whole series is the deployed system, never the development process.

This step looks ceremonial and is not — that paragraph is the gate that keeps "but we already use AI" from slipping in as a substitute for actual measurement in the steps that follow. A team that cannot write it is usually debating the governance of something they have not even defined the same way.

At KramKraft: the team could write: "Most of Nong Kram's code was written by a coding agent under our review (intensely AI-assisted) — which is irrelevant to the classification. The deployed system is a chat assistant with M_v in the runtime, answering customers and able to call refund. It is therefore certainly AI-enabled, and must be measured further to determine whether it is AI-core."

Step 2 — Declare the task set and the release-manifest scope

Write a single file stating (a) the set of tasks the system is responsible for, as countable items, and (b) the scope of the release manifest — which model version, which decoding, which prompt version, which corpus snapshot, which tool schemas — and commit it with a date. Definition 1 opens with these two things because without them, "task success" has nothing to be measured against.

The reason the task set must be declared rather than inferred: model competence is jagged intelligence — being good at task A says nothing about a similar-looking task B. The paper points to the τ-bench results: the same function-calling agent passes the retail domain at roughly 61.2% but the airline domain at roughly 35.2%, and when required to pass eight consecutive runs (pass^8) the retail figure drops below 25% — these are benchmark-specific system results, not a universal baseline for any model^[1][4]. The engineering lesson: an undeclared task boundary is the boundary across which users will drag your system into competence holes nobody ever measured.

# task-set.md — Nong Kram's declared task set (commit before running any evaluation)
task_set:
  T1: answer order-status questions          # reads the order store
  T2: answer product questions               # retrieval over catalog/
  T3: answer returns/shipping-policy questions  # retrieval over policy/
  T4: execute refunds                        # via refund(order_id, amount, reason)
out_of_scope: everything else, including technical ceramic-care advice
release_manifest_scope:
  model: M_v            # frozen hosted LLM, pinned version
  decoding: to be declared in the release manifest
  prompts: system prompt v3
  corpus: policy/ + catalog/ snapshot (hash recorded)
  tools: refund schema v1

At KramKraft: writing out_of_scope triggered the team's first real argument — should Nong Kram answer "is indigo glaze dishwasher-safe"? It was cut from the first release, because no document in the corpus supports it. That is this step's real job: forcing the decision to be made before a customer makes it for you with a question the system was never ready for.

Step 3 — Measure decision authority from traces, not from the architecture diagram

Walk through what model output determines among the things that leave the system — and read it off the decision trace of real episodes, not off the diagram drawn at design time. The diagram states intent; the trace states fact. Plenty of systems have a "human reviews before send" box on the diagram that on the ground has become an approve button pressed in bursts without reading.

The three places where authority shows itself, exactly per Definition 1:

• Released user-visible content — the final wording the customer sees: determined by the model, a template, or a human?
• External actions — which tool calls originate from a model proposal, and does anyone genuinely approve them along the way?
• Runtime branches — where does the code branch (route, escalate, choose a step) based on what the model answered?

At KramKraft: the team sampled 200 past episodes from the logs (a tutorial number) and found that nearly every customer-facing message was drafted by M_v and released directly with no human reading it first, and that every refund command began as a model proposal. Even with no tool at all, the first finding alone pushes the authority axis to autonomous — because released text is a released system output.

Step 4 — Design the removal ablation, and run it once in your head

Pin down the three parts of the removal ablation: the non-model fallback that will be swapped in for M_v (it must be declared and actually exist, not "we'll think of something"), the golden set that will be frozen, and the per-case pass criterion. Then run it once in your head: walk the task set item by item and ask whether the fallback can do each one — the thought-run exposes every place where your definition of "pass" is still fuzzy, and it has to be sharp before the real run.

Beware the trap: do not read real numbers at this step. If you see results before declaring the threshold in step 5, this classification round has already lost its methodological meaning — the correct order is design (this step), declare (step 5), then select cases and run for real (after that).

At KramKraft: the declared fallback is a templated FAQ menu (keyword-matching into canned answers from policy/) plus a human queue for refunds. The thought-run says immediately that parts of T3 would probably survive (policy questions matching a template), while T1, which reads the order store per customer, and T4, which decides refund eligibility, would probably collapse almost entirely — probably is not yet a number, and the team has not yet run anything.

Step 5 — Predeclare the indispensability threshold, before selecting cases

Write the thresholds into a file, date it, commit it — before choosing which cases enter the golden set. At minimum two numbers: the authority share that will count as "high" for axis one, and the fallback success rate below which the model counts as "indispensable" for axis two. The numbers may come from your judgment — the paper prescribes no universal values — but the timing may not: declare before case selection, or the classification carries no meaning^[1].

The file is almost embarrassingly short, but it is the single piece of evidence that proves to an outsider (an auditor, a partner, or yourself in six months) that the line was drawn before the results were seen — not drawn around the result somebody wanted.

# thresholds.md — committed 2026-09-08 (tutorial numbers)
# rule: this file must be committed before any case is selected for the golden set
authority_high: "model determines released content/actions in >= 80% of episodes"
indispensability: "fallback passes the golden set at < 60% of the full system's rate
                   => the model is indispensable"
fallback_declared: "templated FAQ menu + human queue for refunds"
golden_set: "no cases selected yet — selection happens only after this file is committed"

At KramKraft: the team chose 60% because the owner said "if it answers fewer than six in ten of what it used to, customers walk" — an ordinary business reason, not a sacred number. The sacred thing is the commit timestamp, two days ahead of the day the cases were chosen.

Step 6 — Place the system in its quadrant

Only now are cases selected into the golden set and frozen, the ablation actually run, and the two axes read together: the authority evidence from step 3 against the declared share, and the ablation result against the declared threshold. The answer lands in one cell of Table 1 automatically — at this point there is nothing left to argue about, because every input was declared in advance. That is the entire payoff of doing the steps in order.

At KramKraft: the golden set holds 40 cases (25 Q&A cases from T1–T3 and 15 refund-eligibility cases from T4 — all tutorial numbers). The full system passes 36/40; the fallback passes 9/40, which is 25% of 36 — clearly below the 60% threshold. Axis two: indispensable. With axis one autonomous from step 3, Nong Kram lands in Autonomous × Indispensable = AI-core.

Step 7 — Read off the quadrant's obligation, and write it down

Open the table in section 2 at the row of the quadrant your system landed in, and copy that quadrant's governing obligation into the worksheet in writing — together with the name of the one owner responsible for making that obligation real. A classification that ends at a label is a classification wasted; its value always lives in the next sentence: "therefore, we must build…"

And do not forget the other direction: if your system lands in another cell, that is an equally good outcome — you have just obtained evidence that you do not have to pay for the full envelope, and a lighter list of obligations that actually fits the real risk.

At KramKraft: the team wrote the worksheet's final line: "Nong Kram is AI-core for task set T1–T4 under this manifest → obligation: hard mediation of every effect · per-dimension semantic evaluation · complete tracing of every path · risk-proportionate fallback — owner: the engineering lead." Those four items are, precisely, the table of contents for the rest of this series.

4. The KramKraft Classification Worksheet

Here is this post's artifact in full: classification-worksheet.md, version 1, dated 2026-09-08 — the single table that consolidates the seven steps above so that someone who was not in the process can read it and audit it. Copy the skeleton straight into your own system. Any row you cannot fill means the corresponding step is not actually done.

This one-page worksheet is the inheritance the coming posts pick up immediately: the manifest line will grow into a full release manifest, the 40-case golden set will become the spine of the validation harness at the end of the series, and the four obligations in the last row are what posts #2 through #10 will build, one piece at a time, until complete.

5. Validation Check — Audit Your Own System

The paper's rule, which I will use to close every post in this series: every answer must point at an artifact that actually exists, never at a reassuring adjective^[1]. This table is post #1's exam — walk it row by row against your own system. Pass means the artifact can be opened and inspected; fail means it does not exist, or exists with its dates in the wrong order.

If any row fails, do not move on to post #2 yet — especially rows 5 and 6, because a broken timeline there makes every remaining number tell a story that sounds good and proves nothing, and it will haunt every remaining post of the series.

6. The Road Ahead

This post answered a single question, but answered it all the way down: does your system genuinely have AI at its core — via a two-condition definition, two measurable axes, the predeclare-before-selecting rule, and a worksheet that ends in one of four quadrants with its governing obligation attached. That one page changes the governance conversation from "how much AI do we use?" to "we sit in this cell, because of this evidence, and our obligations are this list".

What this post deliberately did not answer is the entire next panel of questions: how to build the full envelope Nong Kram now owes — where hard mediation sits, what semantic evaluation measures, what a trace must retain to count as complete, and what a risk-proportionate fallback looks like. All of that is the assurance envelope, and it is the subject of the rest of the series. Before it can be built, you need to see why classical engineering does not hold here — the next post, #2 Software 1.0 · 2.0 · 3.0, is about the three eras of software that did not replace one another but stack as layers inside a single system — Nong Kram's own call path already carries all three layers, though the team does not know it yet.