ProofVault が証明責任の文書宣言から、再現可能なリリースアーティファクトへと変容させた経緯

ProofVault は現在、自身の証明責任の一部をリポジトリ内に担っています。 多くのプロジェクトはセキュリティ、プライバシー、または完全性について関心が深いが、具体的な試料を提示し、リポジトリから再生成して、自動的なドリフト検出、改ざんの有無を示す、あるいは公開タグに紐付く正確なホストグリーンリリースツリーを識別できるのは少数です。 ProofVault はこれを成し遂げました。 この記事では、単なる文章に頼らず、コード、生成アーティファクト、CI、およびリリース規律を通じて強制される信頼ケースの構築について述べるものです。 その結果、ProofVault Trust Case v1.0.1という、オフラインファーストの暗号化証拠アプリの再現性のある信頼ケースを導き出し、それは正確な公開リリースに紐付けられ、ホストされた CI において安定しています。 ProofVault は、不安定、プライバシー敏感、かつ高ストレスの条件下のために設計された、オフラインファーストの暗号化証拠および事象キャッチュアプリケーションです。 そのようなシステムは、通常の製品ソフトウェアよりも高い証明責任を背負っています。 アプリがデータを暗号化すると言うだけでは不十分です。アプリがレコードをエクスポートすると言うだけでは不十分です。認証機能を持っていると言うだけでは不十分です。 これらの主張は、具体的な物事、検証可能なもの、反復可能なものとの結びつきを持たない限り、抽象的なままです。 これが、この信頼ケース作業が目指した隙間でした。 目標は、検証可能な形式で回答する公開アーティファクトを作成することでした。 ProofVault が保証するもの ProofVault が保証しないもの それらの主張を支持する証拠 第三者が信頼に決定的な出力をどのように再現できるか 環境が変化した際にリリースの完全性がどのように保存されるか その結果、docs/trust-case/ 下に信頼ドосьエが、docs/trust-case/demo/ 下にピンセットされた試料が存在します。 そのパッケージには含まれています： 有境界の信頼ケース 明確な脅威モデル 実試料に基づく検証ウォークスルー ピンセットされた観測結果と冻结されたデモケース 自動化された再生成とドリフト検出 GitHub のホストランナー上で試料を強制する CI ワークフロー 重要な点は、これらの部品が個別に存在することです。 重要な点は、それらが互いに接続されていることです。 リポジトリは現在言えます： これは試料です。 これは再生成方法です。 これは期待された出力とされるものです。 これはドリフト検出方法です。 これは改ざんが何を見るかです。 これはホストされた CI を通過した正確なリリースツリーです。 その証明に紐付く公開タグです。 これは README の一文とは異なる類の信頼性です。 ピンセットされた試料は会話を変化させました。 抽象的な完全性について話す代わりに、信頼ケースには実際のエクスポート、実際の証明マニフェスト、実際の検証レポート、実際のフィンガープリントデータ、そして不一致行動を示す実際の改ざんケースが含まれます。 これは信頼の負担を重要な方法でシフトさせます。 プロジェクトは、レコードエクスポート経路、マニフェストシールバックアップ検証、およびリリースプロセスがすべて結びついていると仮定して読者に要求するのではなく、それらがつながっている正確な一実施例を示し、そのサンプルが現実と一致しなくなるとリポジトリが気づく方法を提供します。 ドリフト検出がない信頼ケースは急速に衰退します。 試料がチェックインされると、将来の変化が信頼に決定的な出力を無音で変更しながら文書が古い動作を記述し続けるという明白なリスクがあります。それが信頼言語が劇場に崩壊する方法です。 ProofVault は、試料をチェックインされた不変量として扱うことでこれを回避します。 ローカルゲートと GitHub Actions ワークフローは試料を再生成し、ピンセットされた出力と比較します。信頼に決定的な表面が変更される場合、変更が明確にレビューされ、試料が意図的に更新されるまでビルドが失敗します。 これは、信頼主張を保守的規律に結びつけることが重要だからです。信頼ケースは単に一度発表されるのではなく、常に圧力の下で維持されます。 この作業の最も重要な部分の之一是、ローカルシステムがすでに正しいように見えた後になされたことです。 試料は Windows でグリーンでした。TZ=UTC の下でグリーンでした。WSL 下的 Linux クローンでグリーンでした。 しかし、GitHub のホストランナーはそれでも失敗しました。 それが決定的な瞬間でした。

ProofVault now carries part of its own proof burden in the repository. Most projects say they care about security, privacy, or integrity. Far fewer can point to a concrete specimen, regenerate it from the repository, detect drift automatically, show what tampering looks like, and identify the exact hosted-green release tree tied to a public tag. ProofVault now does. This post is about building a trust case that is not just described in prose, but enforced through code, generated artifacts, CI, and release discipline. The result is ProofVault Trust Case v1.0.1: a reproducible trust case for an offline-first encrypted evidence app, tied to an exact public release and stabilized across hosted CI. ProofVault is an offline-first encrypted evidence and incident capture application built for unstable, privacy-sensitive, and high-stress conditions. A system like that carries a higher burden than ordinary product software. It is not enough to say the app encrypts data. It is not enough to say the app exports records. It is not enough to say it has verification features. Those claims stay abstract unless they are tied to something concrete, inspectable, and repeatable. That was the gap this trust-case work set out to close. The goal was to create a public artifact that answers, in checkable form: what ProofVault guarantees what it does not guarantee what evidence supports those claims how a third party can reproduce trust-critical output how release integrity is preserved when the environment changes The result is a trust dossier under docs/trust-case/ and a pinned specimen under docs/trust-case/demo/. That package includes: a bounded trust case an explicit threat model a verification walkthrough grounded in a real specimen a frozen demo case with pinned observed outputs automated regeneration and drift detection a CI workflow that enforces the specimen on GitHub's hosted runner The key point is not that these pieces exist individually. The key point is that they are connected. The repository can now say: Here is the specimen. Here is how it is regenerated. Here is what counts as expected output. Here is how drift is detected. Here is what tampering looks like. Here is the exact release tree that passed hosted CI. Here is the public tag tied to that proof. That is a different class of credibility than a sentence in a README. The pinned specimen changed the conversation. Instead of talking about integrity in the abstract, the trust case now includes a real export, a real proof manifest, real verification reports, real fingerprint data, and a real tampered case showing mismatch behavior. That shifts the burden of trust in an important way. The project no longer asks a reader to assume that the export path, manifest sealing, backup verification, and release process all fit together. It shows one exact instance of those things fitting together, and it gives the repository a way to notice when that example stops matching reality. A trust case without drift detection decays quickly. Once a specimen is checked in, the obvious risk is that future changes silently alter trust-critical output while the documentation continues to describe old behavior. That is how trust language collapses into theater. ProofVault avoids that by treating the specimen as a checked invariant. The local gate and the GitHub Actions workflow regenerate the specimen and compare it against the pinned outputs. If the trust-critical surface changes, the build fails until the change is explicitly reviewed and the specimen is intentionally updated. That matters because it binds trust claims to maintenance discipline. The trust case is not merely published once. It is kept under pressure. One of the most important parts of this work happened after the local system already looked correct. The specimen was green on Windows. It was green under TZ=UTC. It was green in a Linux clone under WSL. But GitHub's hosted runner still failed. That was the decisive moment. At that point, the responsible move was not to weaken the check, normalize away the problem, or assume CI was flaky. The responsible move was to treat the hosted runner as part of the real release surface and keep digging until the mismatch had a concrete explanation. A trust case that only passes on the author's machine is not yet a release artifact. It is still a local belief. The hosted mismatch surfaced three environment-sensitive faults in the specimen generation path: timestamp rendering that depended on host-local presentation archive metadata that drifted across environments pinned specimen metadata that incorrectly stamped the live Node patch version Each of those faults was fixed at source. The check stayed strict. The easiest way to get a green build would have been to weaken the invariant, normalize away the mismatch, or quietly stop comparing the unstable parts. That would have made the trust case look cleaner while making it less meaningful. Instead, the mismatches were traced and fixed where they originated. Temporary CI diagnostics were added only long enough to expose the hosted-runner disagreement, then removed before the final release tag was cut. That sequence matters as much as the fixes themselves. It shows that the release process was not green by accident. It was made legible under the same hosted surface the public repository actually depends on. The release history is part of the trust case. proofvault-trust-case-v1.0 remains the first public trust-case cut. It was not moved or rewritten after publication. proofvault-trust-case-v1.0.1 exists because the project found and corrected real cross-environment specimen drift, proved the fixes on hosted CI, removed temporary diagnostics, and tagged the final non-debug tree. That preserves something important: provenance. Instead of silently rewriting the first tag, the project kept the original public cut intact and published a corrected release with a clear explanation of what changed. That is stronger than pretending the first release had been universally stable all along. This work does not prove that ProofVault solves every trust or security problem. It does prove that the project can: define a bounded trust model connect that model to code and generated artifacts make tampering visible through a verifier path detect cross-environment drift in trust-critical output fix release-surface mismatches without weakening the invariant publish a public tag tied to an exact hosted-green tree That is the core of the trust case. ProofVault is no longer asking for trust on the strength of intent alone. It is carrying part of its own proof burden in the repository. This pattern is reusable. Any system that makes claims about privacy, integrity, recoverability, or verification can benefit from the same discipline: define the bounded claim surface publish one reproducible specimen encode expected outputs treat drift as a first-class failure require the real release surface to pass, not just a local machine For ProofVault, that makes the trust case a credibility pillar. More broadly, it provides a reference specimen for what doctrine looks like when it is translated into architecture, tests, CI, and release hygiene. The corrected public trust-case release is: proofvault-trust-case-v1.0.1 The final hosted-green non-debug release commit is: dc5fbe9 The original public cut remains: proofvault-trust-case-v1.0 That is the final shape of the trust case. Not a statement of values, but a system that can show its work. If this kind of work interests you, the useful question is not just whether a product has security features. It is whether the product can make its trust claims legible, reproducible, and release-bound.