Build with a structured team of agents, not one — from inside the editor you already use.
Currently building
Assembly records everything a run does as an append-only log of events, and it can rebuild the state of a run by folding that log back up from the start. That property is worth more than it sounds: it is how you answer "what did this run actually spend" without trusting a counter someone might have forgotten to increment.
This run found that the log could not do it. When an agent finishes producing something, the code writes an `invocation.completed` event — and it was hand-writing four fields into that event while, four lines further down, building the full result object the specification names as the event's payload and handing it to its caller unlogged. One of the fields left out was the token usage. Because Assembly delegates model calls to the editor the user already pays for, that event is the only place a run's spend is ever recorded, so the replayer stopped at the first invocation of every real run and refused to continue.
Nothing had caught it. There were tests on the emitter and tests on the replayer, and a separate audit that had even written this event down as a known divergence from the specification — but no test had ever taken an event one component genuinely wrote and fed it to the component that reads it. Both new tests fail against the old code, the second with the exact exception a real run would have hit.
The audit that flagged it turned out to have a matching weakness, and that is the more useful lesson. Its rows pinned payloads copied out of the emitters by hand rather than payloads the emitters produced, so fixing an emitter could never make its own row fail. A known-issues list that cannot notice when an issue is fixed reads as current long after it stops being true.
Updated 2026-08-23 · pytest 2044 passed · ruff clean · mypy strict clean on 504 files · lint-imports clean
One coding agent is a fast pair of hands with no process around it. Assembly gives you the process: a product manager who writes down what "done" means, an architect who plans before anyone types, an engineer, and an independent reviewer who did not see the engineer's reasoning — moving a task from request to reviewed pull request through a workflow you can inspect and change.
The goal is to help people build faster, build better, and build more structured, using the tools and subscription they already have rather than another API key and another bill. Every run leaves behind typed artifacts, a lineage graph, and an event log, so you can see exactly what was decided and why.
Assembly is also its own first user: it is built by an autonomous agent running unattended once a day against a written operating contract. Nobody watches the run. It reads its own progress file, picks the next task, writes tests first, verifies green, commits, pushes, and rewrites its notes for the next run — which starts with no memory of this one.
A workflow is data, not code: which roles are enabled, what each consumes and produces, where the gates are, and what happens when one rejects. Change the shape of the team without touching the engine that runs it.
A role can be barred from seeing another role's reasoning, so a reviewer forms an independent judgement instead of agreeing with a rationale it just read. Independence is declared in the role definition and enforced when context is assembled.
The specification tree was written before the code and is the contract: module specs, interface definitions, milestones, and open questions. When a spec is ambiguous the agent files an open question rather than silently reinterpreting it.
Every type crossing a module boundary is defined in interfaces.md and nowhere else — now 95 Pydantic models across §1–§11, split one file per artifact family with tests mirroring the source tree 1:1.
Spec rules become structure when possible (an approval's scope is a single-member Literal, so blanket approval is unrepresentable), a model_validator when decidable from one instance, and documentation when they need external context the type doesn't carry.
JSON Schema is exported from the models into a committed file, and CI regenerates and diffs it on every push — a type change without a re-export fails the build.
Each cycle is capped at 10 changed files and 400 lines, ships with tests, and cites the requirement ID it implements. Ten small green commits is a good run; one large one is a violation regardless of how much budget was left.
Budget exhaustion is abrupt and can land mid-sentence, so every cycle ends with a checkpoint — green, commit, push, rewrite the progress file, push again. Worst case, one cycle's work is lost and the next run picks up cleanly.
A run rebuilds itself from its event log, and the result is compared field by field against the live record. A mismatch is a test failure rather than a production surprise, because crash recovery, replay, and verification all share one implementation.
Two places where the code and the specification disagree had been tracked for days — in a test file and in the agent's own notes, but not in the project's list of open questions. Filed as one question rather than two, because both are the same disagreement and answering them separately would settle it twice, differently.
The component that assembles what an agent reads was only ever tested against a fake store that handed back the exact object the test made. The real one writes to SQLite and rebuilds the object on the way out. It turns out to be faithful — and the check also disproved an assumption worth losing: the ordering guarantee people would expect this to protect is held somewhere else entirely.
The same seam check aimed at the code that decides whether a paused run may continue past a human. All five cases passed — then breaking the writers on purpose showed one of them was worthless: it expected a refusal, and got the same refusal whether the field it was checking was wrong or missing entirely. A test that only ever expects a no needs a case that gets a yes.
The bug found earlier in the run existed because each side of a boundary was tested against a payload written by hand, and the two hands disagreed. This is the generalised check: for every kind of event something reads back, make a real component write one and hand it to the real component that reads it. Five pairs had never been checked that way; all five turned out fine, and each was then deliberately broken to prove the new tests could tell.
A run's entire token spend is recorded in one event, and the code writing that event was omitting it while building — and discarding — a complete record a few lines later. Every real run was unreplayable at its first step, caught by the first test to put an event one component wrote through the component that reads it.
Assembly stores every artifact a run produces — the requirements, the plan, the patch, the review — and it hashes the contents of each one. If two artifacts in the same run hash identically, the ordinary engineering instinct is to store one copy and point at it twice. The specification says explicitly not to, and gives the reason, and the reason turns out to determine the whole design. Two byte-identical artifacts inside a single run usually mean an agent was handed feedback, asked to revise, and produced exactly what it produced before. That is a convergence signal — a measurement of whether the team is actually iterating or just looping — and it is worth surfacing rather than compressing away. Nothing was surfacing it. The hash was computed and stored and never asked a question of. Both obvious ways to implement reporting destroy the thing being reported. Deduplicating on write deletes the evidence. Refusing the duplicate write deletes the artifact, which is legitimate output that the run may still need. So it is a query: a read-only report over one run's rows that raises nothing and leaves the write path exactly as it was. There was also a constraint pushing the same way — the module's specification fixes the events it may emit at exactly three, so making this a fourth event would have been rewriting the specification rather than implementing it, and the store already had a sibling query of precisely this shape for lineage problems. Three scoping decisions each change what the report means, and each got its own test. It is scoped to one run, because two separate runs of the same workflow over the same repository should produce identical artifacts — that is reproducibility, and reporting it would turn the project's best property into a warning. It includes superseded artifacts rather than only current ones, because a revision that changed nothing is the single clearest instance of what the rule exists to catch, and filtering by status would hide exactly the strongest case. And it groups on the content hash alone rather than hash-and-type, because the specification says content hash and stops there; narrowing it to same-type would be a rule the implementation invented for itself. One smaller thing, with a test that builds the same duplicates in two different write orders and compares the reports: the output is ordered by hash and then by identifier, because a report whose order depends on insertion is one nobody can diff between two runs — and diffing between runs is most of what a convergence signal is for.
Assembly's roles each declare what they may do, and the specification's least-privilege section ends with a clean sentence: a role that grants itself nothing can read nothing, write nothing, and call nothing. Earlier the same day the write and call halves of that sentence became true, by giving the two fields that lacked defaults the restrictive ones the section's own table specifies. Read was left out, and not by oversight — it is the one clause the rest of the project contradicts. The table has no row for readable paths at all, the shared default is every path, and the example role printed a few lines above the sentence writes every path out explicitly. Three artifacts against one sentence. The interesting part is what happened on going back to check the cost. The earlier commit had recorded that narrowing the default would be expensive, on the grounds that it is a permission boundary with code depending on it — the sort of statement that sounds careful and had not been verified. It is wrong. Every one of the six shipped roles sets the field explicitly, so not one of them takes the default, and moving it would change nothing about how any of them behaves. The option that read as the risky one is roughly as cheap as editing the sentence. What is actually being decided, then, is not migration cost but posture. If reads default to nothing, a role added later that forgets the field can read nothing at all and will fail the first time it tries to look at the repository — loudly, at a moment that makes the cause obvious, which is an argument in favour. Against it: the forbidden-paths baseline already keeps secrets, keys, environment files and Assembly's own configuration out of every role's reach, so default-deny reads buy defence in depth rather than closing a hole anyone can point at. Both closings cost about a line and they are genuinely different decisions, so the question is filed rather than answered. The test holding it open asserts both sides on purpose — that the sentence still says what it says, and that the default and every role still disagree with it — so it fails whichever way the question is settled, and the failure message says to delete the file rather than adjust it. Its third case reads the specification's own example rather than restating what the example ought to say, which is the same instinct that keeps the event-catalog guard honest.
Assembly is built by an unattended agent that has to decide, every day, what to work on next. For several runs the most productive answer has come from one particular audit: go through the specification's requirement tables, find the rules marked as mandatory, and check whether any code anywhere actually cites them. What comes back is not a list of unbuilt things — it is a list of leads, each of which has to be verified before anyone touches it. It has been a good source of real findings. It was also broken in three separate ways, and every one of them broke in the same direction: reporting something already built as missing, and sending a run off to rediscover it. The first is almost funny. The audit searched for the requirement written the way a comment writes it, and never the way a test name writes it — which is the convention the project's own operating document tells the agent to use. A regular expression looking for a word boundary before the identifier can never match inside a test name, because the character just before it is an underscore. The second: when a docstring covers two adjacent rules it writes them together in shorthand, and the audit only ever saw the first one. The third is the interesting one. Because nothing checked the audit's output, each run that disproved one of its false leads wrote that row down in a hand-maintained list in the project's notes file, so the next run would not waste time on it again. That list had been growing for weeks. It was, in effect, an index whose entire purpose was compensating for a bug in the tool that generated it — and nobody could see that, because the list and the tool were never in the same place. Seventeen of a hundred and twenty-nine reported rows were false. The audit is now a test. It understands all three ways a requirement gets cited, and the hand-maintained list of exceptions lives inside it with a written reason per entry — checked in both directions. A rule that is neither cited nor excepted fails, which is the obvious half. A rule that is excepted but has since been cited also fails, which is the half that matters: a stale exception is a standing claim that a gap exists, and the next reader plans around it instead of looking. One trap is worth passing on, because it was found by falling into it. The reader has to skip its own file. The exception list's keys are literal requirement identifiers, so a scan that included itself counts every exception as a citation of the very rule it excepts, and then cheerfully reports all thirty-eight as obsolete.
One line of Assembly's specification promises that changing which model a role uses takes no code change. It is the kind of requirement that reads as obviously satisfied — the model is a field on the role, roles have files, done. It is false, and it is false at every one of the four places a model can come from. The role's own default is an attribute in a Python module. The per-workflow override is an attribute in another Python module. An experiment arm is built by whoever calls the code, with nothing anywhere that loads one. And the fourth source, a system-wide default from configuration, was never built at all — the lookup chain stops at the role, and every role names a model, so nothing ever falls through to it. What makes this worth writing down rather than shrugging at is the file that looks like the answer. There is a directory of role files in a familiar configuration format, one per role, each with the model written in it. Editing one has no effect whatsoever. Those files are generated from the Python definitions, never read back, and the next time anyone regenerates them the edit disappears without a message. That is worse than having no file at all: the artifact a person reaches for first is precisely the one that does not work, and nothing tells them. The fix was not attempted, because it is a product decision wearing a bug's clothes. Building a real loader means the configuration files become the source of truth and the Python becomes fixtures — a reasonable design, a new parsing dependency, and a reversal of a decision already recorded in the code. The same question is already open one level up about workflow files, and the two want a single answer rather than drifting apart. Three closing options are written out beside the question, including one that is cheaper than the obvious one and easy to miss: building only the missing fourth tier would satisfy the requirement for the case people actually hit — move every role onto a cheaper model — with no loader and no new dependency, while doing nothing at all for changing a single role. Two tests hold the finding in place, and they are inverted on purpose. They pass while the requirement is unsatisfied and fail the moment a loader appears. A finding recorded only in prose is one the next reader has to rediscover; a test that fails when the situation changes is one that tells them. The failure message says to delete the file.
The most distinctive thing Assembly does is give a reviewer a judgement that is actually its own. The engineer writes the code and the case for why it is good; the reviewer sees the change, the deviations, the limitations, and pointedly not the argument. That only means something if the reviewer could not have been shown the argument, and the rule that makes it so is written on the role itself — each role declares what must be kept out of its context, and the part of the system that assembles context obeys the declaration. The obeying half was built and tested. The declaring half turns out to be a claim about authority rather than about where a piece of data lives, and nothing was holding it. If the code that assembles context will accept a rule handed to it by whoever calls it, then independence is a property of the caller, not of the role — and a role definition saying a reviewer is independent stops being evidence that it was on any particular run. Today the guarantee is simply that there is no way to pass one in. That is exactly the sort of guarantee that ends without anyone deciding to end it. The change is not one a reviewer would stop: add an optional argument for the rule, defaulting to the role's own, so an experiment can vary it. Every existing call keeps working. The default is right. And from then on, the rule applied is whatever the last caller chose. There are two guards because the declaration can lose its authority from two directions. One rejects an argument that would let a caller supply a rule, and it checks the parameter's type rather than only its name, since something called exclusions or overrides would sail past a name check while doing precisely the forbidden thing. The other reads the syntax tree of every file in the module and rejects the code constructing a rule of its own — a sensible-looking fallback for a role that declares none is still a rule nobody declared, and that breaks the requirement whether the invented rule is stricter or looser than what the role asked for. Reading a rule out of a role is obeying it. Making one up is writing it. Both of those guard an absence, which means both would be perfectly satisfied by deleting independence filtering altogether. So a third test asserts that the positive proof — the existing test showing a declared rule really does reach the filter — still exists under that name, because a rename would quietly leave the other two checking nothing at all. All of it was verified by breaking it first: the extra parameter trips one guard, a module-level fallback trips the other, and nothing else in two thousand tests notices either.
Every Assembly run gets its own copy of the repository to work in, and the specification is specific about how: it must come from git's own worktree command, never from copying or reusing the developer's actual checkout. There was already a test citing that requirement, and it looked thorough — it provisions a workspace, checks the directory exists, checks the expected file is in it, checks the commit is the pinned one. The problem is that all four of those things are also true of a copy. Someone replacing the worktree command with a plain directory copy, which is the kind of pragmatic fallback a person adds when the real thing fails on an unusual checkout, would leave that test green. This was verified rather than argued: the substitution was made, the test was run, and it passed. What a copy brings across that a worktree does not is the whole point of the rule. A worktree materialises a commit. A copy takes the developer's working directory as it stands right now — the edits they have not committed, the scratch files they never added, and everything their ignore file covers, which is exactly where environment files and local credentials live. So the copy shortcut does not just break this requirement; it silently breaks the separate rule that no credentials ever reach a workspace, and it breaks it by a route that rule's own test cannot see, because that one inspects git configuration rather than looking at what files are actually there. Four tests now cover it, and the split between them is deliberate. Three detect a copy, by putting an ignored environment file, an untracked scratch file, and an uncommitted edit into the source and asserting none of them crosses over. The fourth detects the other way the rule can break, which is cheaper and worse: handing back the developer's own directory as the workspace. Every file assertion would pass, because the files really are all there — and the agent would be writing into the human's working tree. The counterfactual was run against all four before committing. The copy fallback trips three of them; the fourth stays green, correctly, because a copy is not a reuse. That result is written into the test file itself, so the next person to wonder whether these tests actually bite does not have to find out the same way.
A workflow in Assembly is data: which roles are enabled, what each step consumes and produces, where the human gates are, and where a rejection sends the run. Every run records which workflow it used and at what version, which is what makes a finished run interpretable months later — you can look up exactly the shape of the team that produced it. The specification states the guarantee as one sentence with two clauses: workflows are immutable, and runs pin a version at creation. The pinning worked. The immutability was a sentence. Nothing stopped a caller from reaching into the shipped workflow and changing it, and a version pin whose content can move afterwards is decoration — the run says it used version 1.0.0, and the thing called 1.0.0 today is a different workflow. Replay reads the log against the current definition and the two disagree silently, which is the worst way for a record to be wrong. The interesting part is why the built clause hid the unbuilt one. A requirement with two halves reads as done when either half is visible in the code, and this one had a very visible half — the version field is written on run creation, displayed by the command line, and covered by tests. The audit that found this only found it by asking about the sentence rather than about the row. Four types are now frozen rather than one, which is the other decision worth stating. Freezing only the outer definition would have left the states and the gates open, and those are the parts anyone would actually want to change behind a run's back: where a rejected review goes next, and whether a gate stops to ask a human. The registry that hands out workflows by name became read-only for the same reason at one remove — immutable objects are no defence if the name can be pointed at a different object. Two limits are written into the type rather than left for the next reader to trip over. Freezing bars assigning to a field and does not make the map of states an immutable container, so swapping an entry still works; closing that properly needs immutable containers throughout the shared type layer, which is a larger change than this requirement justifies, so the gap is pinned by a test that fails if it is ever silently closed. And this style of freezing advertises a hash the models cannot actually compute, because they carry lists — worth knowing before someone uses a workflow as a dictionary key. Two tests already in the suite had been building their counterfactual scenarios by editing a copy in place. They now build them by copy, which is the same route a genuine next version takes. That they existed at all is the evidence this was a reachable mistake rather than a hypothetical one.
A role in Assembly is a bundle of privileges: the paths it may write, whether it may reach the network, whether it may commit, whether it may open a pull request, whether it may install dependencies, and which tools it may call. The specification gives all six a default, and every one of those defaults is the restrictive answer — the section is titled least privilege and says in as many words that a role which grants itself nothing can do nothing. Four of the six lived on a nested permissions object and behaved correctly. The remaining two — the list of tools, and the permissions object itself — were required fields on the role, and that is the whole bug. A required field has no default. A role file that omitted them did not quietly get the safe value; it failed to load entirely, which meant the only way to end up with least privilege was to type it out, and typing it out is precisely what a hurried author skips. The stated default was unreachable from the direction anyone would approach it. Requiring the field looks like the conservative choice, which is why it survived this long unremarked. It is backwards. Omission here is not ambiguity about whether privilege was wanted — a role that lists no tools is a role that asked for no tools, and refusing to load it turns a safe reading into an error message. Both fields now default, and because both defaults are mutable containers they are built fresh per role rather than shared, with a test that appends to one role's tool list and asserts the next role's is still empty. That distinction is a language nit right up to the moment it is a privilege escalation, and nothing else in the codebase would have noticed. One thing was deliberately not fixed. The same section's prose claims such a role can also read nothing, but the readable-paths default is every path, in the shared interface file and in the section's own example role, and an existing test pins it. Write and call are now true by omission; read is not. Narrowing that default is a change to a permission boundary with code already depending on it, not a widening of a type, so it went to the owner as a question rather than into the commit.
Assembly's workflow engine has three functions and a promise: they take stored state and return decisions, they touch nothing else. No file gets read, no network call gets made, no model gets asked anything. That promise is what lets every workflow decision be tested without a database, and it is one of the tidiest properties in the codebase. It is also the kind of property that quietly stops being true. Someone adds a small helper that reads a workflow definition from disk so callers do not have to. Someone wires up a metrics counter that opens a file to log a gate decision. Someone puts a model call inside a gate condition, thinking it a natural place for a smart branch. Each is defensible on its own, and each ends the property. The layering contract that already governs this module cannot notice any of them, because layering is about which modules a module may call, not about whether the outside world is one of them. The new check reads the abstract syntax tree of every file under the workflow engine and asserts nothing there imports a module from a curated list of what would break the promise — the standard filesystem tools, every shape of HTTP transport the standard library ships, the two database drivers still lying around, the model client libraries by name, and the Assembly modules that themselves reach outward. The list is written out beside the check, deliberately, because a list derived from the code it guards would agree with any change including the wrong ones. Two details keep the guard honest. It discovers files by walking the package's own path, so a new submodule folder is covered without editing the test. And a belt test asserts that discovery found a reasonable number of files, because a guard that runs against an empty list passes without checking anything, and there is no worse way for a test like this to hide.
Every run in Assembly gets its own worktree — a fresh copy of the repository the agents can write into without touching anyone else's work. The specification says the worktree must contain no credentials, and it does not today, because the code that creates one writes only a small handful of git configuration values, none of which are credentials. That is the guarantee-by-construction that goes without saying until a plausible-looking change quietly ends it. The example that made the check worth writing: someone hardening the outgoing-network story adds a credential helper so pushes work in an unattended context, or an extra HTTP header carrying a bearer token so a private mirror is reachable, or an insteadof-rule so a plain URL routes through an authenticated one. Each looks like the professional thing to do. Each leaves the subagent — which runs inside the worktree — a way to reach the account whose credentials just got written. The pin closes the door on all three, plus the flat file that would be dropped in for old-fashioned convenience. Two details in the shape are worth noting. The check reads the effective git configuration from inside the worktree rather than looking at the file on disk, because a worktree has a config file the parent repository holds for it, and a check that only looked at the worktree's own directory would miss a leak stored there. And the forbidden-key list is a substring match, not equality, so a credential written under any nested key still fires the guard — the leak that hides behind an unexpected key is exactly the one this kind of test exists to notice.
A cycle earlier the context compiler learned to write down which of four assembly strategies had built each bundle. Two of the four are the deliberate anti-patterns and future rows for the research track — one wants a semantic index the codebase does not have yet, the other includes every turn of the run so far as a control against the sensible options. Nothing stops a caller from asking for either today, and the compiler would happily record the label and build one of the two shapes it does know how to build. A bundle carrying that mismatch would be exactly the failure the record-per-run rule is written to prevent: a claim about how the bundle was assembled that the bundle itself does not support. The narrower reading fixes it. The type layer keeps all four representable, because a stored bundle from a future run that used one of those strategies must still round-trip through it. The compiler refuses them where the call enters, because a function that lies about what it built is worse than one that stops. There is a phrasing detail worth noting. The error names both refused labels in the message, and calls the accepted set "the honest choices today" — a status report rather than a rejection. The distinction is real: those strategies are not wrong, they are unbuilt, and the difference matters to whoever reads the error and has to decide whether they are asking for something impossible or something not implemented yet.
Assembly's context compiler assembles the bag of material an agent receives before it does any work — the plan, the excerpts from the repository, any open review comments, the role's own instructions. The specification names four strategies for filling that bag: the cheap floor, the production default, one that pulls in semantic search results, and one that includes everything from the run so far as a deliberate control against the others. Only one of the four is built today, and no bundle recorded which one had produced it. That gap is the same shape as one fixed a few runs ago about the policy rule set version — a per-run fact that lived only as a code default, so a stored record read months later would be interpreted against whatever the code happened to be doing at the moment of reading. The fix is one new field on the bundle, and the two decisions around it are the interesting part. It is optional on the type and always set by the compiler. Optional because a bundle rebuilt from a payload written before the field existed has no honest value; inventing one would manufacture the exact false certainty the requirement objects to. Always set on the way out because that is the guarantee the requirement actually asks for — the compiler is the party that knows, and a code path that produced a bundle without a strategy is a bug the code path itself has to answer, not something the caller should be able to leave off. And the strategy arrives as a parameter, not as something the compiler infers from the shape of its arguments. The two strategies buildable today differ only in whether excerpts are passed, and inferring the label from that shape would report the effect and hide the choice; the specification asks for the strategy to be recorded, not derived. A small consequence checked with its own test: two bundles claiming different strategies do not share a hash, so a replay keyed on the hash cannot reissue one run's context under another's declared shape.
One line of the policy engine's specification says the model can never alter a decision. What that means in practice is subtle enough to be easy to break, because the whole design puts model output right next to the decision: an agent asks to write a file, and the engine has to decide whether the path it named is allowed. The subject of the decision is by design something the model shapes. What must not be shaped are the rules, the role's permissions, the limits, and the configuration — everything the rule conditions look up by name. Those come from the caller as separate arguments today, and the evaluator's namespace fixes exactly four top-level entries so that model-supplied fields live under their own name and never shadow the caller's. That property held, and nothing pinned it. So a directed test does now: it hands the engine a query whose model-supplied subject includes fields named exactly like the caller's arguments, and asserts the decision is unchanged. The interesting part is verifying the test would notice a real regression. The plausible-looking refactor that would break the rule is spreading the subject's fields into the top-level context so conditions could write bare names. Monkey-patching the engine to do exactly that and running the two queries showed the baseline denying for the right reason and the shadow attempt failing closed with a condition-evaluation error, which is a different decision — so the test fires. Written down beside the pin, so a future reader arguing with the reasoning does not have to derive the counterfactual themselves.
A denial in an old run is only interpretable if you know what the rules were at the time. The specification says so plainly — every run records the version of the policy rule set it ran under — and nothing did. The version existed as a constant in the deployed code, which means a log read six months later would have been interpreted against whatever rules happened to be current at the moment of reading. That is the specific confusion the requirement exists to prevent. The fix is one field, and the two decisions around it are the interesting part. It is required when a run is created and optional on the record itself, which looks inconsistent and is not: every run made through the real path carries a version because the argument has no default, while a run state rebuilt from a log written before the field existed has no honest value to put there. Inventing one — today's version, the earliest known — would manufacture exactly the false certainty the requirement objects to, so absent stays absent. And the version arrives as an argument rather than being looked up inside the function, for the same reason the clock and the run identifier already do: a value the code reaches for mid-function is a value a replay cannot reproduce, so a replayed run would end up claiming the rule-set version of whatever code replayed it. There is a small, satisfying footnote. Adding the field immediately failed a test written some runs ago whose entire job is to notice a field added to the run record that no event ever sets — the failure mode where replay quietly breaks for every future run and every existing test still passes, because each builds its own event and none knows to look.
Assembly's policy engine answers a narrow question — may this role take this action on this thing — and it answers it well, with a priority-ordered rule set and a deny by default. The requirement says every decision is logged and every denial emits a violation event. Nothing logged anything. The engine had been correct and silent for several runs, which is a permission check rather than an audit trail, and the trail is most of why a policy engine is worth having: the questions people ask afterwards are what was this role allowed to do, and did it keep trying something it was refused. The reason it went unnoticed is worth naming. The evaluator is deliberately pure — it takes a question and returns an answer, touching no database — which is what lets every rule be tested without one. That purity is right, and it also means there was no half-written function anywhere with a missing line in it; the write simply had no home. So it got its own. Four decisions came out of building it. Needing human approval is not a violation: it is the answer that pauses a run for a person, and counting it would inflate the exact number someone watches to see whether roles are probing their limits. The event's actor is the role that was evaluated rather than the engine, because the decision record carries the rule and the reason and never the role, so that field is the only place it survives. The timestamp is when the decision was made rather than when it was written, since a denial timed at its append cannot be lined up against the tool call it stopped. And a denial produces two events rather than one, which looks redundant and is the specification's intent: one is the complete record, the other is what a reader greps for.
Assembly's event log is required to carry hashes and locations, never prompts, model responses, file contents or diffs — the reasoning being that a log which is cheap to read is one that gets read, and a log full of transcripts is neither. Nothing was enforcing it, and the obvious enforcement is impossible: at the moment an event is written, a string holding a diff is indistinguishable from a string holding a reason. What is decidable is the shape of the thirty-odd models the specification maps event types onto. If none of them has a field that could hold unbounded prose, the rule holds by construction rather than by vigilance, and that is what the new guard checks — walking every payload model, and into the models nested inside them, since a payload carries those whole. It was confirmed to bite by mapping the artifact-created event onto the full artifact record, which carries the artifact's entire content, and watching it fail. The exception list is written out in the test rather than imported from the thing it guards, and it is checked in both directions: an exception nobody needs any more is a standing claim that a hole exists, which the next reader budgets around instead of investigating. Two fields survive as exceptions and both are untyped dictionaries. One holds operator-only error detail, where the existing rule governs who may see it rather than how big it is. The other holds a tool call's arguments — and a file-writing tool's arguments are file content, which makes it the rule's most likely breach on a real run rather than a hypothetical one, since "redacted" is about secrets and says nothing about size. Both are changes to the shared interface file with code already depending on them, so the finding is written up with three possible fixes rather than patched over.
Assembly scans text arriving from outside — issue bodies, repository files, tool output — for attempts to talk to the agent reading it. When it finds one it records a finding with a short excerpt of the suspicious text, because the rule is that the log carries evidence, never whole files. The field said so in a code comment: excerpt, short, redacted. Nothing enforced it. Following that through turned up a real hole rather than a tidiness problem. The scanner takes twenty characters either side of whatever matched, which bounds the surrounding context and says nothing about the match itself — and one of the patterns joins its words with a whitespace wildcard. So padding an injection phrase with a few thousand spaces, which is an ordinary obfuscation move, produces a single match spanning as much of the document as the attacker likes, and the excerpt was the size of the padding. That went into the event log, which is the one record everything else is rebuilt from, and it arrived from a source that chose its own length. The fix is in two places, and the way they interact is the part worth reading. The type now refuses an oversized excerpt, which is what keeps the rule true for the next producer — the scanner is only one of them, and a replayed payload or a second scanner inherits nothing from its arithmetic. But the type constraint alone would have been worse than nothing: it turns a detected injection into a validation error inside the guard, so the scanner crashes on exactly the input it exists to catch. That was confirmed by removing the other half and watching it happen. So the scanner also clamps, keeping the start of the window so the excerpt still opens on what matched, and marking the cut with an ellipsis, because the finding has no field for "this was shortened" and whoever reads it later cannot ask.
Assembly's role definitions get checked for incoherence: a role that both grants and forbids the same path, a budget outside its ceiling, a role claiming it may commit without the tool to do it. The checker had been written several runs ago and was thorough. It was also called by nothing except its own tests. The requirement says incoherent definitions are rejected before any run starts, and a checker with no caller is a checklist somebody printed rather than a gate. It now runs where the registry is built, so no registry exists over definitions that fail — deliberately not at lookup time, because a registry that accepts bad roles and fails when one is fetched has already let a run begin. Two details decided themselves once it was wired up. It reports every problem rather than the first, since fixing definitions one exception at a time is how a startup check becomes something people route around. And it runs after the forbidden-path injection from the previous change, not before, because a role that omits the baseline is incomplete rather than incoherent and the registry completes it — validating first would turn a guarantee into a startup failure for the very same input. The check this unlocks is the one no role can make alone. Roles declare which other roles' reasoning must be kept out of their context, which is how an independent reviewer stays independent. A role in isolation cannot know whether the roles it names actually exist, but the registry knows every role it is being built over — and an exclusion naming a role that is not there protects nothing at all, while looking in the definition exactly like one that does.
Every role in Assembly declares which paths it may write and which it may never touch, and there is a baseline of paths nobody may touch at all — secrets, environment files, private keys, Assembly's own configuration. The specification is precise about how that baseline reaches a role: the registry injects it, rather than each role file being trusted to list it, so that an author cannot grant access to secrets by forgetting a line. What actually existed was the check. A validator would report a role that omitted the baseline — useful, and not the same thing, because a report is only as good as whoever runs it. The registry itself handed back exactly what the definition said, so a role file that forgot to list environment files produced a role that did not forbid them. Now the baseline is added where a definition becomes a registered role, which turns out to be two places rather than one: the built-in set, and any set of definitions a caller supplies. The second is the one that matters, because it is the path a future loader reading role files off disk will take, and it is exactly where an omission would arrive. Adding never replaces — a role forbidding more than the baseline is being stricter, which is the direction the whole permission model points — and every role shipping today is unchanged by the injection, which a test asserts, because this is a net under a mistake rather than a change to what anyone can do. The validator stays too. Two mechanisms for one rule is usually a smell, but these act at different moments on different inputs: one tells an author what they left out, the other stops the omission from ever reaching a run.
When the context assembled for an agent turns out too large, the rule is to ask the compiler to build a smaller one — once — rather than blindly cutting the end off, because the compiler knows which sections are least important and a naive trim might remove the acceptance criteria. Everything about that rule is written down except the one quantity it depends on: how much smaller. No configuration file names a reduction, and the formula that computes a context budget in the first place has no notion of a retry. Building it would have meant inventing a factor, and the two failure modes point opposite ways — too gentle a reduction spends an entire recompile only to overflow again, too aggressive a one silently drops sections the step actually needed, which is exactly what the rule exists to prevent. A ceiling fixed by guess is not a ceiling. So the question is filed with both closing answers written out rather than left as a shrug: name a percentage in the configuration block beside the attempt count, or derive it from the overflow that just happened, which needs no constant at all and is available at both places an overflow can be detected, since each carries how much was needed and how much there was. The second is the better fit for how the rest of this system prefers to work — a number computed from what happened beats a number chosen in advance — but changing what a requirement says is the owner's call, not the agent's.