Checklist
MAP Evidence Checklist
What to check on a record of a MAP violation before relying on it — identity, price, policy version, coverage, standing, confirmation, integrity — and what to write down when you take your own screenshots.
Use this checklist before treating a MAP finding as proven, before sealing a package, and before sending any evidence outside the brand. Each item is a question a seller, a distributor, a marketplace or counsel can ask; a record that answers all of them is one you can hand to anyone.
The reasoning behind the items is in What Evidence Should You Capture for a MAP Violation?.
A. What the record must establish
Check that the record carries each of these, and that each is a value written at the time rather than looked up now.
| # | Item | What to look for |
|---|---|---|
| A1 | Seller identity | The marketplace's seller id, and the storefront name as it was at the moment of observation. A name alone is not identity. |
| A2 | The offer | Advertised price and currency exactly as reported; condition; fulfillment channel; whether the offer held the Buy Box. |
| A3 | The instant | Date and time of the observation, in UTC. |
| A4 | Coverage | How much of the listing the scan read: sufficient, partial, insufficient. A partial read still establishes what it saw; it establishes nothing about what it did not. |
| A5 | The policy | The policy version with its effective date, the tolerance, the treatment rules (shipping, coupons, cart-only, out of stock), any promotion in force, and the resulting effective floor. |
| A6 | The seller's standing | Authorized, unauthorized or unknown as of capture — snapshotted, not re-read. |
| A7 | The decision | Who confirmed that the brand considers the price below its policy, and when. |
If A1, A5 or A7 is missing, the record is a screenshot with extra steps.
B. Before sealing
Sealing is permanent. Run these before a Brand Admin seals.
- The package is ready for review and its capture succeeded; a failed capture is retried, not sealed.
- The observation cited is the one you intend — the right instant, the right seller, the right listing.
- The seller's standing at capture is what you would say it was on that date.
- The policy version cited is the one that applied on the observation date, not the current one.
- Any promotion or exception in force on that date is reflected in the effective floor.
- You have read the manifest, not only the summary.
- The person sealing is a Brand Admin acting for the brand, with a fresh second factor — not a support engineer, not an analyst.
After sealing, the only correction is a new package that references this one. Take the minute.
C. Integrity, before relying on a sealed package
A sealed package proves it has not changed only if the checks are actually run.
- Verification passes: the manifest and every asset still hash to the sealed values.
- The sealing record shows the instant, the person and the hashing version.
- The stored object and the database record agree with each other, not only with the seal.
- Every sealed asset is still present, and no unsealed asset has appeared.
- The last verification is recent. Verification runs on every read in MapProtector; if your tool verifies on demand, run it now.
A failed verification is a first-class finding about the package, not something to be repaired. Do not rely on a package that has failed; supersede it.
The mechanics are on Hash verification.
D. Screenshots you take yourself
A person's screenshot is a reasonable illustration alongside a sealed record. Keep it honest:
- Taken by a person in a browser — not by automation that worked around the marketplace's access controls.
- Filed with the URL, the date and time (say the timezone), and who took it.
- Filed beside the sealed record for the same observation, not instead of it.
- Never edited — not cropped, not annotated on the original. Annotate a copy.
- Described accurately when shared: "a screenshot of the listing taken by our team on [date]", not "our monitoring evidence".
E. What to send to a third party
When evidence leaves the brand — to a seller, a distributor, a marketplace or counsel — send the sealed record, and describe it as what it is.
- The manifest, downloaded from the sealed package, with its SHA-256 fingerprint stated so the recipient can recompute it.
- The sealing details: sealed at, sealed by (role, not necessarily name), hashing version.
- An accurate description: a record derived from what the marketplace's API reported at the observed instant, judged against the policy version named in it. Not a screenshot.
- The seller's standing as of capture, and, if it has changed since, a note saying so.
- Nothing that is not in the record. A summary that adds a conclusion the record does not carry is a summary the recipient will test.
F. What the record should not contain
- Legal conclusions. The record says what was observed and how it was judged against a floor the brand configured. Whether that amounts to a breach of an agreement is the brand's statement, made elsewhere.
- Inferred authorization. "Unauthorized" in a record must be a classification the brand made, with a reason. An unknown seller is recorded as unknown.
- Re-read values. Anything read live at the time of viewing — a current storefront name, a current standing, a current floor — is not evidence of what was true on the observation date.
Quick version
Seven facts (A1–A7), sealed by an administrator, verified before use, described honestly, sent with its fingerprint. Screenshots illustrate; the record proves.