Assurance Case Overview (v1.0)

TL;DR: InvarLock evaluates whether weight edits (quantization, pruning, etc.) regress a model beyond defined bounds. It does not evaluate content safety, alignment, or deployment security. 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. Each claim has tests and report evidence.

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

This note enumerates the explicit assurance claims the toolkit makes, the evidence shipped 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 non‑goals

InvarLock’s assurance case is intentionally narrow. It is about regression risk from weight edits relative to a chosen baseline under a specific configuration, not about global model safety.

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.

Out of scope (non‑goals)

• Preventing or detecting content harms (toxicity, bias, jailbreaks), prompt‑level attacks, or alignment failures in general use.
• Guaranteeing safety for unrelated training changes, new datasets, or new architectures that fall outside the calibrated families and tiers.
• Enforcing infrastructure or deployment hardening (authz, data governance, access control); these live outside the InvarLock runtime.
• Guaranteeing correctness on environments outside the stated support matrix (e.g., native Windows, custom CUDA stacks, 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, not a universal guarantee about model safety.

For the end-to-end validation protocol (Step-0 through Step-8 reproducibility and guard overhead checks), see the methodology overview in the docs.

| Guard Overhead stays within budget (≤ +1.0% PM). | docs/assurance/10-guard-overhead-method.md | report gate validation.guard_overhead_acceptable; bare vs guarded measured on same windows/seeds with single toggle and snapshot/restore. | guard_overhead.{bare_ppl,guarded_ppl,overhead_ratio,overhead_percent,overhead_threshold}, validation.guard_overhead_acceptable | Same schedule and seeds; bare control is guard‑free; snapshot/restore or deterministic reload. |

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 proof packs.

Tier scope: Balanced and Conservative are the supported published assurance tiers. The Aggressive tier is research‑oriented and not covered by this assurance case. The none tier is provided only for dev/demo flows (loosest gates) and is explicitly outside the assurance case.

🔍 Verify on your machine

OMP_NUM_THREADS=1 conda run -n invarlock pytest -q
OMP_NUM_THREADS=1 conda run -n invarlock python scripts/check_docs_links.py
OMP_NUM_THREADS=1 conda run -n invarlock mkdocs build --strict

Running the suite above mirrors the CI guardrails: it replays the assurance tests, regenerates tier tables, validates doc links, and ensures the MkDocs build stays clean.