Claims vocabulary

This page lists every claim in OpenVet’s canonical vocabulary. Auditors use these names to make machine-readable assertions about a package’s properties; consumers compose them into policies via requirement syntax. For the design rationale behind atomic claims rather than judgement-call criteria, see Comparisons.

Two tiers #

The vocabulary splits into two tiers.

Discovery claims (is-*, has-*, uses-*, impl-*) record what’s in the package: observable structural facts the auditor can determine by inspecting the source tree. Every audit must assert every discovery claim (true or false); an audit that omits one is incomplete.

Audit claims (everything else) record what the auditor evaluated and concluded about a particular aspect of the package. Each audit claim is conditional on a discovery claim being true: crypto-impl-safe only applies when impl-crypto = true, network-safe only applies when uses-network = true, and so on. The auditor should assert each applicable audit claim, but may legitimately decline to evaluate one.

Claims are boolean. Absence means unknown: the auditor is not asserting either way. See How it works for how absence propagates through policy evaluation.

Discovery claims #

Global #

Claim	Meaning when true
is-benign	The package contains no malicious code or deliberately harmful behaviour.

Existence: has-* #

What’s in the package alongside the source code.

Claim	Meaning when true
has-binaries	The package ships pre-compiled binary assets (executables, libraries).
has-build-exec	The package has build-time code execution (a build script, post-install hook, etc.).
has-install-exec	The package has installation-time code execution.
has-unit-tests	The package has unit tests.
has-integration-tests	The package has integration tests.
has-fuzz-tests	The package has fuzz tests.
has-property-tests	The package has property tests.

Usage: uses-* #

Runtime behaviour implied by the package’s use of external functionality. Distinct from impl-*: a package may uses-crypto (by linking against a crypto library) without impl-crypto.

Claim	Meaning when true
uses-crypto	The package uses cryptographic operations (hashes, signing, encryption).
uses-exec	The package executes code via exec() or subprocess.
uses-jit	The package uses a just-in-time compiler.
uses-interpreter	The package uses an embedded interpreter.
uses-unsafe	The package uses memory-unsafe code (raw pointers, FFI, unsafe blocks in Rust).
uses-network	The package performs network operations.
uses-filesystem	The package uses the filesystem.
uses-environment	The package reads or writes environment variables.
uses-concurrency	The package uses concurrency (threads, async runtimes).

Implementation: impl-* #

What the package itself implements, as opposed to consumes.

Claim	Meaning when true
impl-crypto	The package implements cryptographic primitives.
impl-parser	The package implements a parser for an external data format or language.
impl-interpreter	The package implements an interpreter.
impl-jit	The package implements a just-in-time compiler.
impl-protocol	The package implements a protocol (e.g. HTTP, DNS).
impl-datastructure	The package implements a data structure.
impl-algorithm	The package implements a non-cryptographic algorithm.
impl-concurrency	The package implements concurrency primitives or abstractions.

Audit claims #

Each group below applies when the indicated discovery claim is true. The naming convention is <surface>-<property> for usage-tier claims (e.g. crypto-safe for uses-crypto) and <surface>-impl-<property> for implementation-tier claims (e.g. crypto-impl-safe for impl-crypto).

When has-binaries is true #

Claim	Meaning when true
binaries-safe	Binaries shipped with the package are safe.
binaries-reproducible	Binaries shipped with the package have been reproduced from source.
binaries-provenance	Binaries shipped with the package have verified provenance.

When has-build-exec is true #

Claim	Meaning when true
build-exec-safe	Build script does not perform malicious or unexpected actions.
build-exec-deterministic	Build script’s output is a pure function of its inputs.
build-exec-no-network	Build script makes no network requests.
build-exec-no-write-out	Build script writes only inside the registry-conventional output area.
build-exec-minimal	Build script does only what’s strictly necessary for the build.

When has-install-exec is true #

Claim	Meaning when true
install-exec-safe	Install script does not perform malicious or unexpected actions.
install-exec-deterministic	Install script’s output is a pure function of its inputs.
install-exec-no-network	Install script makes no network requests.
install-exec-minimal	Install script does only what’s strictly necessary.

When uses-crypto is true #

Claim	Meaning when true
crypto-safe	Package’s use of cryptographic operations is safe.

When uses-exec is true #

Claim	Meaning when true
exec-safe	Process invocation uses argv form and sanitises any attacker-controlled inputs.

When uses-jit is true #

Claim	Meaning when true
jit-safe	Source or bytecode passed to the JIT is either not externally-controlled or properly sandboxed.

When uses-interpreter is true #

Claim	Meaning when true
interpreter-safe	Source or bytecode passed to the interpreter is either not externally-controlled or properly sandboxed.

When uses-unsafe is true #

Claim	Meaning when true
unsafe-safe	Every unsafe block’s invariants have been reviewed and hold.
unsafe-documented	Every unsafe block carries a safety comment explaining its invariants.
unsafe-minimal	Unsafe is used only where strictly necessary.
unsafe-tested	Unsafe blocks are tested with miri, sanitizers, property tests, or fuzzing.

When uses-network is true #

Claim	Meaning when true
network-safe	Network code validates inputs where appropriate.
network-secure	Package uses secure protocols by default (e.g. TLS).

When uses-filesystem is true #

Claim	Meaning when true
filesystem-safe	Filesystem code resists path traversal and writes only to expected locations.

When uses-environment is true #

Claim	Meaning when true
environment-safe	Package reads only documented, expected env vars; does not enumerate the environment.

When uses-concurrency is true #

Claim	Meaning when true
concurrency-safe	Package uses concurrency primitives correctly: synchronised shared state, no races or deadlocks.
concurrency-documented	Public API’s thread-safety contract is documented per type or function.

When impl-crypto is true #

Claim	Meaning when true
crypto-impl-safe	Cryptographic implementation is memory-safe, panic-free, and constant-time on secret-dependent paths.
crypto-impl-correct	Cryptographic implementation passes reference test vectors.
crypto-impl-tested	Cryptographic implementation is tested comprehensively, ideally with fuzzing or property tests.

When impl-parser is true #

Claim	Meaning when true
parser-impl-safe	Parser implementation is memory-safe, free of undefined behaviour, and panic-free on all inputs.
parser-impl-correct	Parser implementation produces correct output for its specified input format.
parser-impl-tested	Parser implementation has comprehensive tests, ideally including fuzzing or property tests.

When impl-interpreter is true #

Claim	Meaning when true
interpreter-impl-safe	Interpreter implementation is memory-safe, free of undefined behaviour, and panic-free on all inputs.
interpreter-impl-correct	Interpreter implementation matches the reference language spec’s behaviour.
interpreter-impl-tested	Interpreter implementation has comprehensive tests, ideally including fuzzing or property tests.

When impl-jit is true #

Claim	Meaning when true
jit-impl-safe	JIT implementation is memory-safe, free of undefined behaviour, and panic-free on all inputs.
jit-impl-correct	JIT implementation conforms to the source language’s documented semantics.
jit-impl-tested	JIT implementation has comprehensive tests, ideally including fuzzing or property tests.

When impl-protocol is true #

Claim	Meaning when true
protocol-impl-safe	Protocol implementation is memory-safe, free of undefined behaviour, and panic-free on all inputs.
protocol-impl-correct	Protocol implementation conforms to the spec and passes any reference test suite.
protocol-impl-tested	Protocol implementation has comprehensive tests, ideally including fuzzing or property tests.

When impl-datastructure is true #

Claim	Meaning when true
datastructure-impl-safe	Data structure implementation is memory-safe, free of undefined behaviour, and panic-free on all inputs.
datastructure-impl-correct	Data structure invariants are maintained, including under concurrent use where thread-safety is claimed.
datastructure-impl-tested	Data structure has comprehensive tests, ideally including fuzzing or property tests.
datastructure-impl-bounds	Operations meet documented time and space bounds under adversarial inputs.

When impl-algorithm is true #

Claim	Meaning when true
algorithm-impl-safe	Algorithm implementation is memory-safe, free of undefined behaviour, and panic-free on all inputs.
algorithm-impl-correct	Algorithm produces correct output for all documented inputs.
algorithm-impl-tested	Algorithm implementation has comprehensive tests, ideally including fuzzing or property tests.
algorithm-impl-bounds	Algorithm meets documented time and space bounds under adversarial inputs.

When impl-concurrency is true #

Claim	Meaning when true
concurrency-impl-safe	Concurrency implementation is memory-safe, free of undefined behaviour, and panic-free on all inputs.
concurrency-impl-correct	Concurrency primitives correctly enforce mutual exclusion, memory ordering, and the contracts the API claims.
concurrency-impl-documented	Concurrency primitives document their thread-safety contract, memory-ordering guarantees, and usage constraints.
concurrency-impl-tested	Concurrency implementation is exercised under adversarial scheduling (loom, ThreadSanitizer, or equivalent).

Custom claims #

Any claim name not listed above is a custom claim. Claim names follow kebab-case ASCII ([a-z][a-z0-9-]*).

Custom claims are useful when:

• An organisation has internal review criteria not covered by the canonical set.
• An auditor wants to express a niche observation that doesn’t warrant promotion to canonical.
• A vocabulary is in flight: an auditor can prototype a name before proposing it to the canonical set.

Custom claims appear unchanged in audits and propagate through imports unchanged. Consumers can rename a custom claim per-log at evaluation time using the policy [alias] mechanism; see requirement syntax.

Stability guarantees #

The canonical vocabulary will evolve over time, but changes to existing claims are restricted so that old audits do not silently change meaning.

Composing claims into requirements #

Atomic claims compose into consumer policies. A few illustrative examples:

[requirement]
no-memory-unsafe = "uses-unsafe implies unsafe-safe"
network-must-be-tested = """
    uses-network implies network-safe and (has-fuzz-tests or has-integration-tests)
"""
implemented-crypto-must-be-correct = """
    impl-crypto implies crypto-impl-tested and crypto-impl-correct
"""
build-must-not-network = "has-build-exec implies build-exec-no-network"

The full requirement language is documented in requirement syntax; the Configuring requirements guide walks through common policy patterns end-to-end.