Verification & Audit Guide
This guide explains how PatentChecker outputs can be independently verified, offline, without access to source code, private repositories, or registries.
PatentChecker is designed so that trust is not required to validate results.
Choose your path
Use this guide when you already have artifacts or release receipts in hand and need to prove they validate without trusting Omnis, the operator, or the execution host.
- 1If you do not have artifacts yet, start with the public runtime and demo assets from Buyers start here.
- 2Verify the run directory first when counsel or procurement only needs artifact integrity and schema conformance.
- 3Verify the release receipt and runner image when security needs supply-chain provenance for the executable itself.
- 4Use demo tracks when the question is really about viral vectors, mRNA workflows, or replayable evidence bundles.
Start with the fast evaluation path if you still need a runtime bundle, packet, or public risk bundle to inspect.
Jump to the offline run verification section if you were handed a run folder and need a pass or fail answer.
Use the receipt and cosign bundle path when you need to validate the signed runner release offline.
Use the public demo catalog if you want concrete proof artifacts by verification track instead of a generic audit guide.
Use the demo hub when the question is modality-specific: viral vectors, LNP delivery, regular mRNA sequences, or offline proof bundles.
What can be verified
PatentChecker produces three independently verifiable layers. Each layer can be verified separately or together.
The concrete outputs of a monitoring run.
The executable used to produce the run.
A signed record binding the runner image, signatures, and metadata.
Trust chain overview
A single view of how watchlists, signed execution, artifacts, and verification connect to audit-ready outcomes.
Verifying a run directory (offline)
A run directory is a self-contained set of artifacts produced by a single monitoring execution. No network access is required.
- • run manifest
- • run digest
- • evidence packets
- • watchlist state
- • input metadata
- • optional receipts
patentchecker artifacts verify ./runs/<run_dir>
No network access is required.
- • All JSON files validate against their schemas
- • All artifact hashes match the values recorded in the manifest
- • Run completeness (no missing required artifacts)
- • Corpus snapshot consistency
- • Adapter contract compatibility
- • Digest integrity
- • Embedded license receipt verification (if present)
✔ schemas valid ✔ artifact hashes verified ✔ corpus snapshots consistent ✔ adapter contract verified ✔ run digest verified ✔ run directory complete
✖ hash mismatch: evidence/family_123.json expected: sha256:abc... actual: sha256:def...
- • Green output means the run folder is internally consistent: schemas, hashes, corpus snapshots, and the final digest all line up.
- • That is enough for offline diligence when the immediate question is whether the delivered artifact bundle was altered or incomplete.
- • A hash mismatch means at least one artifact changed after the manifest was written.
- • A missing-file or schema error usually means the run directory is incomplete, mixed across runs, or not the exact folder the receipt was created for.
Determinism guarantees
PatentChecker is deterministic by design:
- • Same inputs produce the same outputs
- • Execution order is stable and documented
- • Multi-sequence watchlists execute in sorted sequence order
- • Artifact paths and identifiers are predictable
This allows replay, comparison across time, and independent verification long after execution.
Verifying the runner image (public, keyless)
PatentChecker is distributed as a signed container image. Signatures are keyless, issued via GitHub Actions OIDC, and publicly discoverable.
# Receipt is the source of truth for digest + signing identity. # (Use the values from runner_receipt.v0.1.json for the release you are verifying.) export DIGEST="sha256:<64>" export IDENTITY="https://github.com/omniscoder/patentchecker/.github/workflows/release.yml@refs/<ref>" IMG=ghcr.io/omniscoder/patentchecker@"$DIGEST" DOCKER_CONFIG=/tmp/emptydocker cosign verify \ --certificate-identity "$IDENTITY" \ --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \ "$IMG"
Replace both digest and identity with the values from the release receipt you are verifying.
Offline verification with release bundles
For air-gapped or archival review, each release includes cosign.bundle.json and runner_receipt.v0.1.json. These allow verification without registry access.
- • image digest
- • signature bundle
- • runner version
- • schema version
- • adapter provenance (if present)
- • signing identity
- • You should be able to bind the release receipt to a specific image digest, signing identity, and offline signature bundle.
- • That gives security or procurement a proof path for the executable itself, separate from the run-directory checks.
- • If identity or issuer checks fail, confirm you copied the values from the exact runner_receipt.v0.1.json for that release.
- • If bundle verification fails, re-download the receipt and cosign bundle from the same release instead of mixing assets across tags.
Adapter provenance
Each run records adapter provenance explicitly, ensuring adapter behavior is pinned and incompatible changes are detectable.
- • adapter identity
- • adapter contract version
- • adapter version
- • adapter configuration hash
Corpus snapshot integrity
PatentChecker records corpus snapshots and enforces exact snapshot equality between inputs and outputs.
- • corpus snapshot identifiers
- • content hashes
- • coverage metadata
Verification prevents silent corpus drift and preserves defensibility.
What is intentionally not required
- • access to source code
- • access to adapter implementations
- • trust in the operator
- • access to the execution environment
- • live network connectivity
Only the artifacts themselves are needed.
Summary
PatentChecker outputs are:
- • deterministic
- • replayable
- • hash-addressed
- • provenance-tracked
- • offline verifiable
This enables inspection-ready patent monitoring suitable for legal, regulatory, and high-assurance environments.