PII inventory matches usage

Verifies

Every personal-data field declared in a schema is referenced by the code or the contracts of the application; fields collected and never referenced are flagged. No AI engine is involved: the verdict is reproducible from the source alone.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP) plus Prisma, SQL, template (HTML, Jinja, Twig, Blade, ERB, Handlebars, EJS, Pug), GraphQL, OpenAPI/YAML, JSON, XML and CSV files. Schema files (models, entities, migrations, Prisma, SQL) yield the inventory of personal-data fields per store. References are counted in every other file with the tokens of the static analysis kit: identifiers and properties in any case style (birthDate, birth_date, BirthDate are one field), string and template literals naming the field (select and projection keys, serializer fields, raw SQL, DTO keys, form names), and the words of templates and contracts; comments never count. Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed, so a reference that lives only in tests does not count. Nothing of the checkout is executed.

Decision rule

Not applicable when no personal-data field is declared in a schema file. A strong personal-data field (e-mail, phone, names, date of birth, national id, address, financial, health, biometric, IP address, location) with zero references outside its declaring files is MEDIUM (blocks only inside Extended suites); a special-category or financial field (health, diagnosis, biometric, religion, ethnicity, IBAN, card number, salary, tax id…) with zero references is HIGH; a contextual field (name, city, country, company, locale, notes…) with zero references is LOW, informative. PASS when every field has at least one reference; the summary names each field with its reference count and files. Not judged by this check (declared): whether the feature that references the field is exposed, documented or lawful; fields reached only through wildcard access (SELECT *, a whole-record serializer, a spread), which count as unreferenced when nothing names them; and fields referenced only by a fillable, DTO or serializer list with no further use.

Type

deterministic

1.1.0: deterministic: the rule runs over the static analysis kit (tokens, function units, calls, imports, routes) with no AI engine; exact decisionRule and languages published; not-applicable with the reason when the checkout gives nothing to evaluate. References are tokens of other files (identifiers in any case style through the canonical name, strings and templates naming the field, words of templates, GraphQL and OpenAPI documents); comments and excluded tests never count; zero references is MEDIUM for a strong field, HIGH for a special-category or financial field, LOW for a contextual one. Not judged: whether the referencing feature is exposed or documented, wildcard access (SELECT *, whole-record serializers), fillable/DTO-only references. (1.0.2: never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).))

The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.