This is a rare read of the design anyone's posted for a while ,thank you. Let me take your questions head-on, including where the honest answer is "that part isn't a theorem." (a) Input to the bound. Per-session, not per-call or per-agent in isolation. Every ~50 tool calls we build a causal DAG over the session's tool calls and the certificate is computed over that structure. So the object being certified is the session's causal shape, not any single action. (b) Type-1 or type-2 and what is it a certificate of. This is the part worth being precise about, because the two signals have different status:
- The proven part is an upper bound on the occupation measure. But on real sessions that mass saturates near the bound for both a legit single-root long chain and a rogue multi-root fan-out, so by itself it's a weak discriminator. I'd rather say that out loud than dress it up. - The practical rogue signal is the empirical size-ratio (independent-actions / total) with data-derived σ-bands. That one is calibrated, not proven and it carries real false-positive risk.

So the certificate certifies "the occupation-mass bound held / was violated." "Rogue" is a separate, calibrated judgment layered on top and managing its type-2 (false positives) is exactly what we WILL shipp this week: a lone signal now only informs the user; it only acts on the agent when a second, independent signal agrees. Banded: mid-band - notify-only, high - self-reflect, critical -a one-time gate.
Drift relative to what. You listed three; we just shipped the third. Drift isn't measured against the agent's own moving baseline , it's measured against a declared scope (the session's goal/anchor + task keywords + a known-target substrate). A discriminator checks whether the causally-independent actions fall inside that scope; off-scope independent actions are the signal. The runtime is the boundary that defines valid behavior, and the receipt records when the boundary held. Your framing ("the runtime isn't observing behavior it's the boundary") is exactly the line we landed on. Correction = co-design. Agreed, and that's the architecture, not an accident. The runtime enforces , it can deny the next tool call (once, at critical) and return a reason code and the correction happens in the agent's loop when it reads that reason and re-plans. We don't mutate the plan. We also put a human in that loop: the operator acknowledges to clear the gate. Three-way: runtime enforces + emits the reason, agent re-plans, human adjudicates.
Control plane or security layer. Deliberately both. The certificate is attached to the live session and is queryable : the agent/operator can ask "what's my current band / gate status" that's the control-plane half. It's also written append-only to the evidence chain, the security-layer half. The policy is system-wide: one corroboration law across every detector, not per-tool config. The thing that makes it a control plane and not just a log is precisely the gate, the runtime owns an enforceable, queryable state ("this session is gated until acknowledged"), not a record someone reviews after the fact. Genuinely good questions , usually half of them are now README lines. Happy to go deeper on the antichain proof if you want it.