The Release Should Explain Itself | torque

The Release Should Explain Itself

A production Kubernetes PostgreSQL migration where Torque denied an agent twice, authorized it only after proof and policy passed, then captured a replayable stack ledger.

Agent asks to mutate stack-apply for oracle-postgres-k8s

requested

Torque checks proof signed graph, hashes, gate, score, flight

23/23

Torque checks policy deny without allow, deny tampered proof

enforced

Torque records authorization agent-run.json, executed=false

recorded

Mutation runs explicitly stack apply with SQLite capture and export

succeeded

100 release score

20 proof graph artifacts

30 stack audit artifacts

108 stack audit events

Production Kubernetes delivery is no longer only human operators running Helm from CI. Teams are beginning to let AI agents inspect incidents, prepare migrations, and request changes. That changes the acceptance bar. RBAC can say who may write. GitOps can say what desired state should be. Neither explains why this particular stateful mutation is safe right now. Torque fills that gap by turning the change into evidence before execution: proof graph, gate report, policy decision, authorization record, and replayable stack ledger. The result is a production change surface where a human, CI job, or agent can propose work, but the write proceeds only when the proof matches the policy and the final run is inspectable later.

Argo CD and Crossplane were designed before agentic operations became the center of gravity. That is not a criticism of either project. Argo CD is a strong GitOps control plane: it compares Git state with cluster state and keeps applications synced. Crossplane is a strong infrastructure control plane: it turns cloud and platform resources into Kubernetes APIs. Both are useful.

But an AI agent asking to mutate production creates a different problem:

What proof makes this write safe enough to allow?

Torque's operating loop is intentionally narrow and proof-gated:

The agent asks to mutate.

Torque checks the proof.

Torque checks the policy.

Torque records authorization.

The mutation is allowed only with a passing gate.

I tested that loop end to end against a production Kubernetes cluster. The workload was not a synthetic terminal transcript and not a hello world chart. It was an Oracle/APEX-to-PostgreSQL modernization stack running against a live PostgreSQL target inside Kubernetes.

The durable evidence for the run stayed with the release artifacts under /root/torque-agentic-ops-e2e-20260523-095146.

The Workload

The stack was deliberately stateful. It modeled the kind of production change that usually falls between infrastructure-as-code, ticket comments, and a shell script someone hopes they can reconstruct later:

prove the Kubernetes target side is ready;

record change-window approval;

freeze the source Oracle/APEX system;

export source data;

create a PostgreSQL restore point;

expand the target schema;

backfill rows into shadow tables;

verify row counts and route state;

commit the cutover;

promote the application route;

contract the schema;

run a post-cutover check;

audit and export the run ledger.

The Kubernetes side created an isolated namespace, deployed PostgreSQL in the production cluster, and port-forwarded it to the Torque process. After the authorized stack apply completed, PostgreSQL reported:

stage rows: 3<br>shadow rows: 3<br>route flags: true,true,true<br>migration audit phase: contracted

That matters because this was not only "agent ran a command." The agent was asking to run a stateful production change program with sequencing, evidence, and irreversible-looking steps.

The Proof Gate

Before the mutation, Torque built a signed proof graph around the proposed change. The graph linked the stack plan, verifier report, digest-pinned image reference, BuildKit capture placeholder, SBOM, provenance, server dry-run evidence, runtime drift proof, rollout event proof, logs capture, SLO outcome, and repair channel.

proof gate: passed<br>gate checks: 23<br>release score: 100<br>flight events: 20<br>proof graph artifacts: 20<br>checked files: 12

The graph was signed with an ed25519 key generated for the run, and torque proof verify --require-signature verified the signature and file hashes.

Graph Signed file and artifact hashes.

Gate Required checks passed before mutation.

Policy Operation had to be explicitly allowed.

Ledger Stack run captured and exported.

The useful output was not only that the database ended in the right state. The run left behind a signed graph, a gate report, a score report, a flight file, replay output, an agent policy record, a release attestation, stack capture, stack audit, stack export, and event-chain integrity checks.

The Agent Was Denied Twice

The first request looked like an agent asking to perform a mutating stack apply:

"actor": "codex-agent",<br>"operation": "stack-apply",<br>"command": ["torque", "stack", "apply", "--config", "./stack.yaml",...