Commerce Recommendations

This context describes a recommendation product that operates across independent online stores and marketplaces while leaving catalog management, commerce operations, and recommendation presentation to external systems.

Language

Commerce Property: An independently operated online store or marketplace whose catalog and interaction data are used to produce recommendations. Avoid: Retailer, tenant, account

Catalog: The set of products or listings eligible to participate in recommendations for a Commerce Property.

Commerce Scope: The isolation boundary identified by one Relational Data Source, Tracking ID, and Catalog ID within which Items, evidence, Training Runs, and Recommendation Sets have meaning. Avoid: Tenant ID, globally unique Tracking ID

Catalog ID: The source identifier stored in CATALOG_ID that selects the merchant Catalog used to resolve commerce records. Avoid: Commerce Property ID

Product ID: The source identifier stored in PRODUCT_ID for a product or listing within a Catalog. Avoid: Item ID, globally unique product ID

Item: A product or listing identified by its Relational Data Source, Tracking ID, Catalog ID, and Product ID that can anchor or appear in a Recommendation Set. Avoid: Product

Item Metadata: Descriptive and operational information supplied for an Item, including its category, brand, price, Recommendation Eligibility, and creation date, that can support cold-item relationships. Avoid: Product details

Recommendation Eligibility: The source's effective decision at a snapshot cutoff about whether an Item may anchor or appear in Recommendation Sets, incorporating availability and other merchandising constraints. Avoid: Availability, serving eligibility

Sparse Item: An Item with some interaction evidence as of the applicable evidence cutoff but too few qualifying shopping contexts to support a requested Recommendation Strategy confidently. Avoid: Cold Item

Strict Cold Item: An Item that has Item Metadata but no observed interactions as of the applicable evidence cutoff for its Commerce Property. Avoid: New product

Cold Commerce Property: A Commerce Property without enough interaction history to support behavioral Recommendation Strategies reliably. Avoid: New tenant

Interaction Dataset: The input history of shopper activity for a Commerce Property, including product views and purchases. Avoid: Events, behavior dump

Relational Data Source: A configured SQL-accessible database or warehouse from which a Training Run retrieves a Commerce Property's Catalog, Item Metadata, views, and purchases without assuming a particular database engine. Avoid: Database

Generated Relational Data Source: A reproducible synthetic realization of Relational Data Source semantics used to exercise Training Runs without importing production records. Different relational engines may materialize the same logical generated source. Avoid: Fixture database, synthetic database

Generation Manifest: The authoritative record of a Generated Relational Data Source's logical identity and lineage, including the information needed to reproduce and verify its contents. Avoid: Dataset manifest, Recommendation Provenance

Materialization Receipt: The evidence that a database-engine realization of a Generated Relational Data Source matches its Generation Manifest. Avoid: Load log

Oracle Manifest: The versioned set of expected observable outcomes associated with a Generated Relational Data Source. Avoid: Expected-results manifest

Deterministic Scenario: A named family of small Generated Relational Data Source variants that shares one behavioral purpose and a fixed source-to-serving oracle. Each variant fixes its source contents, configuration, time bounds, and prescribed observations. Avoid: Fixture, test dataset

Generation Profile: A named, versioned set of scale and distribution parameters used to produce a Generated Relational Data Source. Avoid: Dataset size, environment

Correctness Verification: Evidence that a service build satisfies every prescribed observation in the current Deterministic Scenario suite. It establishes behavior, not scale or qualification. Avoid: Test pass, qualification

Development Scale Confidence: Evidence that a service build processes the unmodified development Generation Profile through a verified DuckDB source while preserving its required structure, distributions, and bounded oracles. Avoid: Local qualification, capacity qualification

Qualification Claim: An evidence-bound assertion that a specific service build passed the unmodified qualification Generation Profile in the approved PostgreSQL environment. Avoid: Successful Training Run, benchmark result

Qualification Evidence Bundle: The immutable, checksummed collection of identities, manifests, receipts, observations, measurements, and diagnostics that supports or denies a Qualification Claim. Avoid: Qualification log, benchmark output

Synthetic Shopping Mission: A generated latent shopping intent that creates controlled relationships among Items in Browsing Sessions and Orders without representing a shopper or retaining shopper identity. Avoid: Synthetic shopper, persona

Commerce Simulation Harness: A local or test-environment system combining a browsable Simulation Storefront with a Synthetic Visitor Runner to exercise recommendation behavior using controlled commerce activity. Avoid: Fake traffic website, traffic generator

Simulation Storefront: A non-production commerce experience through which a person can browse a generated Catalog, request Recommendation Sets, and create controlled Browsing Sessions and Orders. Avoid: Demo shop, fake website

Synthetic Visitor Runner: An automated participant in the Commerce Simulation Harness that creates bounded, reproducible Browsing Sessions, Orders, and recommendation requests without representing or retaining a shopper identity. Avoid: Bot, synthetic shopper

Simulation Run: An isolated, resettable execution of the Commerce Simulation Harness identified by its scenario, seed, logical time bounds, safety limits, source state, and recorded results. Avoid: Traffic run, load-test run

Simulation Data Source: A mutable, run-isolated Relational Data Source owned by the Commerce Simulation Harness and read by the recommendation service through its normal Data Source Adapter. Avoid: Generated Relational Data Source, fixture database

Simulation Scenario: A versioned, fully resolved definition of the shopping missions, traffic controls, training checkpoints, logical time bounds, and safety limits governing a Simulation Run. Avoid: Traffic profile, load script

Independent-Behavior Scenario: A Simulation Run whose generated shopping behavior is unaffected by Recommendation Sets served during the run, preserving an independent basis for behavioral evaluation. Avoid: Control traffic, unbiased traffic

Recommendation-Feedback Scenario: A Simulation Run in which Synthetic Visitor Runner decisions may follow served Recommendation Sets, explicitly exposing the resulting feedback loop without treating it as independent evidence of recommendation quality. Avoid: Smart traffic, self-learning scenario

Tracking ID: The source-scoped value stored in a TRACKING_ID column to associate imported commerce records with a Commerce Property within a Relational Data Source. Avoid: Store ID, tenant ID, globally unique ID

Online Purchase: A purchase completed through a Commerce Property's online commerce channel. Online Purchases are the required purchase source for a Training Run.

Offline Purchase: A purchase completed through an in-store or other offline commerce channel and imported into the Relational Data Source. A merchandiser may provide Offline Purchases in addition to Online Purchases, but they are optional.

Purchase Channel: The online or offline origin of a purchase. Order identity is scoped by Purchase Channel so unrelated online and offline orders with the same source Order ID are not combined.

Data Source Adapter: The compatibility boundary that connects a Relational Data Source to the product's canonical Catalog and Interaction Dataset contracts. Avoid: Connector

Order: An externally identified purchase transaction that groups Items bought together within one Commerce Property. Avoid: Basket

Browsing Session: An externally identified visit that groups Item views made together within one Commerce Property. Avoid: User history

Shopper: An individual recognized by one Commerce Property across Browsing Sessions through a stable, pseudonymous identifier supplied by that Commerce Property. Avoid: User, account, globally identified person

Shopper History: The retention-bounded sequence of acknowledged commerce interactions attributed to one Shopper within one Commerce Property and Catalog. Avoid: Browsing Session, customer profile, raw event archive

Shopper Profile: A bounded, rebuildable projection of one Shopper History used for request-time personalization within the same Commerce Property and Catalog. Avoid: Customer record, source of truth, identity profile

Personalization Authorization: A purpose-specific assertion from a Commerce Property that permits personalization for one property-scoped Shopper under a named policy version and effective state. Avoid: Login, identity proof, blanket consent

Interaction Acknowledgement: The durable receipt for one ordered Shopper interaction, identifying its committed sequence and the Shopper Profile version it produced. Avoid: Event receipt, training acknowledgement

Causal Token: A short-lived, opaque capability derived from an Interaction Acknowledgement that lets a Shopper request require observation of at least the acknowledged Shopper Profile version. Avoid: Shopper ID, authentication token, session token

Personalized Recommendation: A Recommendation Set whose ordering reflects a Shopper's current and prior acknowledged interactions in addition to property-local recommendation evidence. Avoid: Item-to-Item Recommendation, targeted advertisement

Co-occurrence: An observed association between two Items because both appear within the same defined shopping context, such as an order or browsing session.

Item-to-Item Recommendation: A Recommendation Set anchored to one Item and derived from aggregate relationships between Items rather than the identity of an individual shopper. Avoid: Personalized recommendation

Recommendation Strategy: A distinct recommendation intent, such as Frequently Bought Together or Also Viewed, that produces relevant product relationships for a Commerce Property. Avoid: Swimlane, algorithm

Swimlane: A named, Commerce Scope-specific ordered sequence of Recommendation Strategy and Geographic Variation steps that accumulates distinct eligible Items toward a quota, with authorized browsing history as its final resort. Avoid: Recommendation Strategy, blended model

Geographic Variation: A Recommendation Strategy's evidence and results restricted to a source-local city, region, or country hierarchy within one Commerce Scope; the global variation covers that whole scope. Avoid: Global city ID, cross-property region

Recent-history Recommendation: A Recommendation Set derived from published co-view or co-purchase neighborhoods of an authorized Shopper's recent viewed or purchased Items, respectively. Avoid: Recently viewed Item list, retraining

For You: A global Recommendation Strategy that uses an authorized Shopper Profile with the latest Recommendation Snapshot. The default path boundedly reranks published global candidates; an opt-in embedded ANN path may discover eligible Items across that snapshot's Catalog. Avoid: Personalized model, cross-property discovery

Frequently Bought Together: An Item-to-Item Recommendation Strategy based on Items that co-occur in the same Order.

Also Viewed: An Item-to-Item Recommendation Strategy based on Items that co-occur in the same Browsing Session.

Similar Items: An Item-to-Item Recommendation Strategy based on shared Item Metadata and intended to surface substitutable or closely related Items.

Popular Viewed Same Category: An anchored Recommendation Strategy that ranks eligible Items in the anchor's known category by recent view popularity.

Popular Bought Same Category: An anchored Recommendation Strategy that ranks eligible Items in the anchor's known category by recent purchase popularity.

Frequent Bought Different Category: An anchored Recommendation Strategy based on same-Order co-purchase between Items in different known categories.

Frequent Viewed Same Category: An anchored Recommendation Strategy based on same-Browsing-Session co-view between Items in the same known category.

Frequent Viewed Different Category: An anchored Recommendation Strategy based on same-Browsing-Session co-view between Items in different known categories.

Best Sellers: A Recommendation Strategy that ranks Items using recent purchase popularity within a Commerce Property.

Most Viewed: A Recommendation Strategy that ranks Items using recent view popularity within a Commerce Property.

Trending: A Recommendation Strategy that identifies Items whose recent interaction momentum is elevated relative to a longer baseline within a Commerce Property. Avoid: Popular

Recommendation Set: The output of a Recommendation Strategy: products associated with a given product or shopping context and ordered for downstream use. Avoid: Swimlane

Fallback Strategy: A secondary method that produces a Recommendation Set when the requested Recommendation Strategy lacks sufficient Item-level evidence. Avoid: Default recommendations

Recommendation Provenance: The disclosed primary method or Fallback Strategy responsible for an Item's inclusion in a Recommendation Set. Avoid: Explanation

Training Data Drift: A material change between Training Runs in the bounded aggregate characteristics of a Commerce Property's Catalog or Interaction Dataset. Avoid: Shopper outcome drift, conversion drift

Recommendation Output Drift: A material change between Recommendation Snapshots in aggregate Recommendation Set characteristics such as coverage, provenance, fallback use, or concentration. Avoid: Shopper outcome drift, conversion drift

Training Evidence Schema: The versioned meaning, units, and compatibility contract of the durable aggregate measurements attached to a Training Run. Avoid: Telemetry schema, dashboard schema

Comparable Training Run: A prior successful Training Run for the same Commerce Scope whose model, configuration, and Training Evidence Schema versions match the run being assessed. Avoid: Previous run, failed run

Drift Assessment: A bounded comparison of one Training Run's aggregate evidence against recent Comparable Training Runs, with explicit status when history, sample size, version compatibility, or values are insufficient. Avoid: Model failure, shopper outcome measurement

Training Run: An API-triggered batch operation that reads one Commerce Property's Catalog and Interaction Dataset through a Data Source Adapter and produces a versioned Recommendation Snapshot. Avoid: Training job, model training

Recommendation Snapshot: The complete, versioned collection of Recommendation Sets produced by a successful Training Run and made available for serving. Avoid: Model, output file

Training API: The product interface used to request and inspect Training Runs for a Commerce Property. Avoid: Batch endpoint

Serving API: The product interface used by downstream systems to retrieve Recommendation Sets from an available Recommendation Snapshot. Avoid: Prediction API, inference API

Model Constraint Platform: A shared contract and governance boundary that evaluates product-defined constraints across model readiness, artifact qualification, allocation, and serving while preserving each constraint family's distinct enforcement semantics. Avoid: Service Limit System, universal limiter

Constraint Measurement: A typed, provenance-bearing and freshness-bounded observation produced by an ML product for evaluation against a Constraint Contract. Avoid: Raw product data, arbitrary policy input, metric label

Constraint Effect: The lifecycle-appropriate consequence declared by a Constraint Contract when its condition is not satisfied, such as warn, block, mark ineligible, defer, deny, degrade, or retry. Avoid: Exception, universal failure state

Model Serving Admission Control: A policy-enforcement system in front of Model Serving APIs that decides whether a request may consume serving capacity. It enforces hierarchical quotas, rate and concurrency limits, priorities, and cost or resource budgets; issues short-lived capacity permits for admitted work; and produces auditable limit decisions and usage telemetry. It may invoke explicitly declared queueing or fallback policies during overload, but does not own inference, recommendation logic, experimentation, or general model routing. Avoid: Service limit system, model orchestrator

Constraint Contract: A versioned, machine-readable agreement that defines a bounded condition applying to training or serving, the evidence used to evaluate it, the effect of a violation, and the Diagnostic Occurrence to expose. Training and serving may enforce different kinds of constraints while sharing this contract and its diagnostic vocabulary. Avoid: Exception class, error-message catalog, generic limiter rule

Model Capability Contract: An immutable, versioned Constraint Contract published with a model version that defines its supported training prerequisites and operating bounds, such as minimum qualifying history or maximum Catalog size. A Deployment Limit Policy may tighten these bounds but cannot relax them. Avoid: Model configuration, deployment quota

Deployment Limit Policy: A versioned operational policy that applies environment-, scope-, or capacity-specific limits to training or serving. It may enforce stricter bounds than the applicable Model Capability Contract but cannot authorize work outside that model's declared capabilities. Avoid: Model capability, hard-coded threshold

Diagnostic Occurrence: An immutable, machine-readable record that a Constraint Contract was violated or that another classified operational condition occurred. It carries a stable code and contract version, typed audience-safe parameters, observed and expected values when applicable, severity, effect, retry semantics, troubleshooting guidance, and correlation identifiers. The Training API and Serving API expose context-appropriate projections of the same diagnostic contract. Avoid: Exception string, stack trace, failure category