Library
The Christensen Engine Has No Twin — But It Has Relatives in Surprising Places · 11 of 12
The Christensen Engine Has No Twin — But It Has Relatives in Surprising Places
technology HIGH

Rules of Thumb from 16 Products

The Christensen Engine Has No Twin — But It Has Relatives in Surprising Places

Key Principle

Across 16 products in clinical, financial, legal, educational, and business domains, a set of recurring design principles emerged. These are the distilled heuristics that every team learned — often the hard way.

Why This Matters

These rules compress years of collective engineering experience into actionable guidance. Each one represents a failure mode that at least two independent teams encountered and resolved. Ignoring them means repeating known mistakes; following them accelerates past the most common traps.

Good Examples

Architecture Rules:

  • The LLM interprets; the state machine decides. Never invert this. (All 16 products)
  • 85% of value comes from deterministic workflow design, 15% from AI augmentation. (Neota Logic, p. 2, chunk 004)
  • Build the state machine first, test with zero LLM calls, then add the LLM shell. (p. 1, chunk 006)
  • "When the stakes of AI output are high enough to demand deterministic control, this architecture emerges naturally." (p. 1, chunk 003)

LLM Constraint Rules:

  • Use a fixed command grammar — convert the LLM from generator to classifier. (Rasa CALM, p. 3, chunk 004)
  • Don't tell the LLM not to use a tool — remove the tool from its prompt entirely. (Salesforce, p. 5, chunk 004)
  • The LLM should never see the full state graph — show only current state instructions and available transitions. (p. 3, chunk 005)
  • If you're writing longer instructions to fix LLM behavior, extract the logic into the state machine instead.

Data & Assessment Rules:

  • Structured data collection drives outcomes, not AI-generated insight. (Limbic, p. 1, chunk 004)
  • Use three-valued logic (Present/Absent/Unknown) — never force binary on incomplete data. (Ada Health, p. 5, chunk 003)
  • Score only what you assessed — never generate scores for dimensions without evidence. (Alex AI, p. 2, chunk 005)
  • Phase transitions should trigger on quality, not completion. (Buildpad lesson, p. 1, chunk 005)

Operational Rules:

  • Log the fully assembled prompt for every LLM call — you cannot debug what you cannot reconstruct. (p. 4, chunk 005)
  • Every backward transition gets a maximum-attempts guard: prevent infinite loops. (p. 4, chunk 005)
  • Design every workflow step to be independently retryable — ~80% work, 20% reveal edge cases. (Sixfold, p. 1, chunk 005)
  • Knowledge elicitation from domain experts is consistently harder than the technology. (Neota Logic, p. 2, chunk 004)

Counterpoints

  • "The AI isn't good enough" is usually the wrong diagnosis. Woebot's failure was business model. Salesforce's was instruction bloat. ValidatorAI's was insufficient deterministic control. (p. 1, chunk 006)
  • Procedural feels natural but collapses at scale. Decision trees become fragile beyond ~100 rules. Declarative rules with automatic inference outperform at scale. (Neota, p. 2, chunk 004)
  • Domain authority, not AI cleverness, is the real moat. Any competitor can adopt the same LLM. Domain expertise encoded in the deterministic layer — years of knowledge — cannot be replicated quickly. (p. 1, chunk 003)

Key Quotes

"the Christensen Engine's closest behavioral relatives succeeded not by being AI-first but by being domain-authority-first with AI as the delivery mechanism." (p. 1, chunk 003)

"eager to demonstrate how smart and helpful they are" (p. 3, chunk 005) — on why LLMs skip assessment states

"It's as much a distributed systems problem as an AI problem." (p. 1, chunk 005) — Sixfold CTO

Rules of Thumb

  • Lead with domain authority, not AI capability.
  • Treat pain points as engineering problems with known solutions.
  • Confirmation loops catch misclassification at the point of error, not after compounding.
  • Mandatory questions as waypoints: fix destinations, free the path between them.
  • Use LLMs to draft initial rule sets, then validate with domain experts.
  • Every assessment should produce structured output (assumption maps, not verdicts).

Related References