Inspiration

What it doesAI can accelerate research, software development, analysis, and reporting. But the same speed creates a new integrity problem: once a result is known, it becomes easy to revise thresholds, regenerate an unfavorable review, hide failed attempts, or rewrite the original claim so that the outcome appears stronger.

I built Rufino ProofLock around a simple question:

How can we prove that a claim, its metrics, and its success criteria were fixed before the result existed?

The project was inspired by the need for a practical chain of custody for AI-assisted experiments—one that preserves not only successful outcomes, but also negative results, blocked attempts, and unfavorable AI reviews.

Its guiding principle is:

Scientific outcome  =Evidence integrity

A negative result can have excellent integrity. A positive result can still be rejected when its evidence chain is broken.

What Rufino ProofLock does

Rufino ProofLock is an AI-native chain of custody for reproducible experiments.

Its workflow is:

DEFINE → REVIEW → LOCK → EXECUTE → SEAL → AUDIT → EXPORT

Before execution, the user defines:

a falsifiable claim; the evaluation metrics; the success criteria; the permitted execution boundary; the evidence that must be preserved.

ProofLock converts the contract into canonical JSON and records its SHA-256 identity. Once locked, the contract can no longer be silently rewritten.

The system then permits one controlled execution, seals the primary result, preserves failed or blocked attempts, audits the order and identity of the artifacts, and exports a portable evidence bundle that can be verified offline.

ProofLock deliberately separates two conclusions:

Scientific outcome: Did the experiment pass or fail? Evidence-chain integrity: Was the process executed and preserved according to the locked contract?

ProofLock does not claim that a hash proves the underlying science is true. It verifies integrity, identity, and order for the artifacts it controls.

How I built it

I built Rufino ProofLock as a Python application with a Streamlit interface and an evidence-oriented core.

The product includes:

canonical JSON serialization; SHA-256 artifact identity; pre-execution contract locking; temporal and state-transition gates; one-shot execution consumption; primary-result sealing; preservation of failed attempts; evidence-chain auditing; portable bundle export; offline bundle verification; agent-provenance records.

The interface walks the user through the full lifecycle: defining the experiment, reviewing the draft, locking the contract, executing once, auditing the evidence, and exporting the result.

The final repository state passed 32 of 32 automated tests.

How I used GPT-5.6

GPT-5.6 Sol was integrated as a reviewer for contracts that were still mutable.

The model reviewed the experimental draft through the Responses API using strict structured output. Its role was not to produce the desired answer, but to identify weaknesses before the contract became immutable.

In the preserved demonstration, GPT-5.6 returned:

lock_ready=false

It found that the evaluation data and metric semantics were not sufficiently specified.

That unfavorable response became an important part of the demonstration. I did not regenerate the review until the model produced a more convenient answer. ProofLock preserved the original result as evidence.

This showed one of the project’s core ideas: an AI review is useful only when its provenance and unfavorable outputs are preserved.

How I used Codex

Codex was used to implement an offline evidence-bundle verifier under a deliberately bounded task.

Its authority was restricted to four files:

README.md prooflock/cli.py prooflock/verify.py tests/test_verify.py

Codex was not permitted to modify:

the ProofLock core; the Streamlit application; the GPT-5.6 integration; repository instructions; Git history.

It also could not commit its own work.

After Codex completed the implementation, I independently reviewed the changes and tested the verifier against both a valid export and a deliberately corrupted copy. The contribution was accepted only after human verification.

This made Codex part of the evidence chain rather than an unrestricted code generator.

Live read-only case

The demo also includes SofiaStar as a live, read-only use case.

A pool of 137,036 candidates was committed before a future public-randomness event. An early attempt to select a candidate was blocked because the committed event had not yet occurred.

At the time of the demonstration:

candidate selected: no confirmatory metric computed: no early execution attempt: blocked and preserved

The case demonstrates that ProofLock can enforce temporal boundaries before a future result exists. SofiaStar is displayed only as sealed evidence; ProofLock does not alter or advance its scientific process.

Challenges

The hardest challenge was defining the trust boundary honestly.

It would have been easy to describe ProofLock as proving that an experiment is “true.” That would be incorrect. SHA-256 can establish artifact identity, but it cannot prove that an external dataset is representative or that a scientific interpretation is valid.

The product therefore makes a narrower and more defensible claim:

ProofLock verifies the integrity and order of the evidence it controls—not truth by proclamation.

Another challenge was preserving unsuccessful events as first-class evidence. Traditional workflows often emphasize only the final successful run. ProofLock had to retain blocked attempts, negative outcomes, unfavorable model reviews, and corrupted-bundle test results without allowing them to be silently replaced.

A third challenge was balancing AI assistance with human authority. GPT-5.6 and Codex were useful precisely because their permissions were constrained, their outputs were preserved, and their contributions remained subject to human review.

What I learned

I learned that reproducibility is not only about saving code and data. It is also about preserving sequence:

What was claimed? When was it locked? What was permitted to run? What happened first? What failed? What changed? Who or what produced each artifact?

Inspiration

I also learned that negative evidence can be more valuable than a polished success story. A preserved lock_ready=false, a blocked premature execution, or a corrupted bundle rejected by the verifier can demonstrate integrity more convincingly than an unbroken sequence of favorable outputs.

Most importantly, I learned that AI systems become more trustworthy when their authority is explicit, bounded, and auditable.

Result

Rufino ProofLock demonstrates a working approach to AI-assisted experimental custody:

freeze the claim before the result; preserve inconvenient evidence; separate outcome from integrity; constrain agent authority; verify the final bundle offline.

The goal is not to make scientific judgment automatic. It is to make silent retrospective rewriting harder—and visible when it happens.

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Rufino ProofLock

Built With

  • api
  • codex
  • command
  • git
  • github
  • gpt-5.6
  • interface
  • json
  • line
  • openai
  • responses
  • sha-256
  • streamlit
Share this project:

Updates