Typed artifacts for agentic product development

Agentic runtimes are completion-driven: they read whatever they find in a workspace, treat much of it as instruction, and invent what they cannot find. That behavior is a capability in a single session and a liability across many. This paper proposes a small type system for the artifacts a product team keeps around its work: ten classes defined by three attributes, with one central rule — authority derives from an artifact's class, never from its content. Three of the classes carry spec authority at nested scales (the promise that is honored, the thread that closes, the move that lands), and the split of ownership between them lets autonomous execution be both safe and useful. The design yields a mechanical injection boundary, a complete promotion trail, deterministic context assembly, and a learning loop that survives pauses, resumptions, and high agent volume. It is drawn from small-team practice and offered as a working hypothesis, not a proven method.

The problem: ambiguity, agents, and authority

Product development is the continuous effort to convert ambiguity into value. A team's work can be pictured on two axes: how clear an idea is, and how committed the team is to it. Ideas hatch vague and uncommitted; shaping raises their clarity; commitment gives them standing; execution converts them into shipped capability.

Two thresholds structure the plane. Work must clear both to be worth building. Work that is committed but unclear sits in a danger zone where time and resources burn.

Figure 1. The clarity–commitment plane. Product development is the continuous motion of ideas up and to the right; the thresholds define what an execution system may pick up.

Agentic runtimes raise the stakes in a specific way. Tools like Claude Code are completionists: given an ask, they drive toward something that satisfies it: filling gaps in the specification, exploring the workspace for anything that resolves ambiguity, and, where nothing is found, inventing.

Exploration is a capability, but a downstream one. The agent reads the README, discovers instruction files, and greps the code not because roaming is its job but because whatever it finds reduces its uncertainty about what "correct" and "done" mean. So it grants standing to whatever it finds.

Discovery-as-authority is less a designed architecture than the emergent behavior of a completion drive set loose in a workspace. In a single session it mostly works. Across many sessions it degrades predictably:

Stale instruction files silently steer agents against current intent — a completionist prefers a stale answer to no answer.
One agent's generated prose mints rules for the next agent's run.
Any writable file in the workspace becomes a channel for injecting behavior.
Where the workspace answers nothing at all, the gap is filled by confabulation.

At high agent volume, where agents author most of the text that agents later read, the feedback loop of unratified instruction compounds.

The failure has a precise shape: these systems conflate the information channel with the authority channel, because the completion drive makes no distinction between them: anything that fills the gap gets treated as if it belongs there. What the agent actually needs is three different things:

Freedom — to roam across everything the team knows;
Obedience — owed only to what the team has deliberately decided;
Grounding — enough evidence within reach that gaps are filled by citation rather than invention.

The design below delivers all three by design: evidence stays open to roam, ratification alone fixes what commands obedience, and typed context assembly supplies the grounding, so the completion drive cites instead of inventing.

The baseline: a repo, issues, markdown, and an agent

The most popular alternative to this design is not a heavier process but a lighter one, and many teams working with agents are already running it: a repository, an issue tracker, freeform markdown, and Claude Code. It works, and the reason it works is where this design starts.

It works because a human supplies the type system at read time. Reading a README, you classify without effort: this paragraph is aspirational, this one is stale, this is a rule the team means, this is a note nobody ever ratified. The classification exists and the team runs on it; it just lives in heads and team memory rather than in the artifacts. Freeform tools are not untyped systems. They are typed systems whose labels are stored in wetware.

Seen that way, the baseline is already a knowledge system, with exactly one authority rule: whatever is in the repo binds. A CLAUDE.md is a policy set with no ratification act. The issue backlog is a desire pool with no commitment gate. TODO comments are moves with no verification. Every class in the table that follows is present in the baseline, stored in two unlabeled containers. So this paper does not propose a different kind of thing. It proposes the same thing with gates installed on the authority channel: moving labels that already exist out of heads, where agents cannot read them, into artifacts, where they can.

Issues, in particular, keep their seat. An issue is excellent capture — permalinked, timestamped, threaded — and that is the seat it holds here. What strains an issue is being asked to be a desire, a commitment, a plan, and a discussion in one noun; the spec triad later in the paper exists to relieve that. Keep the issues; stop asking them to be promises. The same holds for adoption generally: a team's tracker and documents already contain every class this paper describes, so adopting the system is an act of ratifying labels, not migrating data.

The trade also runs the other way. This design abandons the traditional work-item apparatus as well: no sprints, no story points, no burndown, no epic hierarchy — ten classes and a handful of verbs. And nearly everything stays freeform. Slack threads, markdown documents, transcripts, and notes remain untyped, because they are evidence, and evidence needs no discipline. The type system governs only the small canonical set that binds, guides, or tasks. Structure at the authority and commitment joints; freedom everywhere else.

A note on provenance, finally. This design grew out of small-team practice, in the baseline setup described above, as agents took on a growing share of the reading and the writing. It is a working hypothesis with one team's experience influencing it, not a proven method. Nothing here claims that freeform practice fails; the paper describes what one team reached for when the labels in its heads stopped being readable by the agents doing the work.

Foundations: three attributes

The system rests on classifying every artifact along three independent dimensions.

Type of utterance

Artifacts differ in what kind of utterance they are. The classification is borrowed from speech-act theory: Austin's observation that saying something is often doing something (How to Do Things with Words, 1962), and Searle's taxonomy of the kinds of doing (1975). Three of the four types here are Searle's; records are an addition the append-only layer needs.

Assertive — a truth-apt claim about the world: metrics, as-built descriptions, reproduced bugs. Assertives can be wrong, and they can go stale.
Directive — an action-guiding rule: a standing conditional of the form "when X, do Y." Followed or violated, never true or false; statements about the world merely plug into its trigger clause.
Commissive — a commitment: fulfilled, broken, or withdrawn.
Record — a claim about what happened: append-only, and never stale, because the past does not change.

Derivation level

Artifacts also differ in how processed they are, in a pipeline familiar from data engineering. Derivation level largely determines volume and loading behavior.

Raw — high-volume and uninterpreted: threads, tickets, transcripts, exports. Retrieved on demand, never loaded wholesale.
Derived — extracted and shaped; every derived artifact cites the raw material it came from, so a reader — human or agent — can descend and verify. Loaded filtered.
Canonical — the small, curated, authoritative surface: the current policy set, the active promises, the open threads, the verified facts. Always loadable, because it is kept small.

Authority

The third attribute is what an artifact is entitled to do to an agent's behavior. It is enforced by the harness, not the agent runtime, and the distinction matters here. The runtime (Claude Code and its kin) is the completionist inside the loop: it weighs whatever enters its context roughly equally, and it cannot be trusted to police what binds it. The harness is the system wrapped around the runtime: it assembles context, dispatches runs, and verifies outcomes, and it is the only place authority can be enforced. Four levels suffice.

Constraint — binds. The agent cannot proceed past it, and the harness enforces it mechanically.
Guidance — biases judgment without blocking.
Spec — defines an outcome and what counts as reaching it — never the steps to take. Three classes carry it, at three nested scales, with three distinct completion predicates.
Evidence — informs. Consulted and cited, never obeyed.

Of the three attributes, authority is the one that is directly a security property:

Content never carries authority; only classification does. A document that says "always do X" is evidence that someone wrote that — nothing more — until someone with standing ratifies it into a class that binds.

This single rule is the prompt-injection boundary. Raw material is full of imperative-sounding text, and the system makes it structurally impossible for that text to bind an agent, no matter where it appears — a Slack message, a README, a comment in generated code.

A qualification — once text is inside a context window, no harness can mechanically control how a model weighs it; a hostile instruction in a capture can still influence the session that reads it, and the separation of channels relies in part on prompt discipline and on the runtime honoring it. What the classification makes structural is the boundary around a session, not the model's behavior within one: unratified text never enters the compiled authority preamble, hard guards do not care what the model believes, verification does not accept a deceived agent's claims, and nothing a session was talked into can ratify itself into the knowledge layer. Injection can still bend a single run. It cannot mint durable authority or compound across sessions, which converts a persistence problem into a bounded, per-session one.

The artifact classes

The full cross-product of the three attributes yields dozens of cells, most of them incoherent. The ten discrete combinations below are the ones that have recurred enough to highlight.

Class	Utterance	Derivation	Authority	In one line
Capture	record	raw	evidence	Immutable observation: threads, tickets, transcripts, exports, run exhaust
Fact	assertive	derived / canonical	evidence	Cited, dated claim about the world; its strength follows what it cites
Desire	commissive embryo	derived	evidence	A shaped want with explicitly no standing
Promise	commissive	canonical	spec	Durable commitment — "X is true for Y"; honored or broken, never "done"
Thread	commissive	canonical	spec	Episodic execution arc opened against a drift; done-when defines closure
Move	commissive	derived	spec	Agent-owned plan atom: one verifiable assertion; lands when its check passes
Policy	directive	canonical	constraint	Mechanically enforced rule; one current answer per question
Principle	directive	canonical	guidance	Advisory value; violation is a conversation, not a blocked merge
Decision	record	derived	evidence	Append-only entry logging a promotion, ratification, or ruling
Storyline	assertive	derived	evidence	Correlation: asserts that a set of artifacts is one line of product-making

The authority column collapses to something legible: one class binds, one guides, three task at nested scales, and everything else (the great majority of artifact volume) is evidence, structurally incapable of directing an agent's behavior. It can inform a run, never steer one. Figure 2 shows the classes in their zones.

Figure 2. Zones and authority. Managed artifacts and the capture layer sit inside the knowledge system; entities sit outside it, reachable by name only. Border treatment encodes authority.

The spec triad

The three spec-carrying classes resolve a failure that afflicts nearly every product artifact stack — call it the single-noun problem. Teams need a middle layer that is durable enough to plan against and stable enough to represent a commitment, yet also granular enough to organize execution and episodic enough to have a start and an end. Those are different things. Every noun asked to be both — the Epic, the Initiative, the Workstream — ends up state-shaped in some sentences ("the search capability") and motion-shaped in others ("the search overhaul"), a commitment and an arc at once, neither clearly.

The solution is to split the noun, and this system splits it twice:

Promise — state-shaped and durable: "X is true for Y." Honored or broken on a continuing basis; never completed.
Thread — motion-shaped and episodic: an execution arc opened against a specific drift. It carries done-when criteria — observable conditions on the environment that mean the drift is gone — and closes when they verify.
Move — the plan atom inside a thread: a single declarative assertion ("an index exists on the column," "the regression test passes") with a check that verifies it landed.

Collapsing promise into thread produces the Epic. Collapsing move into thread produces a subtler failure: acceptance criteria and plan steps interleaved in one list, so that revising the plan means touching the definition of done.

Keeping the three apart yields three distinct completion predicates: honored-when (evidence criteria, re-derived on a cadence), done-when (drift-closure conditions, fixed at open), and landed-when (one verifiable assertion per move). It also yields a clean ownership split. Done-when is human-ratified, because it is the edge of the commitment. The move plan is agent-owned: an agent may propose, reorder, replace, and abandon moves freely, because closure never rests on the plan, only on done-when verifying in the environment.

This split is why autonomy and safety stop trading off against each other. An agent with no plan authority pushes its planning into ephemeral session files; an agent with done-when authority can define its own success. The triad gives it the middle.

Notes on the evidence classes

Desire — "No standing" sounds bureaucratic; it is the mechanism that keeps the backlog from lying. Most ideas — including verified bugs — never get built; a desire gives them a place to wait without pretending they are scheduled. Commitment (turning a desire into a promise, or opening a thread) is a human act, or the act of a role explicitly delegated commit authority, because commitment is where accountability lives.
Policy — carries current-set semantics: for any question it answers, exactly one active answer exists at any time. "What applies now" is never an exercise in parsing timestamps across a decision history.
Decision — points at what it created rather than containing it. The classic architecture decision record is one species: a ruling bundled with its rationale, while the live rule it produced stands alone in the policy set.

The storyline is the class most easily mistaken for a container. The citation graph among artifacts already connects everything implicitly; what it cannot say is where one story of product-making ends and another begins. That boundary is a judgment someone asserts, which is why a storyline is an artifact rather than a computed view. And despite the shared root, a storyline is not an agile story grown large: a story is a unit of work with a definition of done; a storyline is the correlation among many units of work, and it has neither.

The storyline is the durable home for the fragments the work actually consists of: the Slack threads, the bug reports, the telemetry exports, the threads that came and went. Its defining property is that it outlives any piece of work: a fix closes; "checkout reliability" never does. Two constraints keep it from decaying into a hierarchy:

A storyline references its members and never owns them. Membership is many-to-many — a bug can belong to "checkout reliability" and "the Q3 release" at once.
A storyline has no lifecycle authority. Threads close, promises are honored; the storyline merely goes dormant. A dormant storyline is where an abandoned good idea returns, and where a resumed effort starts warm.

The test that separates storyline from thread: if it should stop existing when verification passes, it is a thread; if more related work will obviously come afterward, it is a storyline.

Evidence and the world: captures and entities

The word "source" collapses three different things (the provenance of information, source code, and data-emitting systems), and the collapse causes design confusion. The system separates two categories with opposite semantics on nearly every axis:

Capture — something that happened, frozen at the moment of observation: a Slack thread as ingested Tuesday, a bug report as filed, a session transcript, a metrics export, a Git commit. Immutable by nature rather than by policy; never stale, because the past does not change; cited by content.
Entity — something that persists and changes: a running service, a repository at HEAD, a customer, a third-party API. Outside the system's custody; named rather than cited; any description of one begins decaying the moment it is written.

The relationship between the categories is generative: entities emit, the system captures. The test: if it can change after you look at it, it is an entity; if it cannot, it is a capture.

Figure 3. Entities emit; the system captures. Facts are the connective tissue: they name entities, cite captures, and carry the verification dates that track decay.

Why hold captures at all? A cache is the wrong model: a cache implies the original is authoritative and the copy disposable, and captures invert that. Slack retention expires, logs rotate, dashboards recompute, tickets get edited — the copy inside the system is the evidentiary record, often the only durable one. This is custody, not caching: closer to how a court treats an exhibit than how a CDN treats an object.

Nor is every capture a slice of something external. Session transcripts and harness events are born inside the system with no original elsewhere. The class is defined by the properties the evidence layer needs, not by where its contents came from.

A tempting version of this layer makes custody an admission rule: a fact may cite only what the system holds or what carries delegated immutability, and a bare URL does not qualify. That strictness is theoretically clean and practically an adoption cliff — teams live in tools whose contents cannot all be ingested, and a system that refuses to record "the dashboard says X" records nothing. The rule here is a gradient instead:

The evidence strength rule: a fact's evidentiary strength follows the citability of what it cites — held bytes are strong, delegated immutability (a commit hash) is strong, a name (a URL, a ticket id) is weak. Citation is never forbidden; strength and staleness are derived from it, visibly.

The gradient preserves the incentive the hard rule was after, without the cliff. A fact citing a capture is trustworthy in a way a fact citing a URL is not, and the system says so in its quality scoring, staleness tracking, and context assembly, rather than refusing the weaker fact entry.

The gradient also gives a delegation test: Git commits are citable in place, because content-addressing supplies custody for free. A SaaS ticket ID is a name, because tickets get edited. Ingesting the ticket turns the name into a capture and the weak citation into a strong one, which is the action the gradient rewards.

Where the discipline stays strict is the boundary where strictness is free: exhaust born inside the system is always captured. Run transcripts, verifier output, drift reports, compiled context bundles: none has an external original, and none is costly to hold. A system that deletes its own transcripts while pleading custody principles for other people's Slack messages has its priorities inverted; the richest capture the system produces is the record of its own runs.

The two cases that most strain the "source" vocabulary come apart the same way. Source code is an entity with built-in capture semantics: the repository at HEAD (the living thing agents modify) is an entity, described by facts that decay; every commit is already an immutable, content-addressed capture. Facts about code cite commits; threads and promises target the repo.

Product signals split the same way: the telemetry-emitting subsystem is an entity; each ingested export is a capture; "p99 is roughly 340ms" is a fact naming the former and citing the latter. The staleness asymmetry follows: a fact wholly grounded in captures ("the July 3 export showed 340ms") never becomes false, while a fact about an entity ("the service's p99 is 340ms") starts decaying at birth. Only the second kind needs a verification date.

In short: cite the strongest evidence available, name what you must, and let strength be visible.

Promotion and the decision log

Artifacts change class through a small set of promotion paths, and every promotion is logged:

Extraction turns captures into facts.
Shaping turns captures and facts into desires.
Commitment turns a desire into a promise, or opens a thread against a drift — the crossing of the commitment threshold from Figure 1, made concrete as a gate.
Ratification turns a desire, or an incident's lessons, into a policy or principle.

The readiness criteria a thread must meet before opening (clear intent, verifiable done-when, a judgment gate where the intent is subjective) are themselves a policy about threads. That move turns the danger zone of Figure 1 into something a harness can lint: no intention enters committed state without passing the readiness policy, the same way no code merges without passing tests.

Below the commitment gate, one path is deliberately ungated: agents propose and revise moves freely within an open thread. The plan carries no authority over what counts as done — a move is ratified by landing, not by review.

Figure 4. Promotion paths. Gates sit on the crossings that mint authority; each promotion drops an entry into the decision log automatically. Move proposal, below the commitment gate, is deliberately ungated — moves are ratified by landing.

Urgency enters without breaking type discipline, through policies that connect artifact attributes to promotion speed: "sev-1 facts auto-shape to threads within 24 hours" is a ratified rule rather than an exception to the pipeline.

And because every promotion logs a decision, the log becomes the system's telemetry about itself. How long do desires sit before shaping? What fraction of threads get abandoned? Which policies are proposed repeatedly before ratification? These are queries over the event stream, and the reflection process consumes that substrate.

A worked example

Each step below gives the actor, the action, and the artifact it touches.

A customer files a bug report. The harness ingests the ticket as a capture: a claim someone made, not yet an established problem.
The harness, on its next reconciliation pass, finds drift against an operational promise ("every reported bug gets a triage verdict within 24 hours") and dispatches a triage run to close it.
The triage agent reproduces the failure and proposes a fact, "checkout fails when the cart contains a discounted item and a gift card," citing the ticket and its own reproduction transcript. When four duplicate tickets arrive that week, the triage agent adds their citations to the same fact instead of minting new ones.
The harness, on the pass after the fact lands, re-derives the Observed face of the checkout promise the fact touches: honoring flips to no, and a drift instance (regressed, citing the reproduction fact) enters the attention queue. Drift is always the harness's computation, never anyone's assertion.
The product owner, working the attention queue, shapes the fact into a desire: a want ("fix this"), linked to the fact, waiting with no standing. Shaping is cheap and commits no one. Not every verified bug gets fixed, and the pool says so plainly, rather than through a backlog that implies a commitment nobody made.
The product owner later commits: picks the desire from the pool, writes the done-when (the reproduction fact becomes false), passes the readiness policy, and opens a thread against that drift. The thread itself is the commitment (no new promise is minted; the thread serves the existing checkout promise), and the act emits a decision entry. The human authors intention only: at open, the harness derives the thread's opening drift from the done-when, and the criterion reads open because the reproduction fact currently holds.
The build agent, dispatched on the harness's next work cycle (the newly opened thread sits in the attention queue, and the work policy authorizes a run), proposes the move plan: add a regression test, fix the discount-plus-gift-card interaction, add an alert. No ratification is needed; moves are agent authority.
The harness dispatches runs against the ready moves. Dispatch width is a tuning knob, not a rule: a session may land one move or batch several ready ones, and verification stays per-move either way. The harness checks each landed-when, files each transcript as a capture, and requeues any move whose check does not pass. When the done-when verifies (the failure no longer reproduces), it closes the thread and emits the decision.
The team, in retro, judges the root cause systemic and ratifies a policy citing the fact and the thread — the incident-to-rule path.

The original tickets never change; the layers above them flip state. An updated fact names the release that resolved the bug. And the storyline the whole episode belonged to ("checkout reliability," say) absorbs all of it and stays warm for the next arc.

One thing the example overstates: the ceremony. This walkthrough shows the discretionary lane, where a human decides whether the work is worth doing. Most bugs travel a delegated lane instead: a standing operational promise ("sev-1 and sev-2 defects are fixed within N days") plus a ratified policy that delegates commitment for that class — so when the reproduced-bug fact makes the promise drift, the harness opens the repair thread itself and logs the decision under delegated authority. The threshold between the lanes is not promise-versus-thread; it is delegated-versus-human commitment. And it is itself a policy, so a team tunes its own ceremony level, and every auto-commitment still leaves a decision entry.

The process layer: the plan is an artifact, execution is not

Runs, sessions, and turns appear nowhere in the class table, and the omission is deliberate. The artifact classes are the knowledge layer; execution is the process layer, and the two are different kinds of stuff with different lifecycles. Artifacts are durable and slowly changing. A run is ephemeral and fast, holding enormous transient state (context windows, tool calls, intermediate files) that would poison the knowledge layer if persisted as first-class artifacts.

The type system defines execution's interface without containing it:

a thread defines what a run is for;
the dispatched moves define what this run should land;
policies define what the run may do;
facts and captures are what it consults.

Execution is what happens between artifact states, not an artifact state. The analogy is a legal system: statutes, contracts, and case records are artifacts; a trial is a process, and nobody files the trial — they file its transcript and its verdict.

The boundary could plausibly sit one rung higher, with the plan kept out of the artifact table too and any urge to add a "task" class treated as a symptom — of a promise too big, or of harness state leaking into the knowledge layer. Sometimes it is that symptom. But what the task-shaped hole actually wants is the plan layer, and the plan is a legitimate artifact: durable across sessions, meaningful to resumption, owned by an identifiable authority. What must stay out of the knowledge layer is liveness (which run is executing, how far along, on whose context window), and that belongs to the harness. So the boundary lands here: moves sit above the line; runs sit below it.

Figure 5. The reduction ladder. Three completion predicates at three scales above the durability boundary; below it, everything is process whose exhaust is captured at run end. The authority boundary sits between Thread and Move: done-when is human-owned, the plan is agent-owned, verification is always the harness's.

One rung below the boundary sits the session plan: the plan.md or todo list an agent writes for itself. It is the right tool at its timescale — an agent decomposing its dispatched moves into turns.

The failure mode of bare agent runtimes is that this file is the only plan layer, and it evaporates with the session: the very fragmentation the knowledge layer exists to fix. With moves above the line, the session plan becomes cheap and disposable by design: regenerated from the current move at each dispatch, its useful residue flowing back as move status and captured exhaust, never as authority for the next session.

The distinction also untangles a term teams chronically overload. Acceptance criteria, properly, are a thread's done-when: outcome-level, environment-observable, fixed at open. The scrum-style "Definition of Done" (tests written, docs updated, review passed) is not any thread's criterion; it applies to every move in every thread, which makes it a policy: ratified once, compiled into every run, appended to every move's verification. Per-thread edges and every-thread floors live in different classes with different authority. Most methodology arguments about "DoD versus acceptance criteria" dissolve once they do.

Run exhaust maps onto existing classes completely:

The transcript enters as a capture the moment the run ends.
Completion or failure is a decision.
Anything worth keeping is proposed as a fact or a desire.
What remains is in-flight state — which threads are executing, by whom, how far along — and that belongs to the harness, much as Kubernetes owns pod state while Git owns manifests.

The three loops

The worked example in the previous section quietly involved three different loops, and they are easy to conflate. Each is level-triggered: it derives its work from current state, never from remembered continuity.

The reconciliation loop — the harness measures. On a cadence or a trigger, it re-derives observed state everywhere: each promise's honored-when, fact staleness, untriaged captures, instruction files with no ratified counterpart. Its output is ranked drift, and its dispatches are knowledge work: triage, probes, reflection.
The run loop — agents reduce. Per open thread: pick the ready move, compile context, dispatch a run, verify landed-when, re-check done-when, requeue or close. Its dispatches are product work: changes to the repo and the world.
The authority loop — humans decide. The harness maintains the queues (attention, proposals, held items); accountable roles work the gates: shape, commit, ratify, release. Nothing in the other two loops can mint authority, so this loop is where all of it enters.

Operational commitments are what make the first loop concrete. "Every reported bug gets a triage verdict within 24 hours" is a promise like any other: state-shaped, measurable, capable of drifting. Real teams carry such commitments implicitly; the type system forces them to be named, and once named, an untriaged ticket is drift the harness can see and close. Autonomous triage is also safe for a structural reason: everything a triage run can produce (facts, citations, desires) is evidence-class, so no gate is needed between it and the knowledge layer.

The repository

Where does source code sit? Outside the classes: it is the referent the system exists to produce. The knowledge layer holds artifacts about the codebase — facts describing its architecture, policies constraining how it changes, threads open to modify it, decisions recording why — while the code itself lives in the ordinary Git, build, and deploy world. Identity without membership, exactly as with any other entity: repo:acme/webapp is a name governed by the naming policy; claims about it are facts; commits are its captures.

The more interesting observation: a repository is full of documents that look like code but are knowledge artifacts in disguise, already compiled into executable form. Lint configs, CI pipelines, branch protection, and CODEOWNERS files are compiled policy — the enforcement mechanism for policy-class artifacts.

The discipline that follows: the canonical policy artifact is the source of truth, and repo config is generated from it or verified against it. Otherwise the written policy and the enforced behavior drift apart, and agents obey the linter because the linter is what actually binds. When enforcement config exists with no corresponding policy artifact, that is an unratified constraint operating by fiat — and the promotion path runs backward: extract the rule, ratify it, log the decision.

Prose documents — READMEs, CONTRIBUTING files, inline docs — are the messiest case, because a typical README interleaves facts, policies, principles, and instructions in one file. In a system with high agent volume they are treated as evidence with no authority, the same rule as a Slack thread. A README saying "never touch the legacy module" does not bind an agent; the ratified policy citing that README does. This matters most in repositories agents write to: a generated README must not silently mint constraints for the next agent's run. The injection boundary, applied inside the repo.

Traffic flows the other direction as well: the codebase is the best raw material for as-built facts. What the architecture actually looks like should be derived from code by agents, cheaply and repeatedly, rather than hand-maintained — the code is ground truth, and the fact layer is a cached, cited, staleness-tracked projection of it. Facts derived from code carry a verification hook: re-derive at HEAD, invalidate on drift. Agent volume helps here rather than hurting; regeneration is cheap enough that as-built facts stay fresher than any hand-written architecture document ever did.

The placement rule in one line: the repo holds the product plus compiled projections of knowledge artifacts; the knowledge layer holds the authoritative versions and everything derived.

Context assembly

The payoff of the type system is that assembling an agent's context stops being retrieval over a pile of markdown and becomes a typed query with per-class loading rules. Given a thread, the harness loads:

the full current policy set — always; it is small by construction;
the principles;
the thread's frame and move plan, with the dispatched moves foregrounded;
the facts and references of the storylines the thread belongs to;
retrieval on demand into the capture layer, when the agent needs to verify a citation. Decisions load only for archaeology.

The storyline supplies the boundary of relevance — a human-curated table of contents rather than pure similarity search. That is the difference between an agent reconstructing the story every run and being handed it.

Figure 6. Context assembly. Typed inputs converge into a compiled bundle; the session retrieves evidence on demand and emits its transcript back into the capture layer.

The compile edge is how the design coexists with today's runtimes rather than fighting them. Agentic tools keep their native discovery mechanisms; what they discover is generated. The harness compiles CLAUDE.md (or whatever instruction format the runtime respects) from the canonical policy set, principles, and the dispatched move at run start, giving every instruction a provenance trail.

Instruction files found in the workspace that lack a ratified counterpart are surfaced as anomalies (quoted to a human, proposed for promotion) rather than silently obeyed or silently ignored. The runtimes themselves do not yet distinguish the information channel from the authority channel; everything in context flows into behavior with roughly equal weight. So the harness enforces the distinction from outside: controlling what enters context at assembly time, and compiling authority into the formats the runtime natively respects.

The runtime contract

Compilation assumes something on the other side. The harness can wrap any agent runtime, but it requires four things of one — a contract with four planes.

Selection — work is dispatched to a persona: a named profile bundling model, tool surface, skills, permission posture, and trust level. The harness picks the persona per dispatch, guided by the work (a move's verifier types, a thread's altitude) and governed by policy. The persona is also the unit that trust and delegated authority attach to.
Injection — the compiled bundle and the persona's skills enter through whatever channels the runtime respects: a system-prompt append, a generated instruction file, tool-server resources. Every injected item traces to a ratified artifact.
Enforcement — each policy compiles to the strongest tier the runtime supports: a hard guard (a hook that denies a tool call before it executes), a sandbox boundary, or prompt-plus-audit, where the rule rides the preamble and the harness checks the captured transcript afterward. Each policy records the tier it received, and prompt-only enforcement reads as weak: the false-confidence discipline from the evidence layer, applied to authority.
Observation — the runtime owes the harness a session id, a streamable transcript of text and tool calls, and an exit status: the raw material for captures, audit, and liveness.

The flagship hard guard implements a rule the model already implies: the knowledge layer has a single writer. An agent never appends to the artifact store directly; it proposes facts and desires through tools, and the harness files its exhaust. The rest of enforcement degrades gracefully — a runtime without hooks gets sandbox plus audit, and because every transcript is already a capture, audit is nearly free. A detected violation becomes an anomaly in the attention queue; a repeatedly violated policy becomes a reflection finding ("violated in a third of runs: propose a hard guard, or revise the rule").

Nor is the enforcement extension new theory. The repository section established that lint configs and CI pipelines are compiled policy; a guard configuration injected into the session is the same class, compiled policy at session scope, reaching one layer further down.

Does the stricter model limit agent capability? The limitation lands almost entirely on the authority channel, where predictability is the goal, and barely at all on the information channel, where capability lives. An agent remains free to roam the filesystem, read every README, grep the code, and cite anything it finds. And on the one channel where agent judgment is the point — the plan — the agent holds authority of its own: it revises its moves without asking. What it cannot do is treat discovered text as binding, or redefine what counts as done.

The trade forecloses behaviors the way a type system forecloses bugs, and most of what it forecloses is what accumulates when no head is in the loop: stale instruction, minted rules, confabulated gaps. Explore everything, cite anything, plan freely, obey only what is ratified.

Multisession operation and reflection

Priced against a single-session baseline, this structure looks like friction: an agent's mid-run insight must wait for ratification instead of being written directly into its own instruction file. Priced against the actual unit of work — a storyline spanning many threads and months, paused and resumed — the accounting inverts. Most of the friction turns out to be the mechanism multisession work depends on.

Consider self-modification. Within one session, an agent editing its own instructions is a tight, appealing learning loop. Across sessions it is unversioned state accumulating in the authority channel: session twelve inherits instruction files mutated by sessions three, seven, and nine — each encoding a lesson from a context that no longer exists, none reviewed, some contradictory. The lesson from session three may have been correct for session three and wrong ever since, and without ratification there is no moment at which anyone asks whether it still applies. Persistent shared state needs write discipline, here as everywhere else in software.

Reflection supplies the learning loop that direct self-modification was a degenerate version of. The insight lands as a proposed desire or draft policy plus a decision entry, and the reflection process reviews accumulated proposals with cross-thread visibility no single session had: this lesson was proposed four times across three storylines; it conflicts with a policy ratified in March; here is the promotion recommendation. Session-local adaptation samples one trajectory; reflection integrates over many. An agent that instantly self-modifies is doing online learning with batch size one and no evaluation set.

Resumption makes the same case from another angle. Picking up a storyline after three dormant weeks requires knowing what currently binds versus what was contextual to the last session. If authority lived in prose accreted across sessions, resumption would mean archaeology. With typed artifacts it is a query: open threads and their move plans, current policy set, storyline narrative, recent decisions. The strictness is the resumability.

What survives as an actual cost is ratification latency: a good lesson waits, and if humans are the only ratifiers, human attention gates the policy-update rate. That is a tunable parameter rather than an architectural ceiling: ratification authority can be delegated to agent roles for low-stakes policy classes, with formatting conventions auto-ratifying under logging while safety rules keep a human gate. The structure holds (every constraint has a promotion event); the throughput scales.

Design rules

The system compresses into a short set of rules, each of which earlier sections derive.

Authority derives from class, never content. Imperative text anywhere — Slack, README, generated code — is evidence until ratified.
One class binds, one guides, three task at nested scales; everything else informs. Most artifact volume cannot direct an agent's behavior, by type.
Promises are honored, threads close, moves land. Three completion predicates; conflating any two of them is the single-noun failure: the Epic when promise and thread merge, the task-shaped done-when list when thread and move merge.
Done-when is human-ratified; the move plan is agent-owned; verification is always the harness's. The authority split lets autonomy and safety coexist.
Evidence strength follows citability. Held bytes and delegated immutability are strong; names are weak but admissible. Everything born inside the system is captured; the run transcript is the system's richest evidence about itself.
Every promotion emits a decision. The paper trail is exhaust from the mechanism, not a separate practice, and it is the substrate reflection consumes.
Desires have no standing. The uncommitted pool is where sorting happens plainly, instead of through a backlog treated as a promise.
Policies carry current-set semantics. One active answer per question, with history in the decision log rather than in the rule. A team-wide Definition of Done is a policy, not a criterion.
Execution is a process; the plan is an artifact. Moves sit above the durability boundary, runs below it; liveness belongs to the harness, and session plan files are regenerated shadows, never authority.
The repo holds the product plus compiled projections; the knowledge layer holds the authoritative versions. Enforcement config without a ratified policy is an anomaly to surface.
Storylines reference, never contain, and never close. Correlation is a judgment worth recording; it must not become a shadow hierarchy or a shadow authority channel. It is also where a resumed effort starts warm.
Commitment and ratification are acts of accountable roles. Human by default, delegated explicitly, logged always; delegation breadth is the throughput knob.

None of this replaces the runtimes or the workflow engines; it wraps them. The harness assembles typed context in, enforces policy during, and files typed exhaust out — and the knowledge system in between is what lets a team's intent stay coherent across sessions, agents, and months of product-making.