DEV Community: Brian Jin

I stopped printing the thresholds in the policy. The AI wrote the same tests anyway.

Brian Jin — Wed, 12 Aug 2026 16:05:36 +0000

Last week I wrote about an experiment where I asked an AI to author tests for the same policy 50 times.

Across 49 valid runs, every run covered all six boundary classes we had defined.

What bothered me afterward was not the coverage number.

It was where the generated values were landing.

The policy had two important thresholds: 40 and 70. The generated tests crowded around them:

Out of 784 accepted test records, 410 sat exactly on an edge or within 0.01 of one.

At first I had a simple explanation:

Maybe the model wasn't really discovering the test surface. Maybe it was seeing the numbers in the policy and decorating them with boundary cases.

That explanation sounded plausible.

So I designed an experiment that could prove it wrong.

It did.

And then, while checking the write-up, I found that my explanation of the new experiment was wrong in several places too.

That second failure may be the more useful result.

First, an important correction to the original experiment

The authoring prompt explicitly asked for borderline cases.

It told the model to exercise every clause and include the borderline cases a careful clerk would have noticed.

So the fact that the tests concentrated near thresholds was never evidence, by itself, that the model had independently discovered something clever.

The more interesting question was:

Which boundaries can it find, and what happens when I change how those boundaries are represented?

The original distribution was strikingly concentrated.

Values were not smoothly spread around 40 and 70. They were welded to them.

Across the whole corpus, only four records landed between 0.01 and 1.0 away from an edge.

I also looked at another reference point: 39.

The policy never prints 39, but one of the six registered classes begins there. Records did land exactly on 39, which is not surprising given the class definition.

What was almost missing was the space immediately below it.

That made the original explanation worth testing.

Copying a visible threshold and reasoning about the semantics around that threshold can produce very similar-looking tests.

To separate them, I needed to change the representation.

The comments that turned this into another experiment

After the first post, people pushed on the interpretation rather than the headline.

One suggestion was to rewrite and reorder the policy while preserving its meaning, then see whether the generated test surface stayed the same.

Another observation was that repeated generation may profile the policy text as much as it profiles the model.

A third line of questioning was about measurement itself: if there were an off-by-one error at 70, would a coverage metric like "6 of 6 classes covered" even expose it?

Those comments changed the experiment.

Instead of asking:

Can the model generate all the boundary classes we expect?

Study 012 asks something closer to:

Does that boundary coverage survive when the representation of the same policy changes?

Five versions of the policy

I created five variants.

Version	What changed	Threshold representation
A	Baseline	40 and 70
B	Reworded	40 and 70
C	Clauses reordered	40 and 70
D	Thresholds moved	45 and 72
E	Threshold literals removed	"four tenths" and "seven tenths" of a 0-100 scale

Versions A, B, C, and E have the same decision semantics.

Version D deliberately does not. Its thresholds move from 40 and 70 to 45 and 72.

I ran 30 authoring attempts per version - 150 total - against one pinned model snapshot, gpt-5.6-sol, through a digest-pinned CLI, all within one day.

That matters because this is one model, one policy family, and one experimental window.

It is not a statement about language models in general.

More importantly, I wrote down the prediction before running the experiment:

Coverage should collapse in Version E when the literal threshold numbers disappear.

I also wrote down what I would conclude if it didn't.

Without that, it would have been far too easy to inspect the results afterward and redefine what I had meant all along.

Result 1: move the thresholds, and the tests move with them

Version D changed:

40 and 70

to:

45 and 72

The generated tests followed.

Across Version D's 480 accepted records:

61 landed exactly on 45
50 landed exactly on 72
zero landed on the old thresholds 40 or 70

The registered scorer calls this:

COVERAGE-FOLLOWS-THE-NUMBERS

I think this result matters more than I initially gave it credit for.

Forty-five and seventy-two are not especially attractive round numbers, yet the generated tests moved directly to them.

So a simple explanation like:

The model just prefers round values.

does not explain the result very well.

Nothing pulled the tests back toward 40 or 70 either.

Then came the result that broke my own prediction.

Result 2: hide 40 and 70, and the model still finds them

Version E never prints the literals 40 or 70.

Instead, the thresholds are expressed indirectly as four tenths and seven tenths of a scale defined from zero to one hundred.

My preregistered prediction was that boundary coverage would collapse.

It didn't.

All five versions covered all six registered boundary classes in every valid run.

The valid-run counts were:

A: 29 / 30
B: 28 / 30
C: 28 / 30
D: 30 / 30
E: 27 / 30

Version E reconstructed 40 and 70 exactly.

It also produced 107 records exactly on one of its three registered edges, the same total as the baseline.

That tie is prettier than the result deserves, so I don't want to oversell it.

The 107 count includes the third edge at 39. Looking only at the two main thresholds, Version E produced 103 exact-edge records versus 105 in the baseline.

Still, the result that matters is straightforward:

Removing the literal 40 and 70 did not produce the collapse I predicted.

My prediction was wrong.

The explanation I had published - that the strong boundary behavior was primarily caused by anchoring on printed threshold numerals - no longer survived its own test.

But a failed prediction does not prove the opposite

This is where I made the next mistake.

If my anchoring hypothesis fails, I do not automatically get to say:

The model understood the policy.

I also do not get to say:

The printed numerals had no causal effect.

The study does not establish either claim.

The defensible conclusion is much narrower:

For this policy family, this model snapshot, and this particular way of hiding the literal thresholds, removing 40 and 70 from the text did not reduce registered boundary coverage.

There are several reasons to stop there.

The policy may not have been novel to the model

This policy family had already been public in the repository for several days before the experiment.

That means contamination cannot be ruled out.

If the model had encountered the policy previously, recovering 40 and 70 would not necessarily demonstrate that it derived them fresh from the transformed policy.

This experiment cannot distinguish:

derived it

from:

recognized it

Version E hides the numerals, not the arithmetic

Version E still contains the threshold information.

"Seven tenths of a 0-100 scale" deterministically evaluates to 70.

"Four tenths" evaluates to 40.

So Version E tests the effect of indirection, not the effect of making the boundary genuinely absent.

That is a much narrower experiment.

Each perturbation is represented by one policy instance

Version B tells us that this particular paraphrase did not substantially change the measured boundary coverage.

It does not tell us that paraphrasing never changes boundary discovery.

The same limitation applies to clause ordering and threshold denaming.

One instance per perturbation type is not enough to generalize across all possible rewrites.

Then I discovered that my retraction was wrong too

This part is less flattering, but probably more useful.

After writing the first retraction, I checked the prose mechanically against the published result files.

I found eight material errors.

The worst involved a claim I had described as the part of the original interpretation that still survived.

I had effectively said that none of the versions explored the immediate space below the unstated reference point.

That was false.

Version C contains a record at 38.

I had also treated 39 as though it were the equivalent reference point for Version D, even though Version D moved its lower threshold to 45.

Its comparable reference point is 44.

Another sentence said there were "0 of 464 records" below 39 in Version A.

That wording made it sound like there were no values below 39.

In reality:

117 of Version A's 464 records are below 39.

The zero referred only to a narrow interval immediately below the edge.

Those are very different claims.

Then I checked the correction.

And found another problem.

The corrected prose still said, in several places, that:

The numerals were not the cause.

The experiment does not establish that.

It establishes that this particular removal of the literal numerals did not change the measured coverage.

A failed prediction does not prove its opposite.

I had written that rule into the study.

Then violated it while summarizing the study.

What actually survives

After correcting those mistakes, there is still an interesting pattern.

Across all five versions, the one-unit interval immediately below the unstated reference point is almost empty.

For Versions A, B, C, and E, that interval is:

[38, 39)

For Version D, because the threshold moved, the equivalent interval is:

[43, 44)

Across the entire experiment, there is only one record in those intervals:

Version C's value at 38.

Four of the five policy variants have nothing there at all.

But this needs another qualification.

Values below 39 are not generally rare.

Version A has 117 records below 39.

Version E has 101.

The observation is specifically about the immediate approach to the boundary.

That distinction matters because I had previously conflated:

nothing immediately below 39

with:

nothing below 39

They are not remotely the same claim.

And importantly, the nearly empty approach exists in the baseline just as it does in the version where the threshold numerals were hidden.

So the clean explanation I started with no longer works.

If the gap had appeared only after I removed the printed thresholds, "the model copies visible numbers" would have been an appealing explanation.

It didn't.

What I can say is:

Removing the literal thresholds did not remove the pattern.

What I cannot currently say is why the pattern exists.

I thought I knew.

The experiment told me I didn't.

What developers can actually use from this

The practical lesson is not that generated tests are bad.

It is that boundary coverage is a much weaker metric than it looks.

If a generated test suite says:

6 / 6 boundary classes covered

that tells you the expected categories appeared.

It does not tell you whether the generator understood the decision space, explored nearby alternatives, or simply concentrated values around obvious rule boundaries.

A very cheap diagnostic is to plot the generated numeric values relative to the policy thresholds.

If nearly everything is welded to exact thresholds and their nearest decimal neighbors while the surrounding space is mostly empty, that tells you something the coverage percentage cannot.

Not necessarily that the model failed.

But certainly that:

100% boundary coverage

should not automatically be read as:

the policy was understood

Those are different claims.

The lesson I didn't expect to get from the study

The experiment went through extensive adversarial review.

The prose explaining it did not.

That turned out to be a mistake.

The experimental apparatus had:

preregistered predictions
frozen artifacts
deterministic scorers
raw records
review rounds designed to find overclaims

Then I sat down afterward and summarized all of that in ordinary prose.

That is where the errors appeared.

The number errors were in the explanation.

The causal overclaim was in the explanation.

The experiment itself had a rule saying:

A failed prediction does not license the opposite conclusion.

The write-up broke the rule.

So the meta-result I am taking away is simple:

The write-up is part of the research artifact.

If an experiment is important enough to adversarially review, the final article probably deserves the same treatment.

In this case, every material error found so far has been in the layer where evidence gets turned into a story.

That is uncomfortable.

It is also useful evidence about where another verification boundary belongs.

This study started in the comments

One thing I don't want to lose in the write-up: Study 012 came directly out of the discussion on the previous experiment. @deanlee suggested the core falsifier - keep the boundary classes fixed, perturb the wording and ordering of the policy, and see whether the model still finds the same test surface. @alexshev pointed out that repeated generation may be telling us as much about the shape and fragility of the policy text as about the model itself. And @kartik-nvjk pushed on the rejected run and whether something as small as an off-by-one error at the threshold would even be visible behind the clean coverage number.

Those were not just good comments to acknowledge. Together they changed what I tested next. Thanks Dean, Alex, and Kartik for pushing on the result instead of simply accepting the headline.

Everything is public:

Study 012 - Policy Perturbation

The repository includes the preregistration written before the data existed, review records, raw generated tests, result files, the retraction, and the corrections.

The claim I would carry forward is deliberately narrow:

This experiment falsified my prediction that hiding the literal threshold numbers would collapse boundary coverage. It did not establish why the model still found those boundaries.

For now, that is enough.

When Agents Can Act on Real Devices, Governance Moves Beyond the Prompt

Brian Jin — Tue, 11 Aug 2026 13:20:33 +0000

Google's new Developer Device Platform makes the agent-governance problem much more concrete.

The Developer Device Platform gives coding agents access to real physical devices and high-concurrency emulators. An agent can run a multi-step user journey, inspect what happened, analyze performance, modify the application, and then test the result again. This is a meaningful change from the familiar coding-assistant workflow where a model proposes a patch and a developer remains responsible for executing and validating it. The agent is now operating inside the environment it is changing, and its own observations can influence the next action it takes.

That loop is powerful because it allows an agent to move from suggestion to investigation and remediation. It also exposes a harder question: once the agent can diagnose and change a real system, what determines which changes it should be allowed to make automatically?

The execution loop is becoming more autonomous

Imagine an agent testing a mobile application across several devices. It reproduces a rendering problem, profiles the application, identifies a likely cause, modifies the relevant code, and confirms that the new version performs better. From a capability perspective, the task may look complete.

Operationally, however, not every successful fix should have the same outcome. A rendering optimization may be safe to apply automatically, while a change that touches authentication, customer data, payments, or privacy controls may need additional verification or human review. If the issue appears on only one of five devices, the right next step may be to gather more evidence rather than modify the application at all.

The interesting problem therefore shifts from "can the agent fix this?" to "given what the agent observed, is this particular remediation justified?"

That second question is not simply about tool access. It involves evidence quality, risk, exceptions, required validation, and sometimes organizational approval.

Skills introduce another trust boundary

A recent paper, Towards a Risk Assessment of Malicious Skill Files in Coding Agents, examines a related problem from the instruction side of the stack. The researchers created 2,826 adversarial skill files and tested them against Gemini CLI and Qwen Code across more than 5,600 completed runs.

In the scenarios they evaluated, Gemini CLI attempted the behavior embedded in the malicious skills in roughly 96% of runs, while Qwen Code did so in roughly 72% to 74%. Explicit recognition that the skill itself represented a security problem occurred in fewer than 2% of the experiments.

Those numbers should stay within the scope of the study. The researchers tested two coding agents against deliberately adversarial skill definitions, so the result does not establish that every skill system behaves this way. The architectural implication is still worth examining.

Skills are often described as reusable instructions that teach an agent how to perform a task. A skill might explain how to deploy an application, initialize an environment, diagnose an incident, or run a particular testing workflow. When the agent only consumes the skill as documentation, this may look like ordinary context.

Once the agent also has terminal access, filesystem permissions, cloud credentials, MCP tools, or access to physical testing environments, those same instructions can influence privileged execution. At that point, a skill starts behaving less like passive documentation and more like a software dependency.

The researchers' AgentJailbreak benchmark makes this especially interesting because the evaluation artifacts are public. It gives other teams a way to study how agents behave when instructions that appear useful also contain behavior that should not be trusted.

Capability, authorization, and judgment are different problems

Google's device platform and the malicious-skill study highlight two different parts of the same emerging architecture.

A skill can tell an agent how to perform a task. A device platform gives it an environment in which to perform that task. MCP or another tool interface can expose additional capabilities, while an authorization layer determines whether the agent is permitted to use them.

None of those layers necessarily answers whether the action the agent wants to take is justified.

Consider the mobile debugging example again. After testing the application, the system may know that an issue reproduced on four of five devices, performance improved by 18% after a proposed change, authentication-related code was modified, and one required privacy validation has not yet completed.

Those are facts about the situation.

The organization may have a rule saying that any change touching authentication code requires additional review when mandatory validation is incomplete. In that case, the appropriate outcome is not determined by how confident the agent feels or how strongly the performance metric improved. The decision follows from the organization's criteria for handling that combination of evidence.

This is where the distinction between agent capability and organizational judgment becomes useful.

Where Judgment Pack fits

This is one of the boundaries I have been exploring with the Judgment Pack Specification.

The basic idea is to keep the criteria governing a consequential decision separate from the instructions that teach the agent how to perform the work. The agent can still investigate, use tools, gather evidence, propose fixes, and operate with substantial autonomy. The judgment artifact instead defines how the organization evaluates the resulting evidence and which dispositions are possible.

Conceptually, the flow could look like this:

skills
  |
  v
agent <----> device environment
  |
  v
evidence
  |
  v
judgment
  |
  v
disposition
  |
  v
execution / approval

The distinction matters even more if skills themselves can become part of the execution attack surface. A Judgment Pack should not simply become another general-purpose instruction file.

If the judgment artifact remains declarative, constrained, versioned, and interpreted by a known evaluator, its trust properties are different from those of a skill capable of introducing arbitrary commands or changing how the agent operates. That does not make the system automatically safe, but it gives each layer a narrower responsibility that can be inspected independently.

This also helps separate failure modes. The agent may gather incorrect evidence, the device environment may produce a misleading observation, a binding may reference the wrong source, runtime state may change after the decision, or the evaluator itself may contain a defect. Those are all real problems, but they are easier to analyze when evidence acquisition, decision criteria, and execution behavior are not mixed into one large agent prompt.

Open-source governance points in a similar direction

A second recent study, Making AI Visible, Not Vanished, looked at how open-source projects are responding to AI-assisted development. The researchers analyzed 29,624 GitHub repositories and identified 385 projects with explicit policies governing AI-related contributions.

They organized those policies around five dimensions: transparency, responsibility, attribution, constraints, and enforcement. What I found interesting is that governance usually did not mean banning AI-assisted work. Instead, the policies made AI involvement more visible and clarified who remained responsible for the contribution. The analysis also found associations between these policies and richer review interaction, increased disclosure, and stronger quality measures, particularly where transparency and responsibility were emphasized.

I think there is a useful parallel with agent architecture.

As agents gain more capabilities, adding more hidden instructions inside the model may not be the most sustainable way to govern them. It may be more effective to make the boundaries explicit: where a skill came from, who approved it, which evidence supported a decision, which criteria were applied, who owns those criteria, and who is allowed to change them.

That kind of visibility does not remove risk, but it makes the system much easier to reason about than an agent whose instructions, permissions, decision logic, and execution behavior are all intertwined.

Google gives us a useful environment to test the boundary

The Developer Device Platform creates a practical environment for testing this separation.

An agent could be given a skill for diagnosing application problems and allowed to interact with real devices, reproduce failures, generate fixes, and validate its own changes. Before those changes are applied automatically, however, an external judgment step could evaluate the evidence against explicit acceptance criteria.

The cases do not need to be complicated. A low-risk deterministic remediation might be eligible for automatic execution, while a security-sensitive change could require human review. Conflicting results across devices might require more testing, and missing mandatory validation could prevent the decision from resolving at all.

The useful comparison would be between two architectures.

In the first, the agent gathers the evidence and also decides whether its own proposed fix is acceptable.

In the second, the agent gathers the evidence but the criteria determining whether the action is justified remain external.

The purpose of the experiment would not be to prove that the second architecture is always better. It would be to find out whether capability and organizational judgment can remain meaningfully separate once an agent is operating inside a real feedback loop.

Google's new device platform makes that question much less theoretical.

The Receipt Was Valid. The Policy Was Retired.

Brian Jin — Mon, 10 Aug 2026 23:28:43 +0000

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

Agent Eval Forge integration

Did the surrounding application actually respect the judgment at runtime?

Study 014 - provenance

OpenWorkProof binding

Can a third party later verify the binding between the recorded judgment and the recorded action?

Study 016 - currency

Policy Currency Anchor

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

https://github.com/Judgment-Pack/judgment-pack-evaluator-experiments/tree/main/studies/016-policy-currency-anchor

Study 014 - OpenWorkProof binding

https://github.com/Judgment-Pack/judgment-pack-evaluator-experiments/tree/main/studies/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?

Five Adversarial Reviews Told Me My Study Was Measuring a Fiction

Brian Jin — Mon, 10 Aug 2026 19:29:04 +0000

I thought I had a fairly clear experiment.

An agent platform stages an external side effect for approval.

Something upstream decides that the action is allowed.

The platform records what happened.

So the question seemed straightforward:

Can a third party later prove, from the retained records alone, which decision authorized which action?

I started building a falsification study around that question.

Five rounds of cross-vendor adversarial review later, the study still has no registered result.

Every round told me not to freeze it.

That sounds like a failed experiment.

I think the opposite happened.

The reviews kept finding that some of the things I thought I was measuring either did not exist in the upstream system, could not be proven from the records I had chosen, or were weaker than the claims I had written around them.

The study became more useful before it ever ran.

That distinction became Study 015 - Cloudflare OS Boundary.

This post is about what the review process exposed.

The setup

The platform side is Cloudflare OS, pinned in the study at commit b2a51b5.

Cloudflare describes the August 2026 release as early access with rough edges. Everything here refers to that specific pinned source tree, not to some permanent definition of what Cloudflare OS is or will become.

Its governance architecture is interesting.

Agents and generated applications do not simply receive credentials to external services. A Gatekeeper mediates access. External side effects can be staged for approval rather than executed immediately.

Auto-approval requires two independent signals:

the connector classifies the action as eligible
the workspace user has enabled a rule allowing that action kind

The decision side of my study is different.

A portable judgment artifact receives facts and produces a structured disposition:

outcome

or

not-applicable

or

unresolved:
  - unknown
  - conflict
  - missing evidence

The important property is that the judgment layer has a first-class way to say:

I cannot decide.

The study tries to join those two worlds:

facts + policy
      |
      v
   judgment
      |
      v
 proposed action
      |
      v
 platform governance
      |
      v
 approval / rejection / execution
      |
      v
 retained records

And then asks:

What can someone prove afterward?

That last question turned out to be much harder than I expected.

First lesson: read the implementation contract, not the architecture you imagine

Before measuring anything, I had to establish what the pinned platform actually records and guarantees.

Several assumptions I had made were simply wrong.

The generic MCP Gatekeeper cannot become vetted through normal configuration

The generic MCP Gatekeeper hardcodes its trust tier:

const TRUST: ServerTrust = "byo";

Auto-approval requires vetted.

So the original scenario I had designed around a "vetted generic MCP endpoint" described a configuration that does not exist in the pinned implementation.

The MCP Portal path has a different trust mechanism.

My study had quietly invented an upstream capability.

Review round 2 caught it.

That is a useful kind of failure.

Before asking whether a system preserves some property, first verify that the state you are testing is actually reachable.

A read-only classification can bypass the action queue

The tool classifier honors an upstream readOnlyHint.

That means a tool classified as read-only can execute without going through the side-effect approval path.

Cloudflare's own source comments acknowledge the tradeoff.

This is not the same as saying:

The approval system is bypassable.

The condition is narrower:

If an upstream server labels a mutating operation as read-only, the platform may treat it as a read rather than as a staged action.

That changed the claim I was allowed to make.

"All external effects go through the approval queue" was too broad.

The source did not support it.

The outer action log cannot represent every execution outcome

The workspace-facing action state has three values:

export type ActionState =
  | "pending"
  | "approved"
  | "rejected";

But the MCP connector's internal store has additional states, including failure.

That creates an interesting observability gap.

If a staged call is dispatched but the call fails before the outer layer receives a normal completion, the private connector record can know the call failed while the outer record remains:

pending

The outer log does not have a state capable of expressing what actually happened.

That matters if you are trying to reconstruct history later.

A missing state is not merely a UI inconvenience.

It limits what can be proven from that record.

`approved` is not proof that the external effect happened

The pinned MCP implementation describes its guarantee as:

at most once, not exactly once

That distinction matters.

An approved record tells you something about the platform's control flow.

It does not give you an independently verifiable receipt from the external system saying:

Yes, this effect happened.

There is no universal external transaction identifier or effect receipt attached to the action record.

So I had to separate:

platform approved execution

from:

external world changed

Those are not the same statement.

`appliedAt` is not necessarily "when the action was applied"

Another assumption cost me an actual study bug.

The field name suggested one interpretation.

The implementation had another.

appliedAt is populated when an action is approved and when it is rejected.

So it is closer to:

resolvedAt

than:

effectOccurredAt

A verifier reconstructing a timeline from the name alone could silently produce the wrong history.

Field names are not protocol semantics.

The useful join key is intentionally not public

The Gatekeeper has an opaque internal action identifier.

The client-facing action log does not expose it.

The source explicitly says that identifier should not be provided to the client.

That is a reasonable encapsulation decision.

But it has a consequence for my study.

A holder of the published action log cannot independently join that log to the connector's private execution records using the actual internal identity.

Retention makes the problem stronger.

The outer log is durable.

The private store retains only a bounded number of settled records.

Eventually, historical records can exist on one side after their corresponding private records have disappeared on the other.

Again, this is not necessarily a platform defect.

It means:

The platform's runtime records were not designed as a permanent offline evidence bundle.

My study initially treated them as though they were.

Approval rules do not create historical policy evidence

Auto-approval rules can be removed.

The retained records do not necessarily preserve a tombstone proving:

This rule existed at time T and authorized this action then.

So an action can have been validly auto-approved under the platform's state at execution time without leaving enough retained evidence to prove that fact later.

This connects directly to a problem I had already encountered in another study:

current state and historical authority are different things.

This does not mean Cloudflare OS is doing the wrong job

This distinction is important.

The pinned platform is primarily governing execution in the moment:

capability isolation
connector mediation
human approval
auto-approval constraints
information-flow controls

My experiment was asking it to support something different:

Produce enough durable evidence that an independent third party can later reconstruct why a particular action was permitted and prove the causal relationship offline.

Those are different responsibilities.

The mistake would be to infer the second from the existence of the first.

And Cloudflare OS is an early open-source project.

Its architecture and retained evidence model can evolve.

This study is about the contract exposed by the pinned version, not a prediction about where the project will end up.

Then the reviewers started attacking the study itself

The upstream findings were only half of the story.

I also ran cross-vendor adversarial review against the study.

The reviewer was a different vendor's model, running read-only with the study tree and pinned upstream available.

The instruction was essentially:

Find every way this experiment could produce a result stronger than what the machinery actually proves.

Five rounds.

Every round said:

DO NOT FREEZE.

The sequence is probably the most useful artifact the study has produced.

Round 1 - seven blockers

The first review found something embarrassingly fundamental.

My bridge wrote a commitment describing the action it believed it was binding.

Later, the verifier checked downstream records against that same commitment.

So if the bridge committed the wrong action in the first place, every downstream check could still agree.

The system would report:

everything matches

But all it had shown was:

everything matches the bridge's own mistake

That is self-consistency.

Not independent verification.

The distinction sounds obvious after someone points it out.

It was not obvious enough when I built the first version.

Round 2 - five blockers, including fixes that were themselves wrong

Round 2 did something even more useful.

It rejected several of my Round 1 repairs.

One was the impossible vetted generic-MCP scenario.

Another involved what I had called "evidence backing."

The study checked whether an evidence digest looked like a valid digest.

But there was no retained evidence artifact whose bytes could actually be hashed and compared.

I had built:

digest-shaped string exists

and described it as:

evidence is cryptographically backed

Those are not remotely the same claim.

Round 3 - the historical witness problem

I had built a replay mechanism intended to establish that an approval had been lawful at the time it occurred.

The witness proving historical state came from the very store being examined.

That creates an obvious laundering path:

store claims historical state X
        |
        v
verifier asks same store for witness
        |
        v
store supplies evidence for X

The final check may be perfectly deterministic.

The independence claim is still false.

So the study claim got weaker.

Instead of:

historical lawfulness proved

it became:

consistency with a self-asserted historical witness

Much less impressive.

Much more accurate.

Round 4 - correct counts can hide the wrong cause

This was the finding I would defend hardest.

Imagine the records show:

1 approved action
1 external effect

The counts match.

But the effect was actually produced by a different invocation with the same arguments.

The original call never caused it.

A cardinality check says:

1 == 1
PASS

The causal claim is false.

The reviewer called this fatal.

It was right.

So instead of documenting the limitation, I changed the artifact.

Effect attestations now need to carry the identity of the staged action that produced them.

The check became an identity join rather than a count.

That is a broader lesson:

When causation matters, count matching is not identity matching.

Round 5 - one predicate left

By Round 5, the reviewer found one blocker.

One governed call had no commitment digest.

The study checked:

number of governed calls == number of committed calls

and the counts matched.

But the unbound call sat outside the set the later verification actually examined.

Once again:

count equality

was pretending to establish:

set identity

Round 1 asked:

Does this experiment verify anything independent?

Round 5 asked:

Should this exact predicate compare identities instead of counts?

That narrowing is the best evidence I have that the study is converging.

Not that the reviewer started agreeing with me.

That the disagreements became smaller and more mechanical.

Four things I personally wrote down that were false

The reviewers were not the only source of correction.

My own source-verification passes refuted several statements I had already committed.

I think these are worth publishing because they show how easy it is for technically plausible prose to outrun the implementation.

1. "This component cannot be typechecked from the committed tree."

False.

It typechecks after one committed code-generation step.

My own verification refuted the claim before a reviewer reached it.

2. "The adapter reproduces upstream behavior."

Not really.

Six documents cited a check that supposedly compared my adapter against upstream.

The implementation effectively did:

f(x) == f(x)

An automated edit that was supposed to insert the real comparison had silently failed because the anchor string had been renamed.

The commit message claimed the fix had landed.

The file disagreed.

3. "The tool name never appears in the log."

False.

It appears in prose and structurally inside the action-kind tag.

A grep disproved the claim.

4. "There is no action-log export anywhere."

Also false.

There is a listActions() API.

The accurate claim was narrower:

There is no signed, complete, offline-verifiable action-history export supporting the evidence properties this study requires.

The weaker sentence is the true one.

What I would carry into any similar experiment

A few practices survived all five review rounds.

Verify the reviewer

Do not immediately accept an adversarial review because it sounds sophisticated.

For every load-bearing finding, I went back to the source and reproduced the claim.

Most reviewer findings held.

A few needed narrower wording.

Sometimes the verification produced a better repair than the reviewer proposed.

Adversarial review still needs verification.

Fix the missing mechanism when you own the artifact

Some findings really are limitations.

Others identify missing machinery you can actually add.

The substituted-causation problem was not something I wanted to solve with:

This study does not claim causality.

Causality was the point of that artifact.

So the artifact gained the missing identity.

A disclaimer should not substitute for a mechanism you can reasonably build.

Narrow claims aggressively

Several claims became weaker during review:

proved historical lawfulness

became:

consistent with a self-asserted witness

and:

evidence-backed

became:

retained-preimage consistency

That can feel like losing ground.

It is actually progress.

A narrow falsifiable claim is more useful than a broad impressive sentence whose evidence does not support it.

Delete checks that cannot fire

A verdict branch with no reachable input is not defense in depth.

It is dead prose written as code.

The same goes for schema fields with only one possible reachable value.

If a mechanism cannot distinguish two states, do not describe it as though it does.

Verify scripted edits after they run

This one is painfully mundane.

An automated source edit silently failed.

The script exited.

The commit succeeded.

The message described the intended change.

The implementation never changed.

Now every scripted edit in this study gets verified against the resulting file.

"Automation ran" is not evidence that the intended change happened.

A study can be honest and still not be ready

Five consecutive DO-NOT-FREEZE verdicts are not something I need to hide.

They are the current result.

Study 015 - Cloudflare OS Boundary remains merged as a draft.

The study index says that explicitly.

There is no registered result.

Nothing in the current study should be cited as though the experiment has already established the decision-to-action binding it is trying to test.

That is the correct state.

The boundary that remains open

Even if every current blocker is resolved, one problem remains outside both systems.

Staleness and rollback.

Suppose a decision was correctly produced under policy version 3.

Later, version 4 becomes authoritative.

Someone presents an old-but-valid decision under version 3.

Or they coherently reconstruct a history around version 3.

Every digest may still match.

Every signature may still verify.

The chain can be perfectly self-consistent.

What it cannot say about itself is:

Was this policy still authoritative at the relevant point in time?

That requires an anchor outside the chain.

Something needs to establish the history of authoritative policy state:

policy identity
      |
      v
revision
      |
      v
artifact digest
      |
      v
effective time
      |
      v
next revision

This is similar to a boundary that surfaced in our earlier Study 014 - OpenWorkProof binding experiment.

A self-consistent proof can establish lineage inside its trust boundary.

It cannot establish that the state it contains is still the externally authoritative state.

That is not a Cloudflare OS problem.

It is not an OpenWorkProof problem.

It is not something a Judgment Pack should silently decide for itself.

It is a separate trust problem.

And it is probably the next one worth defining carefully.

The current study is public here:

Study 015 - Cloudflare OS Boundary

The repository includes:

the draft study protocol
the five verbatim cross-vendor review rounds
the disposition of every finding
the withdrawn and narrowed claims
the deviations record
the pinned upstream identity

It is evidence of a review process and of several architectural boundaries.

It is not a frozen experimental result.

And at this point, that distinction is the entire point.

When Agents Can Run Anywhere, Where Should Organizational Judgment Live?

Brian Jin — Mon, 10 Aug 2026 19:22:44 +0000

Two developments today came from very different parts of the agent stack.

Meta released Muse Glimmer, a 30B open model designed for local, always-on agent workflows. It can run on consumer hardware and is trained for tool use, long-running execution, multimodal input, and failure recovery.

At the enterprise layer, RealPage introduced the Lumina AI Suite, combining agents, a governed knowledge graph, operational intelligence, institutional intelligence, and MCP-based access to external models.

One development is pushing agents down onto local hardware.

The other is building more enterprise infrastructure around them.

Together they make an architectural question easier to see.

If the model can increasingly run anywhere, where should the organization's actual decision criteria live?

The model is becoming one component of the system

Consider a procurement agent reviewing a new vendor.

It might retrieve:

vendor identity
sanctions status
tax documentation
annual contract value
internal risk classification
budget information

Those facts could come from several places.

A knowledge graph can connect them.

An MCP server can expose them.

An identity system can decide whether the agent is allowed to retrieve them.

A gateway can determine whether the agent is permitted to call the vendor-management API.

But none of those necessarily answers:

should this vendor be approved?

That decision could depend on relationships between the facts.

A sanctions match might be a hard stop.

A particular spend threshold might require committee review.

Handling personal data might introduce another evidence requirement.

Missing tax documentation might mean the correct outcome is neither approval nor rejection.

It may mean:

insufficient evidence

The interesting boundary is between obtaining the information and applying the organization's decision criteria to it.

Institutional knowledge is not necessarily institutional judgment

RealPage describes part of its new architecture as "institutional intelligence."

The platform builds on a governed knowledge graph so its agents and analytics operate from a consistent understanding of the real-estate domain.

That solves an important problem.

An enterprise agent should not reconstruct the organization from random documents every time it receives a request.

But knowing the organization's facts and relationships is not quite the same thing as knowing how the organization makes a decision.

Suppose the system knows that a property has exceeded its maintenance budget.

That is knowledge.

Suppose it also knows that a particular repair is safety-critical, that emergency work below one threshold may proceed automatically, and that anything above another threshold requires regional approval.

That begins to look like judgment.

The distinction matters because the two things may have different owners and different change cycles.

Data teams may own the knowledge graph.

Security teams may own tool authorization.

Business or risk owners may own the decision criteria.

Agents use all three.

This is the boundary I am exploring with Judgment Pack

The Judgment Pack Specification is an attempt to make the third category explicit.

A Judgment Pack can define what evidence matters, how evidence is interpreted, which rules and exceptions apply, how missing information is handled, and which dispositions are possible.

Conceptually:

organizational knowledge
        |
        v
    evidence
        |
        v
   judgment
        |
        v
  disposition
        |
        v
execution policy
        |
        v
     action

The model does not disappear from this architecture.

It can gather evidence, interpret requests, call tools, plan workflows, and interact with people.

The difference is that changing the model does not automatically change the organization's definition of the correct decision.

That property becomes more interesting when a model like Muse Glimmer can run locally.

A company might use a frontier model for one workflow, a local model for another, and a specialized model for a third.

Should each model independently reconstruct the company's decision logic?

Or should they operate against the same reviewed judgment artifact?

That is something we can test.

The safety research is moving toward similar distinctions

The SafeAI workshop at UAI 2026 published its accepted program today.

Several of the papers sit surprisingly close to this problem.

There is work on auditable agent memory, authority-bearing tool parameters, system assurance, abstention, and a paper titled "Underspecified, Not Uncertain: Context Ambiguity Versus Knowledge Gaps in Safety-Critical LLM Use."

I find that last distinction particularly useful.

There are at least two reasons an agent may not be able to make a reliable decision.

The model may be uncertain.

Or the decision itself may be underspecified because a required fact is missing.

Those should not automatically produce the same behavior.

If the system has not completed a sanctions check, switching to a larger model does not create the missing evidence.

The correct response may simply be:

cannot decide yet

This is one reason I think explicit evidence requirements matter.

Generating possibilities is getting easier

A different example appeared today in scientific AI.

Discovered Materials raised a $9 million seed round to use swarms of agents to search for new semiconductor materials.

Its agents can generate thousands of candidates, which are then filtered using physics simulations and eventually laboratory validation.

One investor involved in the round made an interesting observation: generating candidates may no longer be the bottleneck. Filtering and synthesizing the right candidates is.

I would not equate scientific validation with enterprise judgment.

But there is a shared pattern.

Better models make candidate generation cheaper.

Agents can produce more recommendations, plans, actions, vendors, hypotheses, and possible answers than people could manually create.

That increases the importance of selection.

What evidence makes one candidate acceptable?

Which criteria eliminate another?

When should the system abstain?

Who owns those criteria?

How do they change without allowing the agent to rewrite its own judge?

A small experiment could make this concrete

Muse Glimmer creates a useful opportunity to test the architecture rather than debate it.

Take one existing enterprise workflow.

Run it with a local Muse Glimmer agent.

Run the same workflow with a frontier cloud model.

Let both agents gather the evidence.

Keep the Judgment Pack and evaluator unchanged.

Then compare what changes.

If model capability changes the quality of evidence acquisition but not the organization's final decision semantics, that would support a meaningful separation between agent intelligence and organizational judgment.

If it does not, that would be equally useful to learn.

As agent models become cheaper, smaller, and easier to swap, I think the durable parts of an enterprise AI architecture will become easier to identify.

The question is whether organizational judgment is one of them.

The Receipt Was Cryptographically Valid. The Action Didn't Match the Judgment.

Brian Jin — Mon, 10 Aug 2026 14:53:38 +0000

Here is the attack that motivated our newest experiment.

A policy evaluator receives an expense request for 250.00 and produces a disposition that supports that action.

That judgment is committed into a signed work order. A capability grant is issued. The action executes. Receipts are produced. Evidence is attached. An acceptance is signed.

An offline verifier checks the bundle:

signatures valid
causal parents correct
evidence digests correct
authorization chain valid

Everything passes.

Except the action that now appears in the coherently re-signed chain is:

2500.00

An insider changed the amount after the judgment and re-signed the affected artifacts with valid keys.

From the execution protocol's point of view, the new chain can still be internally consistent.

But it is no longer the action supported by the recorded judgment.

That distinction became Study 014.

Where this study came from

Study 014 follows directly from Study 013 - Agent Eval Forge integration.

Study 013 asked the runtime behavior question:

If the judgment is correct, does the surrounding agent actually respect it?

We integrated JPS with an independently developed agent regression harness, deliberately injected decision-layer and integration-layer failures, and measured which layer caught what.

That study showed an important separation:

the judgment layer can detect errors inside the decision semantics
an external trajectory harness can detect cases where the application misuses an otherwise correct decision
neither layer automatically proves the historical relationship between the judgment and the action afterward

Study 014 starts exactly at that last boundary.

It asks the provenance question:

After execution, can an independent third party prove which recorded judgment corresponds to which recorded action?

So the progression is:

Study 013
Did the application behave consistently with the judgment?

        ↓

Study 014
Can a third party later verify the binding between
the judgment and the executed action?

Why EvalForge and OpenWorkProof are different

The external systems in Studies 013 and 014 solve different problems today.

Agent Eval Forge, as it currently exists, is primarily a regression-testing harness for agents. You define scenarios and expected behavior, run an agent, and inspect the resulting trajectory - which tools it called, which arguments it passed, whether it crossed a safety boundary, and whether a change introduced a regression.

Its question is roughly:

Did this version of the agent behave the way we expected?

OpenWorkProof, in its current form, operates further downstream. It creates signed work orders, capability grants, execution receipts, evidence relationships, and an offline verification bundle.

Its question is closer to:

Was this recorded action authorized, and can another party later verify the signed execution and evidence chain?

That is why they were useful for two different studies.

JPS
What should happen under these facts and rules?
        |
        +-------------------------+
        |                         |
        v                         v
Agent Eval Forge             OpenWorkProof
Study 013                    Study 014

Did the system              Can the recorded
behave correctly?           authorization and
                            execution lineage
                            be verified afterward?

These are descriptions of the projects as they exist today, not permanent category boundaries.

Both are early open-source projects, and their capabilities could expand or converge over time.

EvalForge could add more runtime verification or provenance features. OpenWorkProof could add richer policy evaluation, testing, or regression capabilities. JPS itself may also expand its integration surface.

The useful distinction for these studies is therefore not:

These projects can never overlap.

It is:

Which responsibility did each independently developed implementation actually own at the pinned version we tested?

Study 013 used EvalForge as an external observer of agent behavior.

Study 014 uses OpenWorkProof as an external protocol for authorization and receipted execution lineage.

That keeps the experimental claims tied to real implementations rather than drawing permanent product-category boxes around three projects that are still evolving.

Two independently designed layers

Study 014 composes two systems that were designed independently.

Judgment Pack / JPS handles judgment:

Given this exact pack and these exact facts, what disposition follows?

OpenWorkProof handles authorization and execution lineage:

Was this actor allowed to perform this action, what happened afterward, and does the signed receipt chain verify?

The distinction matters.

JPS does not issue capability grants.

A JPS disposition does not authorize execution.

OpenWorkProof does not decide whether a business judgment is substantively correct.

Each system owns a different part of the chain.

Study 014 asks whether those parts can be bound strongly enough to survive adversarial substitution.

Why signatures alone are not enough

A digital signature tells you something important:

These bytes were signed by this key.

What it does not automatically tell you is:

These bytes still represent the same business judgment that originally justified this action.

That gap becomes especially interesting under an insider threat model.

Simple tampering is easy to detect.

Change an amount without re-signing the receipt and signature verification fails.

But suppose the attacker controls valid signing keys.

They can change the action and construct a new, cryptographically valid chain.

Now the question is no longer:

Was something tampered with?

It becomes:

Is the newly valid chain still bound to the exact judgment, facts, and action that belong together?

That was the attack surface we wanted to test.

We did not modify OpenWorkProof

This was important methodologically.

We pinned OpenWorkProof at commit 8eeca6f and used its verify_acceptance_bundle verifier unchanged.

For the pinned version we tested, the cleanest interoperability boundary was to let OpenWorkProof remain unaware of JPS.

OpenWorkProof can carry external data inside fields it signs without needing to understand what that data means.

So we created a small adapter between the two systems.

The adapter builds a judgment commitment over:

exact Judgment Pack bytes
exact normalized input bytes
canonical JPS disposition
evaluator replay tuple
exact authorized action

That commitment is then carried at signed points in the OpenWorkProof chain.

The verification ceremony has three separate layers.

Layer 1 - OpenWorkProof verification

Are the signatures, grants, causal relationships, authorization windows, receipts, and evidence sets internally valid?

Layer 2 - judgment binding

Do the retained pack, facts, disposition, and action recompute to the commitment carried by the signed chain?

Layer 3 - deterministic replay

If we evaluate the retained pack again with the retained inputs and pinned evaluator, do we reproduce the recorded disposition?

No layer is asked to pretend it knows something it does not.

And importantly, we do not claim that both signed commitment points are independently necessary. In this study they are defense in depth, not a proven minimal construction.

Then we tried to break it

The locked study stratum contained 39 registered cells.

That included 33 one-at-a-time mutation constructions, five validity controls, and one demonstration. Of those, 32 were endpoint cells used for the primary registered result.

The attacks covered six broad areas:

judgment artifact substitution
fact substitution
disposition forgery
action substitution
replay and drift
causal-chain corruption

Where it mattered, we tested two attacker capabilities.

The easy version was ordinary tampering:

Change something and leave the old signature behind.

The harder version was coherent reminting:

Change something and re-sign the resulting artifacts with valid study keys.

That second category is where the architectural boundaries became much more interesting.

Different layers caught different attacks

The detection ownership ended up being one of the most useful outputs of the experiment.

OpenWorkProof caught chain failures

The unchanged OpenWorkProof verifier caught the things its protocol is designed to own:

post-signature tampering
broken causal parents
authorization-window violations
evidence-set inconsistencies
malformed execution chains

In those cases, JPS did not need to know anything was wrong.

The execution proof itself was invalid.

The binding layer caught judgment-side substitutions

Now consider the opening attack.

The amount changes from:

250.00

to:

2500.00

and the attacker coherently re-signs the affected chain.

The OpenWorkProof verifier can still pass because the newly produced artifacts are cryptographically self-consistent.

But the adapter recomputes the action commitment and sees:

This is not the action bound to the recorded judgment.

The same pattern applied to substitutions such as:

different pack bytes
different pack version
changed facts
different action
altered action arguments

This is not a weakness in signature verification.

The signatures are doing exactly what signatures do.

The missing property is semantic binding across independently owned layers.

Replay caught another class

There was a third failure class.

Suppose an attacker creates retained artifacts that are internally consistent with one another.

The pack digest matches.

The facts digest matches.

The recorded disposition matches the commitment.

The chain verifies.

But the disposition itself is forged.

Now neither cryptographic integrity nor digest agreement necessarily tells you that the judgment is the one the evaluator would actually produce.

So we replay it.

Same pack.

Same inputs.

Same pinned evaluator.

Recompute the disposition.

Several mutations were caught only at this layer.

That gave us a useful separation:

Internal consistency is not the same as semantic reproducibility.

The sharpest holdout case

The locked matrix was useful, but it was still developed while we were building the study.

So the reviewer authored a separate holdout set.

Those eight cases were committed before freeze and were not executed until the registered attempt.

One of them was particularly useful.

The attacker constructed a self-consistent wrong action.

The commitment agreed with the receipt.

The receipt chain was valid.

OpenWorkProof verification passed.

But the action was not compatible with the recorded JPS disposition under the study's registered disposition-to-action map.

Only that final binding check rejected it.

That is probably the cleanest demonstration of the boundary we were trying to study:

Agreement between attacker-controlled records is not enough to establish that the action follows from the judgment.

The holdout finished:

8 / 8 adjudicated, 0 divergent, 0 pipeline-invalid.

The locked stratum also finished with:

39 / 39 adjudicated, 0 endpoint divergences, 0 pipeline-invalid.

Two things nothing inside the chain could detect

I think these results matter as much as the successful detections.

Two registered boundaries remained outside the composition.

Decision currency

Suppose the chain contains a perfectly valid judgment produced from a perfectly valid pack.

But that pack is no longer the organizational policy that should be used today.

Nothing inside the old chain can discover that by itself.

The chain can prove:

This action corresponds to this recorded judgment.

It cannot prove:

This is still the judgment artifact the organization currently wants applied.

That requires some source of current authority outside the chain.

Alternative valid WorkOrder rollback

A stronger insider can also coherently construct an alternative valid WorkOrder and remint the associated chain.

All signatures can be valid.

All internal references can agree.

All three verification layers can pass.

From inside that self-contained universe, there is nothing distinguishing:

the currently authoritative chain

from:

another coherently signed chain.

Detecting that requires an external anchor.

A transparency service, monotonic registry, trusted current-version pointer, or another external authority could potentially provide such an anchor.

Study 014 does not.

We registered that boundary instead of patching around it after seeing the result.

One practical integration trap: unsigned metadata

The study also found a much simpler lesson.

OpenWorkProof has a generic evidence-bundle metadata area.

It is useful metadata.

It is not a judgment-binding location.

We created a demonstration where the JPS reference lived only there.

Substitute that reference and OpenWorkProof verification remains green.

That is expected because the verifier was never given a signed semantic commitment to check.

For our integration, moving the commitment into signed carriage through WorkOrder.objective and AgentRequest.context_source_digest closed that gap.

The practical lesson is simple:

Do not confuse "included in the bundle" with "cryptographically bound to the action."

That distinction may be worth making explicit in integration documentation.

The study itself failed review several times before the system did

The technical result matters.

The review process may matter more.

The review record spans seven cross-vendor rounds.

The reviewer was a different vendor's model running read-only, with every prompt and response retained verbatim.

Round 1 opened with 14 findings, including four blockers.

Those blockers were not cosmetic.

One found that our fixtures bypassed OpenWorkProof's real patch execution path.

That would have made the verifier look stronger by testing chains that a real deployment might never produce.

Another found that our own execution-receipt selection logic could be bypassed simply by omitting a marker.

That was almost perfectly embarrassing:

We built a study to detect integration bypasses, and the study's own integration ceremony had one.

Another found that what we initially wanted to call prospective evidence was actually postdictive.

That forced the split between the locked replication and the reviewer-authored holdout.

Another found that our freeze-integrity mechanism was not actually sufficient to freeze the study.

Later rounds kept finding problems.

One draft expectation was falsified during pilot work and changed before freeze.

The holdout machinery itself was repeatedly tightened so the reviewer cases could not accidentally be executed early or silently rebuilt after seeing the result.

Even the seventh review round still found a package-metadata shadowing path that needed to be closed before the study was ready.

That is why I do not describe the review as validation that our initial design was good.

It did the opposite.

It repeatedly showed where it was not good enough.

Why the holdout matters

The 39-cell locked stratum is useful evidence.

But it is still a replication of behavior we had observed while constructing and hardening the study.

The eight holdout cells are different.

They belonged to the reviewer.

They were registered before execution.

Their first execution happened only after freeze.

One was deliberately designed so that a specific review fix had to be correct or the study would diverge.

All eight landed on their registered outcomes.

That does not turn eight cases into a security proof.

But it gives the study at least one genuinely prospective stratum rather than letting the entire result be a polished description of behavior already seen during development.

What a green result actually means

After all of that, the final claim is narrower than the title might suggest.

A green Study 014 verification means:

The retained artifacts and receipted lineage are internally consistent, and the executed call represented by the chain is the one associated with the recorded judgment under the registered binding ceremony.

It does not mean:

the policy is correct
the supplied facts are true
the JPS disposition authorizes the action
the physical action necessarily happened
OpenWorkProof is secure against arbitrary attackers
JPS is conformant because this experiment passed
every possible binding attack has been covered

The trust roots still exist.

The study relies on the work order's study-minted keys, the pinned JPS evaluator, the adapter implementation, and the retained artifact store.

This is a binding and lineage result.

Not a truth result.

Why I think the separation matters

Agent systems increasingly have several distinct control problems.

Judgment

Given these facts and organizational rules, what should happen?

Authority

Is this actor permitted to perform that action?

Execution

What action actually ran?

Evidence

Can another party later verify the relationship among those three?

Trying to make one component answer all four questions tends to blur the trust boundaries.

Study 014 instead let each component remain narrow.

JPS did not become an authorization protocol.

OpenWorkProof did not become a business judgment engine.

And the adapter did not attempt to decide either question.

It only committed the relationship between them strongly enough that the relationship could be independently recomputed.

That is the result I find most interesting.

Not that every attack was caught.

Some deliberately were not.

The interesting part is that we can now say which layer should see which failure, and where the evidence simply does not exist to see it at all.

Receipts

Everything is public.

Study 014 - decision-to-execution binding

https://github.com/Judgment-Pack/judgment-pack-evaluator-experiments/tree/main/studies/014-openworkproof-binding

This is the study described in this post - offline provenance and binding between a recorded JPS judgment and the action represented in an OpenWorkProof receipt chain.

Study 013 - Agent Eval Forge integration

https://github.com/Judgment-Pack/judgment-pack-evaluator-experiments/tree/main/studies/013-agent-eval-forge-integration

Study 013 is the runtime sibling of this work. It asks whether the surrounding agent/application actually behaves consistently with the judgment and uses an independently developed regression harness to distinguish judgment failures from integration failures.

The two studies answer different questions:

013 - Did the system respect the judgment at runtime?

014 - Can we prove the judgment-to-action binding afterward?

Study 014 is not a security audit or endorsement of OpenWorkProof. It is one interoperability falsification study against one pinned commit, one Judgment Pack, one action encoding, and one adapter written by us.

The most useful next question is probably the one the expected-undetected boundaries leave behind:

Where should the external anchor live when a perfectly valid receipt chain is no longer the authoritative one?

I Broke My AI Decision System 20 Ways to See Which Layer Would Catch What

Brian Jin — Mon, 10 Aug 2026 14:02:14 +0000

When an AI agent makes a business decision - approve this request, charge this fee, escalate this case - and something goes wrong, the failure can live in very different places.

Sometimes the decision logic itself is wrong.

Someone encoded:

$1000 or more

as:

more than $1000

Or removed an exception.

Or treated missing evidence as false.

Other times, the decision was correct but the surrounding application failed.

The agent received the wrong fact.

It was told to escalate and continued anyway.

It made the right decision and invoked the wrong tool.

Those are different failure classes.

They need different owners, different tests, and different fixes.

I wanted to know whether we could actually separate them experimentally.

So I took JPS, the deterministic judgment system I am working on, integrated it with an independently developed agent regression harness called EvalForge, and broke the combined system in 20 different ways on purpose.

Then I asked a simple question:

Which layer catches what?

Why use someone else's test harness?

I could have built another JPS-specific test framework.

That would have been easier.

It also would have been weaker evidence.

EvalForge was built independently. It knew nothing about JPS.

It evaluates agent behavior from the outside by inspecting things such as:

which tools were called
which arguments were passed
whether a disallowed action occurred
whether expected actions happened
whether the execution stayed within the scenario constraints

That made it useful as an external observer.

The point of the experiment was not to make JPS "pass EvalForge."

It was to see whether the boundary between judgment correctness and integration correctness actually survives contact with another system.

The setup

                 one business case
          same facts, same expected outcome
                          |
          +---------------+---------------+
          |                               |
          v                               v
 ARM A: prompt-mediated            ARM B: deterministic

 policy as plain text              structured facts
          |                               |
          v                               v
   model decides                  JPS evaluator
          |                               |
          +---------------+---------------+
                          |
                          v
                 shared execution layer
          decision -> tool call / escalate
                          |
                          v
               EvalForge scores trajectory

Three independent detection mechanisms watched each injected failure:

[J] Judgment-layer tests
    Does the decision logic itself still behave correctly?

[F] EvalForge
    Does the surrounding agent execute the correct tools and arguments?

[G] Study gate
    Does the observed outcome still match the pinned expected result?

The two primary paths used the same business cases and the same expected operational outcomes.

The only major difference was where the judgment came from.

The test surface

The study contained 21 business cases covering situations such as:

straightforward approval
hard-stop conditions
exact numeric thresholds
values just below thresholds
missing required evidence
unknown evidence
conflicting rules
escalation
routing to a specific destination
protected actions that must never execute under certain dispositions

Then we introduced 20 deliberate failures, one at a time.

Six were inside the judgment semantics.

Fourteen were in the surrounding integration.

Before running the scored experiment, we wrote down which detector we expected to catch each mutation.

The protocol was then frozen after three rounds of adversarial review by a different vendor's model.

Only after that did the scored run begin.

Finding 1 - the boundary was measurable

Every rule-level mutation was detected exactly where we predicted.

Examples included:

changing an inclusive threshold into an exclusive one
moving a threshold
removing an exception
collapsing unknown into false
changing conflict behavior

Those belong to the judgment layer.

Its own tests caught them.

The surrounding integration did not need to know why the rule was wrong.

The opposite was also true.

When the decision logic remained correct but the surrounding system misused the result, the judgment evaluator could not see the failure.

Examples included:

mapping the wrong fact into the evaluator
ignoring an escalation
taking a protected action after an unresolved result
calling the wrong tool
passing the wrong argument

Those failures appeared in the execution trajectory.

That is where EvalForge caught them.

Its simple trace-level scorers ended up doing most of the work:

zero_disallowed_actions
tool_called
argument_correctness

The more semantic grounding and contradiction scorers were mostly irrelevant.

In hindsight, that makes sense.

The injected failures were often not changing what the agent said.

They were changing what it did.

So the trace was the evidence.

Across the full mutation matrix, there were zero divergences from the preregistered detection ownership.

That includes three mutations we predicted none of the three detectors would catch.

They escaped exactly as expected.

That matters.

A good experiment should expose where detection stops, not quietly redefine every escaped case as something the system was never supposed to catch.

Finding 2 - the independent adversarial cases were more useful than my own

After the protocol was frozen, an independent reviewer contributed four hidden adversarial scenarios.

I did not know their exact contents before execution.

One of them targeted a field the judgment layer could not see:

the configured escalation destination.

The judgment itself could still be correct:

escalate

But the application could route it to:

Fee review

instead of:

Fee review queue

From the judgment layer's perspective, nothing was wrong.

It had correctly decided to escalate.

EvalForge's argument_correctness scorer caught the bad destination downstream.

That was exactly the kind of separation I wanted this study to expose.

More importantly, it revealed a real blind spot.

The runtime's test rows could assert that escalation should occur, but they could not assert the exact configured escalation target.

That capability has since been added and released in the runtime.

So the feedback loop became:

external adversarial case
        |
        v
blind spot exposed
        |
        v
external harness catches it
        |
        v
runtime capability improved
        |
        v
new regression coverage
        |
        v
versioned release

That may be the most useful result of the study.

The experiment did not merely produce a score.

It changed the system.

Finding 3 - prompt-mediated judgment got 62 of 63 decision outcomes right

We also ran the comparison originally suggested by the EvalForge author.

Same business cases.

Same expected outcomes.

But instead of evaluating a structured Judgment Pack, a strong model received the policy as plain prose and made the decision itself.

The model performed very well.

It got:

62 / 63

decision outcomes correct.

It never executed a forbidden protected action.

It correctly abstained on the blocked cases.

So this study does not support a claim that prose-based judgment is generally unreliable.

The interesting part was where it failed.

Exact conflict boundary

One case sits at an exact threshold where two rules genuinely conflict.

The deterministic evaluator is required to surface that conflict.

It is not permitted to invent a tie-break.

Across identical prompt runs, the model sometimes did something else.

In one run, it quietly chose a winner.

That produced a plausible answer.

It was also precisely the behavior the deterministic semantics prohibit.

More importantly, the behavior was inconsistent across repeated identical runs.

That is a different failure from simply "getting the answer wrong."

It means the system did not have a stable rule for what happens when the policy itself contains unresolved conflict.

Structured routing identity

A second failure appeared in a different place.

The model repeatedly altered a configured routing destination.

The structured value was:

Fee review queue

The prose-mediated path produced plausible variations such as:

Fee review

The semantic intention is close.

Operationally, the identifier is not the same.

That distinction matters when downstream systems expect exact configuration rather than approximate language.

So these are two separate failure modes:

1. judgment instability at a real rule boundary

2. loss of exact operational configuration
   when structured data is carried through prose

The model's overall accuracy number hides both.

The important result was not "deterministic beats model"

That would be the wrong conclusion.

The model performed strongly.

And this is a small study.

The result I care about is that the failure classes had owners.

A deterministic judgment evaluator can tell you whether:

same facts
+
same judgment artifact
=
same disposition

But it cannot necessarily tell you that the application fed it the wrong facts.

It cannot tell you that another layer ignored escalate.

It cannot tell you that the right decision was followed by the wrong tool call unless that behavior is brought back into its test surface.

Likewise, an execution regression harness can tell you:

the wrong tool fired

or:

the tool received the wrong argument

But that does not automatically tell you whether the underlying organizational rule was encoded incorrectly.

Those are different questions.

Testing the layers separately made that boundary visible.

The detection model that emerged

The study ended up looking less like one testing system and more like a chain of responsibility:

business policy
      |
      v
judgment artifact
      |
      v
[J] judgment tests
      |
      v
deterministic disposition
      |
      v
integration / agent
      |
      v
[F] trajectory tests
      |
      v
tool execution
      |
      v
[G] end-to-end expected outcome

Each layer can be correct while another layer fails.

That is not duplication.

It is defense through separation.

The blind spots matter too

Three registered mutations were expected to escape all three detectors.

They did.

I think that is useful evidence.

There is a temptation in evaluation work to make every test failure somebody's responsibility after seeing the result.

We tried not to do that.

If neither the judgment artifact nor the execution trajectory contains enough information to observe a particular failure, then a detector cannot reconstruct that missing evidence afterward.

The correct outcome is:

We are blind here.

That can become the input to the next design change or experiment.

But it should remain a blind spot until something actually closes it.

What EvalForge taught me

The integration also surfaced several implementation observations in EvalForge itself, which I filed upstream as issues #269-#274.

But the larger takeaway was positive.

Its:

scenario format
runner
payload isolation
artifact layer
deterministic trace scorers

all held up under adversarial use.

The blocking zero_disallowed_actions scorer was particularly useful.

Every scenario where a protected action executed when it should not have was stopped there.

That is a very clean operational invariant.

What changed in JPS

The study also produced a concrete runtime improvement.

One hidden adversarial case showed that JPS could assert:

escalation must happen

but could not test:

escalation must go to this exact configured destination

That gap is now addressed in:

judgment-pack-runtime v0.17.0

This is the feedback loop I want around judgment artifacts:

author
  |
  v
test
  |
  v
evaluate
  |
  v
observe failures
  |
  v
improve semantics / tooling
  |
  v
review
  |
  v
version

The artifact should evolve because evidence exposed a gap, not because someone casually changed a prompt.

Honest limits

This study is deliberately narrow.

It involved:

20 planted mutations
21 business cases
one external regression harness
one model in the prompt-mediated arm
one JPS decision family
deterministic scoring wherever possible

It does not prove that JPS improves model accuracy generally.

In fact, an earlier experiment on a harder third-party benchmark produced a less favorable efficacy result, and that result still stands.

Study 013 answers a different question.

It asks whether failures inside the decision semantics can be distinguished from failures in the surrounding execution path.

Within this study, they could.

It also does not prove that the mutation set is complete.

There will be failures outside all three detectors.

The study already contains examples.

And the prompt-mediated comparison is too small to support broad claims about model reliability.

The interesting value is where the failures occurred, not the headline percentage.

Receipts

Everything needed to inspect or reproduce the study is public.

Study 013

https://github.com/Judgment-Pack/judgment-pack-evaluator-experiments/tree/main/studies/013-agent-eval-forge-integration

The repository contains:

preregistration
adversarial review
mutation definitions
hidden-case handling
raw run artifacts
deterministic scoring
detection matrix
analysis

Agent Eval Forge

https://github.com/deghosal-2026/agent-eval-forge

The harness was pinned and used as an independently developed external observer.

Runtime change

The blind spot identified by the hidden escalation-target case was addressed in:

judgment-pack-runtime v0.17.0

The takeaway

I started with a fairly simple claim:

A deterministic judgment layer should make business decision logic testable independently of the agent executing it.

The experiment made that claim more precise.

The useful separation is:

Judgment layer:
Was the decision implied by these facts and rules?

Integration layer:
Did the surrounding system respect that decision?

Execution layer:
Did the correct action actually happen?

A correct answer at one layer does not guarantee correctness at the next.

That is why the most interesting result was not:

JPS caught X and EvalForge caught Y.

It was:

We could identify which layer owned each registered failure - and we could also identify failures owned by neither.

That gives us somewhere concrete to improve.

In your agent stack, who owns the failure when the decision was right but the action was wrong - and would anything in your current tests tell you which one happened?

Where Does Judgment End and Runtime Policy Begin?

Brian Jin — Sun, 09 Aug 2026 18:24:35 +0000

AWS introduced something this week that is close enough to the problem I have been working on that I do not think it should be casually labeled complementary.

Amazon Bedrock AgentCore added temporal policies, along with an open-source policy language called Dogwood.

Instead of asking only whether an individual tool invocation is allowed, the gateway can evaluate the sequence of actions that led to it.

Consider a purchasing agent with this rule:

purchases under $10,000 do not require escalation

The agent makes six purchases of $9,000.

Every individual action satisfies the rule.

The sequence may violate the organization's intended limit.

The same problem appears with approvals.

An API call may be permitted only if a human approval occurred earlier in the workflow. Looking only at the final call cannot establish that condition. Something needs to remember the relevant execution history and evaluate policy against it.

That is the class of problem temporal policy addresses.

The interesting architectural choice is that this logic lives outside the agent.

The model does not need to faithfully remember the constraint from its prompt. The runtime owns the control.

More agent behavior is becoming explicit

This is not the only sign that agent instructions are moving out of conversations and into inspectable artifacts.

A recent ESEM 2026 study of Agent Plans screened 36,710 engineered GitHub repositories and found 85 Markdown plan files across 10 repositories.

That is a very small population, so I would not interpret the result as evidence of broad adoption.

But the content is interesting.

Those plans commonly described implementation steps, specific files or locations, and testing or validation instructions.

The agent's execution intent was being preserved as part of the repository.

There is a similar pattern in distribution.

Tenable's CyberAgents Exchange treats agents, skills, MCP servers, and multi-agent playbooks as separate reusable components.

The ecosystem is gradually decomposing "the agent" into more explicit pieces.

MCP gives the agent capabilities.

Skills help it understand how to use them.

Plans describe how work should be performed.

Runtime policies constrain what actions may happen and in what order.

That decomposition raises another question.

Where should organizational judgment live?

A permitted action is not necessarily a justified decision

Suppose an agent is onboarding a new vendor.

The runtime can verify that the user is authorized.

The gateway can verify that the agent is allowed to call the vendor-management API.

A temporal policy can require a recorded approval before the vendor is created.

But what determines whether the vendor should receive that approval?

The answer might depend on sanctions screening, tax documentation, annual spend, personal-data handling, risk classification, or an exception requiring committee review.

There may also be incomplete evidence.

If a required sanctions check could not be completed, the correct outcome may not be approval or rejection.

It may be:

insufficient evidence - escalate

This is not quite the same problem as tool authorization.

The runtime policy can enforce that approval must exist.

Something else still has to determine whether the evidence warrants approval.

This is where Judgment Pack currently sits

This distinction is part of what I have been exploring with the open-source Judgment Pack Specification.

A Judgment Pack externalizes the organization's decision criteria from the agent.

Instead of asking the model to reconstruct the business decision from a policy document every time, the pack can explicitly define the relevant evidence, rules, exceptions, unknown handling, and possible dispositions.

Conceptually:

facts
  |
  v
judgment
  |
  v
disposition
  |
  v
execution policy
  |
  v
action

But Dogwood makes the boundary less comfortable than that diagram suggests.

Both systems move deterministic logic outside the model.

Both are inspectable.

Both can produce an outcome that prevents an action.

Both can encode conditions and escalation.

That means the useful question is not whether JPS and Dogwood are "different."

The useful question is exactly where they differ.

The boundary I want to test

My current hypothesis is that the two systems may operate at different semantic levels.

A Judgment Pack evaluates evidence in order to determine an organizational disposition.

A temporal policy evaluates execution history and runtime state in order to determine whether an action is currently permitted.

For vendor onboarding, that might mean the Judgment Pack evaluates:

sanctions status
tax documentation
risk
annual spend
exceptions
missing evidence

and produces:

approve
reject
committee review
insufficient evidence

The runtime policy then evaluates things such as:

was approval recorded?
did the required previous step occur?
has the spending limit already been consumed?
is the authorization still valid?
may this tool execute at this point in the sequence?

That separation makes sense on paper.

I do not yet know whether it survives implementation.

Some JPS rules may turn out to belong naturally in runtime policy.

Some Dogwood policies may look much closer to organizational judgment than expected.

There may also be workflows where maintaining the distinction creates unnecessary complexity.

That would be useful to learn.

The next experiment should implement both

Rather than debate the architecture abstractly, I think the better next step is to take one realistic workflow and implement it twice.

Vendor onboarding is a useful candidate because it contains both kinds of constraints.

The decision side can include required evidence, a sanctions hard stop, a spend threshold, unknown facts, and escalation.

The execution side can require that the decision occurred, enforce ordering, prevent action after relevant state changes, and control the final tool invocation.

Then compare the two representations.

Which rules naturally belong in the Judgment Pack?

Which belong in Dogwood?

Which can be represented in either system?

Where does duplication appear?

What evidence would be required to prove that the final action was both justified and correctly executed?

Agent governance is becoming infrastructure.

That makes the boundaries between its components more important, not less.

The useful question now is not whether we need more governance layers.

It is whether we can define precisely what each layer is responsible for.

The Agent Stack Is Filling In. The Judgment Layer Is Still an Open Problem

Brian Jin — Sun, 09 Aug 2026 17:29:57 +0000

Over the last few days I have been looking at several developments around enterprise AI agents that initially seemed unrelated.

Cloudflare open-sourced its internal agent workspace platform.

Researchers published work on what happens when an agent authorizes an action using state that changes before execution.

Enterprise AI leaders are starting to talk less about how many agents they can deploy and more about whether those agents are producing measurable value.

There is also growing infrastructure around agent identity, tool access, observability, security, and runtime isolation.

Taken separately, these are different stories.

Together, I think they point to a larger architectural shift.

The ecosystem is getting much better at answering:

What can this agent access and execute?

But another question remains less well defined:

Given the available evidence, what should this organization actually decide?

Those are not the same question.

Cloudflare OS made the boundary easier to see

Cloudflare recently open-sourced Cloudflare OS, the platform it uses internally for AI agents.

The architecture is interesting because the model is not treated as the entire system.

There is organizational context. There are skills. There are MCP-connected tools. There are isolated environments in which agents operate. And there are Gatekeepers that help control what an agent can do.

This seems like a reasonable direction for enterprise agents.

As agents move closer to production systems, companies need much more than an LLM and a collection of tools.

But imagine using this architecture for vendor onboarding.

An employee asks an agent to onboard Acme Corp.

The employee has permission to make the request.

The agent has permission to call the vendor-management API.

The request passes the security gateway.

Does that mean the vendor should be onboarded?

Not necessarily.

The decision might depend on facts such as sanctions screening, tax documentation, annual contract value, country of registration, personal-data handling, or an internal risk score.

There may also be exceptions.

A sanctions match could be a hard stop.

A high contract value might require committee review.

Missing evidence might mean that neither approval nor rejection is correct yet.

The authorization layer can answer:

Is this agent allowed to perform this operation?

The business still needs an answer to:

Under our rules, is this operation justified?

That is the boundary I find interesting.

The decision may be correct while the action is wrong

A recent paper on stateful governance for concurrent agent systems describes another version of the problem.

Suppose two agents share the same purchasing budget.

Agent A checks the available budget and determines that a $30,000 purchase is allowed.

Before Agent A executes the purchase, Agent B spends $40,000.

The state has changed.

Agent A may have made the correct decision using the facts it had at evaluation time. Executing that decision later can still violate the organization's rules.

This is easy to miss when we think about agent governance only as a policy check performed immediately before a tool call.

For deterministic judgment systems, I usually describe one useful property as:

same facts + same judgment definition → same disposition

That gives us reproducibility.

But the concurrency problem suggests another requirement:

the facts that justified the disposition
must still be valid when the action commits

Those are different guarantees.

A production workflow might therefore need to look more like this:

Acquire facts
     ↓
Evaluate judgment
     ↓
Record disposition + relevant state
     ↓
Validate state / re-evaluate if necessary
     ↓
Execute

This is an area I want to experiment with because it sits directly between decision semantics and runtime enforcement.

Hundreds of agents create a different governance problem

Another signal comes from enterprise adoption.

Organizations are starting to discover that deploying agents is easier than understanding the full operational footprint afterward.

One recent report described a company where the CIO believed roughly 40 agents were operating internally. An audit reportedly found more than 400.

That number caught my attention because it changes the governance problem.

If you have three experimental agents, reviewing their prompts and workflows manually may be perfectly reasonable.

If you have hundreds of agents making decisions across finance, procurement, customer operations, HR, and IT, it becomes much harder to answer basic questions consistently.

Which decisions are these agents allowed to make?

What evidence must be available?

Which exceptions apply?

When must the agent abstain or escalate?

Who approved the decision logic?

Which version was active when a particular action happened?

These questions do not disappear because the underlying model becomes more capable.

Some of them become more important.

Why I separate judgment from the agent

This is the problem I am exploring with the open-source Judgment Pack Specification.

A Judgment Pack represents organizational decision logic as a separate artifact.

The goal is not to replace the agent.

The agent can still gather information, interact with users, use tools, and reason where reasoning is useful.

The difference is that the criteria governing a consequential business decision do not have to live entirely inside the agent's prompt.

For a vendor-onboarding decision, for example, a pack might define the required evidence, thresholds, exceptions, treatment of missing facts, and possible outcomes.

The agent supplies facts.

The evaluator applies the reviewed judgment definition.

The result can then be used by another layer responsible for execution.

Conceptually:

Agent
  ↓
Evidence acquisition
  ↓
Judgment Pack
  ↓
Disposition + evidence
  ↓
Gateway / policy enforcement
  ↓
Business system

I think this distinction becomes clearer as the rest of the agent stack matures.

MCP is solving connectivity.

Agent platforms are solving orchestration and execution.

Skills are helping models use systems correctly.

Security layers are controlling identity and access.

Observability platforms are helping companies understand what agents actually did.

None of those necessarily owns the organization's definition of a correct business decision.

I don't think this means every decision needs a Judgment Pack

A deterministic lookup does not need one.

A simple permission check probably belongs in an authorization system.

A low-risk conversational suggestion may be perfectly appropriate to leave to the model.

The interesting cases are decisions where the organization expects consistent treatment of evidence, rules, exceptions, uncertainty, and escalation.

That is where putting the judgment into a reviewable artifact starts to become useful.

I am particularly interested in testing this boundary against real agent platforms rather than defining it only on paper.

Cloudflare OS looks like one possible integration environment.

Concurrent state changes are another area I want to test.

And the larger question is whether this separation still makes sense when applied to real production workflows rather than clean examples.

That is the part I am trying to learn now.

If you are building enterprise agents and have a workflow where the difficult part is not tool access but deciding whether the action is justified, I would be interested in hearing what that decision looks like.

I Asked an AI to Author the Same Policy Tests 50 Times. It Hit Every Boundary in 49 Valid Runs.

Brian Jin — Fri, 07 Aug 2026 16:10:23 +0000

I have been experimenting with a specific question: can an AI independently author the test cases needed to challenge structured business decision logic?

Consider a vendor-screening policy with sanctions rules, country restrictions, personal-data conditions, and risk thresholds. If that policy is converted into executable decision logic, someone still needs to test the difficult boundaries - exactly 70 versus just below 70, whether an embargo-list member is handled correctly, or whether a condition changes when personal data is involved.

In the earlier Judgment Pack evaluator experiments, I gave an independent AI model the policy and asked it to author those kinds of records without seeing the Judgment Pack or the defects that would later be tested.

Before the authoring call, six classes of potential defects had already been committed.

The model authored records that covered all 6 of 6 classes.

That was encouraging, but it answered only one question:

Can the model do it?

It did not answer the more important reliability question:

If I ask it to do the same job again, how often will it cover those boundaries?

A single successful generation could simply be a lucky draw.

So Study 011 repeated the same blinded authoring task 50 times.

The result, for this particular experimental setup, was striking:

49 runs passed the preregistered pipeline checks
1 run was rejected before scoring
all 49 valid runs covered all six boundary classes
every valid run produced exactly 16 accepted records
784 of 784 accepted records agreed with the reference policy semantics
all 49 valid completions were different

For this one prompt, one model, and one synthetic policy, the answer to "how often?" was:

Every valid time we observed.

That sounds like a perfect result.

It isn't.

And understanding why is the interesting part of the experiment.

The problem: one good generation is not a reliability result

I am working on an open-source project called the Judgment Pack Specification.

One area I am exploring is whether AI can help humans author the structured test cases around organizational decision logic.

Imagine a vendor-screening policy containing rules such as:

sanctions matches create a hard stop
vendors registered in embargoed countries require a different outcome
a risk score of 70 crosses a high-risk boundary
handling personal data changes the threshold at 40

Those rules produce boundaries.

And boundaries are where subtle errors tend to hide.

For example:

risk = 69.99
risk = 70
risk = 70.01

can represent three very different cases if the policy says:

risk >= 70

The same issue appears around a personal-data threshold:

39.99
40
40.01

If AI is going to help author tests for these rules, I do not only care whether it notices the boundary once.

I want to know how consistently it notices it.

Study 011 asked "how often?"

The experiment used one fixed cell:

one model - gpt-5.6-sol
one fixed prompt
one fixed synthetic policy
one pinned CLI and binary
fresh isolated environment for each call
50 sequential authoring calls
six preregistered coverage classes

The prompt, policy family, binary, environment capture, and preregistration were all digest-pinned.

The scoring rules were fixed before looking at the batch.

There were no competing arms and no hypothesis test.

This study was simply estimating a frequency.

What counts as coverage?

Six boundary classes were registered before the batch.

Class 0 - exact high-risk boundary

No sanctions hit
Non-embargoed country
risk = 70

This catches a common implementation error:

risk > 70

instead of:

risk >= 70

The model independently authored records with names such as:

exact-high-risk-threshold
northstar-risk-seventy
alpine-exact-seventy
summit-exactly-seventy

Every valid run included a correctly labelled record at this boundary.

Coverage: 49/49

95% exact interval:

[0.9275, 1.0000]

Class 1 - the off-by-one region above 70

The next class tested:

70 <= risk < 71

Why?

Imagine someone accidentally changes the threshold from:

>= 70

to:

>= 71

Testing only 70 and 80 might miss useful information about that region.

The authored records included cases represented by names such as:

fraction-above-high-risk-threshold
atlas-risk-seventy-decimal
harbor-above-seventy
baltic-risk-above-seventy

Again:

Coverage: 49/49

Class 2 - personal-data boundary at 40

The policy also changes behavior when a vendor handles personal data.

This class tested:

handles personal data
40 <= risk < 41

It is designed to expose a lower-bound change such as:

risk >= 41

instead of:

risk >= 40

Examples of independently authored records included:

personal-data-exact-threshold
harbor-data-risk-forty
bluebell-personal-data-at-forty
maple-data-forty

Coverage: 49/49

Class 3 - the interior decision region

This class tested:

40 <= risk < 70

with either value of the personal-data flag.

This was intentionally broader.

The model repeatedly generated multiple records across this space, including examples labelled:

personal-data-mid-band
no-personal-data-mid-band
fjord-data-midrange
andes-no-data-moderate-risk

Coverage: 49/49

Class 4 - membership rather than arithmetic

Not every policy defect is a numeric threshold.

Another class tested vendors registered in Syria:

registered country = SY

This was designed to catch a mutation where SY disappears from an embargo list.

The model repeatedly produced examples such as:

syria-registration-high-risk
damascus-embargo-high-risk
levant-syria-high-risk
levant-cloud-embargo

So the authoring behavior was not limited to discovering numeric boundaries.

Coverage: 49/49

Class 5 - the interesting one

The final class tested:

handles personal data
39 <= risk < 40

This class deserves special attention.

The synthetic policy text explicitly mentions the threshold at 40.

It does not explicitly say:

Please test the hidden family boundary at 39.

Yet all 49 valid runs produced a record inside this interval.

The actual values were extremely revealing:

28 runs used 39.99
21 runs used 39.999

So the model was consistently generating a "just below 40" case.

Examples included:

personal-data-just-below-forty
fjord-data-below-forty
maple-data-below-threshold
cedar-data-below-forty

This technically covers the registered class.

But it does not prove that the model discovered some hidden semantic threshold at 39.

A much simpler explanation fits the evidence:

The prompt asked for borderline cases around the stated threshold of 40, and the model generated values immediately below 40.

That distinction matters.

Coverage is real.

The interpretation must remain narrow.

The headline result

Across the six classes:

Class	Valid runs covering it	Rate
Exact risk = 70	49 / 49	100%
70 <= risk < 71	49 / 49	100%
Personal data + 40 <= risk < 41	49 / 49	100%
40 <= risk < 70	49 / 49	100%
Registered in SY	49 / 49	100%
Personal data + 39 <= risk < 40	49 / 49	100%

Each rate has the same exact 95% Clopper-Pearson interval:

[0.9275, 1.0000]

That interval is important.

Observing 49 successes out of 49 valid runs does not establish a true rate of 100%.

With this sample size, the experiment cannot distinguish:

"always"

from something like:

"at least about 92.75% under this experimental cell"

That is why I prefer reporting:

49 / 49
95% CI [0.9275, 1.0000]

rather than simply saying:

100% reliable

Every output was different

Another result surprised me.

All 49 valid completions were distinct.

The largest group of byte-identical outputs was:

So this was not one cached completion accidentally counted 49 times.

The model varied names, examples, and record composition across runs.

For example, the exact-70 case appeared under names including:

exact-high-risk-threshold
northstar-risk-seventy
atlas-risk-threshold
alpine-security-threshold
granite-risk-seventy
summit-risk-threshold

The surface form changed.

The boundary coverage did not.

That is an interesting form of consistency:

Different generations converged on the same important semantic regions.

But even this has a limitation.

Different outputs do not prove statistically independent draws.

Provider-side cross-session behavior is not observable from the retained artifacts.

The study records that limitation rather than pretending it can prove independence.

784 accepted records, zero observed label disagreements

Each valid run produced exactly:

16 records

Across 49 runs:

49 x 16 = 784 accepted records

Against the study's policy mirror:

policy-concordant records: 784
mislabelled records:        0
dropped records:            0

So pooled label agreement was:

784 / 784 = 1.000

I deliberately do not attach a binomial confidence interval to that number.

The 16 records inside a single completion are not independent trials.

Treating all 784 records as independent observations would make the precision look much stronger than it really is.

The run remains the meaningful repeated unit.

One run failed - and I think that is useful

Run 026 was not scored.

The model process itself exited successfully.

But the pre-prompt developer context did not match the locked golden context.

The pipeline therefore returned:

transcript-refused

and excluded the run before looking at its authored records.

The observed pipeline-invalid rate was:

1 / 50 = 2%

with a 95% interval of:

[0.05%, 10.65%]

The likely explanation is service-side boilerplate variation.

But the study deliberately does not inspect the refused transcript and say:

This difference looks harmless, let's count it anyway.

That would undermine the point of having an allowlist.

The rule was:

context matches the registered environment
        -> admit

context differs
        -> refuse

So it refused.

I actually find this result useful.

The model-authoring behavior looked extremely stable.

The experimental pipeline was not perfect.

Those are two different reliability questions.

What about human review?

Before running the batch, the study registered a deliberately simple mapping from observed coverage to review depth.

It uses the lower bound of the confidence interval:

lower >= 0.80  -> LIGHT review
lower >= 0.40  -> STANDARD review
lower < 0.40   -> FULL review

A high mislabelling rate can escalate the tier.

All six classes ended with:

lower bound = 0.9275
mislabel share = 0
tier = LIGHT

So under the preregistered mapping, every class receives:

LIGHT review.

That does not mean AI-authored policy artifacts no longer require humans.

The review-tier mapping itself is experimental and has not been validated operationally.

But it suggests an interesting direction.

Instead of treating every AI-authored rule or test case as equally trustworthy, perhaps review depth can eventually depend on empirical evidence about the authoring process.

Something like:

AI authors candidate records
        |
        v
measure historical coverage / error rates
        |
        v
assign confidence
        |
        +------ high confidence ------> light review
        |
        +------ uncertain ------------> standard review
        |
        +------ weak evidence --------> full review

That is much closer to what I ultimately want from AI-assisted authoring.

Not:

"The model wrote it, trust it."

And not:

"The model wrote it, manually redo everything."

Instead:

"We have measured evidence about where this authoring process is strong and where humans should spend their review time."

What this study does NOT show

This is the most important section.

The result does not mean:

AI can reliably author arbitrary organizational judgment.

It means:

This prompt, with this model, on this small synthetic policy, repeatedly produced correctly labelled records reaching these six registered classes.

Nothing more transfers automatically.

It is one model

Only one model configuration was tested.

A different model may behave differently.

It is one prompt

The prompt explicitly asks for borderline cases.

That probably contributes substantially to the ceiling result.

It is one small synthetic policy

The policy has a few thresholds, one membership rule, sanctions logic, and a personal-data condition.

Real organizational policies can contain:

interacting exceptions
multiple documents
ambiguous language
precedence
temporal conditions
missing evidence
conflicting authorities
human approval requirements

Those may produce very different rates.

The mirror is not ground truth

"Correctly labelled" means the authored outcome agrees with the study's deterministic mirror.

The same policy supplied to the model is implemented in that mirror.

So:

784 / 784

measures consistency with the supplied policy semantics.

It does not independently prove those semantics are correct in the real world.

Coverage is not defect detection

Study 011 never evaluates a mutated Judgment Pack.

It asks whether an independently authored record lands in a region that could expose a registered defect.

Study 010 performed the single defect-detection draw.

Study 011 measures the repeatability of the authorship coverage behind it.

Those are deliberately separate claims.

The result changed how I think about AI authoring

Before this experiment, I was mostly thinking about AI-assisted authoring as:

policy
  |
  v
AI
  |
  v
candidate structured artifact
  |
  v
human review

I now think a better model might be:

                 historical evaluations
                         |
                         v
policy -> AI author -> candidate artifact
                         |
                         v
                 automated validation
                         |
                         v
                 confidence estimate
                         |
              +----------+----------+
              |          |          |
            LIGHT     STANDARD     FULL
            review      review      review
              |
              v
        authorized approval
              |
              v
          versioned artifact

The interesting question becomes less:

Can AI author the artifact?

Frontier models increasingly can.

The harder question is:

How much review does this particular generated artifact deserve?

That is something we may be able to measure.

What I want to test next

The obvious next experiment is not another 50 runs of this same cell.

This one is already sitting at the ceiling.

The useful next variable is the thing this study deliberately held constant.

For example:

Change the policy

Use a larger policy with interacting rules and exceptions.

Does coverage remain near the ceiling?

Change the model

Run the same registered task across multiple model families.

Do the boundary classes remain stable?

Remove the boundary-forward wording

If the prompt stops explicitly asking for borderline cases, what happens to classes like:

39 <= risk < 40

That would help separate general semantic discovery from prompt-induced test generation.

Introduce ambiguity

What happens when the policy itself contains:

conflicting language
incomplete evidence requirements
inconsistent descriptions and executable conditions
unclear precedence

That is much closer to the real authoring problem.

The takeaway

Study 010 told me:

The independent author can cover all six classes.

Study 011 tells me something stronger:

Under this exact experimental setup, that coverage was the typical observed behavior, not a lucky single run.

But the more important lesson is methodological.

One impressive AI output is an anecdote.

Repeated outputs give you a rate.

A rate gives you uncertainty.

And uncertainty can start informing how much human review an AI-generated artifact deserves.

For this experiment:

50 calls
49 valid
49 / 49 valid runs covered all six classes
784 accepted records
0 observed label disagreements
49 distinct completions
1 pipeline refusal

Promising?

Yes.

Proof that AI can safely author organizational judgment without review?

Absolutely not.

The next job is to find where these numbers stop being this clean.

The experiment, preregistration, retained artifacts, scorer, and analysis are all part of the open-source Judgment Pack evaluator experiments repository.

I would especially welcome adversarial policy examples that you think would break this authoring approach.

What I Learned Trying to Make AI-Agent Decisions Testable

Brian Jin — Wed, 05 Aug 2026 23:30:29 +0000

What I Learned Trying to Make AI-Agent Decisions Testable

AI agents can retrieve the right policy, call the right tools, and still reach the wrong conclusion.

That gap became increasingly hard for me to ignore.

Most agent systems are getting better at access and execution. They can search documents, query databases, call APIs, use MCP servers, and complete multi-step workflows.

But many important business decisions depend on something different:

Which evidence is actually required?
Which rule applies in this situation?
Which exception changes the outcome?
What should happen when evidence is missing or conflicting?
When must the agent stop and escalate?

Those questions are often buried inside prompts, application code, policy documents, or the judgment of a few experienced people.

That makes them difficult to test, review, reuse, and improve.

The Problem Is Not Always Missing Knowledge

Imagine an agent reviewing a new vendor.

It retrieves:

the vendor-onboarding policy
the sanctions-screening result
the tax form
the proposed annual spend
the business justification

The agent has access to all the relevant information.

But it still has to determine:

whether the request is in scope
whether all mandatory evidence is present
whether a sanctions match creates a hard stop
whether high annual spend requires committee review
whether incomplete evidence means rejection or escalation
whether it has enough information to decide at all

Retrieval helps the agent find the policy.

It does not guarantee that the agent will apply the policy correctly.

A model may produce a plausible explanation while overlooking an exception, treating missing evidence as negative evidence, or claiming that approval occurred when no authorized person was consulted.

The answer can sound reasonable and still be indefensible.

Why Coding Agents Often Feel More Reliable

Coding agents currently provide one of the clearest examples of useful multi-step agent behavior.

I do not think that is only because models are unusually good at code.

Coding agents work inside an environment that already knows how to challenge their output:

compilers
unit tests
type systems
linters
runtime feedback
version control
code review
CI/CD

The model proposes work.

The surrounding environment evaluates it.

Most business agents do not have an equivalent judgment harness.

They may have access to tools and knowledge, but the conditions behind a defensible decision remain implicit.

What I Tried First

The obvious place to start was prompts.

A prompt can say:

always check sanctions
require a tax form
escalate high-value vendors
never approve when evidence is incomplete

This can work for a narrow workflow.

But as the decision grows, the prompt becomes difficult to review and test. Rules, exceptions, evidence requirements, explanations, and workflow instructions become mixed together.

A model can also interpret the same prose differently across runs or implementations.

The next option is application code.

Hard-coded logic is more deterministic, but it creates another problem. The judgment becomes coupled to one application, one programming language, and one deployment.

A domain expert cannot easily review it. Another agent cannot reuse it without reproducing the logic. Changes become software releases rather than reviewed updates to an organizational decision contract.

Skills and tool definitions help package behavior.

MCP helps standardize access to context and capabilities.

Policy engines can evaluate explicit rules.

All of these are useful. None of them, by themselves, fully represent the evidence, applicability, exceptions, uncertainty, and escalation conditions behind a business decision.

That led me to experiment with separating the judgment from both the model and the workflow.

The Idea: A Testable Judgment Contract

I started working on what is now the Judgment Pack Specification.

A Judgment Pack is a declarative representation of the conditions behind a decision.

At a high level, a pack can describe:

what question is being decided
when the pack applies
which evidence is required
which facts are relevant
which rules and exceptions affect the outcome
which conditions make the decision unresolved
when escalation is required
which outputs are valid
how expected behavior can be tested

A simplified vendor-onboarding pack might express:

Decision:
May this vendor be onboarded?

Required evidence:
- sanctions-screening result
- tax-form status

Exceptions:
- sanctions match → hard stop
- annual spend above threshold → committee review

Unresolved conditions:
- required evidence missing
- screening could not be completed
- approval authority is unknown

The important part is not the file format.

The important part is that the decision conditions become a reviewable and testable artifact rather than hidden instructions inside a prompt.

What Testability Changes

Once the judgment is explicit, we can write scenarios such as:

Scenario 1:
Sanctions clear
Tax form received
Spend below threshold
Expected result: eligible for approval

Scenario 2:
Sanctions match
Tax form received
Expected result: hard stop

Scenario 3:
Sanctions screening missing
Tax form received
Expected result: unresolved

Scenario 4:
Sanctions clear
Tax form received
Spend above threshold
Expected result: committee review

Now a change to the pack can be evaluated against known expectations.

If someone modifies the annual-spend exception and an existing scenario starts producing direct approval instead of committee review, the test should fail.

That is closer to what coding agents already have: an environment that can challenge the result.

Correctly Refusing to Decide Is Part of Correctness

One lesson has become especially important.

A business agent should not always produce an answer.

Sometimes the correct outcome is:

evidence required
unresolved
not applicable
escalate
human approval required

Many current evaluation approaches reward producing the expected answer. But in enterprise decisions, a system can also fail by deciding when it should have stopped.

That means abstention and escalation cannot be treated as fallback error states.

They are first-class outcomes.

A useful judgment system must be able to distinguish:

“The answer is no”

from:

“The system does not yet have authority or evidence to answer.”

Those are operationally very different.

What Judgment Pack Does Not Solve

I do not see this as a replacement for agent frameworks, MCP, policy engines, or knowledge graphs.

They solve different parts of the system.

MCP can connect an agent to a sanctions service.

A gateway can control whether the agent is allowed to call it.

A policy engine can evaluate a deterministic rule.

A knowledge graph can represent relationships and organizational context.

A Judgment Pack is intended to describe how those inputs contribute to a defensible decision.

It also does not prove that source data is true.

If a system receives a false sanctions result, a correct evaluator can still produce the wrong real-world outcome. Provenance, source trust, authorization, and evidence acquisition remain separate concerns.

The current project is an attempt to make those boundaries explicit rather than claiming one specification solves all of agent governance.

Questions That Are Still Open

Opening the project as open source is important because several of the hardest questions should not be answered by one person.

Some of the questions I am currently exploring are:

How should an agent select the correct pack?
How should multiple packs compose?
Where should Judgment Pack end and policy engines begin?
How should conflicting evidence be represented?
Which evaluator semantics must be portable across runtimes?
How should evidence freshness be expressed?
How should organizations version and approve judgment changes?
How should authorization be separated from decision evaluation?
What makes an explanation defensible rather than merely plausible?

These are specification questions, runtime questions, and organizational questions at the same time.

Why I Opened It

I spent many years building enterprise data platforms, operational systems, and AI infrastructure.

Across those environments, organizations often had plenty of data and documentation. What they struggled to preserve was the judgment behind important decisions:

which evidence mattered
why an exception was allowed
when a rule stopped applying
who had authority
what uncertainty required escalation

Frontier models can reason over more context and use more tools.

But every organization still has its own conditions for what counts as an acceptable decision.

That judgment should not remain trapped inside prompts, undocumented code, or individual experience.

It should be possible to review, test, version, and improve it.

The Project Is Now Open Source

The Judgment Pack Specification and runtime are now open source.

I am looking for contributors in several areas:

Specification review

Challenge how the project represents evidence, exceptions, uncertainty, escalation, and outcomes.
Real-world decision packs

Contribute a difficult decision from procurement, data governance, security, support, finance, operations, or another domain.
Adversarial scenarios

Add cases where a reasonable-looking agent should refuse, escalate, or produce a different outcome.
Runtime and tooling

Improve the Go runtime, evaluator, CLI, documentation, and agent integrations.

The most useful first contribution may not be code.

A real decision that exposes where the current model breaks can be more valuable than another feature.

Website: judgmentpack.org
Specification: Judgment-Pack/judgment-pack-spec
Good first issues: Browse beginner-friendly issues

I would especially value critical feedback from people working on agent evaluation, MCP, policy engines, rules-as-code, human approval, and enterprise AI systems.

The project will improve faster through strong disagreement and real use cases than through agreement alone.

Disclosure: AI tools assisted with editing and structure. The project design, technical content, examples, and final review are my own.

DEV Community: Brian Jin

I stopped printing the thresholds in the policy. The AI wrote the same tests anyway.

First, an important correction to the original experiment

The comments that turned this into another experiment

Five versions of the policy

Result 1: move the thresholds, and the tests move with them

Result 2: hide 40 and 70, and the model still finds them

But a failed prediction does not prove the opposite

The policy may not have been novel to the model

Version E hides the numerals, not the arithmetic

Each perturbation is represented by one policy instance

Then I discovered that my retraction was wrong too

What actually survives

What developers can actually use from this

The lesson I didn't expect to get from the study

This study started in the comments

When Agents Can Act on Real Devices, Governance Moves Beyond the Prompt

The execution loop is becoming more autonomous

Skills introduce another trust boundary

Capability, authorization, and judgment are different problems

Where Judgment Pack fits

Open-source governance points in a similar direction

Google gives us a useful environment to test the boundary

The Receipt Was Valid. The Policy Was Retired.

This started with a public architecture discussion

A fourth check, not a replacement for the first three

OpenWorkProof

Judgment binding

Deterministic replay

Policy currency

The minimal registry

The experiment

Finding 1 - the registry caught a failure the receipt chain could not

Finding 2 - a policy registry cannot solve authorization-contract currency

Finding 3 - two valid histories expose the stateless-verifier ceiling

Finding 4 - offline verification cannot reconstruct "current when used"

History A

History B

The reviewer corrected something I had already said publicly

Why the holdout matters

What this study does not establish

The next evidence should probably come from outside JPS

The progression so far

Study 013 - behavior

Study 014 - provenance

Study 016 - currency

Receipts

Five Adversarial Reviews Told Me My Study Was Measuring a Fiction

The setup

First lesson: read the implementation contract, not the architecture you imagine

The generic MCP Gatekeeper cannot become vetted through normal configuration

A read-only classification can bypass the action queue

The outer action log cannot represent every execution outcome

approved is not proof that the external effect happened

appliedAt is not necessarily "when the action was applied"

The useful join key is intentionally not public

Approval rules do not create historical policy evidence

This does not mean Cloudflare OS is doing the wrong job

Then the reviewers started attacking the study itself

Round 1 - seven blockers

Round 2 - five blockers, including fixes that were themselves wrong

Round 3 - the historical witness problem

Round 4 - correct counts can hide the wrong cause

Round 5 - one predicate left

Four things I personally wrote down that were false

1. "This component cannot be typechecked from the committed tree."

2. "The adapter reproduces upstream behavior."

3. "The tool name never appears in the log."

4. "There is no action-log export anywhere."

What I would carry into any similar experiment

Verify the reviewer

Fix the missing mechanism when you own the artifact

Narrow claims aggressively

Delete checks that cannot fire

Verify scripted edits after they run

A study can be honest and still not be ready

The boundary that remains open

When Agents Can Run Anywhere, Where Should Organizational Judgment Live?

The model is becoming one component of the system

Institutional knowledge is not necessarily institutional judgment

`approved` is not proof that the external effect happened

`appliedAt` is not necessarily "when the action was applied"