• A positive float (0…1) ranks how suitable a Location is
• -1 filters a Location out of consideration
• Criteria are applied in sequence to produce a final ranked list of eligible Locations

• Apply → Execute → Normalize:
  • `apply()` calls pre-logic, executes business rules, and post-logic
  • `normalize()` adjusts raw scores to a [0–1] range where applicable
• Sequential Stack:
  • Criteria are applied in order of appearance
  • The first Criterion usually defines the main ranking dimension (e.g., distance or inventory availability)
  • Later Criteria resolve ties
• Parameter Parsing:
  • `parseParams()` reads JSON params defined in the `fc.rubix.order.sourcing.criteria` Setting
  • Helper Utilities (`getFloats`, `getStrings`, `getDistanceUnits`) ensure correct types and default handling

Default Sourcing Criteria

• `value`: Numeric thresholds or band breakpoints. An input like [10, 25, 50] defines 4 bands:
  • (–∞ … 10]
  • (10 … 25]
  • (25 … 50]
  • (50 … +∞)
• `valueUnit`: Selects unit of measure where applicable (kilometres, miles)
• `component`: UI input type such as `fc.field.multistring`, `integer`, or `select`
• `mandatory` / `exactSearch`: Validation flags controlling whether the field must be provided and if exact match applies

• Order Criteria deliberately: put Exclusion Criteria first, then your primary ranking Criterion, then tie-breakers
• Provide exact values and enforce strict types via schema-driven components (e.g., units in select, numeric bands)
• Test boundary and edge cases thoroughly
• Apply overrides in `fc.rubix.order.sourcing.criteria.custom` when tailoring Criteria for specific Accounts / Retailers

• Implement `SourcingCriterion` (or extend `BaseSourcingCriterion`)
• Put computation in `execute(CriterionContext ctx)` (when extending `BaseSourcingCriterion`)
• Parse configuration in `parseParams(JsonNode params)` if needed
• (Optional) Override `normalize(min, max, rating)` when your metric’s “lower is better” (e.g., distance)

1@SourcingCriterionInfo(
2    name = "mySourcingCriterion",
3    type = "company.sourcing.criterion.my",
4    tags = { "ATS-agnostic" } // or "ATS-dependent", "Exclusion"
5)
6public class MySourcingCriterion extends BaseSourcingCriterion {
7
8    @SourcingCriterionParam(name = "value", component = "integer")
9    private Integer threshold;
10
11    @Override
12    public void parseParams(final JsonNode params) {
13        // parse threshold, lists, units, etc.
14    }
15
16    @Override
17    protected float execute(final SourcingCriteriaUtils.CriterionContext ctx) {
18        // Return:
19        //  -1f to exclude a location,
20        //   0..1f (or any float) to score/rank a location.
21        return 0.75f;
22    }
23
24    // Override normalize(...) only if the default doesn’t fit your scale
25}

Schema Autogeneration

How it works

• The generator scans all classes registered in `SourcingCriteriaTypeRegistry`.
• Reads `@SourcingCriterionInfo` + `@SourcingCriterionParam` annotations
• Produces a complete JSON (name, type, tags, params, including select options)

Run it

• Command: `java -jar <path>util-sourcing-<version>-sources.jar`
• Output: SourcingCriteriaSetting.json in the same folder as the JAR/classes
• Use this JSON to populate `fc.rubix.order.sourcing.criteria.custom` Setting

When to use

• Any time you add/update Sourcing Criteria or their `params` - regenerate to keep UI configs in sync

• Use the Sourcing Profile GraphQL API to add the new Criterion to a Sourcing Strategy. 
• Test against different Sourcing Requests and confirm the expected outcomes.