6.Guards, Gates, Tracks: Show Your Work

Every AI-assisted workflow, the whitepaper observes, must answer two questions: what context should guide this work, and how do we know the result can be trusted? Frames answer the first. Everything in the architecture so far, though, is generation-side: it makes AI work more oriented, more governable, more organized. None of it yet makes the work verified, and generation and verification are different activities the industry has habitually blurred. A fluent output and a correct output look identical at a glance. Institutions that face auditors, regulators, and courts are not permitted to operate on glances.

The whitepaper's Accountability Plane is its name for the validation apparatus as a whole, "not a fourth layer beside the other three, but a plane that cuts across all of them." Revision 9 adds a placement worth noting: the plane is the architecture's answer "to what the industry calls observability and governance, made concrete enough to ship with the artifacts themselves." That is a claim about form, not just function — the industry treats observability as a system you run beside your workloads, and this proposes shipping it inside them. The plane separates the two activities and then splits verification itself into three roles with a grammar worth memorizing, because the entire plane unfolds from it: Guards check. Gates decide. Tracks record.

Guards: checks broader than tests

Software engineers will want to map Guards onto unit tests, and the mapping is deliberately too small. Some Guards are deterministic (does the generated SQL execute; does the invoice total reconcile; does the output match the schema). Others are probabilistic, or comparative (do three independently prompted Cogs agree), or human (route a 5% sample, or anything high-risk, to an expert). Some run before work starts, some during, some after, some continuously across versions. The paper organizes the space into seven categories:

The paper ranks these usefully: algorithmic Guards are the strongest (they verify directly), outcome Guards the most business-meaningful (they verify value rather than form). Note also the closed loop with Part II: many policy Guards enforce rules that are written in Frames. The Healthcare Compliance Frame states the rule about patient data; a privacy Guard checks whether an Op's output respected it. Context and verification are two ends of the same commitment, and the paper makes the direction explicit: Frames can themselves declare associated Guards that must be called and pass on the system's output (§4.3), while every Op should still declare its own.

Gates: where the decision lives

A failed check is information, not a decision. Not all validation failures mean the same thing: some need a retry, some need a human, some need an expert, some need everything to stop. A Gate is the point in an Op where Guard results determine which of those happens: proceed, pause for revision, request human approval, escalate to an expert, run additional validation, retry differently (including with a different Cog), or halt. The paper's examples give the flavor: unsupported claims found by a source Guard pause the Op for revision; low confidence routes to human review; detected sensitive data stops the Op before anything leaves the building; strong disagreement between Cogs escalates to an expert.

Section 4 introduced the other half of what a Gate is for. In Revision 9's employment framing, Gates are where an agent's autonomy budget is set: "the precise boundary between what the agent may do alone and what requires a human," granted per engagement rather than per platform (§4.2). Two descriptions of one mechanism — a Gate is a failure-routing device when you look at it from the Guard's side, and an authority-granting device when you look at it from the agent's. The second is the one a board will care about.

This is where the regulatory landscape stops being background and becomes specification. The EU AI Act's human-oversight requirements for high-risk systems mandate that a natural person can interpret an output, decide not to use it, override it, or intervene and stop the system (Regulation (EU) 2024/1689, Article 14); enforcement and transparency obligations run from August 2026, while the high-risk obligations themselves are anticipated, under the AI Omnibus political agreement, for December 2027 (standalone systems) and August 2028 (AI embedded in regulated products). That list is a functional description of a Gate. The paper's framing, which we think is its most quietly effective argumentative move, is that regulation is not a compliance tax to be absorbed but a spec to be implemented, and Gates are the implementation.

Tracks: evidence, not logs

A Track is the durable record of what happened: which Op ran, which Cogs it invoked, which Frames applied, what inputs and sources were used, which Guards ran and what they found, which Gates passed or escalated, which humans approved what, and what came out the other end. The paper insists on the distinction between this and logging, and the distinction is real: a log is whatever the system happened to emit; a Track is a structured accountability artifact, designed in advance to answer the questions an auditor, a compliance team, a debugger, or a skeptical customer will ask.

Here too the regulation reads like a requirements document. The EU AI Act requires high-risk systems to automatically record events across their lifetime and requires deployers to retain those logs (Articles 12 and 19). An organization whose AI work leaves Tracks by construction satisfies that obligation as a side effect of its architecture rather than as a retrofit project.

Tracks have, since Revision 8, been "retained under the governance boundary of the Hub that produced them and only produced when required by audits or regulators." Revision 9 adds one sentence to that definition, and it is five words long:

The line does real work. An architecture that exchanges almost everything has to say what it will not exchange, and saying it about evidence is the difference between a marketplace and a data broker. Section 10 returns to it, because the refusal turns out to be economically load-bearing rather than merely principled.

The declared Validation Strategy

The plane's parts assemble into a contract. Every Op, the paper requires, declares its Validation Strategy: which Guards run at which lifecycle stage, where the Gates are and what thresholds trip them, what the Track retains and for how long. Validation runs across four stages: pre-flight (is this Op allowed and configured), in-flight (is the work staying in bounds), post-run (is the output correct and safe), and continuous (is quality drifting over time). How much of that apparatus an Op needs is matched to risk. A drafting Op might need format checks and user review; a fraud-detection Op might need source grounding, multiple independent Cogs, expert sampling, and a Track retained for years.

The paper renders its running example (a Vendor Fraud Review Op it threads through the whole document) as a validation-aware manifest, and it is the single most clarifying artifact in the whole document:

Everything this guide has covered is visible in one short manifest: context declared, workers named, checks staged, decisions encoded, evidence specified. The paper's summary sentence earns its emphasis:

Two remarks close the plane. First, the loop: Tracks feed back into the organization's accumulated memory, so corrections and overrides become signals for improving Frames, Cogs, Ops, and the Guards themselves. The paper renders this as an eight-step accountability loop (Frames orient → Cogs perform → Ops orchestrate → Guards validate → Gates control → Tracks preserve → memory learns → artifacts improve), and it is the architecture's answer to how quality compounds rather than decays. Second, Guards are themselves artifacts: authored, versioned, shared, and in some cases sold. The paper sees this as one of the largest open-source opportunities in the whole design, with communities publishing Guard libraries the way they publish test frameworks today. Revision 9 broadens the reason from the company to the category: where an earlier revision argued that "trust cannot be built by OpenTeams alone," the paper now says trust "cannot be built by any one company." The edit costs the argument nothing and gains it a great deal, since a validation regime whose credibility depends on its author is not a validation regime. Note the concrete demand: prompt injection, adversarial input crafted to make a model ignore its instructions and follow the attacker's instead, currently tops the OWASP Top 10 for LLM applications, the application-security community's standard risk ranking, and community-built Guards are the natural countermeasure. Standards bodies point the same direction; a declared Validation Strategy is how frameworks like NIST's AI RMF and the ISO/IEC 42001 management-system standard become machine-checkable practice rather than aspiration. Guards will reappear in Section 10, because a marketplace turns out to need them as much as a compliance office does.