Assurance Case Overview (v1.0)

Plain language: This overview lists every assurance claim, the evidence we ship with the repo, and the runtime contracts that enforce each claim in CI/release review.

Overview

TL;DR: InvarLock evaluates whether weight edits (quantization, pruning, etc.) regress a model beyond defined bounds. The assurance case covers: (1) paired primary metrics with bootstrap CIs, (2) the canonical five-stage guard chain (invariants pre, spectral, RMT, variance, invariants post), (3) deterministic evaluation with full provenance. Content safety, alignment, and deployment security remain separate review domains. Each claim has tests and report evidence.

Assurance boundary: The assurance case supports a configured weight-edit regression review for one baseline, subject, dataset window plan, tier, profile, and runtime policy.

This note enumerates the explicit assurance claims the toolkit makes, the evidence included in-tree, and the runtime contracts that enforce each claim. Each claim must have:

If you need definitions for guard terms (kappa threshold, epsilon band, window pairing), see the Glossary.

1. a short argument/derivation (“Evidence”), and
2. a test or contract that fails fast when assumptions are violated (“Runtime enforcement”).

We also list observability—the report fields that let reviewers verify the claim.

Scope, Assumptions, and Adjacent Domains

InvarLock’s assurance case is intentionally narrow. It is focused on regression risk from weight edits relative to a chosen baseline under a specific configuration. Content safety, alignment, and deployment security belong to separate review domains.

In scope

• Structured or quantization‑style weight edits applied to an existing model (baseline vs edited subject).
• Paired primary metrics (ppl/accuracy) on calibrated evaluation windows, with log‑space pairing and BCa bootstrap CIs.
• GuardChain behavior: invariants, spectral, RMT, and variance guards that detect structural breakage, unstable weights, outlier growth, and harmful variance shifts introduced by the edit.
• Determinism and provenance for the evaluation run: seeds, datasets, tokenizers, pairing schedules, and policy configuration reflected in the report.
• Execution on Linux/macOS environments using the pinned HF/PyTorch stack and profiles documented in the configs and docs.

Separate Review Domains

• Content-harm review for toxicity, bias, jailbreak behavior, prompt-level attacks, and alignment behavior in general use.
• Model-change review for unrelated training changes, new datasets, or new architectures outside calibrated families and tiers.
• Infrastructure and deployment review for authz, data governance, access control, and runtime hardening outside the InvarLock evaluation runtime.
• Platform qualification for environments outside the stated support matrix such as native Windows, custom CUDA stacks, or arbitrary dependency versions.

The table below should be read with this scope in mind: each row is a claim about paired evaluation and guard behavior for weight edits under the documented tiers and environments.

For the end-to-end report lifecycle, see One Run Lifecycle. Guard overhead evidence is detailed in Guard Overhead Method.

Summary

• Every assurance-critical guard links to a short assurance note and an automated test.
• The report verifier enforces log‑space math and pairing at runtime.
• Observability fields make the assurance case auditable in reports and evidence packs.

Tier scope: Balanced and Conservative are the supported published assurance tiers. The Aggressive tier is research‑oriented and outside the current assurance case. none is omitted from packaged runtime tiers; report-policy compatibility treats it like Balanced if encountered, so it is unsuitable as a separate assurance claim.

🔍 Verify on your machine

make verify
make docs-check-build
make docs-lint-strict

Running the suite above exercises the repo-native verification and docs guardrails: tests, runtime verifier, lint/format checks, strict docs build, link checks, and strict docs lint.