Maintained repository documentationView source on GitHub

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

Stored interoperability components#

Verifier Standard (VSTD) version 1.3.0 introduces an experimental stored component format, VSTD-COMPONENT-PACKAGE-1. It is a local, self-contained JavaScript Object Notation (JSON) document, not a receipt, installation archive, or conformance result. It retains component descriptions and exact artifact bytes so a catalog can be shared, inspected and used for verification-surface-hole planning without executing its contents. The stored-document schema describes its structural contract; runtime checks additionally enforce byte digests, canonical catalog form and reference bindings.

What travels together#

A package contains an identifier and version; unsigned publisher, license and description declarations; an exact catalog schema 1.1 registry; retained artifacts encoded as base64; implementation bindings from every component to retained artifact paths; and explicitly declared dependencies. Each artifact has a portable relative path, media type, bytes and Secure Hash Algorithm 256-bit (SHA-256) digest. Paths are logical names, not extraction destinations. Implementation references are opaque descriptive coordinates; the first-party seed uses module/symbol strings, but the container is not Python-specific.

The registry distinguishes solver, prover, checker, verifier, adapter, translator and other roles. It retains native result vocabulary and claim boundaries. Planning schemas and native accepted schemas remain separate. Sharing a schema, family label or domain tag never supplies a missing mechanism match.

The strict loader rejects malformed structures, unsupported schema identifiers, duplicate identifiers, broken bindings, invalid paths and content-digest mismatches. It does not extract files, follow artifact paths, import implementations, resolve dependencies, fetch external content or execute components. Default bounds are 256 artifacts, 16 mebibytes of decoded artifact content and 32 mebibytes for the encoded document; one mebibyte is 1,048,576 bytes. Oversized input is rejected, not treated as an incomplete successful package. Every stored registry array is bounded to 256 entries and text to 4096 characters, with control characters and unpaired Unicode surrogates rejected. Catalog scalar fields that permit empty text retain that meaning.

The local loader accepts ordinary non-link files only, checks the opened file identity, and uses nonblocking/no-follow opening where the operating system provides it. Pipes, devices, links and Windows reparse files are rejected. These checks do not promise a wall-clock bound on filesystem access or protection against privileged concurrent filesystem mutation; they are not an execution sandbox.

Certifier is a capability, not a kind alias#

A certifier issues a native certificate artifact binding an exact subject or claim to a declared assertion and certification basis under a named native contract. That contract must explain its checks, assumptions, failure states, and any issuer-authorization requirements. A prover constructs a derivation; it may also certify, but a certifier need not prove. A checker/verifier may check a certificate without issuing one. Mathematical certificates need not be signed; issuance, signature validity, authorized issuance, and the checked assertion are distinct propositions.

The current closed kind vocabulary has no CERTIFIER member or filter. Use the existing kind that accurately describes the algorithm role; do not silently map certifier to PROVER. Catalog 1.1 and VSTD-COMPONENT-PACKAGE-1 already retain the capability:

Existing descriptor fieldsExplicit serialization meaning
label, native_objectsPreserve the word "certifier" and name the native certificate artifact.
native_inputs, accepted_schema_idsDescribe exact subject/assertion/basis inputs; list serialized schemas only when accepted natively.
native_outputs, emitted_schema_ids, native_result_vocabularyDeclare the emitted certificate contract and native outcomes, not a verified result.
supported_relations, mechanism_idsName certificate issuance, for example relation:certificate-issuance, and the exact native mechanism. These lists declare a Cartesian product; split narrower pairings into separate descriptors.
planning_surface_schema_ids, interaction_modesDeclare where the capability can be planned; the planning document is not thereby a native input.
execution_prerequisites, trust_roots, claim_boundaryRetain qualification, authorization, evidence, and uncertainty requirements.

Matching uses the supplied exact relation/mechanism coordinates, planning schema, and interaction mode, not kind, labels, domain tags, or certificate-output names. Metadata does not execute issuance, authenticate an issuer, confer authority, validate a certificate, or establish its assertion. This mapping adds no native certifier or starter-catalog entry and changes no enum, catalog/package identifier, or receipt format.

Canonical content identity#

Canonical package bytes use Unicode Transformation Format, 8-bit (UTF-8). Characters outside the American Standard Code for Information Interchange (ASCII) character set are escaped. Object keys are sorted; separators are compact commas and colons without extra whitespace; no trailing newline is added. Artifact records sort by path, implementation records by component identifier, dependency records by dependency identifier, and reference arrays lexicographically. The embedded registry must already have catalog 1.1's canonical descriptor and array form; importing a stored package does not migrate or silently normalize an older or noncanonical catalog. No field accepts floating-point values, and non-finite numbers are rejected.

Artifact digests cover decoded artifact bytes. The registry digest covers its canonical JSON bytes. The package digest covers the whole canonical package, including content and declarations. Each digest is 64 lowercase hexadecimal characters. An optional expected package digest compares canonical content, not transport-file whitespace or object-key order; formatting the file differently does not change its content identity.

Create, retain, inspect and plan#

The experimental Python application programming interface (API) is available through verifier.interoperability.storage and the verifier.interoperability facade:

from verifier.interoperability import load_component_package, save_component_package

package = load_component_package("reference-components.json", expected_digest=trusted_digest)
report = package.inspect()
registry = package.registry
save_component_package(package, "retained-reference-components.json")

Here trusted_digest must come from a separately trusted source. Saving requires an absent destination; it does not overwrite an existing file. The constructor types are PackageArtifact, ImplementationBinding, PackageDependency and StoredComponentPackage. canonical_json_bytes() retains a deterministic representation; canonical_digest() identifies those package bytes. A load/save round trip preserves artifact bytes, even when they are not text.

The command-line interface (CLI) can inspect a stored package and supply its registry to the existing nonexecuting planner:

vstd components inspect reference-components.json --json --expected-sha256 EXPECTED_DIGEST
vstd surface analyze geometry.json --plan --package reference-components.json --expected-package-sha256 EXPECTED_DIGEST --json

EXPECTED_DIGEST is the expected 64-character hexadecimal package digest, not a literal value. Omitting the expected digest checks internal consistency but does not establish which externally intended package was supplied. The planner still requires exact matches for declared holes, retains blocked and unmatched candidates, and grants no authority to execute. See the working reference-snapshot example.

Package-selected plans bind the validated canonical package digest inside the plan, not merely in the enclosing catalog report. The experimental Python call is plan_validation(analysis, package.registry, package=package). Plans and readiness reports expose binding_scope (STORED_PACKAGE or REGISTRY_ONLY) and package_digest; registry-only planning does not imply implementation-byte binding.

Call assess_execution_readiness(..., package=package) with the exact package when checking a package-selected plan. Missing package bytes leave readiness NOT_ESTABLISHED; substitution is INVALID. A package-bound caller-supplied AUTHORIZED declaration must name plan_digest, the SHA-256 hexadecimal digest of plan.canonical_json_bytes(). Changing retained implementation bytes changes the plan and invalidates reuse of that declaration. These are declaration-consistency checks, not authentication of the caller or a grant of execution permission.

Attached package dependencies become candidate prerequisites named PACKAGE_DEPENDENCY:<package-digest>:<dependency-id>. The digest binds the exact declared requirement; each attached dependency needs a matching supplied prerequisite resolution. Retaining dependency bytes does not discharge that requirement. These obligations are separate from descriptor DEPENDENCY:<id> declarations; unattached inventory dependencies do not burden the candidate. Readiness checks these declarations, not native availability. Changed requirements change package/plan identity and invalidate prior exact-plan authorization declarations. These checks neither install nor resolve dependencies.

Boundaries that survive storage#

See artifact awareness and confidentiality of awareness. Retaining bytes or hiding them from an inspection summary establishes neither what another artifact knows nor what it can infer. Package and dependency metadata may itself disclose confidential awareness relations; this format provides no disclosure control. A package may retain the experimental composed-untraversability analyzer and its catalog metadata for exact planning. Package integrity, catalog membership and readiness still do not establish that the analyzer ran or that its bounded result was MATCH.

The stored format is experimental under the API stability policy. Readers dispatch on its exact identifier and the exact embedded catalog version. An incompatible future layout requires a distinct format identifier and explicit migration; readers must not reinterpret unknown formats as this one. This does not change any frozen receipt identifier or grant a new numbered-profile result.