PRE-LAUNCH / DESIGN SYSTEM   ·   All product, governance, and capability statements describe design targets and require independent verification before deployment.
PLATFORM · DESIGN TARGET

Token lifecycle, event flow, cohort output.

A pseudonymous broker is a sequence of decisions about what crosses the boundary, when, and in what shape. This page documents the planned sequence end-to-end.

All sample tokens, surfaces, cohorts, and timestamps on this page are fake and visibly labeled. They are illustrative only.

01 · LIFECYCLE · DESIGN TARGET

Opaque token lifecycle.

The proposed token model has four states and three transitions. The intended launch contract would gate and log every transition. No operational implementation is claimed.

  1. Issued

    A participating surface would request a token via a documented, rotating endpoint. BingBong would return a randomized opaque token with a key identifier, issuer surface, and creation timestamp. DESIGN TARGET OPAQUE

  2. Active

    The token may receive events from its issuing surface and any surface operating under a documented consent receipt. Events never carry identity-bound fields into the event domain. COHORT-SCOPED

  3. Rotated

    Rotation is scheduled and on-demand. The prior token continues to receive events for a grace window, after which it is suppressed. Rotation does not break cohort continuity when continuity is part of the contract. DESIGN TARGET

  4. Revoked

    Revocation would be triggered by consumer opt-out, partner removal, governance review, or integrity incident. The target behavior would suppress revoked tokens at ingestion and remove them from cohort construction. DESIGN TARGET

02 · EVENT FLOW · DESIGN TARGET

From surface to cohort output.

The four stages below describe intended behavior for design review, not a deployed processing pipeline.

01
INGEST

Edge request

Surface forwards an event tagged with a token. Identity-bound fields (raw IP, full UA, email, phone, account id) are filtered or routed to the identity domain.

02
BOUNDARY

Domain separation

Event payload enters the event domain. Identity domain holds only the minimum required to operate the token and to honor consent.

03
AGGREGATE

Cohort construction

Tokens are bucketed under cohort definitions. Cohorts below the minimum count are suppressed. Query budgets throttle expensive operations.

04
DELIVER

Buyer contract

Buyers see cohort-shaped aggregates plus provenance, retention, and revocation metadata. No raw events. No per-user lookups.

03 · OUTPUTS · DESIGN TARGET

What a buyer receives.

A buyer output is a structured envelope. The shape is part of the contract and is described here for design review.

FIELD

cohort_id

Opaque, stable identifier for the cohort over the contract window. OPAQUE

FIELD

cohort_size

Rounded to the cohort's minimum-count threshold to defeat near-singling-out by side-channel.

FIELD

window

Time window the aggregate covers, with start/end in UTC and a wall-clock skew budget.

FIELD

aggregate

Cohort-level measure (count, ratio, lift) bounded by the contract and the prohibited-uses list.

FIELD

provenance

Hash of the cohort definition, the ingestion policy version, and the suppression policy in effect.

FIELD

retention

retention_until

UTC timestamp at which the buyer must destroy the local copy. Beyond this point the buyer's copy is out of contract.

04 · ROTATION & REVOCATION · DESIGN TARGET

Two controls, one discipline.

The intended design uses rotation to reduce the value of a compromised token and revocation to remove participation. Documentation, auditability, and buyer-contract metadata are launch targets that require evidence before operational claims may be made.

ROTATION · DESIGN TARGET

Scheduled + on-demand

The default rotation cadence remains a design target. On-demand rotation would be triggered by surface policy, integrity review, or governance event. A planned grace window would prevent breakage during cross-surface handoff.

REVOCATION · DESIGN TARGET

Opt-out, partner removal, integrity

Revocation would be a boundary event. The target behavior would suppress tokens at ingestion and remove them from cohort construction within a documented propagation window, without silent reactivation.

05 · DEMO

Token lifecycle, illustrated with fake data.

The token shown below is synthetic. It exists for design review only.

Token record

tokenbbng_live_8e3a5d2c1f7b49c6a3d8e0b1f4c2e9a6
key_idk_2026Q3_04
issued_at2026-07-14T11:02:38Z
surfacepublisher.example
stateactive → rotated → revoked
rotation_cadence28d (DESIGN TARGET)
grace6h

Boundary events

T+0issued to publisher.example
T+12dscheduled rotation — k_2026Q3_05 begins
T+18dconsumer opt-out — revocation requested
T+18d+12mtoken suppressed at ingestion
T+18d+2hremoved from cohort construction
T+18d+24hretention sweep completes
retention_until2027-01-14T00:00:00Z (target)
06 · NON-GOALS

What BingBong will not do.

The non-goals are part of the contract with stakeholders. They are not negotiable during launch phases.

  • Issue, sell, or transmit direct identifiers (email, phone, account id, full IP).
  • Provide per-user lookups, replay endpoints, or deanonymization APIs.
  • Cross-reference BingBong tokens with third-party identity graphs without a documented boundary event and a governance review.
  • Operate in jurisdictions where a regulated-data exemption is the basis for design, rather than a privacy-by-design basis.
  • Re-enable a revoked token without a documented re-onboarding path.