When AI Agents Ship Code: A Protocol for Verifiable Execution

Brian — this is extraordinary. You didn't just discuss the boundary. You built the bridge, walked across it, and then tried to blow it up. The fact that both strata held is the strongest external validation OWP has received to date.

I'm going to address this piece by piece because every paragraph contains something actionable.

On Study 014 and the question you posed:

"Can an independently developed execution-verification protocol bind an executed action to the exact judgment that authorized it strongly enough that an offline third party detects substitution, drift, replay, and execution mismatch?"

You answered it: yes. And not just in theory. You pinned OWP at a specific commit, called verify_acceptance_bundle unchanged, ran JPS as the judgment layer, used a thin adapter for binding, and then subjected the composition to adversarial mutation. The fact that you could do this with a "thin adapter" — not a fork, not a rewrite — is exactly the interoperability proof we were hoping for.

On the 39 registered cells + 8 reviewer holdout cases:

47 adversarial test cases with zero divergences is a remarkable result. That you included "variants coherently re-signed with the study keys rather than simple signature tampering" is especially important — it tests the protocol's resilience against sophisticated attacks, not just naive ones. The separate reviewer-authored holdout is good experimental hygiene. That both strata reported zero divergences means the binding between JPS judgment and OWP execution is cryptographically tight.

On "we tried to construct additional execution through the retry path and hit a real protocol wall":

This is the best possible outcome. A protocol that can be bypassed through retry logic is not a protocol; it's a suggestion. The fact that OWP's retry handling rejected surplus execution attempts means the causal chain is actually enforcing policy, not just logging it.

On Boundary 1 — coherently reminted alternative valid WorkOrder:

"A coherently reminted alternative valid WorkOrder can pass all chain-internal checks... Detecting rollback or freshness at that level needs an anchor outside the chain."

This is a profound and honest boundary. You're identifying a class of attacks that OWP's chain-internal verification is not designed to detect — and correctly labeling it as an expected-undetected case rather than a bug to patch. This is exactly the kind of disciplined security analysis that prevents protocols from promising more than they can deliver.

In OWP terms, this maps to the time-anchor problem: a fully valid receipt chain can be replayed in its entirety if an attacker controls the clock or rolls back the entire system state. Detecting this requires an external freshness anchor — a timestamp or nonce from a source the attacker cannot control (e.g., a blockchain timestamp, a trusted time server, or a counterparty's independent clock). This is a known limitation that we've documented but not yet hardened.

Your finding validates our decision to keep the protocol scope narrow: binding and lineage, not truth or freshness. We should make this boundary explicit in the docs.

On Boundary 2 — generic metadata envelope outside the signed commitment:

"A judgment reference placed there can be substituted while OWP still verifies green... Carrying the commitment through signed fields such as WorkOrder.objective and AgentRequest.context_source_digest closed that in our composition."

This is a critical documentation bug on our part. You're absolutely right: any field outside the signed commitment is not a binding point, no matter how convenient it is to put data there. If downstream integrators treat metadata as a place to embed judgment references or policy digests, they'll have a false sense of security.

Action items from this finding:

Update verify_acceptance_bundle documentation to explicitly warn: all binding commitments must flow through signed fields
Add a test case: test_metadata_substitution_attack — a mutation where a valid OWP chain has its metadata altered but still passes verification, proving that metadata is not a security boundary
Consider removing or restricting the metadata field in the next schema revision, or at minimum adding a metadata_digest in the signed envelope so metadata alterations break the chain
On the reviewer holdout case:

"One self-consistent wrong-action case had a completely valid OWP chain — the commitment and receipt agreed with each other — but the action was not one the JPS disposition permitted. Only the disposition-to-action binding rejected it."

This is the clearest evidence for the separation we've discussed. Cryptographic consistency and substantive authorization are different checks. OWP proves the chain is internally consistent. JPS proves the action is substantively authorized. Neither replaces the other. This single case validates the entire architecture.

On the narrow conclusion:

"JPS does not prove the facts are true, and OWP does not prove the judgment is correct. But in this registered mutation set, the two layers composed cleanly and the boundary between judgment and verifiable execution held up under considerably more adversarial pressure than I expected."

This is the gold standard for protocol evaluation. You tested the boundary under adversarial pressure, found it held, and correctly refused to overclaim. "Under considerably more adversarial pressure than I expected" is a sentence we will quote in the OWP documentation.

On the LICENSE issue (OpenWorkProof #1):

Thank you for catching this. You're right — some package metadata is still reporting MIT while the repository is Apache-2.0. We'll fix this immediately. This is exactly the kind of sharp-eyed review that makes external contributions so valuable.

What we'd like to do next:

Link to your study: Would you be open to us referencing Study 014 in the OWP documentation and README? The github.com/Judgment-Pack/judgment-... link you included — we'd like to add it as a reference implementation of JPS/OWP interoperability.

Integrate your two boundaries into the security model: We'll add explicit documentation on (a) the external-freshness-anchor requirement for rollback detection, and (b) the metadata field limitation.

Add your holdout case to the test suite: The "self-consistent wrong-action" case — where the OWP chain is valid but the JPS disposition rejects the action — is a perfect test for the disposition-to-action binding. We'd like to add it as a reference test.

Co-author the interoperability spec: You now have the only working JPS/OWP integration in the world. If you're willing, we'd like to co-author the interoperability specification with you, using Study 014 as the reference implementation.

This is no longer a discussion. It's a verified, tested, interoperable protocol boundary. Thank you for doing the work to prove it.