Download the artifact
Start with the proof pack, manifest, checksum ledger, public keyset, and offline verifier.
G‑14 Trust
Trust what you can verify.
G‑14 publishes a downloadable proof pack with signed packets, checksums, an offline verifier, and cases that are required to fail. The same page also states what that artifact does not establish.
Independent verification path Public artifact
Validate integrity
Check the published SHA-256 ledger before relying on any packet or verifier result.
Run both paths
Confirm that five signed packets pass and six deliberately broken packets are rejected.
Inspect the boundary
Separate what the artifact demonstrates from certification and deployment-specific assurance.
Published evidenceConcrete facts from the current AMR v0 diligence artifact.
Download the pack Generated April 25, 2026 with a manifest, checksum ledger, public keyset, and offline verifier.
The pack includes allow, hold-release, hold-block, timeout-safe-state, and replay-seed cases.
Every deliberately broken signature, inclusion, cross-view, or signer-topology case must be rejected.
The published verification run records zero failed checks and a valid packet signature.
Pack SHA-256: b00b2ce5298e2795b7453fbaa8558ab6b7a472423375cdabd5d3478ab7495a55
What earns trust
Four tests a reviewer can run.
The useful question is not whether a claim sounds reassuring. It is whether the artifact can be taken away, tested, rejected when broken, and read within a clear scope.
The proof pack can be downloaded and checked without an account or a G‑14 dashboard.
Portable reviewUnsigned, tampered, incomplete, and invalid-signer packets must fail for the verification run to pass.
Named rejection casesThe packet binds the proposal, policy context, evidence, decision, outcome, timing, and signer references.
Traceable recordThe public artifact is a technical diligence package, not a certification or a customer deployment attestation.
Explicit scopeClaim boundaryWhat the public proof establishes—and what still requires review.
Signed positive packets and named negative-corpus failures are checked through the packaged offline verifier.
The public pack is not an audit opinion, regulatory approval, customer deployment attestation, or claim of external assessment.
Identity, policy, effect channels, key custody, retention, and operational controls must be assessed in the target environment.
Customers remain responsible for their policies, authorized users, connected systems, data handling, and release decisions.
Choose the review path
Move from public proof to the question you need answered.
Start with the artifact. Continue into the technical record or a scoped diligence conversation only when the public evidence no longer answers the question.
Verify
Download the artifact, run its offline checks, and inspect every required rejection.
Open the verification guide →Technical recordRead the threat model, authority boundary, containment behavior, and evidence model.
Open security documentation →Scoped diligenceBring one consequential workflow and define the evidence, authority, and deployment questions that matter.
Review diligence options →Evaluation path
Begin with the artifact, not the assertion.
Run the public verifier first. If your deployment needs a higher burden of proof, bring the exact action path, control boundary, and evidence requirement into a qualified review.