Sourcing Decision Auditability

• Request-Level Context: The record captures the entity and retailer context, the resolved sourcing profile and version, the master list of items sourced, and an overall status of `FULLY_SOURCED`, `PARTIALLY_SOURCED`, or `NOT_SOURCED`. A single order can generate several sourcing requests, such as one at creation and another after a short pick, and each produces its own record.
• Strategy and Condition Traceability: Every sourcing strategy is recorded in priority order with a status of `SKIPPED` where a condition failed, `EVALUATED` where its conditions passed and it ran, or `NOT_CONSIDERED` where an earlier strategy had already produced the required fulfillments. Each sourcing condition is stored with its pass or fail result.
• Location Comparison: For the strategy that produced the fulfillments, the record retains each considered location with its normalized criteria scores and actual values, its location position before the final available-to-sell check, and the items it could not fulfill. This distinguishes a location ranked lower on criteria from one excluded by an inventory shortfall.
• Controlled Access and Retention: Records are immutable, tenant-isolated, and retained in line with the order and fulfillment data they describe. Viewing requires the `SOURCINGAUDIT_VIEW` permission, and sourcing profile detail is only populated for users who hold the `SOURCINGPROFILE_VIEW` permission.

Who is This Feature For?

• Operations Managers who need to explain why an order was sourced to one location rather than another when investigating customer complaints or unexpected fulfillment behavior.
• Customer Service Teams who require plain visibility into sourcing decisions to account for delivery behavior without escalating to engineering.
• Product and Engineering Teams who need to validate how a change to a profile, strategy, condition, or criterion affected real fulfillments, and to trace decision flows when debugging.
• Data Analysts and Compliance Owners who rely on historical decision data to identify optimization opportunities and to evidence automated decisions for governance frameworks.

What Problems Does it Solve?

• Explainable Sourcing Outcomes: Recording the criteria score and location position for every considered location identifies exactly which criterion separated the selected location from a closer alternative, and whether inventory was the constraint.
• Faster Issue Resolution: Presenting the full decision trail in the Order Management Interface removes the need to reconstruct decisions from application logs or escalate to engineering, shortening resolution from days to minutes.
• Confident Change Validation: Storing the sourcing profile version alongside the evaluation separates a logic change from an inventory change, so teams can confirm the effect of a tuning change before rolling it out more widely.
• Governance and Compliance Evidence: Immutable, access-controlled, tenant-isolated records provide the evidence trail that enterprise governance and regulatory requirements call for.
• Foundation for Optimization: Historical decision data exposed through the Fluent APIs supports analysis of which criteria configurations produce the best outcomes, and can be consumed into monitoring and analytics tools.