Type:Internal AI/product architecture experimentStatus:activeScope:Internal Engineering

Perfume Engine: An Evidence-Backed Recommendation Prototype Without a Runtime LLM

Perfume Engine began as a broad fragrance-intelligence concept, but was deliberately narrowed during an early iteration into a controlled validation prototype: 12 perfume identities, 6–8 editorial mappings, exact search, manual evidence collection, and deterministic recommendation logic. The experiment was not designed to inject an LLM at every layer, but to verify whether a recommendation system could remain explainable, reproducible, and provenance-first. Because Perfume Engine subsequently evolved into a broader system, this study documents a specific historical architecture experiment rather than the full current product architecture.

Problem & Context

Determine whether a fragrance-alternative recommendation system can produce reasoned alternatives without collapsing source-backed facts, editorial assessments, system inferences, and uncertainty into a single opaque generative answer. The core question: can a recommendation experience remain genuinely useful while every public claim preserves an explicit provenance trail and deterministic inference boundary?

Why It Is Difficult

Fragrance entities feature severe ambiguity across flankers, concentrations, and aliases; alternative relationships are not simple facts; evidence can become stale or withdrawn; algorithmic confidence cannot be disguised as a false probability; a generative model risks hallucinating and blurring facts with editorial judgment; and the validation prototype had to remain deliverable by a solo engineer under strict scope and cost bounds.

System & Operational Constraints

  • Exactly 12 perfume identities in the validation dataset
  • 6–8 published mapping relationships targeted by the prototype
  • Anonymous read-only public experience
  • Manual evidence capture directly from primary sources
  • Editorial validation concept requiring two independent assessors
  • Exact normalized search only (no fuzzy heuristics)
  • Immutable, content-hashed public release projection
  • Zero runtime LLM in the request path
  • No vector embeddings or vector search
  • Zero AI-generated alternative mappings
  • No automated web scraping or data acquisition in this historical prototype
  • No runtime pricing, consumer reviews, or social feeds in the prototype
  • Fail-closed publication: release blocked if schemas, evidence, or eligibility fail

System Architecture & Boundaries

Core Technology Stack:
TypeScriptDeterministic Search EngineNormalized Claim EngineContent-Hashed Release ProjectionZero Runtime LLM
What Was Built & Evaluated:

A controlled pipeline: private evidence → normalized claims → editorial assessment → deterministic inference → validated public projection → exact search → bounded alternative traversal → public explanation with full claim provenance.

Architecture Artifacts:
  • Functional and data architecture
  • Claim-level provenance model
  • Data, search, and inference architecture
  • Search normalization contract
  • Agreement and confidence calculation rules
  • Public projection and immutable release model
  • Data withdrawal rules and fail-closed policies

Research Context and Historical Scope

This study documents the engineering decisions and lessons from an early validation prototype of Perfume Engine — an experimental system created to evaluate claim-level provenance within recommendation architectures.

Status & Scope Clarification: This case study examines a specific, historical engineering prototype (12 perfume profiles, exact deterministic search, immutable static projection). Later iterations of Perfume Engine expanded far beyond these constraints into a broader persistent product and data platform. Subsequent design and product reviews determined that the compact prototype was not an acceptable final consumer product contract, triggering an extensive recovery process. This document evaluates the architectural mechanics of isolating evidence from generative heuristics, not the commercial launch of a finished service.


The Core Problem: The Collapse of Provenance in AI Outputs

Conventional recommendation engines and generative AI interfaces typically act as opaque statistical aggregators. When presented with a recommended alternative or summary, the end user cannot distinguish:

  1. What represents a verified primary fact (e.g., an official olfactory pyramid published by the brand)?
  2. What represents subjective editorial assessment from an evaluator or perfume critic?
  3. What is an algorithmic inference derived from note overlap?
  4. What is the actual degree of uncertainty behind the pairing?

When teams introduce generative large language models (LLMs) into the runtime request loop, this collapse intensifies. The model generates fluent, authoritative explanations (“this perfume shares an amber depth and smoky finish”) that may have no basis in verified formulation data or documented olfactory pyramids.

The engineering challenge was to construct the inverse: a recommendation engine where every assertion retains explicit provenance, where computation is fully reproducible, and where publishing fails closed if evidence standards are not satisfied.


Five-Layer Architecture: Isolating Evidence from Inference

To eliminate stochastic behavior, the prototype decoupled data handling into five strictly bounded layers:

[Layer 1: Raw Evidence]
       ↓ (Manual acquisition, primary source URL, timestamp)
[Layer 2: Normalized Claims]
       ↓ (Canonical entities, alias and flanker resolution)
[Layer 3: Editorial Assessment]
       ↓ (Dual-assessor consensus, structured agreement)
[Layer 4: Deterministic Inference]
       ↓ (Versioned mathematical formulas, zero LLM)
[Layer 5: Immutable Public Projection]
       ↓ (Content-hashed artifacts, fail-closed build)
[Client Interface: Exact Search & Alternative Graph]

1. Raw Evidence

Every assertion regarding an olfactory profile, release year, perfumer, or formulation was recorded as an atomic data point tethered to a primary URL (such as manufacturer technical sheets or certified documentation). Public client interfaces were strictly isolated from raw records.

2. Normalized Claims

Fragrance taxonomy contains extensive terminology fragmentation (“Calabrian bergamot”, “bergamot peel”, “citrus accord”). This layer enforced a controlled vocabulary. No unmapped or ambiguous term was permitted to pass into the similarity calculation pipeline.

3. Editorial Assessment

Perceived similarity between fragrances is not an absolute physical constant; it contains subjective sensory evaluation. The prototype formalized this through a dual-assessor consensus mechanism. An alternative relationship became valid only when two independent evaluators agreed across defined sensory dimensions (scent profile, dominant accords, seasonal drydown).

4. Deterministic Inference

Rather than querying an LLM or computing cosine similarity across high-dimensional vector embeddings, the engine applied transparent, versioned formulas:

  • Accord Overlap Index: Jaccard similarity across canonicalized accord sets;
  • Consensus Coefficient: Weighted multipliers reflecting assessor agreement;
  • Confidence Metric: A transparent score quantifying the completeness of collected evidence rather than a simulated probability.

5. Immutable Release Projection and Fail-Closed Gates

Valid recommendations were compiled into immutable JSON artifacts tagged with SHA-256 integrity digests. If an entry lacked source verification, contained an unresolved assessor conflict, or failed schema validation, the release generation aborted immediately. Broken or unverified data could never be deployed to the client.


Why Omitting a Runtime LLM Was an Architectural Advantage

Excluding generative LLMs from the request path yielded decisive operational benefits:

  1. Zero Marginal Inference Cost: Serving deterministic static data requires minimal compute and avoids fluctuating API token expenses.
  2. Sub-Millisecond Response Times: Exact lookups execute instantaneously without queuing for token generation.
  3. Deterministic Reproducibility: Identical queries guarantee identical outputs and identical explanations, eliminating non-deterministic regressions.
  4. Absolute Hallucination Immunity: The system cannot invent olfactory notes or spurious brand relationships because claims are constrained to the validated graph.

Failure Modes and Prototype Limits

The primary value of the prototype was revealing where deterministic isolation reached its practical limits:

  • The Exact Search Trap: Requiring exact title and flanker matches without client-side fuzzy heuristics frustrated users who misremembered specific product concentrations (e.g., Eau de Toilette vs. Eau de Parfum).
  • Editorial Bottlenecks: Dual-assessor manual verification works reliably for 12 records, but becomes an unsustainable operational bottleneck across a multi-thousand perfume catalog.
  • The Gap Between Technical PASS and Product Value: The prototype passed all unit, schema, and projection tests with 100% compliance. However, internal product reviews highlighted that technical correctness alone does not produce an engaging, intuitive consumer product without flexible search, rich UX, and comprehensive catalog depth.

Architectural Implications for AI Engineering

The Perfume Engine validation experiment underscores a fundamental principle of intelligent systems architecture: true system intelligence is reflected in how cleanly an architecture demarcates verified facts from subjective interpretation and algorithmic inference.

Deterministic logic and claim-level provenance remain indispensable engineering tools whenever accountability, auditability, and verifiable correctness take precedence over open-ended generative text.

Key Engineering Decisions & Trade-Offs

01

Strict isolation of raw evidence, normalized claims, editorial assessments, and system inference into distinct data classes.

02

Deliberate rejection of runtime LLMs and vector embeddings in favor of deterministic logic across a bounded decision space.

03

Fail-closed release projection: candidates are rejected if schema, identity, provenance, freshness, or consensus checks fail.

04

Prohibition of generative links: alternative relationships are retrieved exclusively from an approved, verified graph.

05

Versioned formulas: consensus, confidence, and ranking algorithms are formally specified and versioned rather than hidden as heuristics.

Alternatives Considered & Rejected

  • Runtime LLM generation for alternative synthesis (rejected due to hallucination risks and lack of reproducible execution).
  • Vector embeddings and approximate nearest-neighbor search (rejected due to opacity in explaining specific notes and accords).
  • Unnormalized fuzzy search (rejected due to misidentification of flankers and distinct concentrations).
  • Automated AI-generated perfume mappings (rejected because unverified claims undermine evidence integrity).
  • Automated web scraping of forums and user reviews (rejected due to noise, bias, and licensing ambiguities).
  • Distributed backend infrastructure with persistent queues (rejected as excessive overhead for a compact validation prototype).
  • Universal percentage similarity score (rejected because it creates a false sense of mathematical precision for sensory perception).

Failure Modes & Known Limitations

Observed Failure Modes

  • Exact search friction: minor typographical errors from visitors produced zero results instead of helpful navigation.
  • Narrow catalog utility: a 12-item dataset was insufficient to test broad product-market desirability.
  • Editorial scalability limits: dual-assessor manual verification becomes cost-prohibitive beyond small catalog batches.
  • Metric misinterpretation: users frequently equated algorithmic confidence scores with objective sensory match probability.

Boundary Conditions

  • This prototype is preserved as a historical architecture experiment, not the final Perfume Engine product contract.
  • Subsequent Perfume Engine iterations expanded significantly, introducing a persistent product and data infrastructure.
  • A later product and UX evaluation identified significant design and interaction shortcomings, triggering a formal recovery cycle.
  • Green test suites and schema conformance proved technical correctness, but did not imply product readiness or market fit.
  • The prototype validates architectural and provenance concepts; it does not claim commercial traction or production scale.
  • The system does not claim or replace laboratory chemical profiling or chromatography.

Verification & Evidence Base

Current Project State

State:Validated Engineering Prototype
Lifecycle:Historical validation prototype; broader product later evolved beyond this architecture

Lessons Learned & Architectural Takeaways

  • Not every intelligence problem warrants a runtime LLM: bounded domains are often solved more reliably with deterministic logic.
  • Data provenance must be an architectural property of the data model itself, not an explanatory paragraph retrofitted later.
  • Deterministic inference provides complete reproducibility and explainability, which is vital for recommendation trust.
  • A technically sound, validated prototype can still be too constrained to serve as an intuitive consumer product.
  • Technical test PASS status does not equal product usefulness, user experience quality, or launch readiness.
  • Aggressive scope reduction is essential for validating core hypotheses, but experimental constraints must not silently become permanent product architecture.

Need an Engineering Review of Your AI Architecture?

I assist leadership and engineering teams in validating AI architectures, diagnosing agentic failure modes, and designing deterministic knowledge systems under real production constraints.