Section 12: One Pipeline, Many Verbs - Follow-up Feature Evolution

Executive Summary: The orchestrator ships, and the follow-ups arrive: objection and opt-out, CCPA and other laws, data residency, automated retention, machine-learning models, and direct transfer to another provider. Each one reuses the same parts: the registry, the claim-check broadcast, the task ledger, the acks, the deadline scanner and the audit chain. What changes is the verb, the policy row, or where the pipeline is deployed.

The interviewer leans back. "It's live. Lena's deletion closed on day 23. Product, legal and the ML org all have requests. What does version two look like?"

The weak answer is a list of new systems: a consent platform, a CCPA pipeline, a retention service. The strong answer is that Sections 4 through 9 built a general-purpose machine. It sends one instruction about one subject to 1,200 holders, tracks every ack against a stored deadline, and proves the outcome. Erasure was just the first instruction.

Key Insight: The orchestrator never knew what "delete" means. Each service's handler knows that. The orchestrator carries a verb, a scope and a deadline. Almost every follow-up is a new verb, a new policy row, or a new place to deploy the same pipeline.

Evolution 1: Restriction, Objection and Opt-Out

Lena doesn't want to leave. She just wants the news app to stop using her history for ad targeting. That is an objection under GDPR Art. 21, or a restriction of processing under Art. 18. In the US, the CPRA gives consumers the right to opt out of the sale or sharing of their personal information, and it requires businesses to honor opt-out preference signals such as Global Privacy Control, which the browser sends with each request.

• What changes: new verbs, RESTRICT and OPT_OUT, on a new topic. The operations field in each privacy.yaml declares which verbs a holder supports. Unlike erasure, these states can be reversed: Lena can withdraw her objection, so the ledger records a current preference, not a one-time terminal event.
• What stays the same: the claim-check event, scoped identifier lookup, idempotent PUT acks, the escalation ladder and the audit chain. Fan-out is still a broadcast to every holder: a holder with nothing to restrict acks NO_DATA.
• Rejected alternative: making the consent store the only enforcement point. Serving paths still read a cached preference, but without the fan-out nothing proves that stores, models and processors downstream honoured the opt-out.
• Trigger: the first time counsel asks for opt-out across products to be enforced and provable.

"Doesn't this blur into consent management, which you scoped out in Section 2?" It sits right next to it. Capturing consent is still out of scope: banners, purpose strings, cookie choices. Enforcing a withdrawal across 1,200 services is a fan-out with acknowledgements, and that is what we built.

Quick check before moving on: