Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.kaireonai.com/llms.txt

Use this file to discover all available pages before exploring further.

​
What this solves

Different product categories often want different ranking priorities. Cards offers are usually conversion-driven (push the highest-converting card to the top). Loans offers in regulated markets need fairness-led ranking (every qualified borrower sees an offer, regardless of model preferences). Without per-category overrides, you’d need a separate flow per category and split traffic at the router — operationally painful and breaks Hungarian uniqueness across the slot set.

​
Why this works

The Score node’s strategyOverrides[] array lets you map a candidate’s category (or productType, or channelId) to a specific RankingProfile. The PRIE engine reads the profile’s {conversion, recency, margin, fairness} weights, maps them to {Wp, Wr, Wi, We}, and recomputes the geometric-mean score per candidate. Same flow execution, three different weight regimes if you want three.

​
The pattern

Three ingredients:
  1. A flow whose Score node has method: "formula" and a default strategyProfileId.
  2. Two or more RankingProfile rows with the weight regimes you want.
  3. strategyOverrides[] on the Score node mapping scope: "category" (or "productType" or "channel") + value (the category name, exactly as it appears on the Offer) → the profile id.

​
Step 1 — Create the ranking profiles

curl -X POST https://playground.kaireonai.com/api/v1/ranking-profiles \
  -H "Content-Type: application/json" -H "X-Requested-With: XMLHttpRequest" \
  --cookie "<your session cookie>" \
  -d '{
    "name": "Cards Conversion-Heavy",
    "weights": { "conversion": 0.6, "margin": 0.25, "recency": 0.025, "fairness": 0.025, "fatigue": 0.1 }
  }'

curl -X POST https://playground.kaireonai.com/api/v1/ranking-profiles \
  -H "Content-Type: application/json" -H "X-Requested-With: XMLHttpRequest" \
  --cookie "<your session cookie>" \
  -d '{
    "name": "Loans Priority-Led",
    "weights": { "fairness": 0.65, "conversion": 0.1, "margin": 0.1, "recency": 0.05, "fatigue": 0.1 }
  }'
Note the IDs returned — call them CARDS_PROFILE_ID and LOANS_PROFILE_ID for the next step.

​
Step 2 — Configure the flow’s Score node

PUT the decision flow’s draftConfig, targeting the Score node: 
{
  "id": "score",
  "type": "score",
  "config": {
    "method": "formula",
    "modelKey": "bayesian-v2",
    "strategyProfileId": "CARDS_PROFILE_ID",
    "strategyOverrides": [
      { "scope": "category", "value": "Loans", "profileId": "LOANS_PROFILE_ID" }
    ]
  }
}
Then POST /api/v1/decision-flows/publish to ship it.

​
Step 3 — Verify

Fire the same recommend against the same customer twice — once with the override array empty (control), once with the override above. You should see Mortgage’s score drop by a known delta while Cashback’s stays constant (or moves only when you flip the Cards default). 
curl -X POST https://playground.kaireonai.com/api/v1/recommend \
  -H "Content-Type: application/json" -H "X-Requested-With: XMLHttpRequest" \
  -d '{
    "customerId": "split-X-007",
    "decisionFlowKey": "your-flow-key",
    "attributes": { "tier": "platinum", "loanAmount": 250000, "balance": 5000 }
  }'

​
What the trace will show

customer        | offer            | category | score   | profile applied
split-X-007     | Mortgage Refi    | Loans    | 0.8363  | Loans Priority-Led
split-X-007     | Cashback Card    | Cards    | 0.8619  | Cards Conversion-Heavy (default)
Look at scoringResults[*].explanations[] on the decision trace — when a strategy override fires, the explanation row records which profile was applied.

​
Gotchas

  • Use the category NAME, not the UUID. The engine matches on offer.categoryRef.name. Passing the category id silently no-ops; the engine falls back to the default profile.
  • Same-customer A/B is the cleanest comparison. The maturity ramp’s per-customer deterministic-random roll means two new customers comparing the same offer can see different drop patterns. Use one customer across both stages.
  • Override priority is array order. First match wins; later entries don’t merge. If you want a fallback, put it last with the broadest scope.

​
Proof reference

This pattern is exercised in T29 of the proof bundle — same customer across three weight regimes, with verbatim score deltas captured from live engine responses.