Separate a recommendation from a catalog write
Belgavi's Book Store is a hypothetical teaching example. Suppose a recommendation service proposes a price for a synthetic book record. The model may rank candidate prices, but the catalog service owns the permitted currency, minimum margin, maximum change and approval requirements. Returning a number is not authorization to publish it.
Use an explicit output contract: item identifier, current catalog revision, proposed amount, currency, reason codes and model version. Reject missing or non-finite values. Check the current revision again when applying the change so a recommendation cannot overwrite a newer catalog edit.
Make the input snapshot reproducible
Keep a versioned snapshot of synthetic stock, cost and demand inputs. Distinguish observations from assumptions. A stock count is a record; an expected demand uplift is an estimate that requires evaluation. Do not present a simulated revenue curve as measured customer behavior.
For a worked calculation, assume cost is 8 units and the required gross margin is 20 percent of price. The minimum permitted price is 8 divided by 0.8, or 10 units. A recommendation of 9.5 fails the constraint even if its estimated demand is higher. This arithmetic illustrates a hard boundary; it does not establish a profitable pricing strategy.
Compare outcomes under the same constraints
Evaluate candidate recommendations on a fixed synthetic holdout. Count invalid currency, negative amounts, stale revisions and constraint violations separately from prediction error. A system that predicts demand well but writes an invalid price still fails the catalog contract.
Stress missing costs, zero stock and an abrupt input change. Require a documented fallback such as retaining the current approved price. Apply the same input snapshot and rules to the baseline and candidate. Changing the constraint between runs makes the comparison uninterpretable.
Keep approvals and rollback visible
Publish a proposal to a review queue with its evidence. Approval should bind to the proposed item, revision and amount. On execution, append an audit event and use an idempotency key so a retry cannot create a second update. Rollback is a new catalog revision that restores an approved value, not deletion of history.
These are architectural exercises using fictional data. They contain no customer records and report no real commercial experiment. Continue with the order workflow guide to handle a change that spans more than one service.
Further reading
For consistent state across services, see AWS guidance on the saga pattern. The pricing example here is hypothetical.