certiv.org

claim audit · exact evidence boundaries

What source enforces. What a release must re-prove.

Certiv treats claim scope as part of the product. Source controls, release qualification, and deployment evidence answer different questions; none can silently stand in for another.

A successful test run applies only to the exact candidate bytes and recorded toolchain. Any source, lock, image, configuration, or deployment change requires proportionate requalification.

enforced and bounded

Source-level evidence

Receipt and execution integrity

Evidence. Strict v2 schemas, canonical digests, exact input and tree hashes, two isolated workspace copies, bounded output, and fail-closed comparisons are covered by adversarial tests.

Limit. A pass records observed execution. It cannot establish truth, provenance, method validity, novelty, safety, or interpretation.

Path and state safety

Evidence. Supported manifest, receipt, registry, evidence, backup, and release paths refuse traversal, links, special files, ambiguous names, unsafe growth, and overwrite races.

Limit. These controls do not sandbox arbitrary author commands or prove the host operating system trustworthy.

Ledger and signatures

Evidence. CAS objects, canonical serialized appends, hash links, atomic deduplication, and bounded self-hashed checkpoints are verified. The API signs its current head response.

Limit. The persisted checkpoint is not signed or immutable. Rewrite detection requires an independently retained head or checkpoint.

Verifier isolation floor

Evidence. The worker refuses execution without a preloaded digest-pinned image and an approved runtime; no host-process fallback exists.

Limit. The operator must prove the actual runtime and host controls. This is risk reduction, not a complete hostile-code security proof.

Recovery

Evidence. Backup and restore bind CAS, ledger, checkpoint, external head, and node identity while rebuilding disposable projections.

Limit. Encryption, key custody, retention, RPO, and RTO remain deployment-specific operator duties.

Brand and package identity

Evidence. Certiv is the owner-authorized project brand. Release metadata enforces the distribution name certiv-receipts.

Limit. The software makes no representation about trademark application, allowance, registration, clearance, or enforceability. The bare certiv PyPI namespace is separate.

per candidate · no inherited green status

Mandatory release qualification

  1. All behavior, adversarial, concurrency, crash-recovery, schema, lint, and strict type checks pass from the exact candidate bytes.
  2. Every Python lock and the exact npm lock audit clean; source-secret, Gitleaks, Bandit, and ShellCheck evidence is retained.
  3. Two Python distribution builds and two static builds match byte for byte under their recorded same-host toolchains.
  4. The staged wheel installs without index resolution and completes init, pack, and check; wheel and source archives pass hostile-member validation.
  5. Every static route and internal link passes desktop/mobile browser, console, overflow, landmark, no-script, and Axe checks.
  6. The actual API and Caddy images run non-root with read-only roots, zero capabilities, bounded resources, readiness gating, and public writes disabled.
Repository work cannot prove a deployment by itself.

A public GA launch also needs project-controlled acquisition, publication, promotion, and operator evidence:

  1. A canonical reviewed source and release-download location.
  2. Protected artifact attestation and publication by an authorized release owner.
  3. Authorized production promotion followed by a successful live same-origin probe.
  4. A retained node identity and signed head response in a separate administrative domain.
  5. A current backup/restore rehearsal, privacy-retention verification, incident owner, and key-custody record.

Read the controlling support boundary, security policy, and threat model. Machine-readable release scope is published at release.json.