The Governance Engine That Remembers

My system’s gate-status endpoint exposes a signal that did not exist in the codebase a week ago. When I captured it for this note, it read:

The endpoint reported seven contributing events across three origins. No individual snapshot crossed the configured gate threshold, but their decayed contributions accumulated above HOLD. Because the signal is observe-only, nothing was throttled — that is the point of this stage. The climb is the argument, so let me be exact about what this number is, and just as exact about what it is not.

The blind spot a memoryless gate can’t close

A governance gate, in almost every system I have looked at, is memoryless. It scores one decision — is this action permitted? is this spend approved? is this risk acceptable? — and forgets it before scoring the next. That is usually the right design for a single action. It leaves one thing uncovered: a risky sequence of individually-fine actions. Ten actions that are each 0.5 on a 0-to-1 risk scale are all below the configured 0.65 per-call threshold, so a memoryless gate waves each one through — correctly, in isolation. But 0.5, ten times, is a trajectory, and a gate that forgets the last decision cannot see a trajectory. It cannot add up what it refuses to remember.

In the open-source engine, that trajectory is composed per subject — an agent, a session, an actor. A worked example ships in the tests: an agent whose seven consecutive decisions each evaluate to RUN individually composes past the fail threshold and the composed verdict becomes FREEZE. No single gate saw a problem. The sum did.

What the 2.14 actually contains — and what its subject is

Here is where I have to be careful, because the reading above is not an agent’s decision trajectory. Its subject is the system’s security environment. The same accumulation mechanism is applied to a different input: each security event in the last 72 hours is converted to a 0–1 risk weight by severity (a CRITICAL event weighs more than a HIGH), those weights are composed with a 24-hour decay half-life, and the result is the 2.14. It is threat-pressure composition, not agent-decision composition. The mechanism is shared; the subject is not. Treating “agent trajectory” and “environmental threat pressure” as the same thing would be sleight of hand, and I don’t want to do that.

The key configuration behind the number, so its scope is clear:

Two things this number is not

First: the cap is deployment logic, not the engine. The generic open-source composer (constitutional-agent’s AccumulatedRiskComposer) sums optionally-decayed weights for a subject; it does not ingest raw IP events and it does not cap by origin. In this deployment, an upstream adapter converts security telemetry into bounded risk contributions before recording them against the system subject, and caps each origin’s contribution at 1.5 — below the 2.00 HOLD line. So a single origin can raise the reading, but it cannot trigger HOLD by itself. That per-origin cap is my integration’s noise-containment logic, not a feature of the published composition module.

Second: three “sources” is not three actors. The reading came from three addresses that all sit inside a single /24. They may reflect one operator or shared infrastructure — hosting, NAT, a scanning service, compromised hosts; the telemetry cannot establish actor identity. That is the honest limit of this signal: distinct-origin breadth is not distinct-actor breadth. The cap contains noise; it does not make the signal Sybil-resistant. A distributed attacker — a botnet, a rotating proxy pool, IPv6 address churn — can manufacture apparent breadth. A stronger deployment should compose across more durable principals: authenticated identities, tenants, credentials, campaigns, or correlated source clusters, wherever those identifiers exist. IP address is the weakest available origin identifier, and I am using it only because it is what the security log provides.

A gate that forgets every decision can never see the one risk that only exists in the sum of them.

What one reading does and does not prove

I want to be disciplined about the claim. This telemetry proves the path is active: the composition mechanism is wired into the production gate status, it is reading live inputs, and it produced an interpretable value that crossed its own threshold. That is real implementation movement, and a week ago it did not exist. What it does not prove is that the signal is calibrated, robust, or operationally useful. One value is not validation. And the signal is deliberately observe-only: it is surfaced read-only and does not change the system state. Enforcement is gated on calibration, because binding an uncalibrated threshold against real security-event volume is how you cause the incident you were trying to prevent — the same fail-safe discipline that once had this system throttle itself over contained noise. The composition module itself is new (constitutional-agent v0.6.0) and not yet hardened to the degree of the core gates. The 2.14 is the calibration clock starting, not a finished control.

Even with all of those caveats, the shape of the thing is the point. Identity establishes the acting principal; authorization constrains its permissions; policy evaluates individual actions; composition evaluates the accumulated trajectory. That last layer — governing what delegated autonomous authority accumulates to, across sessions within a rolling window — is a capability I have not found documented in the governance engines I compared. It is the part worth building carefully, and worth being honest about while it is still young.

Comparison basis (public documentation reviewed 2026-07-18): Microsoft Agent Governance Toolkit / ACS, Galileo Agent Control, Runlayer, NVIDIA OpenShell. The claim is narrow: I did not find documented cross-session accumulation of per-decision constitutional-risk weights — not that these products lack every stateful control. Several document session-wide visibility, budgets, or audit trails; that is a different mechanism.