We Said “What Is Not Attested Is Not Real.” Here Is the Run.

deployment_signed: false
slsa_verified:     false
supply_chain_score: 0.2

That is what one of our two production environments reports about itself, from its own status endpoint. Its twin, asked the same question, reports a signed deployment record and build provenance, and a score to match.

Same code. Same container image, byte for byte, down to the digest. Both serving the same agent platform. One of them can prove where it came from. The other cannot. And the one that cannot is the more hardened of the two: the environment we lock down hardest is the one that has no evidence of its own origin.

Earlier this year I published a sentence meant as a foundation: what is not attested by the witness is neither real nor true. The post made the argument. It did not show a run. This is the run.

How both are true at once

The supply-chain score is not a label anyone typed. It is computed at runtime from what the running service can actually present: a build provenance record, an image digest that matches what that provenance says was built, a deployment record signed with a key the service does not hold, a workload identity the platform vouches for. Each piece of evidence adds weight. Missing evidence adds nothing.

The two services differ in one thing: the path their code took to production. The twin that scores well was deployed by the pipeline, and the pipeline writes the provenance and signs the deployment record as part of shipping. The hardened twin cannot use that pipeline. Its build trigger fails before it fetches the source, and it has not succeeded since it was set up in July. So it is deployed by hand, with a direct replace command, and a direct replace skips the steps that write the evidence.

The score cannot read code. It reads evidence. Identical code with no evidence scores like code nobody can vouch for, because operationally that is what it is. Attestation is a property of the path, not of the code.

That is the whole claim, measured. “Not real” was never a statement that the service doesn’t run. It runs, it serves traffic, it does its job. It is a statement about what anyone can demonstrate about it, and the system computes that answer on its own, without anyone having to agree with the claim.

We almost erased it

The unattested twin is deliberate now. It did not start that way.

When the score first showed up, every signal read like an unfixed defect: a red build history, a 0.2, an empty identity bucket, a note that said the root cause had not been found. We proposed the obvious workaround. Upload the source from a laptop and run the full build-and-sign pipeline against it, sidestepping the broken source fetch. It would have worked. It would also have produced a perfectly attested service and silently destroyed the only side-by-side demonstration we had that attestation changes the computed answer.

The gap stays. A deployment file in that environment now carries a header that says, in capitals, not to fix it, and records the exact workaround and why it must not be run without retiring the demonstration first. The broken path is documented as the control arm of an experiment, not as a bug.

That decision is cheap to describe and easy to undo by accident, which is why it lives in the file that would be edited, not in someone’s memory.

What the run does not show

The score has its own limits, and they are in the code, not in a footnote.

One of its inputs is weaker than its name. The “verified” signal for build provenance currently reads a flag the build sets about itself, not a cryptographic check of the image signature at runtime. A comment in the scorer says exactly that, and the scorer’s maximum sits below 1 because the runtime signature check is not there yet. The score does not round itself up to the ceiling it hasn’t earned.

And the score is one dimension. It answers where did this come from. It does not answer who is calling or what is it doing, and it must not be read as if it did. How those dimensions are meant to combine into a decision is a separate question, and the engine’s current answer to it is not yet the one the doctrine specifies.

What changed

Three things, each a mechanism:

• The attested/unattested pair is kept as a standing experiment, not a defect. The deployment config carries the do-not-fix header, so the fix that would erase the control has to argue with the file before it can run.
• The score reports its evidence, not just its number: signed or not, provenance verified or not, identity present or not. A reader who disagrees with 0.2 can see which inputs produced it.
• Every service answers the same question about itself in the same shape, so “deployed” and “deployed with evidence” are two readings of one field, not two opinions. A service that can’t prove its origin says so in the place an operator already looks.

The line that stays

The first version of this claim was an essay. It argued that unattested action is functionally identical to no action, and that a team that softens the rule discovers the gap only when it needs the chain.

The run says it more plainly. Two services, the same bytes, two different answers, and the difference is entirely in what was written down on the way to production. Nobody had to believe the claim for the system to compute it.

Same code. Different evidence. Different answer.