US MAP Retail Evidence

US retail catalog and minimum-advertised-price evidence processor for supplied Apify Dataset rows. It produces one deterministic report containing exact-ID evidence, MAP status, seller authorization, availability changes, absence assessments, and review actions that are explicitly not sent.

Quick start

Use exactly one source: inline rows or a buyer Dataset ID.

{
  "schemaVersion": "1.0",
  "requestId": "auto",
  "watchId": "lego-watch",
  "watchUniverse": ["tcin:16747749"],
  "rows": [
    {
      "adapter": "target",
      "sourceRecordId": "target-16747749",
      "sourceName": "target_probe",
      "observedAt": "2026-08-06T11:03:21.195Z",
      "data": {
        "tcin": "16747749",
        "upc": "673419233606",
        "productTitle": "LEGO Classic Large Creative Brick Box",
        "brand": "LEGO",
        "price": null,
        "availability": null,
        "url": "https://www.target.com/p/example/-/A-16747749"
      },
      "mapCents": 2999
    }
  ],
  "options": {"maxItems": 100, "explanation": "off", "analysisModel": null}
}

This example keeps Target's null price and availability as null. For a canonical row use adapter: "canonical_rows", one exact identity field, and the same source metadata. The native mappings are grounded in the committed probe fixtures for Google Shopping, Amazon, Walmart product detail, and Target. Only a public USD integer-cent base price can produce below_map; restricted, member, coupon, non-USD, fractional-cent, and conflicting-variant prices stay indeterminate.

requestId: "auto" is a task-safe sentinel. On Apify it resolves before input validation to the trusted actorRunId, so each Actor run has its own delivery idempotency scope while a replay of that same run never charges twice. Explicit non-auto IDs keep their existing idempotency behavior. A remote run fails closed if Apify cannot provide actorRunId; the deterministic fallback exists only in test mode.

Output and semantics

One useful run writes exactly one report Dataset item with pushData(report, "result-found"). Empty, invalid, all-unavailable, or insufficient input writes only OUTPUT. The terminal statuses are complete, complete_empty, partial_pagination, partial_budget, source_unavailable, delivery_unknown, bootstrap_required, and bootstrap_retry. The two bootstrap statuses and complete_empty are free: a new watch creates and verifies one persistent RequestQueue seed, then asks the caller to retry the same input after bootstrap.retryAfterMs. Bootstrap never reads evidence, writes a report or baseline, or emits result-found. For a closed Dataset with expectedItems: 0, complete_empty truthfully marks every configured identity absent, writes only OUTPUT plus a free baseline snapshot, and emits no result-found event. Partial or unavailable runs do not advance the watch baseline. A complete run advances it only after the result counter confirms exactly one charge and the delivery receipt is persisted. watchUniverse is the configured exact-ID universe, not the current observed set, so deletions compare correctly. Dataset input additionally requires

datasetCoverage: {"closed": true, "expectedItems": N}

delivery_unknown means the delivery side effect may have happened but cannot be proven from the durable receipt and exact counter delta. It is distinct from source_unavailable, never confirms payment, and is never retried automatically. If the persistent RequestQueue lock cannot be released after delivery, the confirmed receipt and counters remain truthful but OUTPUT is downgraded to delivery_unknown and the Actor fails with a nonzero process state instead of exiting as a clean success, even if the failure hook is unavailable. There is no live source discovery: supplied URLs are never requested. There are no nested Actor calls, browser sessions, proxies, or fuzzy product joins. Review actions carry review_required: true and not_sent: true; this Actor never sends them.

Pricing

The default Dataset item event is absent. maxTotalChargeUsd is checked before the paid write. Optional explanation mode is caller-funded BYOK and does not change deterministic facts or billing.

API and MCP

The standard Apify Actor API accepts the JSON input above. The package metadata is MCP-compatible, but this package does not claim a separate MCP server, remote tool registration, or payment endpoint.

curl -sS -X POST \
  'https://api.apify.com/v2/acts/zinin~us-map-retail-evidence/runs?waitForFinish=60' \
  -H 'Authorization: Bearer YOUR_APIFY_TOKEN' \
  -H 'Content-Type: application/json' \
  --data @input.json

Related Actors

These are links for workflow composition only. This Actor never calls them.

SEO

Canonical title: US MAP Retail Evidence | Deterministic Retail MAP Monitoring.

Meta description:

Process supplied US retail catalog evidence into exact-ID MAP, availability, baseline, and review findings without browsing or nested Actor calls.

Keywords: US MAP monitoring, minimum advertised price evidence,

retail catalog evidence

What you get

The Actor turns a bounded snapshot that you supply into one review-ready retail evidence report. It is designed for teams that already have permission to use their catalog, marketplace, retailer, or monitoring exports and need a deterministic way to normalize them. It does not visit retailer pages, discover offers, log into seller portals, or send enforcement messages.

A useful report contains:

• exact product identity using one accepted productId, upc, asin, usItemId, or tcin key;
• normalized source, observation time, product, seller, price, availability, restriction, and currency evidence;
• a MAP assessment that distinguishes below_map, at_or_above_map, and indeterminate instead of treating unknown facts as zero;
• seller-authorization evidence based only on the exact IDs or normalized domains supplied in the row;
• availability changes against a watch-scoped persistent baseline;
• deletion-safe absence assessments against the explicit watchUniverse;
• a list of rejected or incomplete evidence rows and their closed reasons;
• unsent review actions with stable action IDs;
• a decision boundary with outcome, confidence, gaps, a human-review action, and safeToAutomate: false;
• source coverage, processing counts, bounded limits, optional explanation status, and prepared billing intent;
• one current-run KVS OUTPUT record that reconciles the terminal status, Dataset write, named result event, baseline advance, and recovery state.

The paid unit is one delivered aggregated evidence report, not one product, one seller, one finding, or one review action. Up to 100 supplied rows can therefore be represented in one result. A closed empty Dataset snapshot is free and may advance the baseline to record confirmed absences. Invalid, bootstrap, lock, pricing, and source-unavailable outcomes do not intentionally emit the paid result-found event.

The Dataset row is evidence, not a legal or business decision. Its billing object describes the prepared event and is not the settlement receipt. Read the current run's KVS OUTPUT.delivery object and the platform event counters for settlement. Review actions are always unsent. A human remains responsible for policy interpretation, retailer context, contractual scope, evidence quality, and any downstream communication.

Who uses it

Brand protection and channel teams

Use the report to triage supplied offer observations by exact product identity, price relationship, seller authorization, and availability movement. The Actor can organize an evidence queue; it does not decide that a seller violated a contract and does not contact the seller.

Retail operations teams

Use the availability and baseline sections to compare a declared product universe across complete snapshots. A missing record is called absent only when the input proves closed coverage. Partial snapshots produce unknown absence assessments instead of false deletions.

Marketplace governance teams

Use normalized seller IDs and domains as supplied evidence for manual review. The Actor does not resolve corporate identity, beneficial ownership, account control, authorized-reseller agreements, or marketplace enforcement status.

Data engineering teams

Use the closed input, Dataset, and OUTPUT contracts to normalize exports from internal pipelines. Stable digests, exact counters, bounded payloads, and a named baseline make the result suitable for regression tests and controlled workflow routing.

Compliance, legal, and assurance reviewers

Use the evidence ledger to understand what was supplied, what was accepted, what was rejected, and why the Actor requested review. Do not treat below_map, not_authorized, or no_exception_detected as legal conclusions. MAP policy, antitrust rules, reseller agreements, consumer law, and evidence retention remain outside the Actor's decision scope.

Automation builders

Use Dataset for evidence display and KVS OUTPUT for terminal routing. Only route into a human queue. Do not connect a positive finding directly to account suspension, takedown, price intervention, seller outreach, or another material decision. decision.safeToAutomate is always false by contract.

How to run

Choose exactly one source mode:

1. rows for one to 100 inline buyer-supplied records; or
2. datasetId plus datasetCoverage for one bounded first-page Dataset read.

Before the first run, define a stable watchId and the exact watchUniverse. The universe is not inferred from the rows observed today. It must contain every identity whose disappearance you want to assess. Changing the universe, Actor binding, adapter version, or query scope makes the old baseline noncomparable rather than silently changing history.

For a new watch, the first request creates and verifies one persistent RequestQueue seed and returns bootstrap_required or bootstrap_retry without reading evidence or charging a result. Wait for bootstrap.retryAfterMs, then submit the same input once. That second run can acquire the verified watch lease and process the snapshot. Do not submit concurrent runs for the same watch.

Recommended sequence:

1. validate the JSON against the public Input schema;
2. verify that each row is authorized for your use and does not contain secrets;
3. set a charge cap that covers the automatic start event and one report event at your current Apify tier;
4. start one run and retain its run ID;
5. if bootstrap is requested, wait the declared interval and make one retry;
6. poll that run to a terminal platform state;
7. read KVS OUTPUT before consuming the Dataset;
8. verify the run ID, request digest, terminal status, delivery counters, and baseline state;
9. route complete evidence to human review;
10. preserve and manually reconcile any delivery_unknown state without a blind retry.

Inline API call:

curl -X POST \
  'https://api.apify.com/v2/acts/zinin~us-map-retail-evidence/runs?token=YOUR_APIFY_TOKEN' \
  -H 'content-type: application/json' \
  --data-binary @input.json

Dataset mode is appropriate only when the selected Dataset is a closed bounded snapshot. Set datasetCoverage.closed=true and set expectedItems to the exact number returned by the bounded read. If the Dataset is still being written, is larger than the supported page, or lacks a known terminal count, do not claim closed coverage. Use a controlled export or split it into separately reviewed watch scopes.

The optional OpenRouter explanation is one caller-funded BYOK request after the deterministic report has been built. It cannot change evidence, findings, MAP status, baseline comparability, delivery, or billing. Keep it off unless your organization has approved the provider, model, data-processing terms, retention settings, and disclosure of the summarized finding payload.

Input contract

The public UI schema is contract/input.schema.json projected into .actor/input_schema.json. Runtime validation remains authoritative for cross-field and semantic checks.

Root identity

• schemaVersion is exactly 1.0.
• requestId is auto or a bounded caller-defined idempotency key.
• watchId is a stable baseline identity, not a product, seller, or user ID.
• watchUniverse contains one to 100 exact typed identity keys.
• unknown root fields fail closed.

On Apify, requestId: "auto" resolves to the trusted platform Actor run ID. The fallback ID is available only in explicit local tests. A hosted run without a valid platform run identity fails before any paid push. An explicit request ID changes the idempotency scope and should be used only when the caller owns a reliable replay protocol.

Exact product identity

Each universe value starts with one of productId:, upc:, asin:, usItemId:, or tcin:. A normalized row must resolve to one exact identity. Conflicting product facts, composite identity disagreement, duplicated identity with different product facts, or an observed identity outside the declared universe fails closed before paid delivery.

Identity is syntactic and evidence-based. The Actor does not query a retailer, GS1, Amazon, Walmart, Target, a brand registry, or another authority to verify that the submitted identifier belongs to the submitted product.

Inline rows

rows accepts one to 100 objects. Native adapters are google_shopping, amazon, walmart_product_detail, and target; a canonical_rows adapter accepts already normalized evidence. Every accepted row carries source record ID, source name, observed time, adapter-specific data, and optional MAP and authorization controls.

The native adapter names describe the shape of a buyer-supplied export. They do not mean that the Actor contacts those services. Supplied URLs are recorded as evidence strings and never fetched. A URL is not proof of ownership, availability, current price, authorization, or public reuse rights.

Dataset mode

datasetId is read-only and mutually exclusive with rows. datasetCoverage is mandatory in this mode. The bounded read must match expectedItems, and closed must be true before a complete absence assessment is possible. An over-cap Dataset becomes partial_pagination; incomplete coverage never advances a comparable baseline.

MAP and currency

mapCents and accepted base prices are integer cents. Fractional cents are rejected, not rounded. Only an unrestricted public USD base price can produce a deterministic below/at-or-above comparison. Coupon, member-only, variant, shipping-dependent, restricted, non-USD, conflicting, or missing prices remain indeterminate with a reason.

The comparison is arithmetic only. The Actor does not establish that a MAP policy exists, applies to a seller, is lawful, was communicated, remains in force, or may be enforced. Treat the result as a review signal.

Seller authorization

Authorization is checked only against exact submitted seller IDs or normalized domains in the row policy. Similar names, near-match domains, display names, redirects, marketplace badges, and external identity assumptions do not count. not_authorized means no exact submitted match was found; it is not a finding that a seller lacks contractual authority in the real world.

Options and BYOK

options.maxItems is bounded from one to 100. explanation is off or byok. BYOK requires a secret OpenRouter key and a bounded model identifier. The key is excluded from request digests and report content, but Apify stores run input according to workspace retention settings. The Actor cannot truthfully promise that the platform never stores the secret input. Use workspace secret controls and delete retained run input under your own policy.

Happy, partial, and failure output

Complete evidence report

A useful complete run writes one Dataset report and attempts one named result-found event. KVS OUTPUT records the authoritative terminal delivery state. A confirmed paid operation has one attempted push, one confirmed Dataset write, one confirmed result event, one confirmed charge, counter delta one, and zero unknown operations. The baseline advances only after the receipt is persisted and the watch lease is still owned.

The report's decision is intentionally conservative. review_required means at least one finding or review action needs attention. no_exception_detected means no exception was found in the accepted submitted evidence; it does not prove compliance or completeness outside that snapshot. insufficient_evidence means source coverage or accepted evidence is inadequate.

Complete empty snapshot

A closed Dataset with exact expectedItems: 0 returns complete_empty, writes no paid report, and can advance the baseline to mark declared universe entries absent. This is safe only because the buyer explicitly attests that the bounded Dataset is the complete snapshot. Inline input cannot use an empty list.

Partial pagination

If the bounded Dataset exceeds the accepted limit or otherwise cannot prove a closed read, the result is partial. Present evidence can still be normalized, but missing universe entries remain unknown and the baseline does not advance.

Partial budget

If the current run cap cannot cover one result event after the platform start event, the Actor stops before paid delivery. This is a budget state, not a data quality verdict. The automatic start event may still apply. Review the live pricing panel and your current account tier before changing the cap.

Source unavailable or invalid input

Malformed, conflicting, out-of-universe, unsupported, or unavailable evidence fails closed. The Actor writes a bounded terminal record when storage remains available and emits no intentional result event. Fix the source data rather than coercing the rejected value.

Bootstrap and watch busy

bootstrap_required and bootstrap_retry are free control states for a new watch. A concurrent owner produces a lock-related free terminal instead of running the same watch twice. The lock is persistent and cross-process; it is not a process-local mutex.

Delivery unknown

A thrown linked push, unreadable counter, invalid counter delta, receipt-write failure, lost watch lease, baseline-write failure after delivery, or lock-release failure can require reconciliation. The runtime does not retry the paid push. Preserve the run, KVS, Dataset, logs, receipt key, and platform event counters. Do not infer that an ambiguous operation was free, and do not start another run until the original operation is reconciled.

Field dictionary

Evidence item

Each evidence item has a stable evidenceId, adapter, source record metadata, observed timestamp, exact identity, product fields, integer-cent price or null, availability or null, seller facts, authorization comparison, MAP assessment, acceptance flag, and rejection code. Null means unknown or not applicable under the closed contract. It never means zero price, out of stock, authorized, or no restriction unless another field says so explicitly.

Decision object

decisionType is retail_evidence_review. outcome is one of review_required, no_exception_detected, or insufficient_evidence. confidence is high_in_submitted_evidence only when the supplied coverage is complete and adapters produced no errors; otherwise it is limited. safeToAutomate is always false, action is always human_review, and gaps always includes the buyer-fact and human-policy boundaries.

Billing and delivery

The Dataset report is prepared before the linked event settles, so it cannot truthfully contain the final receipt. The billing object therefore remains a settlement-neutral event description. KVS OUTPUT.delivery reports attempted pushes, confirmed Dataset writes, confirmed named events, confirmed charges, unknown operations, exact counter delta, receipt ID, and reconciliation state.

Evidence and boundaries

What is evidence

Evidence is the normalized representation of facts the buyer submitted. Stable digests bind the accepted object to the run and baseline scope. Adapter rules, integer-cent arithmetic, exact identifiers, source coverage, and counter deltas are deterministic and testable.

What is not verified

The Actor does not verify retailer HTML, live price, stock, product ownership, seller identity, authorization agreements, MAP-policy validity, communication of a policy, legal enforceability, source licensing, timestamp authenticity, or whether a submitted URL is still reachable. Optional explanation does not add verification.

No source fetching

Runtime has no retailer HTTP client, browser, proxy, crawling loop, search API, or nested Actor call. Inline values and the selected buyer Dataset are the only evidence inputs. This avoids pretending that a URL is permission or that a page snapshot is complete.

Baseline scope

The named KVS stores one actor-bound baseline record per watch. The persistent RequestQueue provides a watch-specific lease. The baseline contains normalized evidence snapshots and comparability metadata, not raw source pages. A change in Actor identity, Actor version, adapter version, query scope, entity universe, or seller/restriction policy prevents an unsafe comparison.

Privacy

Product and seller identifiers can be commercially sensitive and may become personal data if a seller ID or URL is linkable to an individual. Submit the minimum fields needed for the review purpose. Do not submit customer data, consumer behavior, employee records, emails, phone numbers, home addresses, credentials, access tokens, private contract text, or sensitive inferences.

SHA-256 digests are not anonymization. The run Input, Dataset, KVS, logs, and optional provider request are governed by your Apify workspace and provider retention settings. Establish a lawful purpose, access controls, retention period, deletion process, correction route, and incident response before using the Actor with production evidence.

Rights

You must own or be authorized to process and transform every submitted row and Dataset. A public URL, marketplace listing, API response, export, or internal file does not by itself grant commercial redistribution rights. Keep licences, contracts, source terms, and attribution obligations outside the Actor and make them available to reviewers.

Decision routing

Use the decision fields as a conservative queue selector:

• review_required: preserve the evidence and send it to a qualified human;
• no_exception_detected: retain as a bounded observation, not proof that no issue exists outside the submitted snapshot;
• insufficient_evidence: repair coverage or source quality before drawing a conclusion;
• delivery_unknown: stop automation and reconcile storage and billing first;
• partial_budget: review the cap and live pricing before a new run;
• bootstrap_required or bootstrap_retry: wait the bounded interval and retry the same watch once;
• lock, receipt, or baseline errors: preserve the run and do not create a concurrent replacement.

Suggested workflow gates:

1. platform run is terminal;
2. current-run KVS OUTPUT exists and validates;
3. request and watch IDs match the submitted scope;
4. delivery is confirmed or explicitly free;
5. source coverage is complete for any absence interpretation;
6. decision is not insufficient_evidence;
7. reviewer checks evidence, rights, policy, and context;
8. any external action is made in a separate approved system with its own authorization, audit trail, and appeal/correction process.

Never route directly from below_map, seller_authorization_unconfirmed, or an availability change to seller punishment, marketplace suspension, price coordination, legal notice, or customer representation.

Commercial playbooks

Catalog QA playbook

Supply a closed internal catalog export, exact watch universe, and expected seller policy. Review rejected identity, currency, price, and variant rows. Measure the reduction in manual normalization effort, not the number of alleged violations.

Channel review playbook

Supply authorized marketplace observations gathered by your own licensed pipeline. Route review_required reports to channel analysts. Record the human disposition separately; do not mutate Actor evidence to fit the disposition.

Availability-change playbook

Run stable closed snapshots under the same watch scope. Review present-to-absent and availability changes only when baseline comparability is true. If source coverage becomes partial, treat disappearance as unknown.

Seller-policy audit playbook

Use exact seller IDs or domains from an approved internal policy table. A policy binding change deliberately makes the comparison noncomparable and produces an unsent review action. Confirm the changed policy before resuming the watch.

Pipeline acceptance playbook

Use synthetic or non-sensitive rows to validate adapter mapping, exact-ID conflict handling, price restriction rules, Dataset/KVS reconciliation, and the free bootstrap path. Keep production evidence out of development workspaces.

Integration recipes

Webhook router

Trigger a webhook after the Apify run reaches a terminal state. Fetch KVS OUTPUT, validate status and delivery, then store a reference to the Dataset report. Send only a minimal review notification; do not copy full evidence into chat or email by default.

Warehouse load

Load one report per run into a report table and explode evidence/findings into child tables keyed by request digest and evidence ID. Keep the baseline record in the Actor's named KVS; do not reconstruct it from an incomplete warehouse load. Store delivery state and run ID beside every imported report.

Ticketing queue

Create a ticket only after a human-routing gate passes. Include the evidence ID, finding type, submitted source reference, decision gaps, and current-run link. Keep not_sent=true in the source report; the downstream ticket system owns its own sent state.

n8n, Make, or custom orchestration

Use one step to start the Actor, one to poll the exact run, one to read KVS OUTPUT, one to validate the result, and one to create a human-review item. Do not poll by starting additional runs. Do not treat a missing Dataset row as a free result until KVS and platform counters are reconciled.

Optional explanation

When BYOK is approved, send only the bounded deterministic finding summary. The provider response belongs in the explanation object and must never overwrite evidence, MAP status, authorization, baseline, decision, or billing fields. A provider failure leaves deterministic output intact.

Operating guide

Before production

• confirm rights to every source export and downstream use;
• define the exact watch universe and stable watch ID;
• document MAP and seller-policy ownership outside the Actor;
• test with synthetic data and review every null/rejection branch;
• set Apify Input/KVS/Dataset access controls and retention;
• approve or disable OpenRouter BYOK;
• verify current tier prices and set a bounded run cap;
• assign a named human reviewer and correction path.

During a run

• keep one active run per watch;
• retain the returned run ID;
• do not change the universe or policy binding mid-run;
• allow the bounded RequestQueue lease and heartbeat to finish;
• do not infer success from logs or Dataset appearance alone.

After a run

• read platform status and current-run KVS OUTPUT;
• verify request ID, request digest, delivery state, and baseline state;
• compare Dataset length with the expected one-report unit;
• inspect source coverage, accepted/rejected counts, gaps, and errors;
• route only to human review;
• retain or delete evidence under your approved schedule.

Incident handling

For delivery_unknown, receipt failure, baseline failure, lock loss, or output write failure, freeze automation. Preserve the run ID, build ID, Dataset ID, KVS ID, logs, named-event counters, request digest, watch ID, and receipt key. Reconcile the first operation before deciding whether a new run is safe. Never use a blind retry to make an ambiguous status disappear.

Version and baseline changes

An Actor-version change makes baseline comparison noncomparable by design. Plan the migration, keep the old report and baseline receipt, start the new version, and review the first comparable snapshot under the new binding. Do not manually edit persistent baseline records.

FAQ

Does the Actor scrape retailers?

No. It processes inline rows or one buyer-selected Dataset. Recorded source URLs are never requested.

Does it prove a MAP violation?

No. It performs a deterministic arithmetic and evidence classification under submitted policy facts. Legal, contractual, commercial, and contextual review remains human.

Why is safeToAutomate always false?

Because supplied observations, seller policy, source rights, MAP applicability, and downstream consequences require review outside this deterministic processor.

Why do I need watchUniverse?

A closed universe is necessary to distinguish a true complete-snapshot absence from a product that simply was not included in today's input.

Why does the first watch run ask me to retry?

The persistent RequestQueue seed must be created and observed as stable before it can serve as the atomic watch lease. Bootstrap performs no evidence work and no result charge.

Can two workers run the same watch?

They may attempt to start, but only one can own the persistent watch lease. The other receives a free lock state. Do not intentionally schedule overlap.

Is a Dataset row proof that I paid?

No. It is the report prepared for a linked push. KVS OUTPUT.delivery and the platform named-event counters are the current-run settlement authority.

What does delivery_unknown mean?

The run cannot safely prove the full delivery/charge/baseline state. Preserve the evidence and reconcile manually. Do not retry automatically.

Can a partial snapshot mark a product absent?

No. Missing identities stay unknown unless coverage is closed and comparable.

Can I use floating-point dollar prices?

The normalized comparison uses integer cents. Fractional cents, non-USD values, and restricted variants fail closed or remain indeterminate rather than being rounded into a finding.

Does not_authorized identify an unauthorized seller?

It means only that the supplied seller ID/domain did not exactly match the submitted policy list. It is a review signal, not external identity proof.

Does optional AI change the decision?

No. It can produce one bounded explanation. Evidence, findings, baseline, decision, delivery, and billing remain deterministic.

Is the API key never stored?

The Actor excludes it from digests and output, but the Apify platform may retain run Input according to workspace settings. Use secret controls and your own retention/deletion policy.

What is the paid unit?

One complete delivered aggregated report, regardless of the number of accepted rows up to the bounded limit. The automatic start event is separate.

Can I automatically send notices from review actions?

No. Every action is marked review-required, not-sent, and sent-false. Use a separate approved human workflow if communication is appropriate.

Sources and rights

The runtime uses no live retailer, marketplace, catalog, identity, pricing, or policy source. It makes zero retailer HTTP requests and no nested Actor calls. The adapter fixtures and contracts describe accepted buyer-supplied shapes; they are not a licence to collect or redistribute data from the named platforms.

You are responsible for ensuring that every submitted row and Dataset is:

• collected through a permitted method;
• used for an authorized business purpose;
• licensed for transformation, storage, and downstream review;
• limited to necessary fields;
• accurate enough for the stated purpose;
• retained and deleted under an approved policy;
• accessible only to appropriate people and systems;
• corrected or removed when a valid request requires it.

Retailer and marketplace names are used only to identify input adapter shapes. No endorsement, partnership, official data access, live verification, or authorization is claimed. URLs are supplied references and are not fetched.

MAP rules and seller restrictions can raise competition, contract, consumer, and marketplace-policy questions. This Actor does not provide legal advice and does not recommend coordinated pricing, resale-price maintenance, seller punishment, account suspension, or enforcement. Use qualified counsel and a documented human review process for any material action.

For the optional OpenRouter path, the buyer is responsible for provider terms, model terms, data-processing terms, retention, regional transfer, security, and downstream disclosure. Keep explanation mode off when those controls are not approved. The deterministic product remains fully functional without it.

The correct product claim is narrow: the Actor deterministically normalizes and compares buyer-authorized retail evidence, preserves explicit uncertainty, reconciles one report delivery, and prepares unsent human-review actions. It does not fetch, verify, decide, enforce, communicate, or guarantee compliance.