The Architecture Canontruth · evidence · projection
Pattern

Deterministic Recommendation Pipeline

pattern-deterministic-recommendation-pipeline · canon/patterns/deterministic-recommendation-pipeline/unit.md

Deterministic Recommendation Pipeline

Recommendation systems drift into opaque, creepy, un-debuggable behavior. Make the pipeline deterministic — same inputs, same outputs — so recommendations are reproducible, tunable, and explainable. Intelligence that proposes from truth and projections, owns nothing, and can be reasoned about.

Problem

Recommendation systems often become opaque, manipulative, and hard to debug. Users receive suggestions with no understandable reason. Operators cannot reproduce why a recommendation appeared. Product teams cannot tune behavior safely because small changes can create invisible ranking shifts.

Context

Use this pattern when recommendations affect discovery, matching, prioritization, routing, or ranking, especially when the system must explain why one option appeared and another did not.

Forces

  • Users need recommendations to feel helpful rather than arbitrary.
  • Operators need to reproduce a recommendation after the fact.
  • Product teams need controlled tuning without rewriting truth or projection data.
  • Intelligence should propose from truth and projections without becoming authoritative itself.
  • Diversity and exploration are useful, but they must not erase the reasons for the score.

Solution

Use a deterministic additive scoring model. Persist component scores. Attach human-readable reason codes. Apply diversity and exploration rules after scoring. Keep recommendation inputs grounded in truth and projections, and make the pipeline reproducible from those inputs.

Consequences

Recommendations become explainable. Ranking becomes auditable. Tuning becomes controlled. The platform can say why something appeared. Discovery can improve without making the Intelligence Plane a second Truth Plane.

Failure Modes

  • A recommendation cannot be reproduced from recorded inputs.
  • Reason codes are marketing labels rather than the actual scoring components.
  • Exploration mutates the underlying score instead of being applied as a separate policy.
  • The recommendation output becomes the only record of user or relationship truth.
  • A model update changes behavior without a reviewable score or reason trail.

Proof Points

opportunity recommendations depend on relationship truth and projected context, but should remain explainable and tunable.

  • Ampriot — venue, artist, promoter, scene, and

Full source pattern: 03-deterministic-recommendation-pipeline.md.

Incoming References

Case Study 1