Methodology

Inputs

Every run takes a versioned JSON envelope (schema_version 1.0) that carries the listing claims and the capabilities derived from captured metadata. Claims and capabilities are key/value pairs. Capabilities can come directly in the envelope or from an adapter that reads a captured manifest. Print the exact contract with node src/cli.mjs --schema.

How a result is decided

For each claim the engine looks up the capability with the same key:

• No matching capability, or its value is null → unknown (missing_or_unknown_metadata).
• Claim value and capability value are canonically equal → pass (metadata_match).
• They are not equal → fail (metadata_disagreement).

Canonical equality compares JSON structurally: object keys are sorted and arrays compared in order, so formatting differences never change a result. The run aggregates to fail if any check fails, to pass only if every check passes, and otherwise to unknown.

The explicit-absence rule

An absent capability stays unknown by default. It only becomes an explicit false — so a claim for it can fail — when the caller sets manifest_complete=true on a captured snapshot. Completeness is a caller assertion and is never independently verified, which is why unmeasured is never silently treated as failure.

What it is not

The scope is structured claim-to-captured-metadata equality, not semantic fact checking. No live source is fetched, and no third-party listing is ever edited. Reports contain hashed evidence references and reasons only. See the glossary for each term, or return to the overview.