Order Module 2.3.0 - Sourcing Auditability
Release
Author:
Kirill Gaiduk
Changed on:
3 Sept 2026
| Target release date: | 2026-09-07 |
|---|---|
| Release status: | Released |
Description
Order Module 2.3.0 adds Sourcing Audit generation to Responsive Sourcing. Whenever the reference sourcing Rules run, they now capture a Sourcing Audit of the completed Sourcing Request and submit it through the`createSourcingAudit` mutation.Each audit records the full sourcing decision - the evaluated Strategies and their Condition results, the Locations considered and how they scored against each Criterion, and the resulting Fulfillments - so the outcome can be reviewed and explained. A failure to write an audit is logged and does not affect or reverse the sourcing outcome.Changelog
Rules
`CreateFulfilmentWithSourcingProfile`and`CreatePartialFulfilmentWithSourcingProfile`now:- Capture a Sourcing Audit of the completed Sourcing Request and submit it through the
`createSourcingAudit`mutation - A failure to create the audit is logged and does not affect or reverse the sourcing outcome
- Capture a Sourcing Audit of the completed Sourcing Request and submit it through the
- Sourcing Audit generation: sourcing now captures a Sourcing Audit of the decision (evaluated strategies, condition results, considered locations and their ratings, and the resulting fulfillments) and submits it through the
`createSourcingAudit`mutation - New
`SourcingUtils.captureAudit`method and Sourcing Audit Recorder (`DefaultSourcingAuditRecorder`/`NoOpSourcingAuditRecorder`), enabled per run through`SourcingExecutionParameters.auditRecorder` `SourcingPlan.getSourcingPlanAudit()`now carries the full decision:- Status (
`FULLY_SOURCED`/`PARTIALLY_SOURCED`/`NOT_SOURCED`) - Type (
`PRIMARY`/`FALLBACK`) - Sourcing profile
- Evaluated strategies
- Location count
- Items
- Status (
`getSourcingStrategy()`is superseded by`getStrategies()`/`getSourcingProfile()`- Sourcing Condition evaluation:
- New backward-compatible
`evaluateWithResult()`returns a`ConditionEvaluationResult`(pass flag + actual value) `SourcingConditionUtils.evaluateSourcingConditionsWithResults()`returns the per-condition results- The boolean
`evaluateSourcingConditions`is superseded by`evaluateSourcingConditionsWithResults`
- New backward-compatible
- Sourcing Criterion evaluation: the raw value computed before normalization is retained as the criterion's actual value for audit capture (for distance-based criteria, the measured distance alongside the normalized score)
- Grant
`SOURCINGAUDIT_CREATE`to the role that runs sourcing so it can write audits, and`SOURCINGAUDIT_VIEW`to any role that reads them back
Limitations
- Per-Location detail is retained for the successful Strategy, up to 100 Locations
Packages
| Released capability depth: | Enhancement |
|---|---|
| Release bundle / Capability type: | Module, Tool |
Use case
Problem
As sourcing logic becomes more sophisticated, the reasons behind each decision become harder to see. The Responsive Sourcing Framework evaluates sourcing profiles, strategies, conditions, and criteria against real-time inventory to select a fulfillment location. Once multiple profiles, seasonal strategies, and custom criteria are in play, the outcome of that evaluation is visible but the path to it is not.Without a record of what was evaluated and how each location scored, businesses commonly experience:- Unexplainable outcomes: An order ships from a distant location while a closer one appears to hold stock, and no one can say which criterion drove the decision or whether inventory was the constraint.
- Slow issue resolution: Operations and customer service teams reconstruct decisions from application logs, or escalate to engineering, extending the time to resolve a single customer complaint from minutes to days.
- Validating changes: A strategy, condition, or criterion is adjusted with no reliable way to confirm how the change affected real fulfillments, so tuning becomes guesswork and teams hesitate to make improvements.
- Governance and compliance exposure: Enterprise governance frameworks require that automated decisions affecting cost, service levels, and labor allocation can be evidenced after the fact.
- No basis for optimization: Without historical decision data, analysts cannot identify which criteria configurations produce the best outcomes, or feed those findings back into new sourcing criteria.
Example
A specialty outdoor retailer operating a distribution center in Reno, Nevada and 40 stores across the western United States received a customer complaint about a three-day delivery on an order placed in Denver, Colorado. The retailer's own store in Boulder held the item, and the customer expected same-day dispatch from there. The order was instead sourced from Reno.The operations manager could see the fulfillment record and the selected location, but nothing that explained the choice. The Boulder store's availability at the time of the decision was unknown, and the retailer had recently activated a second sourcing strategy for high-value orders, so it was unclear which strategy had even run. The investigation moved through three teams over four days, ending in an assumption rather than an answer. The same pattern repeated across dozens of similar complaints each month, and the retailer deferred a planned change to its distance criterion because there was no way to measure the impact.
Solution Overview
Fluent Commerce Order Management System (OMS) solves this through Sourcing Auditability: an immutable audit record written at the end of each sourcing request that captures the inputs, the evaluation, and the outcome. Every sourcing decision becomes explainable after the fact, without reconstructing it from logs.How it works at a glance: As the framework runs, the sourcing utilities collect the key inputs, evaluation results, and outcome of the sourcing request. At the end of the request the record is submitted through the`createSourcingAudit` mutation, stored as a compressed JSON document in cloud object storage, and read back through the `sourcingAudits` query. Audit records are presented in the Sourcing tab of the Order Management Interface to users who hold the required permissions.1. Record Every Sourcing Decision as an Immutable Audit
Each completed sourcing request produces one`SourcingAudit` record. It captures the entity and retailer context, the resolved sourcing profile and its version, the master list of items sourced, and the overall status of `FULLY_SOURCED`, `PARTIALLY_SOURCED`, or `NOT_SOURCED`.- A single order can produce more than one sourcing request, for example one at creation and another when a short pick occurs, and each produces its own audit record.
- Records are immutable, with no update or delete operation, and are retained in line with the order and fulfillment data they describe.
- Audit capture never changes the sourcing outcome. A failed write is logged and the sourcing result proceeds unchanged.
2. See Which Strategies Ran and Which Conditions Passed
Each strategy considered is recorded in priority order with its status:`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.- Every condition is recorded with its pass or fail result, showing exactly why a strategy did or did not apply to the order.
- The resolved sourcing profile and version identify the configuration in force at the moment of the decision, which distinguishes a logic change from an inventory change.
- Fallback behavior is visible, so you can see when a primary strategy was bypassed and a fallback produced the result.
3. Compare the Selected Location Against Any Considered Location
For the strategy that produced the fulfillments, the audit retains per-location detail: each considered location, its evaluated-criteria results, and the items it could not fulfill. Location comparison places the selected location alongside any other candidate evaluated by the same strategy.- Each criterion is shown with its normalized score and actual value, identifying which criterion separated the two locations.
- The location position, the rank of a location before the final available-to-sell check, shows whether the most suitable candidate was the one selected.
- Missing items are recorded per location, distinguishing a location ranked lower on criteria from one excluded by an inventory shortfall.
4. Support Governance, Analytics, and Change Validation
Audit records are access-controlled and available through the Fluent APIs, which supports both enterprise governance obligations and downstream analysis.- Access requires the
`SOURCINGAUDIT_VIEW`permission, and sourcing profile detail is populated only for callers who also hold`SOURCINGPROFILE_VIEW`. - Immutable, tenant-isolated records provide the evidence trail that regulatory and internal audit requirements call for.
- Historical decision data supports analysis of which criteria configurations produce the best outcomes, and can be consumed into monitoring and analytics tools.
- Product and engineering teams can confirm how a change to a profile, strategy, condition, or criterion affected real fulfillments before rolling it out more widely.
Solution
Sourcing Auditability Overview
Sourcing Auditability records why the Responsive Sourcing Framework made each sourcing decision. For each Sourcing Request, it records the inputs evaluated and the outcome reached, so you can review the decision later.It helps teams understand:
- Which Strategies and Conditions were evaluated
- Which Locations were considered and how they scored against their Criteria
- The Location(s) selected, and why
- What Sourcing Auditability captures and why it matters
- What you can see and answer with it
- Where audit data appears, and where to find interface and API detail
Sourcing Auditability GraphQL API Overview
This article provides technical users with information about the Sourcing Auditability GraphQL API, which writes and reads Sourcing Audit records within the Responsive Sourcing Framework.
