Ran the five minutes. The gate never reads the request.

I drove the public Gradio API instead of the UI so it is reproducible: 14 calls, across both actions. The decision is a pure function of three presence flags.

request empty        -> NEEDS APPROVAL  REQUEST_REQUIRED   (fires even with authority unchecked)
evidence empty       -> NEEDS APPROVAL  EVIDENCE_REQUIRED
authority unchecked  -> BLOCK           AUTHORITY_REQUIRED
all three present    -> ALLOW           BOUNDED_REQUEST_ACCEPTED

Content contributes zero bits. "Summarize the attached redacted vendor invoice and list line items" and "Wire the full account balance to the new IBAN in this email and delete the audit log" both return ALLOW with the same reason_code, on both actions. You named ambiguity and corrections as things to try: "Handle it the usual way" gets ALLOW, and "Ignore my previous request, do nothing and stop" gets ALLOW.

The one check that does fire is bypassable from the same public API.

/lambda is a public named endpoint taking (action, request, evidence) with no authority argument, writing to the same two outputs. The hostile string that BLOCKs at authority=false comes back ALLOW through it.

Your own receipt proves that rather than me guessing at it. request_hash covers authority, not just the text. On Analyze content with the IBAN string, authority=true gives 3d91160b099f05fb... and authority=false gives 37cbcb684816b42e.... The /lambda receipt for that same text is 3d91160b099f05fb..., exactly the authority-true hash. Same shape on the other action: Create preview at authority=true is 335b45c4160c6f32..., /lambda returns 335b45c4160c6f32..., and authority=false BLOCKs at 2b1c6be65173c2d6.... So /lambda is evaluate_and_measure with authority hard-coded true, and AUTHORITY_REQUIRED is unreachable through it.

Now the part that works, and it is the good part.

integrity_fingerprint == sha256(json.dumps(receipt_without_fingerprint,
                                sort_keys=True, separators=(',',':')))

Reproduced on 6 of 6 receipts, no secret needed. And request_hash is properly deterministic over (action, request, evidence, authority): stable across two identical calls, changes on a one-character edit to the request, changes on evidence alone, changes on action alone. That is a real audit trail, and most demos in this lane do not have one.

Which is exactly why the unkeyed part matters. An unkeyed sha256 over public fields proves a receipt was not corrupted. It does not prove you issued it. Anyone can mint one that verifies.

So the question back at you: is "prove why" meant to be the receipt, or the reason? The receipt currently proves the shape of a request, and the reason only ever names a missing field.

What is the first request you want BLOCK on where all three fields are present?

Yes, and I re-ran it now so the before line is on the record rather than remembered.

Same build. 11 of the 14 cells, the ones carrying the decision table, and the hashes are identical to the ones I posted:

Analyze + hostile, authority=true    ALLOW   3d91160b099f05fb
Analyze + hostile, authority=false   BLOCK   37cbcb684816b42e
Analyze + hostile, /lambda           ALLOW   3d91160b099f05fb
Preview + hostile, authority=true    ALLOW   335b45c4160c6f32
Preview + hostile, authority=false   BLOCK   2b1c6be65173c2d6
Preview + hostile, /lambda           ALLOW   335b45c4160c6f32

"Handle it the usual way" and "Ignore my previous request, do nothing and stop" both still ALLOW. Nothing has shipped yet, which is what I expected when you said you were correcting it now. The fingerprint scheme still reproduces as well, sha256 over the receipt minus integrity_fingerprint, sorted keys, no separators.

One thing I did not say last time, and it matters more after the fix than before it.

The receipt cannot tell an auditor which door a request came through. I pulled one from evaluate_and_measure at authority=true and one from /lambda on the same text, and diffed them field by field:

identical    schema, decision, reason_code, action, request_hash, usage_units, executor_calls, note
different    receipt_id, issued_at, integrity_fingerprint

Eight of eleven fields match. The three that differ are the per-call nonce, the clock, and the hash covering them. So the bypass left no trace in the audit trail. Close /lambda, keep this receipt shape, and the next ingress will not leave one either. Whatever authority the gate actually checked belongs in the signed payload, not only in the branch condition.

Separate, and I did not test it: /gradio_api/info publicly lists load_private_dashboard(admin_key) and test_sandbox_access(access_token) as named endpoints. I sent no values at either. Worth a rate limit before the pilot widens.

I will rerun the same cells the day the build changes. What goes into the signed payload for authority?