AI / ML Data Governance Policy

Field	Value
Status	draft
Owner	DIR (governance) / INFRA (enforcement in code)
Applies to	All analytics/ML use of Partile data: the event taxonomy, consent gating, training-set construction, model lifecycle, and any matching/ranking model.
Review cadence	Annual; plus before any event pipeline, training run, or model ships; and on counsel ratification.
Mapped controls	ML-01–10, PRIV-10 (consent).
Evidence	readiness/ml-event-taxonomy.md; infra PR-17 (7562d25) user_consents, app_events, and emit_event; infra PR-18 (b0590be) try_emit_event product hookpoints and event_hookpoint_smoke.py; infra PR-19 (94d4018) worker lifecycle hookpoints and worker_event_hookpoint_smoke.py; infra PR-20 (9e828db) k-anonymous ML snapshot boundary and ml_snapshot_smoke.py; infra PR-27 (e43b60c) key-gated minimized Claude rationale and rationale_smoke.py; infra PR-28 (d2db03f) key-gated stateless Claude interview and interview_smoke.py; mobile PR-13 (b63e586) consent UI for analytics/ml_training/marketing; READINESS.md decision log (2026-06-07 governance + model-non-deletion decisions); ../counsel-queue.md C8-C13 and C27.
Exception handling	Any use of data outside its consent tier, or any Art 9 / safety-data / Art 22 boundary crossing, is prohibited — not exception-able.

Purpose

Maximize Partile's future data-science optionality through governance, not loose policy. Under-governing is the bigger long-term restriction (retroactive deletion, unusable data, tainted models). Good governance — broad-but-valid consent, clean lineage, clear tiers — is what keeps data usable. Three boundaries are hard-constrained from day one.

The enablement stance

Defining the taxonomy, consent model, and anonymization boundary now, while there are zero real users and before production data exists, is what keeps consent/deletion/PII handling cheap instead of a retrofit. Infra PR-17 implements the consent/event foundation, infra PR-18 wires the first product hookpoints through it, infra PR-19 wires worker match lifecycle hookpoints through the same gate, infra PR-20 adds the k-anonymous T2 snapshot boundary, and mobile PR-13 gives users in-app grant/revoke controls — ratify-now, emit-when-needed.

Consent tiers (gate what data may flow)

Tier	Meaning	Gate
T0 operational	Required for the service to function	Contract / legitimate interest; never ML training without re-consent
T1 product-analytics	Aggregate product metrics	Requires analytics consent
T2 ML-training	May enter model training	Requires explicit, separately-revocable ml_training consent; honours deletion propagation

Consent is represented as three independent, revocable toggles (analytics / ml_training / marketing), timestamped and versioned to the notice (PRIV-10, C2). The backend consent API/table exists and mobile PR-13 exposes grant/revoke in Settings plus a first-run prompt using internal placeholder copy; final legal notice text remains future. No T1/T2 event may be emitted for a user lacking the matching grant — enforced in code via the PR-17 tiered emit_event helper and PR-18/PR-19 try_emit_event hookpoints, not by policy alone.

Hard rules (enforced in code; tested)

1. No content or secrets in events. emit_event rejects banned keys and obvious email/JWT-like string values before insert; PR-18 hookpoint smoke verifies product fields omit terminal/gate/details/email/subject/token/code/ state; PR-19 worker smoke verifies worker fields carry only side/airport_code; PR-22 message.sent records length, never body; PR-24 connection events omit request notes and note is a banned event field; no email/sub/token/boarding-pass field enters an event (ML-04). PR-27/PR-28 smokes verify rationale/interview content is not emitted into events.
2. Reference, don't copy, identity. Events carry the internal user_id UUID, never subject/email — so erasure orphans events cleanly (ML-04).
3. Proximity events are personal data. airport_code + ts is identifying; presence/match events inherit full personal-data handling.

The three day-one hard constraints

These are non-negotiable and not exception-able:

• Article 9 (special category): no inference, derivation, optimization, or storage of special-category attributes. LinkedIn headlines and airport/route data can imply religion, politics, health, sexual orientation — these are excluded from the feature space entirely (ML-02, C13).
• Safety data is never a training signal. safety.blocked / safety.reported are T0 operational-only and may never enter ML training — using abuse reports as a model signal is an ethics/fairness landmine (ML-03).
• No fully-automated significant decisions (Art 22). Match proposal keeps a human/consent element — the user approves each match — so no automated decision with legal or similarly significant effect occurs without safeguards (ML-10, C11).

Erasure & the anonymization boundary (load-bearing)

Operator decision (2026-06-07): models are not deleted or retrained on user erasure. Erasure propagates to the pseudonymized event store only. Models train solely on anonymized snapshots — UUID stripped, direct object identifiers removed, non-whitelisted fields stripped, low-k groups suppressed, and quasi-identifiers aggregated/feature-engineered so re-identification is not reasonably possible — placing trained models outside erasure scope (ML-07).

The load-bearing control is the anonymization standard at the training-set boundary, especially for movement traces, which are not anonymized by dropping the UUID alone. The standard and the model-non-deletion defensibility (incl. memorization / membership-inference risk) are counsel-gated at C8/C9. Infra PR-20 implements the first technical boundary (ml_training_snapshots / ml_training_snapshot_rows) under the working assumption, but no model is trained until the final standard is ratified and model governance work is ready.

Lineage & documentation

• Dataset/model lineage (ML-06, not started): record which data fed which model/feature — required for accountability (Art 5(2)) and for defending the anonymization boundary.
• Model cards (ML-09) and a bias/fairness review (ML-08) for any matching/ranking model before public launch (M5, C12).

Exceptions

None for the three hard constraints, the consent gate, or the anonymization standard. Operational T0 events flow regardless (the service cannot function otherwise) under contract/legitimate interest — that is the tier definition, not an exception.