Compliance Library — coverage & tiering

What “100% coverage” means here

Logrite’s compliance engine is a per-line / per-prompt token+regex matcher emitting block | notify | allow. It evidences controls that leave an artifact in a log line or an AI prompt. It is not an auditor: it cannot read your policies, inspect your contracts, verify staff training, or perform the statistical arithmetic a bias audit requires.

So a coverage percentage is only meaningful against a stated denominator. Every framework carries a coverage manifest — an enumerated list of its obligations, each classified one of three ways:

Class	Meaning	How it is satisfied	Count
DETECTABLE	a log line or prompt can carry evidence	a seeded rule matches	172
ATTESTABLE	real obligation, no runtime artifact	the workspace records evidence	89
OUT_OF_SCOPE	nobody the operator controls can evidence it	excluded from the denominator	4

detection coverage = satisfied_detectable / detectable
attested coverage  = current_attestations / attestable

The two are reported separately and never averaged. “A rule fires on this” and “somebody signed a statement about this” are different strengths of evidence; merging them would produce the most flattering and least honest number on the page.

An unexplained exclusion is impossible to express — the manifest record rejects it at construction, and an ATTESTABLE obligation with no evidence type is rejected the same way.

Note

As of the 2026-08 depth pass: 29 compliance frameworks, 166 compliance rules, 265 enumerated obligations (172 detectable + 89 attestable + 4 out-of-scope), 100% detection coverage — every obligation a line scanner can evidence has a rule behind it, and every obligation it cannot has a named evidence channel.

The seeder holds 221 rules in total: those 166 plus 55 OPS signatures. OPS is operational log triage (Go panics, OOM kills, segfaults), not a compliance framework, and is excluded from every coverage figure on this page.

The number is computed, not asserted

ComplianceCoverageService.computeCoverage() resolves “satisfied” against the live snapshot’s rule ids, never against the manifest’s own claim. A manifest entry naming a rule nobody wrote counts as a gap, not as credit.

ComplianceCoverageManifestTest enforces this in CI. It fails the build when:

• a manifest entry credits a rule the seeder never declares, or
• any framework drops below 99% of its detectable surface.

Adding an obligation therefore lowers the number until someone writes the rule. Coverage cannot rot silently as regulations change.

GET /api/v1/warden/library/coverage

Returns per framework: coveragePct, detectable, satisfied, outOfScope and the named gaps, plus attestable, attested, attestedPct, notApplicable and pendingAttestations. Frameworks with no manifest report measured: false rather than a fabricated 100%.

Tiering — what appears in the picker

Tier	Frameworks	In picker	Coverage
Core — US	HIPAA · PCI DSS v4.0.1 · SOC 2 · CCPA/CPRA · OMB M-26-14 · AI-Data-Gov · OWASP-LLM	yes	100%
Core — EU	GDPR · EU AI Act	yes	100%
Operational	OPS (system-health signals, not a compliance framework)	hidden	n/a
Catalogue	GLBA, SOX, FedRAMP, CMMC, CJIS, NERC-CIP, FERPA, COPPA, BIPA, US-State-Privacy, DORA, NIS2, ISO 27001/27701/42001, NIST-AI-RMF, Colorado-AI, TRAIGA, NYC-LL144, GEN	hidden	100%

Caution

Hidden ≠ disabled. Visibility is a property of the descriptor, never of the library snapshot. Catalogue frameworks are still seeded, still served to the relay and analyzer, and still block or notify exactly as before. A workspace already bound to a catalogue framework keeps enforcing it, and its findings still render with the right label and colour. Hiding only removes a framework from the picker — and even there, a framework that is already selected still renders its chip, so an existing binding stays visible and can be switched off.

OPS is hidden for the same reason: it is operational log triage, not a compliance framework, so it does not belong in a picker captioned “the LLM judge evaluates the request against each selected framework”. The System Health starter set still binds it, and that binding still shows.

Promotion is one flag in ComplianceLibraryService.CORE_FRAMEWORKS, or an ops-side override with no code change at all:

COMPLIANCE_VISIBLE_FRAMEWORKS=hipaa,pci,soc2,gdpr,glba

One library, two consumers — the analyzer no longer keeps its own list

The compliance library is seeded by ComplianceLibrarySeeder; the analyzer runs off rows in AnalyzerRulesConfig. Until 2026-08-14 those were two hand-maintained lists, and only the frameworks someone remembered to add a literal for in LogLeakRulesSeeder reached the analyzer — 24 of the 29 seeded frameworks never got that treatment. A workspace could bind ISO 27001 in the Warden, where it blocked and notified correctly, then run a code scan that had never heard of it: same product, same customer, two different answers about the same regulation.

ComplianceAnalyzerRulesSeeder removes the second list. It reads the live compliance-library snapshot — which already enumerates every rule with its category, severity, citation and remediation hint — and derives the analyzer rows from it at ApplicationReadyEvent. So:

• seeding a new framework in ComplianceLibrarySeeder makes it scannable automatically; there is no second place to remember and therefore no second place to forget;
• a rule disabled or removed upstream simply stops appearing. Existing rows are left alone rather than deleted, so a workspace’s own edits survive a redeploy;
• ComplianceFrameworkVisibilityTest pins the invariant — a framework in the library that the analyzer cannot see fails the build.

Leak rules vs coverage signals — inverted semantics

Two rule shapes, and the difference matters when reading a finding:

Shape	A match means	Action	Runs on
Leak (valuePatterns / tokens)	sensitive data is present — a violation	block / notify	relay hot path + analyzer
Coverage (crSig signature)	this event type is being logged — evidence a control operates	notify only	analyzer log scan (relayApplicable=false)

A false positive on a leak rule blocks a real request, so leak patterns are context-gated: they require the labelling field name, not just a shape. A bare five-digit number is not a ZIP code and a bare date is not a date of birth.

Coverage signals are deliberately excluded from the relay hot path so posture telemetry never adds notify-noise to live AI traffic. Three rules are documented exceptions — m2614_log_management, sox_audit_log_tamper and sox_privileged_access carry a coverage category but have leak semantics (a match is the bad thing), so they legitimately run inline. The list is pinned by a test, so a new coverage rule cannot drift onto the hot path unnoticed.

Second-stage value validation

A regex match is a candidate, not a finding. The PAN patterns are prefix-and-length only, so any 16-digit number beginning with 4 matched them — including ordinary order and trace ids. Because pci_log_leak_payment is a block rule, that was enough to reject live traffic.

matchPattern therefore Luhn-checks (ISO/IEC 7812) any match that is card-shaped — a run of 13–19 digits separated by nothing but spaces or hyphens. Everything else is passed through untouched, so the gate can never suppress a non-card finding: an SSN is nine digits, a phone number at most eleven, and a labelled account id carries its label inside the match.

The scan also walks every match rather than stopping at the first, so a rejected near-miss earlier in a line cannot shadow a real PAN later in it.

Regulatory currency (verified 2026-08-05)

Framework	Status
HIPAA	Security Rule NPRM still proposed; OMB final action slipped to July 2027. MFA/encryption are therefore not treated as required. Safe Harbor 45 CFR 164.514(b)(2) unchanged — all 18 identifiers are addressed individually.
PCI DSS	v4.0.1 only (v4.0 retired 2024-12-31); all 51 future-dated requirements mandatory since 2025-03-31. PCI SSC ran an RFC through 2026-07-20 — a v4.x revision is in motion.
SOC 2	TSC 2017 + 2022 revised points of focus; unchanged in 2026.
CCPA/CPRA	CPPA regs effective 2026-01-01. Risk assessments live now; ADMT 2027-01-01; cyber-audit certifications phased 2028-04-01 → 2030-04-01.
OMB M-26-14	Issued 2026-05-22, rescinds M-21-31. CISA’s Logging Reference Architecture is due ~2026-08-20 and is not yet published — deliberately unmodelled rather than guessed.
EU AI Act	Digital Omnibus in force 2026-07-27. Annex III high-risk deferred to 2027-12-02, Annex I to 2028-08-02. Art.50 transparency applicable since 2026-08-02; Art.51-56 GPAI running since 2025-08-02.
COPPA	2025 amendments in full effect since 2026-04-22 — personal information now includes biometric and government-issued identifiers.

The fail-open bundle

The relay loads its rules from the backend snapshot. If that fetch fails it falls back to a bundled copy. That bundle used to be hand-maintained and had drifted to 68 of 221 seeded rules — so a database outage silently downgraded PCI to a token-only rule that missed a bare PAN.

It is now generated from the seeder, for both the relay and the analyzer’s vendored copy:

npm run gen:catalogue     # regenerate both targets
npm run check:catalogue   # CI guard — fails if the checked-in bundle is stale

The seeder is the single source of truth; the generator never invents a rule.

Caution

The generator fails loudly rather than emitting less than the seeder declares. It used to filter(Boolean) away any pattern constant it could not resolve. Two constants — SSN_VP and EMAIL_VP — were declared as raw Map.of(...) literals instead of via the vp() helper, so they were silently dropped: the bundled hipaa_log_leak_phi shipped with no SSN detection at all, and GDPR’s gen_log_leak_pii with no email detection. Both constants are gone (they were weaker duplicates of SSN_VALUE_VP / EMAIL_VALUE_VP), and an unresolvable reference is now a hard error naming the constant and the rule.

Attestations — the 89 obligations no scanner can see

An executed BAA, a penetration-test report, an ISO certificate, a physical access review: every framework requires things that leave no log line. Reporting those as “out of scope” told a user we could not see them, but not what to do about it. Each is now a first-class obligation with the specific evidence to produce.

GET    /api/v1/warden/library/attestations?libraryKey=hipaa   # the checklist + current answers
POST   /api/v1/warden/library/attestations                    # record evidence
DELETE /api/v1/warden/library/attestations?libraryKey=…&obligationId=…

Each obligation declares an evidence type — POLICY, CONTRACT, TRAINING, PERSONNEL, CERTIFICATION, ASSESSMENT, PHYSICAL, CONFIGURATION, PUBLISHED_NOTICE, REGULATORY_FILING or GOVERNANCE — which decides what the UI asks for and whether an expiry is mandatory.

Caution

An attestation is not a checkbox. The service refuses to record one when:

• the obligation is DETECTABLE — you cannot attest your way past a rule the engine is supposed to enforce, and the error names the rule that covers it;
• the obligation is OUT_OF_SCOPE — it is nobody’s to evidence;
• CERTIFICATION evidence carries no expiry date;
• the expiry is already in the past, or falls before the effective date;
• NOT_APPLICABLE is claimed without a written justification.

owner, attestedBy and attestedAt are mandatory, so “we have a policy” is a signed statement by a named person on a date.

Expiry is derived, never stored. An attestation stops counting on the day it lapses, evaluated against the request date — no sweep job, no cron, no stale certificate quietly propping up a number. GET /library/coverage returns attestable, attested, attestedPct and the named pendingAttestations alongside the detection figures.

NOT_APPLICABLE removes an obligation from that tenant’s denominator rather than counting it as satisfied — a workspace with no physical premises should not be marked compliant with a physical control, only excused from it.

Explicitly out of scope

Only four obligations are genuinely outside the model — everything else that a scanner cannot see is now ATTESTABLE rather than excluded:

Framework	Obligation	Why it stays out
HIPAA	2025 Security Rule NPRM	proposed only; OMB final action slipped to July 2027
M-26-14	CISA Logging Reference Architecture	not yet published — unmodelled rather than guessed
TRAIGA	proving intent	liability turns on a legal state of mind
TRAIGA	AG enforcement / 60-day cure	the regulator’s action, not the operator’s control

The distinction is whether the operator can hold evidence for it. Policy documents, BAAs, physical safeguards, training records, penetration tests, certification engagements and the NYC LL144 bias audit all can be — so they are attestable, not excused.