Rendered from README.md at build time without changing its status. The repository source controls if this presentation differs.

Verifier Standard (VSTD)#

Portable, bounded, refutable evidence for computational claims.

Acronyms used below: accessible pointed graph (APG); Anti-Foundation Axiom (AFA); application programming interface (API); artificial intelligence (AI); Boolean satisfiability problem (SAT); central processing unit (CPU); command-line interface (CLI); Concise Binary Object Representation (CBOR); continuous integration (CI); conjunctive normal form (CNF); CBOR Object Signing and Encryption (COSE); deletion resolution asymmetric tautology (DRAT); directed acyclic graph (DAG); grounded decision certificate (GDC); identifier (ID); intermediate representation (IR); Internet Engineering Task Force (IETF); JavaScript Object Notation (JSON); linear resolution asymmetric tautology (LRAT); machine learning (ML); nondeterministic polynomial time (NP); operating system (OS); Python Package Index (PyPI); reduced instruction set computer (RISC); satisfiability modulo theories (SMT); Secure Hash Algorithm 256-bit (SHA-256); Supply Chain Integrity, Transparency, and Trust (SCITT); unsatisfiable (UNSAT); Verifier Standard (VSTD); YAML Ain't Markup Language (YAML); ZIP archive format (ZIP); zero-identity/zero-knowledge (ZIZK).

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#

Option 1: Instant Python inspection (from PyPI)#

python -m pip install "verifier-standard==1.5.0"

import verifier

print(verifier.__version__)        # '1.5.0'
print(verifier.__standard__)       # 'VSTD-5'
print(verifier.__standard_status__)# 'PROJECT SPECIFICATION; EVIDENCE-BOUND REFERENCE MECHANISM'

Option 2: The defensive CLI 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

What are these four scenarios showing in practice?

1. Wrong artifact (REJECTED): An attacker or buggy script presents a valid mathematical proof, but binds it to the wrong data file. VSTD catches the cryptographic digest mismatch immediately.
2. Exhausted bounds (UNKNOWN): A complex calculation exceeds its allotted compute time or memory limits without finishing. Instead of guessing or falsely claiming success, VSTD cleanly preserves UNKNOWN.
3. Inflated cost (REJECTED): An actor claims a verification step required \$1,000,000 of compute when it actually took minimal work. The proof-carrying receipt refuses the ungrounded cost claim.
4. Revoked ancestor (GRAPH-CANDIDATE-0): A data pipeline produces seemingly valid outputs, but an upstream input or library version was later revoked. VSTD detects the corrupted lineage and alerts you.

[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.

The core intuition: itemized receipt vs. green checkmark#

When you buy groceries, you do not just want the cashier saying "Payment approved" with no paper. You want an itemized receipt showing:

• Which items were scanned?
• What was the price of each item?
• What timestamp, register, and store processed it?
• If there is an error, exactly which line item can be disputed?

In software and artificial intelligence (AI), systems usually just give you a green checkmark or an exit code 0. But a green checkmark does not tell you:

• What exact file or dataset was checked?
• What tool did the checking, and under what memory or time limits?
• Did a test timeout and pass by accident?
• Can anyone else rerun it on another machine and get the exact same bytes?

VSTD is the cryptographic "itemized receipt" for computational claims. It pairs:

1. The exact claim (the precise proposition being made, without inflating its scope).
2. The cryptographic coordinates (Secure Hash Algorithm 256-bit (SHA-256) digests of exact inputs and outputs).
3. The named mechanism (the exact tool, solver, or rule used to check the claim).
4. The refutation conditions (the exact recipe an adversary or third party can use to prove the claim wrong).
5. The honest verdict (PASS, FAIL, or UNKNOWN if compute ran out or evidence was missing).

Seven domain lenses: how VSTD fits your field#

<details> <summary><strong>1. For undergraduates, high schoolers, and self-taught coders</strong></summary>

Think of VSTD as a tamper-proof digital lab notebook. When you write a chemistry or physics lab report, you do not simply assert "the reaction succeeded." You record the initial mass, temperature, chemical purity, and measurement uncertainty. If your scale was uncalibrated or the thermometer went out of range, honest science requires recording "inconclusive" (UNKNOWN), not "success." Anyone grading your work can re-execute your code with vstd reproduce and mathematically prove the output files match the recorded fingerprints.

Tutorial & example: Your first receipt and runnable specimen examples/generic_run/. </details>

<details> <summary><strong>2. For Boolean satisfiability (SAT) and satisfiability modulo theories (SMT) solver experts</strong></summary>

Modern SAT and SMT solvers output SAT or unsatisfiable (UNSAT). But in high-assurance formal verification, you never blindly trust the solver alone—you require an independently checkable proof witness, such as a deletion resolution asymmetric tautology (DRAT) or linear resolution asymmetric tautology (LRAT) certificate. VSTD standardizes how those proof certificates, conjunctive normal form (CNF) formula digests, variable bounds, and independent checker runs are packaged into an immutable JavaScript Object Notation (JSON) receipt that any external verifier can validate or dispute without repeating the nondeterministic polynomial time (NP) search.

Tutorial & example: Clausal proof precedents and executable certificate test tests/test_gdc_certificate.py. </details>

<details> <summary><strong>3. For compiler and systems engineers</strong></summary>

When building optimizing compilers, linkers, or reproducible build systems, a transformation pass claims that an intermediate representation (IR) rewrite preserves program semantics. VSTD turns that claim into a verifiable contract: it binds the input IR digest, output IR digest, translation-validation tool, target central processing unit (CPU) architecture, and operating system (OS) environment constraints. If an optimization cannot be proven semantics-preserving within resource limits, it fails closed or preserves UNKNOWN, preventing silent miscompilations from being promoted.

Tutorial & example: Seal an artifact and detect a change and Publish a silo package. </details>

<details> <summary><strong>4. For AI safety researchers and transfinite mathematicians</strong></summary>

When analyzing self-referential systems, ordinal bounds, non-well-founded belief graphs, or transfinite induction, claims operate at high levels of abstraction where subtle circular reasoning or silent domain upgrades can invalidate safety bounds. VSTD enforces strict stratified profiles (Profiles 1–5): a higher-profile result never supplies or repairs missing lower-profile evidence, self-attestation is never promoted to independent verification, and ungrounded induction steps fail closed.

Tutorial & example: Normative ladder and runnable adversarial suite examples/flagship_demo/. </details>

<details> <summary><strong>5. For intellidynamics and AI benchmarkers</strong></summary>

Automated agent evaluations and language model leaderboards are vulnerable to prompt leaking, test-set contamination, hallucinated citations, and stochastic scoring variance. VSTD transforms benchmark scores from unverifiable claims ("Model X scored 92%") into refutable evidence graphs: exact prompt digests, determinism bounds, random seed coordinates, frozen tool execution traces, and adversarial replay recipes that allow any third party to independently reproduce or falsify the evaluation claim.

Tutorial & example: Publishing a checkable benchmark number and examples/generic_run/. </details>

<details> <summary><strong>6. For deep mathematics and theorem provers (Lean 4, Metamath, and formal kernels)</strong></summary>

In formal mathematical ecosystems—such as hypermath (algebraic kernel, Lean 4 bridge), ordinatics (ordinal arithmetic, Veblen hierarchies), grounded-hyperset-theory (Aczel's Anti-Foundation Axiom (AFA), accessible pointed graphs (APGs)), and grounded-hypercalculi (stratified semantic reflection)—mathematical claims span multiple formal representations. VSTD provides the meta-verification envelope: it explicitly enumerates axioms (refusing ungrounded axioms or sorry escapes), binds the exact prover kernel binary digest, and composes heterogeneous formal proofs into a single refutation graph.

Tutorial & example: Grounded decision certificates and Normative VSTD-4 specification. </details>

<details> <summary><strong>7. For nanochemistry, molecular robotics, and mechanosynthesis (containment and anti-replication gates)</strong></summary>

In molecular dynamics, chemical reaction networks, and autonomous nanoscale robotics, molecular self-assembly poses an acute existential containment challenge: preventing runaway autocatalytic self-replication. A molecular simulation or automated design agent may claim a nanomechanical system terminates cleanly, but without bounded verification, unmodeled parasitic pathways or catalytic loops can trigger unbounded assembly. VSTD acts as a computational containment seal and automated synthesis gate: it cryptographically binds atomic coordinates, force-field potential parameters, stoichiometric mass-action matrices, and temperature/solvent bounds into an immutable receipt. A claim of "bounded non-self-replicating assembly" is paired with a refutation condition (exhibiting any viable catalytic reaction trajectory that exceeds critical branching thresholds). Robotic synthesis hardware can then enforce receipt verification before initiating chemical printing.

Tutorial & example: Artifact control and sealed containment and Publishing checkable computational receipts. </details>

The two independent axes#

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:

<details> <summary><strong>Exact surface-by-surface matrix for reviewers and integrators</strong></summary>

“Implemented” applies only to the named reference surface. It does not imply adoption, external interoperability, certification, or a second implementation.

</details>

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.5.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.5.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.5.0 is the current release, published on 2026-09-18; 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.