Case 002Built · Verifiable acceptance

ProofJudge

AI agents are starting to decide whether work is good enough to be paid. Who verifies the judge?

ArtifactEigenCompute hackathon system

PrimitiveSigned DecisionArtifact

BoundaryTamper-evident, not infallible

ProofJudge threshold showing a sealed acceptance receipt

The threshold

Acceptance is becoming infrastructure.

When software agents produce paid work, a score is not enough. Payers, workers, evaluators, and downstream systems need a shared record of the terms, the decision, the judge identity, and whether the record changed afterward.

Touch the trust boundary

One changed point. One broken seal.

The project’s strongest demonstration is deliberately small: alter a signed receipt after the verdict. The artifact hash diverges, signature verification fails, and settlement should stop.

Interactive reconstructionReceipt sealed

ProofJudgeDecision receipt

Verdict

Accepted

Release payment

Case: OAuth callback hardening
Score: 92 / 100
Artifact hash: e692ee02…647c7d8a
Signature: HMAC-SHA256 · effa91fd…
Judge identity: 0xd36476…e5aC0

Verification result

The sealed record matches.

The receipt body, hash, signature, identity fields, and timestamp agree with the sealed artifact.

Pass Schema recognized
Pass Artifact hash
Pass Signature
Pass Deployment identity present

This demonstrates the project’s trust boundary; it does not perform live cryptographic verification.

The write-up

From an AI opinion to an accountable artifact.

01 / Terms

Make acceptance explicit before judgment.

ProofJudge receives task terms, a rubric, and submitted work. The acceptance boundary becomes inspectable instead of remaining an unstated preference.

02 / Decision

Preserve more than a score.

The resulting artifact carries the verdict, settlement recommendation, evidence checked, reasoning trace, hashes, signature, deployment identity, timestamp, and attestation mode.

03 / Verification

Let another system check the record.

The verification endpoint checks the schema, receipt body, artifact hash, service signature, identity fields, attestation mode, and timestamp. Altered fields break the seal.

04 / Limit

Provenance is not objective truth.

Verification can establish which evaluator produced a decision under which rubric and whether the receipt changed. It cannot establish that the evaluator’s judgment was correct.

One receipt model

Four domain-specific judges.

The same acceptance primitive was deployed for four kinds of consequential work, each with its own rubric and runtime identity.

Code

Reviews code bounties and pull requests against explicit acceptance terms.

Research

Evaluates sourced research deliverables and the evidence behind their claims.

Negotiation

Checks proposals against declared constraints from neutral ground.

Governance

Evaluates proposal completeness and risk before consequential votes.

ProofJudge tamper test with failed hash and signature checks

What was built

A working receipt and verification pipeline.

The project includes a judging API, four domain configurations, signed receipt construction, a verification endpoint, deterministic fallback behavior, a guided proof sequence, and a browser receipt archive.

Current signing: Service-verifiable HMAC-SHA256
Trust upgrade: Offline asymmetric verification
Public claim: Accountable record, not perfect judgment

Inspect ProofJudge on GitHub

The larger question

As agents do more consequential work, which decisions need receipts?

Explore the Lab