Acronyms used below: identifier (ID); reduced instruction set computer (RISC).

VSTD is a verification-domain language and Python reference implementation for turning a bare computational result into an inspectable package: the exact claim, artifact, evidence, checking mechanism, limits, and conditions that could overturn it. It does not replace native domain verifiers, proof systems, signatures, identity systems, transparency logs, or provenance formats.

The shortest useful description is:

result + exact claim + evidence + mechanism + bounds + provenance + refutation route

VSTD evaluates bounded validity propositions about computational processes represented by software and evidence-bearing artifacts. It does not decide whether an actor is good, bad, reputable, or trustworthy, and translating or storing a result never strengthens it.

Current boundary: the repository contains usable reference paths for receipts, generic run capture, provenance Graphs, bounded certificate checking, artifact freezing and sealing, reproduction, and evidence-bound assessment. Some compatibility paths remain NOT_ESTABLISHED, and no real external witness, independent implementation, accreditation, or external adoption is claimed. See current maturity and claims and limits for the exact surface-by-surface boundary.

Normative specifications · 60-second quickstart · Implementation reference · Report an ambiguity or counterexample · Report a vulnerability privately

30–60 second demonstration

git clone https://github.com/TimeLordRaps/verifier.git
cd verifier
python -m pip install .
vstd demo

The side-effect-free demo runs four public adversarial specimens:

VSTD flagship adversarial demo
4/4 scenarios behaved as required.
[DEMO OK] Valid-looking proof, wrong artifact          → REJECTED
[DEMO OK] Bound exhausted without a false answer       → ACCEPTED/UNKNOWN
[DEMO OK] Inflated verification-cost claim             → REJECTED
[DEMO OK] Revoked ancestor behind valid descendants    → GRAPH-CANDIDATE-0

[DEMO OK] means the expected defensive outcome occurred; it is not a VSTD PASS. The scenarios establish bounded behavior of this reference implementation over the included specimens. They do not establish empirical truth, complete provenance, external adoption, independent implementation, or general artificial intelligence (AI) safety. Use vstd demo --json for JavaScript Object Notation (JSON) output or vstd demo --emit-specimens PATH to inspect the generated files.

The 90-second mental model

A normal tool may report PASS. VSTD asks what that word is allowed to mean:

claim ──checked against──> evidence
  │                           │
  └── bounded by ─────────────┤
                              v
                    named mechanism
                              │
                              v
                 PASS / FAIL / UNKNOWN
                    + limits + provenance
                    + refutation conditions

The native verifier still performs the domain work. VSTD records the exact boundary of that work so another person or program can inspect, replay, challenge, or reject it without silently receiving a stronger claim.

VSTD has two independent axes:

• Object profiles describe what is established about one computational claim.
• Graph profiles describe what is established about a bounded collection of artifacts and transformations.

Three rules prevent most misreadings:

1. Each profile answers a different question and needs its own evidence.
2. A later-profile result cannot repair missing evidence for an earlier profile.
3. UNKNOWN is a correct result when the mechanism, evidence, or bound is insufficient.

Choose the smallest useful starting point:

What a result means

VSTD result terms remain tied to one exact proposition, mechanism, evidence set, and bound:

A VSTD PASS never means “true in the real world” without the exact real-world proposition and observation boundary being part of the checked claim.

Current maturity

Use this summary before opening the exact matrix:

The authoritative implementation-to-specification map is docs/ARCHITECTURE.md. Normative meaning remains under standard/.

Why VSTD exists

Ordinary computational results often omit machine-readable answers to four questions:

1. What exactly was claimed? Subject, predicate, parameters, scope, and limits.
2. Which evidence supports it? Exact bytes, digests, mechanisms, provenance, and trust roots.
3. Where does the verdict stop? Explicit coordinates, exclusions, and resource bounds.
4. How can it change? Reproduction, counterexample, challenge, invalidation, and degradation rules.

VSTD packages that review boundary in receipts and provenance hypergraphs. The core design rule is:

No assurance is gained from storage location, field name, repetition, graph multiplicity, actor reputation, or propagation. Every increase must identify the verification mechanism that earned it.

Architecture

The five profile numbers are cumulative verification questions, not software versions, interchangeable layers, or assurance scores. The object axis evaluates one claim; the Graph axis evaluates a bounded collection and its recorded transformations.

A typical object traversal is:

VSTD-1 claim record
   → VSTD-2 bounded verification surface
   → VSTD-3 execution-substrate evidence
   → VSTD-4 portable refutation boundary
   → VSTD-5 evidence-bound witness corroboration

A later-profile result does not supply, imply, upgrade, or repair a prerequisite coordinate. Object profile depth N requires separate passing evidence for every required coordinate from 1 through N.

VSTD-Graph is orthogonal. It records artifacts, transformations, conflicts, lifecycle changes, and deduplicated reachability across a bounded collection. The compatibility graph_level calculation remains a NOT_ESTABLISHED candidate. Evidence-bound Graph establishment must rerun every required rating mechanism over evidence bound to the exact Graph, member set, collection, and claim. Profile zero never becomes established conformance.

Artifact support and diagnostic traversal

The formal names TRUST, ROT, and RUST are semantic terms, not acronyms, actor ratings, scalar scores, numbered-profile verdicts, or references to the Rust programming language:

• TRUST is mechanism-earned artifact support moving forward through one exactly checked transformation.
• ROT is typed, time-indexed degradation of current admissibility without rewriting historical evidence.
• RUST is the inverse-TRUST diagnostic mechanic moving backward from a descendant deviation toward recorded contributing ancestors.

RUST identifies where reassessment should look; it does not by itself establish falsehood, causal localization, responsibility, BLAME, or GUILT. A separately registered localization mechanism must earn BLAME, and GUILT additionally requires an exact violated obligation. Neither result evaluates actor character. The replayable VSTD-GRAPH-ASSURANCE-1 event log binds its historical Graph, evidence, mechanisms, event chain, and derived current view.

Zero identity and zero unevidenced knowledge

The zero-identity/zero-knowledge (ZIZK) artifact-first orientation is Governing VSTD architecture, not an optional research profile. Zero identity means zero identity-derived verdict weight, not anonymity. Architectural zero knowledge means zero unevidenced knowledge is presumed: unsupported propositions remain UNKNOWN.

When a witness must remain confidential, cryptographic zero knowledge can enclose that boundary only through a named proof system that binds the exact program, predicate, public commitments, output, parameters, and verifier without attaching TRUST to the prover's identity. A digest, encrypted file, or omitted input is not a zero-knowledge proof. The RISC Zero reference mechanism is one bounded optional backend under this governing architecture.

For exact ownership, dispatch paths, schemas, compatibility surfaces, and unimplemented horizons, use the architecture map and normative Ladder.

Install and use

The distribution name is verifier-standard. The published base package has no required third-party runtime dependencies.

python -m pip install "verifier-standard==1.3.0"  # exact published release
python -m pip install .                            # current source checkout
python -m pip install ".[yaml]"          # YAML Ain't Markup Language (YAML) manifests
python -m pip install ".[jsonschema]"    # JSON Schema validation
python -m pip install ".[seal]"          # optional Ed25519 artifact sealing
python -m pip install ".[scitt]"         # optional SCITT/COSE experiment

vstd is the canonical cross-platform CLI name. verifier remains a compatibility alias but can resolve to Windows Driver Verifier. verifiable is a permanent legacy alias because historical receipts may bind it in falsification instructions.

An unrelated PyPI distribution named verifier exports the same top-level Python import. Do not co-install it with verifier-standard.

Freeze, seal, verify, and thaw an artifact

Freezing preserves exact regular-file bytes and portable paths. Sealing is a separate, readable authentication and closure action; it is not encryption. Generate an Ed25519 key with a suitable local key tool, then run:

openssl genpkey -algorithm Ed25519 -out ed25519-private.pem
vstd artifact freeze PATH ARTIFACT.vstd --media-type application/octet-stream
vstd artifact verify ARTIFACT.vstd --freeze-only
vstd artifact seal ARTIFACT.vstd --private-key ed25519-private.pem
vstd artifact verify ARTIFACT.vstd --expected-artifact-id EXPECTED_ID
vstd artifact thaw ARTIFACT.vstd MUTABLE_COPY
vstd artifact status MUTABLE_COPY --parent-bundle ARTIFACT.vstd

The finite seal signs the complete envelope with its signature and identifier fields explicitly empty, then derives the seal identifier over the signature-bearing envelope with only its identifier empty. Verification recomputes both projections, avoiding an infinite seal-of-seal regress. The carried public key establishes internal consistency; an expected artifact identifier, expected key identifier, or separately verified manifest/log coordinate is still required to detect whole-bundle substitution.

A freeze or seal establishes bounded integrity and closure only—not correctness, freshness, ownership, authorization, trusted time, external preservation, or actor trust. Thaw is copy-on-write: it creates a mutable descendant and leaves the sealed parent unchanged. Later THAWED_CLEAN or THAWED_DIRTY status requires that actual parent bundle, clean seal verification, and exact agreement with every sidecar parent coordinate. Without the parent, sidecar agreement remains NOT_ESTABLISHED. The sidecar's unkeyed hash does not prove that the historical copy occurred. A supplied parent establishes only internal consistency unless an expected artifact/key identifier or separately verified external log also supplies continuity. See the normative artifact-control mechanism and the architectural realm/time-capsule model.

Capture a generic computation

A manifest contains an executable command. vstd run does not sandbox it. Inspect the plan first and execute only trusted manifests inside an appropriate operating-system or container boundary.

vstd plan examples/generic_run/manifest.json --json
vstd run examples/generic_run/manifest.json --output /tmp/vstd-receipt
vstd validate /tmp/vstd-receipt
vstd inspect /tmp/vstd-receipt
vstd reproduce /tmp/vstd-receipt --rerun

Generic validate checks the strict profile shape and stable-payload digest. It does not rehash external artifacts, resolve evidence references, rerun the command, or verify the recorded declaration as a native domain claim. reproduce --rerun separately executes the recorded command and compares declared output paths, digests, and execution outcome.

When a manifest's open refutation surface declares compatible platforms and explicit result surfaces, compare one receipt from each declared operating system:

vstd compare-platforms receipts/Linux receipts/Windows receipts/Darwin --json

Python reports macOS as Darwin. Newly captured platform-comparable receipts bind their Python implementation and machine identity into the canonical digest. Historical receipts without that additive binding remain valid records but cannot establish comparison. The comparator returns PASS only when every declared platform appears exactly once, canonical receipt integrity passes, non-platform claim, source, command, Python, machine-family, and mechanism bindings agree, and every declared result projection agrees. Comparable result disagreement is CONFLICTED; missing or non-comparable evidence is NOT_ESTABLISHED; malformed or internally contradictory evidence is INVALID. This is a comparison of supplied recorded results—not proof of universal portability, semantic correctness, native execution, or independent actors. Matching outputs alone do not establish environment equivalence or truth outside that scope.

Use the Python application programming interface (API)

from pathlib import Path

from verifier.core.run import describe_run_plan, load_manifest

manifest_path = Path("examples/generic_run/manifest.json")
manifest = load_manifest(manifest_path)
plan = describe_run_plan(manifest, manifest_path.parent)
print(plan["command"], plan["executes_without_sandbox"])

The installed wheel contains byte-identical copies of every normative specification, so a verifier descriptor can retain its exact specification binding outside a source checkout. See the generated CLI and API reference.

Receipts, Graphs, and grounded certificates

• VSTD-1 receipts carry claim coordinates, evidence, checker results, trust boundaries, and reproducibility information.
• VSTD-Graph-1 records content-addressed artifacts, many-to-many transformations, conflicts, and bounded downstream reachability. Its frozen reader preserves separate historical artifact/transformation namespaces; new construction plus evidence-bound establishment and assurance propagation require global cross-kind disjointness.
• VSTD4-GDC-1 binds a decision certificate to a formula, grounding, claim coordinate, verifier descriptor, roots, and resource bounds.

The grounded-certificate checker rejects over-budget headers before proof work, rejects cost-tier inflation, validates grounding before the decision block, and preserves UNKNOWN when a bound is exhausted. Kernel acceptance establishes only the bounded certificate result; it is not VSTD-4 conformance, evidence authenticity, external validation, or proof of the unobserved world.

Interoperability

VSTD composes beside native systems rather than replacing them:

native object ──native verifier──> native result
      └──── exact bytes + identity ──> loss-declared adapter
                                           └──> VSTD claim boundary

The interoperability path connects strict loading and stable modeled-hole detection to an experimental domain-neutral component catalog and planner:

strict VSTD-2 JSON geometry
  -> typed valid geometry
  -> modeled-hole analysis
  -> exact catalog candidates
  -> nonexecuting validation plan
  -> nonexecuting execution-readiness preflight

Analyze the checked-in non-critical formatter geometry without executing a checker:

vstd surface analyze examples/verification_geometry_residual/geometry.json --json
vstd surface analyze examples/verification_geometry_residual/geometry.json --plan --json

The report is deterministic and bounded to the supplied geometry. A reported modeled closure state does not establish that the model includes every real-world obligation.

Run its harmless sorted-grocery-list example:

python examples/interoperability_planning/demo.py

The example reports two exact candidates and three unmatched self-closure holes while keeping plan_only = true, execution_performed = false, and the checker invocation count at zero. Here, validation names the future process of attempting to discharge verification-surface holes with bound execution evidence and then reassessing the geometry. This example only detects and plans: it cannot establish checker availability at execution time, a native result, ordinary or self-closure, safety, authority to act, critical-domain readiness, or VSTD conformance. Its registry version and digest are bound into the plan. --plan uses the first-party catalog's 19 exact entry points across 12 catalog grouping labels, but does not select or invoke them. Those labels organize first-party code; they are not 12 independent or native implementations and do not represent 12 demonstrated interoperability results. The experimental readiness preflight can reject missing or substituted native-input, evidence-output, prerequisite, authorization, and reassessment declarations, but it executes nothing and grants no authorization. Automatic execution and post-execution geometry reassessment remain unsupported. See the example boundary and output.

The experimental multi-geometry diagnostic compares only caller-declared shared propositions bound to exact geometry digests. It preserves explicit VERIFIED versus FALSIFIED disagreement and declared dependency cycles as reproducible structural conflict witnesses; absent identity or an indeterminate judgment remains NOT_ESTABLISHED, and malformed input is INVALID. It does not perform Boolean satisfiability analysis, infer that similarly named claims are equivalent, or establish physical truth, safety, conformance, or authority.

The separate experimental graph-topology checker binds explicit simultaneous Boolean equations and clock-relative backward-time relations to existing graph ports. It reports structural features and bounded consistency separately, retains paradox candidates without inferring their truth, and does not bypass cyclic-assurance admission. The non-critical specimen exports matching inspection documents.

The experimental composed-untraversability interface evaluates whether a declared protected fact is reachable by one finite observer through the complete set of interfaces and inference rules supplied in an exact VSTD Graph contract. A higher-order interface can expose enough structure to control a computation while still forbidding a declared path to lower-order protected knowledge, but that boundary is assessed over the composed Graph rather than inferred from any interface in isolation. A bounded result does not establish open-world non-inferability, continuous awareness tracking, runtime enforcement, authorization, actor attribution, or universal confidentiality.

Operating-system evidence is tracked per component in the platform interoperability matrix; support for one portable Python path does not transfer to a native prover, verifier, solver, or adapter. The linked machine-readable contract records configured test intent, not a hosted pass; exact-run artifacts must bind its digest and the current catalog digest before a platform claim can be evaluated.

Two executable non-critical relationship geometries are documented under interoperability compositions: a bounded proof-producing Boolean solver whose exact refutation bytes feed a separate proof checker, and the existing adjacent VSTD plus Supply Chain Integrity, Transparency, and Trust (SCITT) composition. Both retain native results and negative paths; neither establishes actor independence, external interoperability, or safety.

The experimental SCITT profile uses real Concise Binary Object Representation (CBOR) and COSE signatures and a local inclusion receipt. It demonstrates exact payload carriage and adjacent verification under test keys. The example rejects drift from its three pinned runtime distributions and records the installed scitt-cose version and exact statement/receipt verification entry points, while explicitly leaving package authentication, producer provenance, and independent implementation unestablished. SCITT registration proves neither payload correctness nor VSTD conformance. See the crosswalk, semantic boundary, and runnable example.

The ecosystem map separately covers adjacent provenance, software-supply-chain, signing, and transparency systems without implying endorsement or adoption.

Specifications and navigation

Read authoritative material in this order:

1. Verification complex, terminology, and profile composition
2. Object and Graph numbered-profile documents
3. Serialized receipt identifiers
4. Published schemas
5. Implementation ownership
6. Claims and limits

Additional entry points:

Reproducibility and releases

A release contains a canonical artifact set: ZIP archive format (ZIP), wheel, source distribution, and external manifest bound to the exact public Git commit and file members. At the version 1.3.0 source coordinate, the continuous integration (CI) workflow builds the artifact set on Linux, Windows, and macOS and rejects cross-platform byte differences. It also captures and reruns the portable generic example on three GitHub-hosted operating-system virtual machines, then requires a bounded PASS over the three receipts. GitHub artifact attestations bind uploaded bytes to the workflow; they do not establish source correctness, tag identity, or adoption.

gh attestation verify PATH_TO_DOWNLOADED_ASSET --repo TimeLordRaps/verifier

Use RELEASING.md to verify the manifest, tag, artifact attestations, package name, and historical compatibility. Version 1.3.0 is the current release, published on 2026-09-08; use its versioned release page for published citation and artifact coordinates.

Claims, security, and contribution

Review claims and limits before publishing a VSTD result. The reference implementation may improve auditability, reproducibility, incident analysis, and challenge routing over observable records. It cannot prove general AI safety, reveal hidden model state, establish physical-world completeness, or compensate for missing instrumentation.

vstd run executes manifest commands without sandboxing. See the security policy and use GitHub private vulnerability reporting for sensitive findings.

Contributors should start with CONTRIBUTING.md, which identifies normative, implementation, schema, adapter, test, compatibility, and release pathways. Use the issue forms for a specification ambiguity, counterexample, or implementation/interoperability report.

Project authority and centralization are documented in GOVERNANCE.md. Automated-contributor rules live in AGENTS.md; the human operating model in HUMANS.md; and live repository contradictions only in TIME.md.

Citation and license

Cite a published release from its versioned GitHub release metadata or CITATION.cff at that tagged coordinate. Do not cite unreleased candidate metadata as a published release.

Licensed under the Apache License 2.0; see NOTICE. VSTD is not affiliated with or endorsed by the Apache Software Foundation.