The home page has the short version. This is the longer one: what the lab studies, why it is shaped this way, and where different readers should enter.
The research question is general: how a system legitimately moves from an observation to an action, and what has to hold at each step — how an observation becomes a claim, how a claim gains authority, and when an authorized claim may produce an effect. It first showed up in operations, where every day asks who changed this, how we know, whether the log is trustworthy, and who approved the deploy. But the same failure appears in AI agents, distributed systems, formal verification, and governance — operations is where the questions were learned, not what the work is about.
The dangerous cases happen in the gap between check and effect — the claim was true earlier, but stale, unsupported, or out of scope by the time something tries to act on it. This lab builds small gates for that gap. Agents and automations may propose work; the gate decides whether the evidence is still good enough to act on; every refusal leaves a receipt that can be inspected later.
More precisely: custody controls whether a claim may become an operational premise.
The instruments here keep the check-vs-action gap visible and make stale inputs refuse before effect — small pieces that separate observation from assertion, measure the gap between check and action on a named clock, check intent before it becomes effect, and emit receipts the next system over can act on. Automation proposes work — runbooks, scripts, Terraform plans, AI agents — and cannot self-approve, spend stale permission, or turn “tests passed” into “safe to apply.” Whether the claims those proposals rely on were witnessed, still fresh, and allowed to become premises at the moment of action is the whole question.
Approval is an explicit operator or gate decision over a specific proposal, at an authority-bearing surface, with scope, time, and evidence recorded. A completed run, passing tests, a chat message, a green check, a completed rehearsal, or an agent saying “done” is not approval. Approval is a bounded operator or gate act — not a byproduct of some other event completing.
Authorization asks whether an action is allowed. Custody asks whether the premises behind that action are still good enough to act on. A credential valid at check time can be stale at action time. A green check can outlive its evidence. A log line is self-report until sealed. A demonstrated behavior is not an operational claim. Each of those collapses is invisible to the conventional stack and unrecoverable after the fact. Keeping them visible — and able to refuse before effect — is the whole job.
The closest established analogy is electronic design automation. Not because operations resembles chip layout, but because the useful parts of EDA are compilation, checking, comparison, and explicit promotion — an authored design, rule checking that refuses contradictions, compiled artifacts for each downstream consumer, a ratification step that is a deliberate act, and a comparison of intended structure against realized structure where divergence is a verdict rather than a nuisance. Outwardly the category is design and assurance for operational systems; the intellectual ancestor is EDA.
This is an integration thesis, not a novelty claim. Every constituent technique already exists somewhere — infrastructure-as-code declares intent, monitoring observes reality, policy engines decide, systems engineering has modeled designs for decades. What has not happened is their integration into one discipline with a first-class authored system artifact, explicit evidence obligations, bounded per-consumer views, and typed refusal. That gap is the bet.
The analogy stays on the positioning layer and never enters the vocabulary. Nothing here is called a schematic, a netlist, or a tape-out. The internal terms remain revision, projection, witness, standing, custody, admission, and refusal — a conceptual dependency on the analogy would itself be the failure mode. And the authored-design layer that completes the lifecycle is a candidate: named, designed, not built. The home page marks where the line falls.
Different readers want different doors.
The bet is that governance lives in the conversions between observation and action: what may become a claim, what may become a premise, what may authorize an effect, and what must remain a refusal. Ordinary infrastructure collapses those boundaries into “looks fine” in ways that only show up at incident time. A bet like that wants to be falsifiable, so the work ships as small instruments with explicit refusal boundaries and reproducible demos.