Principles, threat model summary, claims register, abuse handling.
Governance is a separable function from engineering. It exists to defend the privacy boundary under audit, not to ratify product plans after the fact.
Five proposed principles.
These principles define the intended launch contract. They are not descriptions of an operational deployment.
Separation by design
Identity and event data live in different domains. Cross-domain joins are a privileged operation, not a default.
Cohorts, not rows
Buyer outputs are aggregates. Per-user rows never exit the boundary. Minimum-count thresholds are non-reducible by contract.
Consent is a precondition
BingBong does not assume consent. Consent is documented, replayable, and revocable from both sides.
Revocation is a boundary event
Revocation propagates to ingestion and cohort construction within the documented window. It is not silent and not reversible without a documented re-onboarding path.
Honest residual risk
Reidentification and singling-out remain live risks. They are surfaced in methodology and consumer rights, not hidden.
What the boundary has to defend against.
The full threat model lives in docs/PRIVACY_THREAT_MODEL.md. This is the summary that ships with the surface.
| Threat | Status | Primary control |
|---|---|---|
| Reidentification by join | RESIDUAL | Domain separation; minimum cohort thresholds; suppression. |
| Singling-out by side-channel | RESIDUAL | Cohort rounding; query budgets; near-singling suppression. |
| Cross-context correlation | RESIDUAL | Prohibited-uses list; buyer roster; contract enforcement. |
| Token replay | BOUNDARY | Token signing; rotation; revocation propagation. |
| Insider abuse | BOUNDARY | Access logging; least privilege; governance review. |
| Breach | BOUNDARY | Encryption at rest; key separation; documented incident response. |
| Model inversion | RESIDUAL | Cohort-only output; aggregate validation; opt-out propagation. |
| Small cohort / fingerprinting | RESIDUAL | Minimum-count thresholds; suppression at the boundary. |
Draft claim candidates under review.
The full register lives in docs/CLAIMS_REGISTER.md. No SAFE or CONDITIONAL candidate below is approved for operational marketing; each requires counsel review and its listed evidence before use as an affirmative public claim.
"We issue randomized opaque tokens."
Requires: documented issuance endpoint, randomization policy.
"Identity and event data are kept in separate domains."
Requires: architecture diagram, join policy.
"Cohort outputs preserve privacy by minimum-count thresholds."
Requires: threshold table, suppression log.
"Revocation propagates within a documented window."
Requires: documented window, propagation receipts.
"Anonymized."
Pseudonymization is not anonymization.
"Compliant with HIPAA."
No HIPAA compliance is claimed.
"Audited performance."
No audits have occurred.
"Named customers / deployed scale."
Pre-launch design system.
How governance is intended to run.
The operating model below is a pre-launch design target and requires staffing, procedures, and evidence before it may be described as live.
Independent review
The governance function operates independently from engineering and commercial. Reviews are documented, evidenced, and not subject to override by engineering or commercial pressure.
Three-step path
Any party may submit an abuse report. Reports are acknowledged within a documented window, investigated against the threat model, and resolved with a documented outcome. The abuse report path is non-submitting in pre-launch — see rights.
Documented, not theatrical
Disclosure cadence and language are documented in advance. Disclosure does not invent comfort or minimize residual risk.
Provenance over narrative
Every governance decision is paired with the artifacts it relied on: a receipt, a test, a doc reference. Narrative without receipt is not a record.