A receipt can be cryptographically valid.
The judgment can recompute exactly.
The action can still be bound to the same facts, same policy bytes, and same disposition.
And the whole thing can still be stale.
That is the problem behind our newest experiment.
Suppose an agent made a decision under policy version v1.0.0.
At the time, that policy was valid.
Later, the organization retires v1.0.0 and replaces it with v1.1.0.
Someone now presents the old decision again.
Nothing inside the original decision has changed.
Nothing inside the receipt has changed.
Every digest still matches.
Every signature can still verify.
Replay produces exactly the same disposition.
The missing fact is outside all of those artifacts:
Is this policy version still in force?
That became Study 016 - Policy Currency Anchor.
This started with a public architecture discussion
The study grew directly out of a discussion with @dengyier, the author of OpenWorkProof.
In Study 014, we composed our deterministic judgment layer with OpenWorkProof's signed work orders, capability grants, execution receipts, causal replay, and offline verifier.
That experiment asked:
Can a third party prove afterward which recorded judgment corresponds to which recorded action?
It worked across the registered mutation set, but it left an important boundary open.
A perfectly self-consistent chain cannot tell you whether the policy inside that chain is still the policy the organization considers authoritative.
In the DEV.to thread, we started sketching what an external anchor might look like.
Our gateway already had a related pattern: a small signed registry outside the artifacts it checks, used to detect replay and rollback.
But the gateway tracks input lineage, not policy currency.
So the idea became:
Keep the registry pattern. Change the subject.
Instead of anchoring:
which input bytes did this judgment use?
anchor:
which versions of this policy series are in force?
Study 016 turns that idea into something measurable.
A fourth check, not a replacement for the first three
Study 016 did not redesign Study 014.
It added one new check on top of the existing ceremony.
The stack became:
OpenWorkProof verification
|
v
judgment binding
|
v
deterministic replay
|
v
policy currency
Each layer asks a different question.
OpenWorkProof
Is the authorization and execution receipt chain internally valid?
Judgment binding
Are these still the exact pack, facts, disposition, and action that were committed together?
Deterministic replay
Do the retained pack and facts still reproduce the recorded disposition?
Policy currency
Is this pack version in the supported set at the registry snapshot the verifier trusts?
That last question cannot be answered from the decision artifact alone.
So we made the changing world itself an artifact.
The minimal registry
The study implemented a deliberately small signed registry.
It supports policy-version events such as:
add
retire
reinstate
The events form a hash chain.
The registry publishes signed snapshot heads.
An offline verifier receives retained registry state plus out-of-band trust material and checks the history before deciding whether a particular tuple is current:
pack identity
+
pack version
+
pack digest
This is a study prototype, not a proposed standard.
Nothing from it was silently added to JPS Core, the runtime, the gateway, or OpenWorkProof.
That separation matters because the point of the study was to measure the mechanism before deciding whether any project should own it.
The experiment
The preregistration went through five cross-vendor adversarial review rounds before freeze.
A reviewer using a model from a different vendor also authored a separate 10-cell holdout stratum.
Those holdout cells were committed before freeze and had never been executed.
Then the registered primary attempt ran once from the freeze commit.
The result:
Locked stratum:
22 / 22 adjudicated
0 endpoint divergence
0 pipeline-invalid
Reviewer holdout:
10 / 10 constructed on first execution
10 / 10 adjudicated
0 divergence
0 pipeline-invalid
The clean numbers are useful.
The boundaries are more interesting.
Finding 1 - the registry caught a failure the receipt chain could not
The central test reused a decision under a policy version that the signed registry had retired.
The important part is what did not change.
The judgment and execution-chain bytes were the same as the passing control.
So:
OpenWorkProof: PASS
Binding: PASS
Replay: PASS
Only the external world moved.
The currency registry now said:
v1.0.0 -> retired
and the fourth layer returned:
not-current-at-snapshot
That is the result I wanted from the experiment.
It demonstrates why currency is structurally different from integrity.
A digest can tell you:
This is still the same artifact.
A signature can tell you:
This authority signed these bytes.
Replay can tell you:
These inputs still produce this result.
None of those statements mean:
This artifact is still in force.
Currency is relational.
The policy may stay byte-for-byte identical while the authoritative world around it changes.
So the authoritative world has to become part of the retained evidence too.
Finding 2 - a policy registry cannot solve authorization-contract currency
This was deliberately registered as something the new layer should not catch.
Take the exact same judgment commitment:
same pack
same version
same digest
same facts
same disposition
Now bind it under a different but equally valid WorkOrder.
All four layers pass.
That is the correct result.
A policy-version registry has no signal to inspect because the policy tuple did not change.
This is a different kind of currency question:
Is this still the authorization contract under which the action should proceed?
Study 016 does not solve that.
And I do not think the right response is to make the pack registry understand WorkOrders.
The experiment gives us a cleaner boundary:
policy currency
!=
authorization-contract currency
If the second problem deserves an anchor, it needs a subject appropriate to the authorization/receipt protocol.
Finding 3 - two valid histories expose the stateless-verifier ceiling
The next case is more uncomfortable.
One authority.
One policy series.
Two contradictory histories.
Both are internally valid.
Both are correctly signed.
Give history A to a fresh verifier:
PASS
Give history B to a different fresh verifier:
PASS
Neither isolated verifier sees anything wrong.
There is nothing malformed inside either history.
The contradiction exists only when someone can compare the two views.
We also ran a stateful variant.
Once the verifier retained a previously accepted head, presenting the conflicting continuation was refused by prefix containment.
That gives us a narrower measured statement than:
State solves equivocation.
What we actually observed is:
Prior verifier state can expose some conflicting histories that a fresh isolated verifier cannot.
General split-view resistance needs more.
Potentially:
- transparency logging
- witnesses
- cross-signing
- cross-view comparison
- retention requirements
- verifier enforcement
- assumptions about witness independence and non-collusion
Those remain design questions.
The study measured the floor.
It did not design the whole trust system.
Finding 4 - offline verification cannot reconstruct "current when used"
There is another limit no amount of careful digesting removes.
Consider two histories.
History A
Policy v1 is current.
The agent legitimately uses it.
Later, v1 is retired.
Much later, an auditor verifies the old decision.
History B
Policy v1 has already been retired.
Someone reuses the old decision anyway.
Later, an auditor verifies it.
At verification time, the retained decision bytes can be identical.
The decision cannot tell the auditor which history happened.
So the currency layer makes a deliberately narrower claim:
Is this version in force at the pinned registry snapshot?
It does not claim:
Was this version current at the exact moment the action occurred?
That stronger question requires trustworthy temporal evidence connecting execution time to policy-state history.
For an offline-first design, that may require another artifact.
Or the honest answer may eventually be that some forms of real-time freshness are irreducibly online.
The reviewer corrected something I had already said publicly
This part matters to me because the correction is against my own earlier argument.
In the discussion with dengyier, I initially described bootstrap too neatly.
Roughly:
pin an authority key
+
pin a genesis checkpoint
=
bootstrap trust
Adversarial review of the RFC amendment rejected that framing.
The reviewer was right.
A pinned signing key proves:
This key authenticated the history I was handed.
It does not prove:
This is the only history that key has ever signed.
And a pinned genesis checkpoint does not prevent the signer from creating two contradictory histories after that common checkpoint.
The trust problem also changes depending on the signer model.
A publisher signing its own currency assertions and a neutral log attesting inclusion do not necessarily need the same bootstrap artifacts.
So RFC 0011 now leaves the questions open rather than smuggling an answer into the design:
- What does a fresh verifier actually need under each signer model?
- Does it need an independently supplied starting checkpoint at all?
- What threat would such a checkpoint address?
- How should key rotation work?
- What would a real witness contract require?
- How would split views become observable?
- What assumptions about witness independence and non-collusion are necessary?
That is a better outcome than preserving a clean architecture diagram that the evidence did not support.
Why the holdout matters
The locked matrix is useful, but it was developed while we were building the study.
The holdout is different.
The reviewer authored ten cells before freeze.
None had been executed.
On their first-ever execution, all ten landed exactly on the registered outcomes.
Some tested strict parsing.
Some tested first-failure ordering.
Some tested exact size boundaries.
One combined replay and currency failures and verified that the two layers failed independently.
Another deliberately changed unauthenticated labels without touching signed bytes and was expected to pass everything.
It did.
That last kind of case matters.
An adversarial suite should not merely contain more ways to fail.
It should also contain cases designed to prove the verifier is not reacting to irrelevant changes.
What this study does not establish
The cleanest result would be easy to oversell:
We built the missing policy registry.
That is not what happened.
Study 016 establishes something narrower.
Within the registered cells, a small hash-chained signed pack-version registry, added as one fail-closed step over Study 014's unchanged ceremony:
- detected reuse of a version retired at the pinned snapshot
- rejected the registered invalid-registry states
- detected an older-snapshot replay when the verifier retained the required prior state
- accepted the constructions registered as outside its scope
- reproduced the expected split-view and freshness ceilings
It does not establish:
- policy truth
- fact truth
- real-time staleness
- authorization-contract currency
- resistance to registry equivocation for fresh isolated verifiers
- trust from nothing
- a standardized registry format
- interoperability with an independently implemented consumer
- JPS conformance
The registry says:
This authority asserts that these versions are in force at this signed snapshot.
It does not say:
These policies are correct.
Same ceiling as the rest of this research line:
binding and lineage, not truth.
The next evidence should probably come from outside JPS
There is one methodological limitation I do not want to hide.
We wrote both sides of the new currency check.
We wrote the registry.
We wrote the consumer step.
The reviewer holdout gives us useful prospective adversarial evidence, but this is still one project testing its own currency interpretation.
That is not interoperability evidence.
The stronger test would be an independently designed consumer.
OpenWorkProof is a natural candidate because Study 014 already established the receipt-side boundary and because this whole experiment grew out of the discussion with @dengyier.
But that does not mean OWP should adopt our schema.
The stronger experiment would be the opposite:
If OWP ever needs policy currency, let its author design the consumer by OWP's own process, then test whether our registered cells still describe the boundary correctly.
Maybe the formats converge.
Maybe they do not.
Either answer would teach us more than another JPS-owned implementation agreeing with itself.
The progression so far
These last few experiments now form a useful sequence.
Study 013 - behavior
Did the surrounding application actually respect the judgment at runtime?
Study 014 - provenance
Can a third party later verify the binding between the recorded judgment and the recorded action?
Study 016 - currency
Can an offline verifier determine whether the recorded policy version is in force at the registry state it trusts?
They are not three permanent product categories.
EvalForge, OpenWorkProof, JPS, and the surrounding OSS projects are all evolving and may expand or converge.
The useful distinction is narrower:
What responsibility did each pinned implementation actually own in the experiment we ran?
That keeps the claims attached to code rather than turning early open-source projects into fixed architecture boxes.
Receipts
Study 016 - Policy Currency Anchor
Study 014 - OpenWorkProof binding
RFC 0011 - Judgment Currency Anchor
https://github.com/Judgment-Pack/judgment-pack-spec/blob/main/rfcs/0011-judgment-currency-anchor.md
OpenWorkProof
https://github.com/dengyier/OpenWorkProof
Thanks again to @dengyier for pushing on the external-anchor question in public. The useful part of that discussion was not that we agreed on an architecture. It was that the conversation produced a claim concrete enough to test - and the test then forced part of my own answer to change.
The next question is no longer:
Do we need an external policy-state anchor?
For this threat model, we now have evidence that it adds a distinct check.
The harder question is:
Who should operate that anchor, and what would make two contradictory signed views observable to verifiers who never meet?
Top comments (2)
The policy-currency layer is the right call, but I think the "can't tell legitimate historical use from unauthorized replay" limit is a missing temporal binding rather than a fundamental one. The receipt binds the policy version but not the registry state the decision actually observed. Bind that too: have each decision cite the signed registry head it validated against, inside the chain. Then a replay after retirement stands out, because the checkpoint it cites sits behind the retire event on the hash chain, while a decision genuinely made under vN carries proof it saw a registry where vN was still current. That's the inclusion-proof half of the transparency-log direction you gestured at, just pulled into the receipt itself instead of bolted on beside it.
@circuit - yes, I think citing the registry head buys something real.
The easiest way I think about it is like citing a signed Git commit.
Suppose the policy registry looks like this:
A decision is created and records:
Later the registry moves:
Now an auditor can say something stronger than "v1 is not current anymore."
They can say:
I think that is useful, and I would want it in a real consumer.
Thinking about your proposal more, though, there are actually two separate questions after that.
The first is an evidence question:
The second is an organizational-policy question:
Those are not the same thing.
For example, imagine:
One company might say all unused v1 decisions expire immediately at H2.
Another might allow a 24-hour grace period.
Another might grandfather any decision created while v1 was current until that decision's normal expiration.
So I would not want the registry itself to say:
Its job should be narrower:
Then the receipt layer can provide evidence about the decision and execution, and the organization's transition rule decides what that history means.
The cited head helps with the first part.
It lets us establish something like:
And if every execution also creates a fresh receipt that cites the registry state it sees, we could get:
Now we have much better evidence.
A transition rule could then decide:
That separation feels important: the registry records policy state; it should not define the organization's transition semantics.
There is still one adversarial limit.
A party able to coherently remint the execution receipt could deliberately cite H1 even though H2 already existed.
That is similar to saying:
You can prove B is a real commit and reconstruct the repository at B.
You cannot prove from that statement alone that the artifact was actually built before commit C existed.
So I would summarize your proposal this way:
Citing the registry head proves which policy state the decision or receipt claims to rely on. That gives an organization's transition policy much better evidence to work with. It does not, by itself, prove when the action happened relative to later registry states.
That last part still needs some trusted ordering mechanism.
And I think this gives us a better experiment than the three cells I originally had in mind.
Rather than hard-code "use after retirement = failure," I would test the same evidence history against several explicit transition rules:
Then separately test the adversarial case where a reminted execution deliberately cites an older valid head.
That would tell us two things independently:
That seems worth measuring rather than settling by argument.
RFC 0011 tracks the current freshness/ordering boundary here:
github.com/Judgment-Pack/judgment-...