End-customer Notifications with Minimal PII

The real problem: why send a whole customer/order object for a small message?

A shipment update is ready. The source object contains full name, exact address, phone, internal notes, operational identifiers, and raw carrier payload. The outbound message needs only an authorized route, a limited order reference, normalized shipment status, and—where allowed—a safe tracking link. Copying the rich object into a template expands PII exposure and coupling. Marking a provider acceptance as DELIVERED also corrupts delivery truth.

This lesson builds Minimal-PII Notification Projection and Delivery Contract v1: a small purpose-specific projection, routing separated from business truth, versioned redaction/templates, an explicit delivery ledger, bounded retry, and auditable retention.

Lesson boundary

COM-035 owns notification projection and delivery evidence. COM-034 owns carrier-event normalization/truth. COM-036 owns PWA/web-push capability readiness. This lesson consumes carrier truth but does not create it; it can use push as a channel but does not prove platform support.

Hard boundaries:

1. Having an order does not authorize copying arbitrary customer data into arbitrary notifications.
2. provider accepted is not customer delivered.
3. A vendor-specific consent/retention term is not a universal MAKNOW rule.

Mental model: Event → Purpose → Recipient → Minimal Projection → Render → Provider → Delivery Ledger → Retention

Flow:

canonical event → purpose gate → recipient authorization/routing → minimal projection + redaction → versioned template → provider adapter → delivery-event ledger → retention/erase gate

Each stage has its own evidence. Carrier state is business truth; recipient route is operational routing; rendered content is a projection; provider response is evidence only for its provider stage.

Keep FACT, INFERENCE, and DESIGN separate

FACT — Data minimisation. European Commission guidance describes personal data as adequate, relevant, and limited to what is necessary for the purpose; storage limitation also constrains retention.

FACT — Privacy by design/default. Safeguards should be designed in early and default processing should use only necessary data with short necessary retention and limited access.

FACT — Vendor boundary. DHL imposes provider-specific restrictions on tracking-data use/disclosure and retention. Those terms remain scoped to that provider/context.

INFERENCE. A small purpose-specific projection with separately auditable routing, render, and delivery evidence reduces unnecessary exposure and improves auditability.

DESIGN — MAKNOW. The contract fields, delivery states, retry rules, redaction versioning, and fail-closed behavior are local design choices.

The 23-field notification contract

Each notification record contains:

notification_id, event_trigger, purpose_code, message_class, recipient_ref, recipient_channel, recipient_destination_masked, authorization_or_basis_ref, minimal_field_set, redaction_policy_version, template_id, template_version, locale, tracking_link_policy, provider_message_id, queued_at, provider_accepted_at, delivery_event_at, delivery_status, failure_code, retention_until_or_class, owner_ref, evidence_ref.

Gate 1 — Lock purpose before template

SHIPMENT_STATUS is a purpose; “everything we know about the customer” is not. purpose_code bounds which fields can be justified.

Gate 2 — Project business truth instead of dumping it

Templates should not receive the full order/customer/carrier object. A projector should emit only allowlisted fields such as order_ref_fragment, normalized_status, and safe_tracking_link. full_address, internal_note, and raw_carrier_payload are not justified for this message class absent a specific evidenced purpose.

Gate 3 — Separate recipient routing from customer truth

recipient_ref can point to canonical identity, while outbound destination evidence should be masked/tokenized. Do not duplicate raw email/phone across general ledgers or content artifacts.

Gate 4 — Keep authorization/basis explicit

authorization_or_basis_ref points to the applicable policy/contract/consent/context. This lesson does not decide a legal lawful basis. If required basis evidence is missing, use HOLD.

Gate 5 — Version redaction and templates

Without redaction_policy_version and template_version, reviewers cannot reconstruct what content/rules were used. Template change is audit-relevant.

Gate 6 — Do not turn tracking data into raw customer payload

A message can contain an approved safe link or normalized status, but raw provider responses and internal-only identifiers should not leak into customer-facing content.

Gate 7 — QUEUED, ACCEPTED, and DELIVERED are different

QUEUED means the system queued work. PROVIDER_ACCEPTED means the provider accepted the request or issued an ID. DELIVERED requires appropriate delivery evidence. No receipt means no guessed delivery.

Gate 8 — Bound failure and retry

A transient failure can become RETRY_ALLOWED only when the message is not already delivered, idempotency evidence exists, and retry budget is explicit. Blind retries create duplicate-notification risk.

Gate 9 — Make retention a field

retention_until_or_class records the local retention/erase rule. Keep vendor-specific retention scoped to that vendor boundary.

Gate 10 — Missing decisive evidence fails closed

Unknown destination, missing required basis, unknown template version, unknown retention, or recipient mismatch should become HOLD/BLOCKED, not forced green.

Worked examples

1. Minimal shipment SMS → QUEUED

Purpose is SHIPMENT_STATUS; fields are reference fragment + normalized status + safe link; destination is masked; basis and template/redaction versions are present. No provider result exists yet, so state is QUEUED.

2. Provider accepted but no receipt → PROVIDER_ACCEPTED

Provider ID and acceptance timestamp exist, but delivery_event_at is empty. Evidence does not support DELIVERED.

3. Over-complete projection → BLOCKED, then repaired

The first projection includes full_address and internal_note although purpose does not require them. Remove them without functional loss; the repaired projection can proceed.

4. Transient failure with safe retry → RETRY_ALLOWED

The message is not delivered, failure is transient, an idempotency key exists, and retry budget remains. If a delivery receipt already existed, retry would be blocked.

5. Transfer SMS to email and push

Purpose and minimal business fields can remain stable, while channel-specific destination token, template, provider adapter, and delivery evidence are recomputed. Do not copy the SMS verdict.

Common failure modes

• Object dumping: copy the whole order/customer object into templates.
• Provider payload leakage: expose raw carrier/provider data to customer content or broad logs.
• Route-as-truth: confuse delivery destination with canonical identity truth.
• Consent shortcut: treat “customer placed an order” as consent for every message class.
• Accepted=Delivered: turn HTTP/provider acceptance into receipt.
• Versionless template: lose reconstruction of content/redaction rules.
• Infinite retry: resend after delivery or without idempotency.
• Vendor-rule generalization: copy one carrier's retention/terms to all providers.
• Copied transfer: reuse SMS evidence unchanged for email/push.

Alternatives and trade-offs

Full-object templating is quick but increases exposure and coupling. Purpose-specific projection adds design work while making ownership and privacy boundaries explicit.

Raw destination storage eases debugging but expands exposure. token/mask + controlled resolver usually creates a smaller audit surface.

Optimistic delivered makes dashboards look green but corrupts truth. Keeping PROVIDER_ACCEPTED separate may show more unknowns, but it is more accurate.

Aggressive retry can raise eventual-delivery probability while increasing duplicate risk. bounded retry + idempotency is safer.

Long retention helps historical debugging while increasing storage/privacy risk. retention classes should be purpose-driven and reviewable.

Experienced bridge: ten review questions

1. What exact message class and purpose apply?
2. How was the minimal field set justified?
3. Are full address/name/raw payload truly needed?
4. How is recipient routing authorized?
5. Is destination evidence masked/tokenized?
6. Which redaction/template versions were used?
7. Are provider acceptance and delivery receipt separated?
8. What bounds retry and idempotency?
9. Which authority defines retention class?
10. What must be recomputed on a new channel?

Guided and independent practice

Run the offline lab:

python -B lab/COM-035-LAB1/learner/run_checks.py

Inspect the baseline; repair over-collection by removing unnecessary PII; diagnose provider acceptance without delivery receipt; remove basis or template version; try a retry after delivery; then transfer the same purpose from SMS to email/push while recomputing routing/template/provider evidence.

Verification evidence

The evaluator must catch at least:

• unnecessary sensitive fields in the projection;
• raw destination or recipient mismatch;
• missing required basis;
• missing template/redaction version;
• DELIVERED without a delivery event;
• retry after delivery or without idempotency/budget;
• missing retention;
• transfer that copies channel-specific evidence from baseline.

The oracle is deterministic synthetic evidence only—no customer data, provider credential, or hidden model reasoning.

Assessment and transfer

The summative task has four moves: explain COM-035's boundary; complete the baseline contract; diagnose over-collection or accepted-without-delivery; then recompute the same purpose for another channel.

A strong answer shows which fields are necessary for purpose, what was removed without functional loss, how route/basis/template are evidenced, what evidence supports delivery state, and when HOLD/BLOCKED is required.

References and freshness

• EC-GDPR-PRINCIPLES — European Commission GDPR principles; rechecked 2026-09-14.
• EC-GDPR-OBLIGATIONS — data protection by design/default; rechecked 2026-09-14.
• DHL-UTAPI-PUSH — Unified Tracking Push tracking-data terms; rechecked 2026-09-14; vendor-specific.
• LOCAL_DESIGN_AUTHORITY — frozen COM-035 Bible for schema/states/gates.

This lesson is not legal advice. Legal/contractual sources establish FACT boundaries only; real lawful basis, retention class, and channel policy require appropriate contextual authority.