MAP Enforcement Workflow Guide

This guide is a reference for a MAP program that has moved past monitoring and is deciding how notices get written, approved and sent. It is organized as a runbook: the decisions to make before the first notice, the roles, the stages in order, the checks at each one, and the records that should exist afterwards. It describes the workflow MapProtector implements, and it is written so that a program running on other tooling can use the same structure.

Read it with the shorter How to Build a MAP Enforcement Workflow, which explains why each control exists.

Part 1 — Decisions before the first notice

Five decisions, made once, that shape everything after.

Who may approve. A notice reaches a third party with the brand's name on it. The person who authorizes that should be the person accountable for the brand's compliance posture — an administrator, not an analyst — and the authorization should require a fresh second factor. Decide whether approve and send are the same person or two, and record it.

What the words are. Write the templates for each stage of escalation before any case reaches them. Have them reviewed against the brand's own legal and compliance policy. Example wording supplied by a tool is an example, and says so; it is not the brand's statement until the brand has made it so.

From whose address. Notices should leave from a sender identity the brand owns and has verified through its mail provider, with a reply-to a person reads. Never from the monitoring vendor's domain.

How many stages, and how long between them. Three is a convention, not a rule. Decide the sequence the program actually intends — a first notice, an escalation, a final notice — the minimum wait after each send, and whether each later stage needs fresh evidence or fresh approval. Ten stages is a practical ceiling; more than that is a different problem.

When enforcement is off. Decide the situations in which the program measures but does not enforce — a distributor in negotiation, a product under review, a partner disputing a notice — and configure them as exceptions with reasons and end dates, so the queue reflects the decision rather than depending on a reviewer's memory.

Part 2 — Roles

The separations are deliberate. Preparing a document and authorizing its release are two acts, and a gate one person can both open and walk through is not a gate. A vendor support session should be able to do none of the consequential acts: the decision to contact a seller belongs to the customer.

Part 3 — The stages

Stage 0: a confirmed finding

Enforcement starts from a confirmed candidate — a below-floor observation a person has looked at and recorded as below the brand's policy — and the case it opened. Nothing in the enforcement workflow may start from an observation directly. If a system can produce a notice without this step, fix that first.

Stage 1: prove

Request an evidence package for the breach period. The package is assembled from the observation, the evaluation, the policy version and the confirmation, with the seller's standing and the product title snapshotted at capture. Read it. Verify its integrity if you wish. Seal it — a Brand Admin, with a fresh second factor. Only a sealed package can carry a notice.

Record: package id, sealed at, sealed by, fingerprint.

Stage 2: prepare

From the case, a Compliance Manager chooses to act. This starts the brand's default escalation sequence for the current breach period and drafts its next stage: the template rendered with the seller, product, prices, policy and references, frozen as a snapshot and hashed. The draft goes to the review inbox. Nothing is sent.

Record: notice id, stage, template version, snapshot hash.

Stage 3: gate

Before approval, every blocker is evaluated and the whole list is shown. The conditions, grouped:

A notice with any blocker cannot be approved. The gate runs again at approval and again on the send path.

Record: each gate result with its instant. In MapProtector the notice page shows the current result and the timeline keeps the history.

Stage 4: review

The approver reads the notice as the seller will receive it — subject and body from the frozen snapshot — and the facts it was built from: seller and standing, product, observed price, floor, gap, observation date and coverage, policy version, the sealed package. Checks worth making explicit:

• The seller's standing is what the brand currently believes. A partner authorized since the finding is a call, not a notice.
• The cited observation is recent and well covered.
• The stage is the right one — a second notice to a seller who never received the first is the classic mistake.
• The policy version is current; the interlock will say if not.

Stage 5: approve

A Brand Admin approves with a fresh second factor and an explicit attestation. The approval is a signature over the snapshot hash. It lapses if any of these change before sending: the document, the policy version, the recipient, the evidence, the case (cured or period closed), the sender, or a hold placed. A lapsed approval returns the notice to review with the reason; it does not cancel it.

Record: approver, instant, snapshot hash, notes.

Stage 6: send

A Brand Admin queues or sends, with a fresh second factor, as a second act at a second instant. The send path, in order: claim the notice; re-run the gate; re-validate the approval against current state; re-check the recipient against the suppression list; open a delivery record with a unique key; call the provider. One approved notice sends once.

Delivery states: sent (provider accepted), delivered (recipient's server accepted, per provider callback), failed (refused or bounced), delivery unknown (no answer in time — never retried automatically; resolved by a person against the provider's records).

Record: delivery attempt, provider message id, state transitions with instants.

Stage 7: verify

Monitoring continues on its schedule. The period closes as cured only on enough fresh, sufficiently covered observations at or above the floor — never on silence, a hidden price, a disappearance or a reply. A reply is recorded as what the seller said, pauses the sequence for a person to read, and changes nothing else. A relapse opens a new period on the same case; whether it restarts the sequence is a person's decision.

Record: cure with the observations that established it, or the reason the period remains open.

Part 4 — Holds

A hold stops every notice in its scope — one notice, a case, a seller, or the whole brand — for a recorded reason: a dispute, a data-quality doubt, a legal review. It is not a cancellation; when lifted, the workflow resumes where it stopped, and any approval given before the hold has lapsed and must be renewed. Placing and lifting are both attributed.

Use a hold when the question is "should we be sending to this seller at all right now". Use an exception when the answer is "not for the foreseeable future, and we know why".

Part 5 — What to keep

At the end of a period, the record should let a reader reconstruct, without asking anyone:

1. what was observed, when, with what coverage, against which policy version;
2. who confirmed it and when;
3. the sealed package and its fingerprint;
4. each notice — template version, snapshot, gate results, approver, sender, delivery outcomes;
5. each response, as recorded;
6. how the period ended, and on what evidence.

A program that can produce that list for any case is a program whose enforcement will survive being questioned. The MAP Evidence Checklist covers item 3 in detail; the documentation covers how each step appears in MapProtector.