Start here

Understand the system before changing it.

Product Resolver is a proposed way to decide when two merchant listings are the same exact product, and when the evidence is too weak to say so. This guide explains the design. It is not the workbench, and it is not an approval.

Follow one product

The problem

Someone comparing offers needs a stable answer: this page and that page sell the same configuration, or they do not, or we cannot tell yet. A title match is not that answer. A listing URL is not a product. A model suggestion is not a decision. Stock that was true yesterday is not stock now.

The people who feel this are buyers of the comparison, operators who have to correct a bad match, and engineers who later have to explain why a public page changed.

What the design is for

  • Keep the original page, the time it was seen, and the bytes.
  • Separate the exact product from each merchant’s offer.
  • Make a correction traceable to a decision and to evidence.
  • Show the public only what an authorized release has applied.
  • Stay inside a confirmed service budget of USD 50 a month.

Scope of this guide

Use it two ways. Read Purpose and capabilities and then Follow one product for the short path. Use the later chapters, the Glossary, and the Local reference when you need the contracts, decision records, and plan.

The guide does not choose open architecture questions for Jonathan. Where the workbench says proposed, open, or unverified, this guide says the same thing.

Limits you should keep in view

  • Only the USD 50 recurring-service ceiling is confirmed. Workload, providers, thresholds, and launch shape are proposals.
  • No production collector, database, queue, or model call is running because of this package.
  • Real PostgreSQL concurrency, identity-provider cryptography, source access, invoices, and rendered browser layout were not established by the workbench simulations.
  • Pantry & Pour is a fictional fixture for deterministic behavior. It is not evidence that a real source can be collected.

Before the reading path

Stakeholder brief is one page for the problem, the people, the confirmed ceiling, and what is still open. Read it before the numbered path.

Reading path

  1. 01Purpose and capabilities — the problem, the outcomes, and what is in or out.
  2. 02Follow one product — one fictional capture from page to reader.
  3. 03Services and boundaries — who owns what, and where the handoff is.
  4. 04Interfaces and trust — connections, credentials, and delivery behavior.
  5. 05Data and vocabulary — identity, offers, shipping, and time.
  6. 06Operations and improvement — money, retries, replay, and recovery.
  7. 07Implementation roadmap — proposed milestones and the gates in front of them.

The Glossary defines a term in plain language and in system language. Press / there to search.

Everything in this package