ProofVault now carries part of its own proof burden in the repository.
I built a trust dossier, a pinned specimen, automated regeneration and drift detection, and a hosted-CI-enforced release path that narrows the public claim to what the evidence can actually support.
The goal was not to claim more trust.
The goal was to reduce the amount of trust a reviewer has to grant without evidence.
Subhead
A reproducible trust case for an offline-first encrypted evidence app, with a deliberately bounded guarantee surface, pinned specimen, drift enforcement, and a public release tied to an exact hosted-green commit.
The short version of the claim: what is being promised, what evidence exists in the repo, how it is verified, and what residual risk remains outside the guarantee boundary.
What I built
- bounded trust case and threat model
- reduced claim surface: the repository only promises what the specimen and release path can prove
- pinned demo specimen with observed outputs
- verifier path showing valid and tampered behavior
- local and hosted-CI specimen regeneration
- drift detection that fails when trust-critical output changes
- public release tags preserving provenance across
v1.0andv1.0.1
What made this hard
Local success was not enough.
GitHub's hosted runner exposed cross-environment drift that did not appear on the initial local path.
The specimen had to be stabilized without weakening the invariant.
That required fixing the cause of the mismatch rather than teaching the checks to ignore it.
It also required shrinking the guarantee boundary until every remaining claim could survive hostile inspection.
What I fixed
- host-local timestamp rendering
- archive metadata drift across environments
- pinned specimen metadata incorrectly stamping the live Node patch version
How the trust case works
The trust dossier defines the guarantee boundary and the threat model.
That boundary is part of the point.
ProofVault minimizes not user data collection, but unearned trust claims.
The specimen gives the repository a pinned thing to prove against.
The verifier path shows both sides of the claim: expected behavior for a valid specimen and visible failure for a tampered one.
Regeneration keeps the specimen reproducible.
Drift enforcement makes trust-critical change explicit instead of silent.
Hosted CI closes the loop by validating the final non-debug release tree before the public cut is accepted.
The release-binding surface: the specimen, tree, hash, and drift state are made legible enough to inspect quickly under skepticism.
Why the hosted path mattered
This release would have been weaker if it stopped at a local green run.
The hosted runner surfaced drift that the local path did not show.
That difference mattered because the trust claim was not just "the code can pass on one machine."
The claim was that the public release itself could be inspected, reproduced, and tied to the exact hosted-green commit that produced it.
That is a narrower claim surface than "trust us, it passed somewhere once," and therefore a stronger one.
Outcome
- trust specimen is reproducible and release-bound
- guarantee surface is smaller and more defensible
- hosted CI validates the final non-debug release tree
proofvault-trust-case-v1.0remains immutableproofvault-trust-case-v1.0.1publishes the corrected hosted-stable release
Impact line
Trust claims narrowed, legible, reproducible, and release-bound.
Where to inspect next
- Read the portfolio case study at /case-study/proofvault
- Inspect the trust dossier at /projects/proofvault
- Review the public proof surface at /proof