Recommendation Engines &
Personalization Platforms

1. What existing recommendation systems are missing

Netflix, Spotify, and YouTube have sophisticated recommendation systems — multimodal content embeddings, LLM-augmented architectures, unified search and recommendation models, and domain-specific LoRA adapters. These approaches have produced meaningful production gains: M3CSR (Kuaishou) showed +3.4% clicks; 360Brew (LinkedIn) supports 30+ ranking tasks matching specialised models; UniCoRn (Netflix) shows 10% improvement in recommendations. The framework documented here doesn't compete with these on recommendation quality. That is not what it does.

What it does is add a control layer that sits on top of whatever base recommendation model a platform runs — including any of the architectures above. The control layer provides three properties that none of the current production approaches, including the most sophisticated ones, have built in.

No persistent correction loop for explicit rejections

A user who clicks "not interested" on a category repeatedly still gets recommended that category — because engagement models and preference models don't share a persistent correction store. The signal is logged, but it decays quickly and rarely propagates across sessions. The same pattern resurfaces next week, next month, at the next login. There is no mechanism to say "this preference signal was verified and should not decay."

No confidence gate on sparse signals

Recommendation models produce a ranked list regardless of how confident they actually are in those rankings. A new user, a new item, or a session with thin behavioural signals gets the same confident output as a well-calibrated recommendation for a power user. Cold-start is still one of the hardest unsolved problems in production recommendation precisely because there's no principled mechanism to say "I don't know enough — here's a safe fallback."

Multi-objective tradeoffs resolved heuristically

Most production recommendation systems combine relevance, diversity, novelty, and business objectives (margin, sponsored content, inventory clearance) through hand-tuned heuristics and post-processing steps. The weights are implicit, undocumented, and difficult to audit. When a regulator or a user asks "why did you recommend this?" the honest answer is usually "a weighted combination of signals we can't fully decompose."

2. The utility function for recommendations

The recommendation utility function uses the same three-term formula as every other domain in the framework — proved as the unique functional form satisfying five behavioral axioms via Debreu's representation theorem (Theorem B.1, Appendix B). The weights and their domain-specific meaning shift, but the structure is unchanged:

U = w_e(f) · E  +  w_c(f) · C  +  w_k(f) · K

  E — Efficacy:   how well the recommendation serves the platform's
                  definition of a good outcome in this context.
                  Crucially, what counts as "effective" is domain-defined:
                  in discovery mode, E measures novelty-weighted engagement;
                  in fulfillment mode, E measures relevance to known intent;
                  in a business campaign, E measures margin-weighted conversion.
                  Business objectives are not a separate term — they are part
                  of what the platform defines as efficacious recommendation.

  C — Confidence: internal consistency of the recommendation signal.
                  Penalised by sparse data, contradictory signals, cold-start.
                  Below C_min(f), the system falls back to safe defaults.

  K — Curiosity:  exploration bonus for novel items the user hasn't seen.
                  Governs diversity and serendipity within the E constraint.

f — recommendation context (discovery, fulfillment, new user, campaign...)

This framing is consistent with how the framework handles domain variation elsewhere. Surgery defines E to include protocol adherence and patient safety compliance — those aren't separate terms, they're what "effective" means in that context. The same logic applies here: a recommendation platform that values margin-weighted conversion defines E accordingly, with the weight vector making that definition explicit and auditable rather than implicit in a black-box loss function.

Decision rule:
  recommend      if C ≥ C_min(f)   [confidence above threshold]
  safe fallback  otherwise          [popular/proven items for this user segment]

The key properties that make this different from existing multi-objective approaches:

• Explicit weight vector per context — not a single heuristic blending function, but a documented weight profile per mode that can be audited, adjusted, and explained
• Confidence gate as a first-class component — the system can abstain from a personalised recommendation and fall back to a high-confidence baseline, rather than always producing a ranked list regardless of signal quality
• Correction loop feeding back into weights — explicit rejections and verified preference signals become DPO training pairs that adjust the recommendation model's weights at calibration time, not just session-level re-ranking

3. Context-adaptive weight shifting

The optimal recommendation objective changes completely depending on what the user is trying to do and where they are in their lifecycle. The framework handles this with weight profiles — not separate recommendation systems per mode, but a single formula whose weights shift with the detected context. The values below are illustrative profiles; field-specific calibration is required for each deployment.

4. The correction loop applied to preference signals

This is the framework's most distinctive contribution to recommendation. Existing systems log explicit rejections but don't propagate them systematically across sessions and don't use them to update model weights between retraining cycles. The correction loop changes both.

Signal decay classification

Not all preference signals should persist equally. The assertions store applies field-specific decay classes to recommendation signals:

Signal type                  Decay class   Persistence (video recommendation)
──────────────────────────────────────────────────────────────────────────────
Explicit rejection            Class A       Never decays
  ("not interested", thumbs down, hide)
  → stored as verified negative preference
  → injected into all future sessions for this user

Strong positive (purchase,    Class B       Slow (τ = 2yr)
  save to watchlist, rewatch)               [framework default: τ = 10yr]

Engagement (completion        Class C       Moderate (τ = 6mo)
  ≥80%, rating given)                       [framework default: τ = 3yr]

Weak signal (click, start     Class D       Fast (τ = 2wk)
  but abandon <20%)                         [framework default: τ = 6mo]
  → decays quickly; accidental clicks and
    abandoned pilots are noisier here
    than equivalent signals in other domains

Decay constants for video recommendation are set shorter than framework defaults because preference signals in this domain have higher temporal specificity than medical or engineering facts. A user's genre preferences shift meaningfully within 6–12 months as tastes evolve, household composition changes, and the content catalogue refreshes. Class A (explicit rejection) is unchanged — a deliberate "not interested" signal is as durable here as anywhere. Class D decays within 2 weeks rather than the default 6 months because accidental clicks and abandoned pilots on a video platform are meaningfully noisier than equivalent weak signals in other domains.

How a rejection becomes a correction

1. User clicks "not interested" on Action genre recommendations
   for the 4th time this month

2. Contradiction detected:
   "Repeated explicit rejection of [Action] category
    contradicts model's continued recommendation of this category"

3. Correction stored (Class A — never decays):
   "User [id] has verified negative preference for [Action].
    Exclude from personalised recommendations permanently."

4. Correction injected into every future recommendation session:
   → Action items scored to zero in utility function
   → No re-ranking required — excluded at retrieval stage

5. DPO pair accumulated:
   preferred: [recommendations without Action]
   rejected:  [recommendations with Action]
   weight:    high (explicit rejection, repeated)

6. Next calibration cycle:
   → DPO pairs weighted into recommendation model training
   → Model learns not to retrieve Action for this user segment
   → Correction no longer needs injection — baked into weights

5. Confidence-gated cold start

Cold-start has more sophisticated solutions in the literature than what the confidence gate provides. Multimodal content embeddings — YouTube's Semantic IDs, Kuaishou's M3CSR — address cold-start by learning item representations from visual, textual, and audio content, so a new item with no interaction history still gets a meaningful embedding. These are genuinely stronger solutions to the cold-start quality problem than a confidence-gated fallback to segment baselines.

The confidence gate is not a quality solution to cold-start — it is an honesty solution. The problem it addresses is not "how do we recommend better for new users" but "how do we avoid confidently recommending things we have no basis for recommending." A platform that labels a segment-average recommendation as "Recommended for you" when it has zero user signal is making a small misrepresentation that users notice. The confidence gate makes the label accurate.

New user — session 1:
  Signal count: 0
  C = 0.10   [illustrative — far below C_min]
  
  Action: safe fallback
  → Recommend from high-confidence segment baseline
     (most-saved items in user's declared interest category)
  → Present as "Popular in [category]" not "Recommended for you"
  → Maximise diversity to gather preference signal quickly

New user — session 3 (5 interactions logged):
  Signal count: 5 (2 saves, 3 completions)
  C = 0.58   [illustrative — approaching C_min]
  
  Action: partial personalisation
  → Blend segment baseline (60%) with early personalisation (40%)
  → Still diverse — learning phase continues

New user — session 7 (20 interactions, 3 explicit saves):
  C = 0.72   [illustrative — above C_min]
  
  Action: full personalisation
  → Utility function governs recommendations
  → "Recommended for you" label is now honest

C_min for new users requires calibration against your platform's
own data — the point below which personalised recommendations
show measurably lower conversion than segment baselines.

6. Auditability and regulatory compliance

The framework produces a structured log for every recommendation decision — not just what was recommended, but why, with what confidence, and under which weight profile. This is the audit trail that regulators increasingly require and that current production recommendation systems cannot produce at the per-decision level.

Every recommendation session produces a log record:
{
  "user_id": "u_8821",
  "timestamp": "2025-11-14T14:47:23Z",
  "mode": "discovery",
  "weights_active": {
    "w_e": 0.30,
    "w_c": 0.25,
    "w_k": 0.35,
    "mode": "discovery"
  },
  "confidence": 0.78,
  "confidence_gate": "passed",
  "top_recommendations": ["item_A", "item_B", "item_C"],
  "active_corrections": [
    "User has verified negative preference for [Action] genre — excluded"
  ],
  "utility_scores": {
    "item_A": 0.731,
    "item_B": 0.698,
    "item_C": 0.672
  }
}

When a regulator or user asks "why was this recommended?", the answer is in a structured, retrievable log — not reconstructed from a black-box model. When a user asks "why do I keep seeing this category?", the corrections store shows exactly what signals have been accumulated and why the category is or isn't being suppressed.

7. Comparison: existing approaches vs. the framework

Property	Collaborative filtering	Deep learning rec	This framework
Explicit rejection persists	~ Incorporated but decays; varies by system	✗ Re-ranking penalty only; no persistent store	✓ Class A — never decays
Confidence gate on sparse signals	✗ Always produces ranking	✗ Always produces ranking	✓ C_min → safe fallback
Multi-objective weights explicit	~ Heuristic blending	~ Single loss function	✓ Documented weight vector per mode
Per-decision auditability	✗	✗	✓ Structured log per session
Correction propagates to model weights	✗ Only at retraining	✗ Only at retraining	✓ DPO pairs → calibration cycle
Context-adaptive objective	✗ Fixed similarity metric	~ Context features only	✓ Weight profile per mode
Cold-start handled honestly	~ Popularity fallback; content embeddings in advanced systems	~ Multimodal content embeddings (stronger on quality)	✓ C_min gate — honest labelling, not a quality solution

Framework properties from §8 — Correction Loop and §5 — Field Bounds.

8. MVP shape

A practical MVP for a recommendation platform doesn't replace the existing recommendation system. It begins as a correction and confidence layer on top of existing rankings:

1. Stand up the assertions store for explicit rejections — intercept all "not interested," hide, and thumbs-down signals. Store as Class A corrections. Measure how many times the same rejected category resurfaces in the next 30 days without corrections vs. with. This is the baseline metric.
2. Set C_min for new users — identify the signal count threshold below which your current recommendations have measurably lower conversion. That's your C_min calibration point. Below it, present segment baselines as "Popular in [category]" rather than "Recommended for you."
3. Shadow-mode weight profiles — run the discovery/fulfillment/cold-start weight profiles in shadow mode alongside the existing system. Log U scores per recommendation. Measure which profile produces better engagement on a per-session basis before any traffic is shifted.
4. First calibration cycle — after 4–6 weeks of accumulated correction signals, run the first DPO calibration. Measure whether rejection recurrence drops and whether Brier score improves. This is the Phase 1 validation gate.
5. Promote to advisory recommendations — surface the framework's recommendations alongside the existing system's for human review or A/B testing. The framework builds a track record before it controls production traffic.

pip install adaptive-utility-agent

aua init my-recommendation-platform --preset generalist --tier macbook
cd my-recommendation-platform
aua doctor

# aua_config.yaml
specialists:
  - name: discovery_rec
    model: qwen2.5-7b-awq          # your recommendation LLM
    port: 11434
    field: generalist
    metadata:
      rec_mode: discovery           # novelty-weighted, high curiosity
      w_e: 0.30
      w_c: 0.25
      w_k: 0.35

  - name: fulfillment_rec
    model: qwen2.5-7b-awq
    port: 11435
    field: generalist
    metadata:
      rec_mode: fulfillment         # known-intent, efficacy-dominant
      w_e: 0.70
      w_c: 0.20
      w_k: 0.10

safety:
  abstention_enabled: true          # enables C_min confidence gate
  min_confidence_for_direct_answer: 0.65   # tune to your platform data
  abstention_message: "Using segment baseline — not enough signal yet"

audit:
  enabled: true
  hash_chain: true                  # tamper-evident log for DSA compliance
  log_path: ./audit/recommendations.log

assertions:
  decay_class_overrides:
    explicit_rejection: A           # never decays
    strong_positive: B              # τ = 2yr
    engagement: C                   # τ = 6mo
    weak_signal: D                  # τ = 2wk (shorter than default)

security:
  auth:
    enabled: true
    tokens: [{name: rec-api, scopes: [query, read_metrics]}]
  encryption: {enabled: true, key_secret: AUA_ENCRYPTION_KEY}

aua serve

# Standard recommendation query — AUA routes to correct mode and applies C_min gate
curl -X POST http://localhost:8000/query \
  -H "Authorization: Bearer $AUA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "recommend items for user u_8821",
    "session_id": "u_8821",
    "metadata": {"rec_mode": "discovery", "signal_count": 23}
  }'

# Log an explicit rejection — stored as Class A, never decays
curl -X POST http://localhost:8000/assert \
  -H "Authorization: Bearer $AUA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "session_id": "u_8821",
    "subject": "genre:action",
    "assertion": "verified_negative_preference",
    "decay_class": "A",
    "source": "explicit_rejection"
  }'

# Export accumulated DPO pairs for calibration cycle
curl http://localhost:8000/export/dpo \
  -H "Authorization: Bearer $AUA_TOKEN" \
  -o rec_dpo_pairs.jsonl

# Run against your recommendation eval dataset
aua eval run --dataset rec_smoke.yaml --output results/

# Check confidence gate is firing correctly for sparse-signal users
aua eval report --metric abstention_rate --filter signal_count_lt_5

# Shadow-mode comparison: AUA utility scores vs existing system scores
aua eval compare results/baseline.json results/aua_discovery.json