Privacy is a decision input, not a downstream filter

The architecture behind keeping a real-time bidding decision deterministic while consent and regional policy still shape every outcome.

A privacy rule applied after a decision only tells you the decision was wrong. Applied before it, the same rule keeps the wrong decision from happening at all.

Where privacy usually gets bolted on

The common shape of a privacy layer is a filter at the edge of the system: a decision gets made, and a separate compliance step checks whether the result was allowed to happen, then blocks or redacts it. That order is convenient to build, because the decision logic never has to know that privacy exists. It is also backwards for anything running under a hard latency budget, where there may be no second pass left to run.

A real-time auction cannot afford a rejected decision. By the time a bid response would be checked and discarded, the auction has already cleared. The only place a privacy rule can do useful work is before the decision uses the signal it governs.

System design: consent resolves before targeting

The bidder's pipeline treats TCF and GPP consent signals as inputs to scoring, not outputs to audit. Identity and targeting features are only assembled after the applicable consent and regional rules have already been decoded and resolved for that request.

• Decode TCF and GPP — Consent strings are parsed once, at the front of the request, not re-interpreted by every downstream feature that might want to use identity.
• Resolve regional policy — Retention and regional rules apply before any signal derived from identity becomes eligible for scoring.
• Assemble allowed features — The feature set the bidder scores against is already privacy-legal by construction; there is nothing left to strip out afterward.
• Score and respond — The deterministic auction path runs on a feature set that never contained a disallowed signal in the first place.

This is why the architecture decision record for the system states privacy as a decision input, not a compliance layer: fewer signals are available for some auctions, but nothing downstream has to remember to check.

The trade-off this ordering forces

Resolving consent first means some auctions run with less information than they technically could have used, because a signal a looser architecture might have scored on was never assembled in the first place. That is an accepted, deliberate cost. The alternative — scoring first and filtering after — either leaks a disallowed signal into a decision that already happened, or requires the auction to wait on a compliance check it does not have the latency budget to afford. Between fewer signals and a slower or leakier auction, the architecture chooses fewer signals every time.

Keep the audit trail attached to the decision, not beside it

Every decision the bidder makes carries a traceable event ID shared across decision features, policy state, and outcome — the same identifier the analytics and agent-operations layers read downstream. That means a reviewer asking "was this decision allowed to use this signal" is answering the question from the same record that produced the bid, not reconstructing it from separate logs that have to be joined after the fact.

• Decision features, policy state, and model/config versions travel together on one event
• Agent operations reads this trail to investigate anomalies, but never sits on the bidding path itself
• A privacy question about a past decision is answered by replaying one event, not correlating several systems

From production: what the ordering actually protects

AgentBid's bidding path has no LLM anywhere on it, for latency reasons covered elsewhere in this portfolio — but the privacy ordering is a separate, independent constraint that would still hold even if the auction were slow. TCF/GPP decoding and regional policy resolution happen before identity or targeting features are constructed, which means a consent withdrawal or a regional restriction removes a signal from consideration rather than removing a decision after the fact. The reporting console and the ClickHouse-backed attribution layer read from the same event stream the bidder publishes to, so privacy state, decision state, and outcome state are never three separate stories that have to be reconciled — they are one event, read three ways.

The same discipline shows up in how the agent-operations layer is scoped. It investigates anomalies and proposes bounded actions by reading events after the fact; it does not sit in front of the bidder deciding what the bidder is allowed to see. Keeping a probabilistic assistant out of the path that decides which signals are legal to score on is the same reasoning, applied to privacy instead of latency: a decision that has to be provably correct on every single request is not a place for a model to improvise.

What to carry forward

• Resolve consent and regional policy before assembling the features a decision will use
• Treat "fewer available signals" as an accepted cost, not a bug to work around later
• Give every decision one traceable event ID instead of logs that must be joined afterward
• Keep probabilistic components off any path that has to be correct on every single request
• Audit the decision from the record that produced it, not from a downstream reconstruction

Applied in the portfolio

• AgentBid — An open architecture for real-time bidding operations, combining a high-throughput data plane with explainable AI assistance.