Context — จัดบริบทเป็น dependency ที่มีรุ่นTreat Context as a Versioned Software Dependency

1. The engineering problem

Programmers understand dependency drift in libraries. AI behavior also depends on context: selected instructions, retrieved files, tool results and source revisions. If a requirements document changes while the model version stays fixed, the resulting patch can change. Treat the assembled context as an input artifact with an identity. The companion uses one reviewed pricing specification so the relationship is easy to inspect before introducing retrieval infrastructure.

assemble_context constructs named fields for the untrusted task, reviewed skill, evidence, evidence hash and policy. The evidence identifier is pricing-spec-v1. The issue cannot supply a file path that the host then reads. The manifest records the context hash alongside policy and question hashes. This is provenance, not trust by hashing: a hash can show that bytes match a recorded snapshot, but cannot establish that the original requirement was correct or approved. Review the source before recording its identity.

2. The boundary to design

In a real repository, retrieval should enforce permissions before selecting passages, pin the base commit and retain source locations. A search hit is relevant text, not an instruction with authority to change policy. Keep the amount of context bounded and explain why each source is present. TypeSafe's state documentation recommends explicit structured state [1]. The architectural addition here is a reproducible evidence snapshot and a separation of task content from the host's authoritative rules.

3. Read the implementation

Implementation excerpt from the companion. Run the complete lesson below with its imports and fixtures.

def assemble_context(request):
    # A reviewed, fixed snapshot for the tutorial; no issue-provided file paths.
    spec = {"id": "pricing-spec-v1", "text": SKILL["requirements"]}
    return {"task": request["issue"], "skill": SKILL, "evidence": spec,
            "evidence_hash": digest(spec), "policy": POLICY}

def digest(value):
    raw = json.dumps(value, sort_keys=True, ensure_ascii=False, allow_nan=False)
    return hashlib.sha256(raw.encode()).hexdigest()

A useful failure drill changes the requirement from floor rounding to nearest-cent rounding without changing the model. The context hash must change and the trusted behavior cases must be reviewed. Reusing the old result or evaluation report is now an invalid comparison. This is why a model name alone cannot identify an AI release. The tutorial hashes its small objects directly; production releases also need immutable storage, access control, retention rules, and a manifest that identifies the application revision, generator, retrieval configuration and evaluation dataset.

4. Compare the outcomes

The following output comes from scripted fixtures that verify architecture behavior. It is not a measurement of live Jev accuracy, latency, or cost.

{
  "evidence": {
    "id": "pricing-spec-v1",
    "text": "Integer cents; subtract percent; floor to cents; no I/O."
  },
  "snapshot": "8b5a62915a854dc948283a89b3dce60b4cac90b38f11d3ad1884a0980a40b519",
  "policy": "draft-only-v1"
}

5. Run, break, and explain

Part 09 code · Implementation · Tests: test_reproducible_manifest · Exercise

git clone https://github.com/Anirach/ai-core-engineering-workbench.git
cd ai-core-engineering-workbench
git checkout 18cdfcd4156d3d02acb8badf3b3a0a823113e0ed
python3 -m workbench.lesson 9
python3 -m unittest tests.test_boundaries.BoundaryTests.test_reproducible_manifest -v

Your turn

Change one requirement sentence and show the context hash changes. Decide which behavior tests must change and which must stay invariant.

Keep three artifacts: the input you tried, the resulting state and reason, and an explanation of which boundary owns that result. Do not change an expected result merely to make a test pass.

6. Sources and limits