dds

# Platform profiles

The check's engine (`../check_join.py`) is platform-neutral set
logic; everything platform-shaped lives here, one profile per
platform:

- `<name>.json` — detection + config the engine consumes:
  - `detect`: `[{file, pattern}]` — the profile is ACTIVE when any
    pattern matches in its file; the matched line is captured as
    evidence and reported (detection is witnessed, not assumed);
  - `code_file_regex`: which repo paths witness code facts (drives
    NEEDS-EXTRACTION for delta files);
  - `surface_file_regex` / `credential_file_regex`: files whose delta
    marks the surface / credential class changed;
  - `fk_suffix`: how a `belongs_to`-style relationship names its
    column (pin validation);
  - `person_signal` / `audit_store` / `auth_plug`: the derivation
    regexes (engine defaults apply when omitted);
  - `reference_roots` / `reference_file_suffixes`: where dormancy
    reference-counting looks;
  - `sketch: true`: unproven — the report says so.
- `<name>.md` — the extraction record shapes for that platform,
  read by the agent when the instrument names the platform. The
  generic law stays in `../extraction.md`.

Multiple profiles can be active at once (their configs union). No
active profile = the engine runs docs-side checks only and reports
the degradation honestly — it never guesses a platform.

Adding a platform is data + one guide file, not engine code. Keep
detection evidence-based (a dependency line in a manifest, not a
directory name), and mark new profiles `sketch` until a real repo has
run them.