# Execution — ORCHESTRATED · context **Everyone whose setup looks like this should read this file.** One agent, deep structured knowledge. The effort has gone into what is written down and how it resolves, not into running many things at once. You are building now. Read the four files the interview wrote before you touch anything. --- ## Read first /CONTEXT-MAP.md what loads, what fires, what costs /INTERVIEW.md what they said, marked measured or stated /TIER.md the tier and the three dimension scores /DECISIONS.md what has already been settled If any is missing, stop and say which. Building from a partial record is how you produce something that contradicts a decision already made. --- ## The gate — the thing that makes this durable **The gate is the mechanism by which the school reaches this person's agent WITHOUT them remembering it exists.** A module they have to remember is a module they will not use. Present your options ranked, with **exactly one marked RECOMMENDED** and one line of why each. Then build the one they choose. 🔴 **The bar: if they accept every recommendation without reading, they end with a working system.** That is what separates a recommendation from a menu with a default. For this tier, rank the options against what `CONTEXT-MAP.md` shows they actually have. Do not offer a mechanism their harness does not support, and say so if the obvious one is unavailable here. --- ## What to build Every tier gets at least these three, and they are the minimum rather than the target: **A way to run a module.** Given a module URL, fetch it, extract the prompt for this harness, prepare whatever it needs, and hand it over ready to run. **A record of what has been run.** One row per module: which, when, what artifact it produced and where that artifact lives, and **what changed as a result**. 🔴 **The last column is the one that matters. A row marked done with nothing in the what-changed column is a module that was not completed** — and the record should make that visible rather than let a tick hide it. **A way to learn a new module exists.** The school adds modules. Something must re-check. Do not build a background process for this — a check that runs when they next work is enough, and a daemon is a thing that breaks silently while continuing to look healthy. --- ## What closes this tier's gaps - **a fact's trust does not improve by passing through a model** — derivation launders provenance unless something forbids it - **a missing key logs a gap, never a guess** — fail-closed resolution is the whole difference from a wiki Build toward these where the interview showed appetite. Where it did not, say so and leave them — building against a gap the person does not have is how a durable system becomes an abandoned one. --- ## Prove it fires — both tests, always Do not report that the gate works. Show it: say a sentence that SHOULD trigger it → it fired say a sentence that should NOT trigger it → it stayed quiet 🔴 **A gate that fires on everything is as broken as one that fires on nothing, and only the negative test catches it.** If either fails, fix the description and run both again. Then verify the rest against reality: the tracker's paths resolve to files that exist, and the always-on cost in `CONTEXT-MAP.md` matches what the harness actually loads now that you have added to it. --- ## Finish Every file created, its path, and the two test results with their real output. Append to `DECISIONS.md`: what you recommended, what they chose, and what you did not build. Then stop.