Reference Integrity

The resolution layer: does everything the code claims to reference actually exist?

In scope. Imports that fail to resolve (module not installed, path typo), API endpoints called but not defined, database tables / columns referenced but not in schema, RPC / stored-procedure names that don't exist, routes linked but not declared, environment variables used but not documented or declared, asset URLs pointing at missing files, JSON-LD properties that don't match schema.org vocabulary, type-only references to deleted types, broken foreign keys, reference to a function removed by refactor.

Not in scope. Reference resolves but target is a stub or mock — that's placeholder-hygiene. Reference resolves but to the wrong semantic concept (real package, wrong use) — carries this taxon plus supply-chain or security depending on the trust question. Dead code that's never executed but resolves — that's code-quality.

Distinct because. The defect is the referent does not exist. The code won't run, or runs and raises at the reference boundary. If the symbol resolves, reference-integrity is satisfied even if the resolved code is garbage. A pattern about "imports @scope/pkg not in package.json" is reference-integrity. A pattern about "imports package that exists but returns mock data" is placeholder-hygiene.

Conceptual sub-structure. Module / import references, route / URL references, database-schema references, env-var references, asset references, API-surface references.

Note on external mappings. No established external taxonomy names this failure class at pattern granularity. AuditBuffet aims to be the primary named vocabulary.