Context Is a Control Artifact — บริบทคือส่วนหนึ่งของโปรแกรมContext Is a Control Artifact — Version It Like Source Code

🤔 If your vendor silently upgrades the model to a new version tonight — while your prompt, your corpus and your code do not change by a single character — is the system you maintain still "the same system" tomorrow morning?

The previous post, The AI-OS Mental Model, closed on five seams where the classical guarantees break — weights return a sample rather than a fixed value, the context window is RAM with no memory protection, retrieval has no stable read contract, tool calls are "requested" in natural language, and agents carry no built-in privilege separation. The question I left hanging was this: if the things we pour into that RAM — the system prompt, the passages retrieval brings back, the tool descriptions, the conversation history — determine system behaviour to that degree, what exactly is their engineering status: documentation? Config that ops can tune at will? Or program? The paper answers plainly and answers one way: it is program.^[1]

The whole post's answer fits in one equation and one sentence. The equation is the paper's equation (1): Y ~ P(· | M_v, D, C, R, T, K, S, E) — the behaviour a user sees is distributed conditional on eight terms jointly, not on the model alone and not on the prompt alone. The sentence is: a change to any term of (1) is a change to the program. The work of context engineering is therefore not the art of choosing words in a prompt but the engineering discipline of making every term identifiable, versioned, reviewed, and released together in a single release manifest. In this post we walk seven steps to KramKraft's first manifest, plus the skeleton of a context-assembly function that forces the whole system down to exactly one path that can produce context.

1. One Equation That Says Where Behaviour Comes From

This section's conclusion fits in one sentence: the output of an AI-core system is not distributed according to "the model" but according to the joint condition of eight terms, and context is only one of them — special because it is reassembled on every request by our own code. The paper writes it as equation (1):^[1]

Y ~ P( · | M_v, D, C, R, T, K, S, E )        ...(1)

C = A(q, R, T, S; θ_A)

The phrase context engineering is not new — Karpathy described the engineer's leverage moving to runtime context in his 2025 talk^[2] — but what the paper adds is the stiffness the phrase needs to carry engineering weight: enumerate the terms completely, define each one precisely, and attach the version-control obligation to every term equally. For a developer maintaining a real system, these eight terms are not floating symbols — every one of them points at something tangible in the KramKraft system:

C is not a string anyone types — C is the output of a function

The second line of the equation matters more to daily work than the first. C = A(q, R, T, S; θ_A) says that the context the model sees on each request is the output of assembly code A, which takes the user's question q, the retrieval results, the tool descriptions and the session state, under the parameters θ_A — the template in use, the maximum number of passages, the number of history turns attached, the order the blocks are laid in. If today your system concatenates prompt strings at five places in five handlers, you do not "not have an A yet" — you have five invisible A's with no name, no version, and no reviewer.

The corner people miss most often is treating θ_A as a technical detail, when it is program to exactly the degree the template is: change max_passages from 6 to 12 without touching a word of the prompt, and what the model sees changes, the distribution of Y changes, and the behaviour your customer meets changes — all of it while not one line of "the prompt" has moved.

Context evidence is bound to the model that gives it meaning

The deepest point of equation (1) hides in its own shape: C stands beside M_v and D inside the same conditioning bar. The paper's conclusion is that context cannot be interpreted independently of the model that gives it semantics — hold C fixed to the last character and change M_v or D, and the distribution of Y changes immediately.^[1] The sentence "we tested this prompt" is therefore a joint claim about the whole tuple (C, M_v, D, R, T, ...), never a claim about C on its own — and context evidence is not portable across model versions: a prompt that passed your test suite on M_v1 has no evidence at all on M_v2 until that suite is run again.

This is the answer to the question that opened the post: the night the vendor silently upgrades the model, the term M_v changes — your system became a different program before you woke up. Every piece of evidence you had collected is now evidence about the old program, and no diff tool in your repo sees the change at all, unless you pinned the version and recorded it yourself.

💡 My view: I have stopped using the phrase "a good prompt" without context. A prompt shared on the internet has the status of a hypothesis — it once worked well somewhere, on some model version, under some decoding policy, over some corpus. Until you have run it through your own test suite, on your own (M_v, D, R, T), it carries not one piece of evidence in your system. The rule I use with my team is short: you can borrow a prompt, but you cannot borrow its evidence.

2. Every Term Is the Program — So Every Term Is Versioned

This section's conclusion: prompts, context-assembly code, retrieval configs, tool schemas, evaluation suites and model manifests all belong to the codebase — versioned together, reviewed together, released together — because changing any one of them is deploying a new version of the program. The reason is not tidiness. It follows from two observable rules the paper uses to separate "the things that determine behaviour" from "the props".^[1]

The two rules that make "control" an observable matter

• The control-surface rule — at least one released behaviour is materially determined by model output, as recorded in the decision trace — not as the team feels or a slide claims. An answer released to a customer counts, and an authorised tool call counts too
• The load-bearing rule — under removal ablation, replacing the model with the declared fallback drops task success on a fixed test set below a share that was predeclared — the model is not decoration; it carries real weight

Both rules come from the AI-core definition in the first post of the series, but their logical consequence lands exactly here: if model output really is a control surface, and the model really is indispensable, then everything that shapes that output — every term of (1) the team can edit — is also controlling the system's released behaviour. The paper compresses the obligation about as far as it can be compressed:

Prompts, context-assembly code, retrieval configs, tool schemas, evaluation suites and model manifests — all of it belongs to the codebase: versioned together, reviewed together, released together. A change to any term of (1) is a change to the program.^[1]

What goes into the repo — and what the code still holds

• Every prompt and template file — the system prompt, the few-shot examples, the answer template — ordinary files that can be diffed, not text boxes in a vendor console
• The context-assembly code — the function A together with the whole of θ_A: the chosen template, the passage count, the history-turn count — a config change to A changes behaviour exactly as a template change does
• The retrieval config — the corpus version id, the ranker's name and parameters, and the allow-list of accepted sources — the half of the term R that usually has no owner at all
• The tool schemas — a JSON Schema for every tool with its parameter ranges — documentation for the model and a checkpoint for the system, in the same file
• The evaluation suites — the golden set, the adversarial set, the deciding thresholds — because "it passed testing" is a claim bound to the version of the test suite as well
• The model manifest — the version-locked identifier of M_v and the decoding policy D — the two terms that live outside the repo by nature and therefore have to be pulled in by recording them

The paper's next sentence heads off the most common misreading precisely: these artifacts come to sit alongside the code, under exactly the same discipline, but they do not become the source code — the code still holds the control flow, the interfaces, and the mediation everything depends on.^[1] Do not read this post as an invitation to move logic into the prompt; the direction is inward — pull the things that floated outside the discipline in under the discipline of code. The same expectation appears in the NIST AI RMF in governance language: the components that determine an AI system's behaviour should be inventoried, documented and traceable across the lifecycle.^[4]

One image is all I want you to carry out of this section: Friday afternoon, someone on the team opens the vendor's dashboard, edits two sentences of the system prompt right there, and hits save — no branch, no PR, no review, no rollback, and no trace in git. In the language of equation (1), that event edited the term C of the production program and deployed it instantly, straight over the head of every gate the organisation ever built.

3. The Seven Steps

This post's seven steps walk from a term-by-term inventory to the first release manifest. Each step ends with an artifact that can actually be committed to the repo, not a meeting resolution. Every number in the example (the 2,000 THB limit, top_k = 6, the seed) is a tutorial number I set for KramKraft — not a value the paper recommends and not universal advice.

Step 1 — Inventory the eight terms of your system, with current value and location

Open one file and answer two questions per term: what is the current value, and where does it live. Work through all eight. The truth that tends to surface when you actually do it: some terms nobody on the team can answer — the ranker runs on vendor defaults nobody ever read, the real system prompt lives in a dashboard rather than the repo, nobody is sure whether the model identifier is version-locked or an alias. An inventory with "unknown" cells is an honest inventory, and those cells are the entire work list for the steps that follow.

# terms.yaml — the eight-term inventory of equation (1) for KramKraft (pre-cleanup state)
M_v: "hosted-llm @ ???"                  # lives: vendor console — version lock not yet confirmed
D:   "temp=0.3 (set by whom? when?)"     # lives: scattered across two API-call sites in the code
C:   "string concat in handlers"         # lives: chat.py, faq.py, escalate.py — three sites!
R:   "corpus=policy/+catalog/"           # lives: a storage bucket — no version id; ranker = default
T:   "refund"                            # lives: schema written inline in code, no version number
K:   "chat loop + 2 retries"             # lives: app/loop.py — the only part fully in the repo
S:   "history 10 turns + customer id"    # lives: session store
E:   "order store, time, language"       # lives: never recorded into any trace at all

Step 2 — Collapse context assembly into one real function

Write A as a real function with a real name and a signature that matches the equation: it takes q, the retrieval results, the tool set, the session state and θ_A — and returns one context plus its supporting evidence. There is only one rule and it must be absolute: any code that wants a context calls this function, and not one line of prompt string-concat survives anywhere in a handler — because every shortcut left standing is another A that nobody versions. For KramKraft this means collapsing the three sites in chat.py, faq.py and escalate.py into one — the full skeleton is in section 4.

# app/context.py — the only path in the system that can produce context
def assemble_context(q, retrieval, tools, state, theta):
    """C = A(q, R, T, S; θ_A) — returns (context, evidence record for the trace)"""
    ...

Step 3 — Pin the model and the decoding policy

M_v must be a version-locked identifier, never a floating alias like "latest" that the vendor can slide underneath you, and D must be recorded completely: temperature, top_p, seed, max_tokens. Remember the lesson from the previous post: deterministic decoding removes sampling variance but does not remove version sensitivity^[1] — so the seed is not a talisman of correctness; it is the minimum condition that makes replay and debugging possible. If your vendor offers no genuinely lockable version, record that limitation in your risk register instead of pretending to forget it.

// config/model.json — the terms M_v and D in one file, versioned in the repo
{
  "core": { "provider": "hosted", "model": "hosted-llm",
            "version": "2026-08-14", "alias_allowed": false },
  "decoding": { "temperature": 0, "top_p": 1,
                "seed": 20260901, "max_tokens": 700 }
}

Step 4 — Snapshot the corpus and the retrieval config

The term R has two halves and both must be pinned. The first half is the corpus: put policy/ and catalog/ in git, and make every state the system ever answered from addressable by a single id (a git tag, for instance) — edit one paragraph of the return policy and that is a new corpus version, which is a new system version. The second half is the retrieval config: the ranker's name, its parameters, and how many passages are drawn — everything that used to be a vendor default becomes a declared value in a file, readable and diffable.

# retrieval.yaml — the half of the term R that usually has no owner
corpus_snapshot: "kramkraft-corpus@2026-09-05"   # git tag of policy/ + catalog/
ranker: "bm25"
ranker_params: { k1: 1.2, b: 0.75 }
top_k: 6
source_allow_list: ["policy/", "catalog/"]       # accepted passage origins

Step 5 — Declare tool schemas as versioned artifacts

KramKraft's term T holds a single tool, but one whose effect is real and irreversible from the moment the payment processor accepts it: refund. Declare its schema as a JSON Schema file separate from the code — types, patterns, parameter ranges, closed with additionalProperties: false. This one file does two jobs at once: it is the description the model sees, and it is the checkpoint of hard enforcement that post #8 will plug into the execution rail. Today's work is only to make it a file, give it a version number, and make it diffable.

// tools/refund.schema.json — v1.0.0 (the limit is a tutorial number)
{
  "$id": "tools/refund.schema.json", "version": "1.0.0",
  "type": "object", "required": ["order_id", "amount", "reason"],
  "properties": {
    "order_id": { "type": "string", "pattern": "^KK-[0-9]{6}$" },
    "amount":   { "type": "number", "minimum": 1, "maximum": 2000 },
    "reason":   { "type": "string", "maxLength": 200 }
  },
  "additionalProperties": false
}

Step 6 — Move prompts into the repo, and make a prompt PR a program PR

Move every prompt and template out of the dashboard and out of in-code strings into files under prompts/, then bind a reviewing owner through CODEOWNERS exactly like any other module. The definition of done for this step is precise: changing one word of the system prompt must travel the same path as changing one line of a function — a diff, a reviewer who understands both the brand's voice and the behavioural consequence, a rollback point. From here on, the history of every phrase the system ever used with a customer lives in the git log, not in one person's memory.

prompts/
  system.th.md          # Nong Kram's voice, task scope, prohibitions
  system.en.md
  templates/answer.j2   # the answer scaffold A uses when assembling context

# CODEOWNERS — a prompt is program, so it has a reviewing owner like program
prompts/  @kramkraft/assistant-team

Step 7 — Assemble the release manifest that pins every term with hashes

The final step gathers the outputs of steps 1–6 into one file: whatever is a file in the repo → store its hash; whatever is a corpus → store its snapshot id; whatever is an external service → store its identifier and locked version. The acceptance test for this step is the one question an ops team should answer in ten seconds: "what is production running right now?" — and the answer must be a single file that names every term, not a tour through five systems.

$ shasum -a 256 prompts/templates/answer.j2     # → a41f...9c2e
$ shasum -a 256 tools/refund.schema.json        # → 03e8...77b1
$ git rev-parse --short corpus-2026-09-05       # → 7d3b1a2
# all values flow into release-manifest.json — the full file is in section 4

4. The KramKraft Artifact — release-manifest v1 and assemble_context()

These are the two artifacts this post leaves behind for the KramKraft system, and the base every later post in the series builds on. The manifest's fields match the list in the paper's conformance profile (§6.1): the core with its decoding policy, the context-template hash, the corpus snapshot with its provenance policy, the tool-registry hash, the control profile with thresholds, and the evaluation-suite hash.^[1] The last two fields are placeholders on purpose — the contract and its thresholds are post #7's work, and the golden set with the evaluation-suite hash is post #9's — a declared gap is better than no field at all, because a declared gap collects on itself.

release-manifest v1 — in full

// release-manifest.json — kramkraft-release-2026-09-08-r1
{
  "manifest_id": "kramkraft-release-2026-09-08-r1",
  "task_set": "customer-support-th: order, product and refund questions",
  "core": {
    "model": "hosted-llm",
    "version": "2026-08-14",
    "alias_allowed": false,
    "decoding": { "temperature": 0, "top_p": 1,
                  "seed": 20260901, "max_tokens": 700 }
  },
  "context_template": {
    "path": "prompts/templates/answer.j2",
    "sha256": "a41f...9c2e",
    "assembler": "app/context.py::assemble_context",
    "theta_A": { "max_passages": 6, "history_turns": 10 }
  },
  "corpus_snapshot": {
    "id": "kramkraft-corpus@2026-09-05",
    "provenance_policy": "accept passages from policy/ and catalog/ only"
  },
  "tool_registry": {
    "sha256": "03e8...77b1",
    "tools": [ { "name": "refund",
                 "schema": "tools/refund.schema.json",
                 "version": "1.0.0" } ]
  },
  "control_profile":  { "status": "PLACEHOLDER — post #7: contract + thresholds" },
  "evaluation_suite": { "status": "PLACEHOLDER — post #9: golden set + hash" }
}

The manifest's requirement language I borrow directly from RFC 2119, following the paper's conformance profile: every release MUST reference a manifest whose every non-placeholder field is filled; changing any hashed file MUST produce a new manifest version; and the system SHOULD refuse to start when a freshly computed hash disagrees with the manifest.^[3] These verbs are not ornament — a violated MUST fails conformance outright, while a SHOULD may be deviated from only with the reason recorded in writing.

The assemble_context() skeleton — one path, with evidence built in

# app/context.py — KramKraft's C = A(q, R, T, S; θ_A)
import hashlib

def assemble_context(q, retrieval, tools, state, theta):
    """The only path in the system that produces context — returns context plus evidence."""
    passages = retrieval.search(q, top_k=theta["max_passages"])
    for p in passages:                      # provenance is post #8's guard
        assert p.source in retrieval.source_allow_list
    ctx = render(theta["template"],
                 system=load_prompt("prompts/system.th.md"),
                 question=q,
                 passages=passages,
                 tools=tools.public_schemas(),
                 history=state.last_turns(theta["history_turns"]))
    record = {                              # the decision trace for the term C
        "manifest_id": theta["manifest_id"],
        "context_sha256": hashlib.sha256(ctx.encode()).hexdigest(),
        "corpus_snapshot": retrieval.snapshot_id,
        "passage_sources": [p.source for p in passages],
    }
    trace.append("context_assembled", record)
    return ctx, record

This skeleton does three things that text inside a prompt cannot do for itself. One, it enforces the single path — the string-concat sites that used to live in three handlers are dead. Two, it collects evidence on every run: the hash of the assembled context, the corpus version, and the origin of every passage flow into the decision trace with nobody having to remember. Three, it makes replay genuinely possible: the same request with the same manifest must yield the same context byte-for-byte — which immediately becomes one of the key rows of the validation check below.

💡 My view: I treat the manifest as the unit of deployment, not an attachment. The test is two sentences, and they work every week, not only on launch day: if the diff between two releases moves no value in the manifest, you did not change the system; and if the system's behaviour changes while the manifest did not move, some term of (1) is still off the books — and that second sentence is the most valuable alarm the manifest gives you for free.

5. Validation Check — Audit Your Own System with Artifacts

The same rule as every post in this series: a "pass" must point at an artifact, not at confidence. Walk this table against your own system — any row whose artifact does not yet exist is this week's backlog, not next quarter's.

Notice that not a single row asks "are the system's answers good?" All seven rows ask only whether the system is identifiable. That is not an accident — it is the boundary this post is responsible for, and the boundary that has to be finished before the quality question can even mean anything.

6. The Road Ahead

If you take exactly one thing from this post, I would pick the change of question inside the team: from "who edited the prompt?" to "which release changed which term of (1)?" The first question sees the system as a model plus decorations. The second sees it as an eight-term program in which every term has an owner, a version and a history — which is what it always was; the ledger simply had never been written.

Three pieces of work can start this week, ordered from cheap to expensive. One: write your own system's terms.yaml inside an hour — its value lies in the "unknown" cells it forces you to write down. Two: collapse the context-assembly paths into one function — the most painful job of the three, and the one that unlocks the replay row of the validation check. Three: negotiate the real system prompt out of the dashboard and into the repo, one file — row 6 of the table changes status immediately, and the team gets to see with its own eyes what a prompt PR looks like.

What this post does not answer — deliberately — is the question that comes next: even with every term pinned, every hash matching, every replay byte-for-byte, the core standing in the middle of the equation still errs — fluently, and with complete confidence. The manifest makes the system identifiable; it does not make it right. Designing on the assumption that the core is a savant that fails — able to fabricate facts, uneven in skill, unable to remember, easily led, and confident out of proportion to the truth — is the whole of the next post.