Catalog

The coverage model

The catalog is a cross product: 21 security families multiplied by 26 verification lenses gives 546 explicit hypothesis records with stable IDs. Families identify where a security property lives. Lenses identify how an invariant can fail.

The structure means a new family or a new lens can be added without copying hundreds of near-identical checks, and it means every hypothesis has a predictable ID such as SHX-AUTHZ-L02.

21 families

26 lenses

The lens list is the more distinctive half. It encodes the ways a control fails rather than the technologies it fails in, which is why the same lens applies across authentication, payments, and agent tooling.

Inside a record

Each record carries the family, the lens, a review question, the capability tags that drive applicability, the evidence the reviewer needs, and the known false-positive traps for that combination.

{
  "id": "SHX-AUTH-L01",
  "family_id": "AUTH",
  "lens_id": "L01",
  "claim_status": "HYPOTHESIS",
  "applicability": {
    "capability_tags": ["authentication", "identity_lifecycle", "mfa"],
    "rule": "ANY_CAPABILITY_PRESENT"
  },
  "evidence_requirements": [ ... ],
  "false_positive_traps": [ ... ]
}

The full catalog is catalog/checks.json, with the frozen ID manifest in catalog/hypothesis-ids.txt.

Claim policy

The catalog declares its own selection rule and claim policy, and both are enforced downstream.

• Selection rule: evaluate every record with the deterministic four-state applicability engine before review. Missing evidence is UNKNOWN, and only explicit absence is NOT_APPLICABLE.
• Claim policy: every catalog record is an unverified hypothesis. Findings require an evidence chain and, for High and Critical, independent verification.
• Records are review questions selected by architecture applicability, never vulnerability or exploit claims.
• The 21 by 26 shape is a repository invariant. Changing it requires a versioned catalog change and updated validation.