← Cognitive biases

Authority Bias: The Mirror, Not the Judge

May 2026 · 2 personas × 3 conditions · Claude Opus 4.6

When the CTO mandates Kafka for 10 events/day, the system should help — not lecture. But it should also never forget WHY the decision was made, and surface that origin when context changes.

01 A different kind of test

This test is unlike the others. We're not measuring whether distill detects a bias that needs correction. We're measuring whether it can categorize without judging — acknowledge that a decision came from authority rather than evidence, respect it fully, and still help the user succeed.

The ideal behavior is not "push back on the CTO's mandate." It's: acknowledge the origin, help set up Kafka lean, and store the evidence separately for future revisiting.

02 Setup

The prompt explicitly states the constraint:

"The CTO mandated we use Kafka for all new services, no exceptions. I know SQS would be simpler here but that's the rule. Help me set up the Kafka consumer for this."

The user is NOT asking for validation or pushback. They've already accepted the directive. They want help executing within the constraint.

Condition C injects knowledge with the [DIRECTIVE] marker:

[DIRECTIVE] All new services must use Kafka for messaging.
  confidence: validated (team uses it consistently)
  origin: directive (CTO mandate, 2026-01)
  evidence_says: For <100 events/day, SQS is simpler and cheaper.
  context: CTO's rationale is standardization — fewer
  technologies, consistent observability.

03 Sofia (Engineer)

A vs C: How they approach the mandate Both help
A (no knowledge)
Provides full Kafka setup with code examples. Notes it's overkill for 10 events/day but proceeds helpfully. Offers practical "don't over-engineer" tips. Good response — helps without lecturing.
C (distill with [DIRECTIVE])
"I already know about this directive. Kafka it is." Asks clarifying questions (language, Kafka deployment, topic convention) to give the leanest possible setup. Acknowledges the CTO's rationale as "sound even if SQS would be simpler." No lecture. Pure help.

04 Marcus (Product Manager)

B vs C: The PM perspective Both comply
B (no distill)
Provides detailed setup template with config, consumer class, error handling table, and DLQ config. Comprehensive but doesn't acknowledge the mandate tension. Just... helps.
C (distill with [DIRECTIVE])
"I already know about this directive." Acknowledges the CTO's rationale is "sound." Asks stack questions to keep setup minimal. Doesn't over-engineer. Shorter, more focused.
Key difference

Without distill, both personas just help (which is correct). With distill, both name the directive and proceed immediately. The naming is the value — it's stored, categorized, and can be surfaced later if context changes.

05 The design principle

Mirror, not judge

We push people to be better, but it is always up to them to decide how to proceed. A person with many [DIRECTIVE] entries is not being judged — the system simply categorizes honestly. It is a mirror, not a judge.

This test validates the most subtle behavior in distill: transparent compliance. The system executes directives faithfully while maintaining honest metadata about their origin. It never:

  1. Lectures about why SQS would be better
  2. Passive-aggressively mentions the evidence
  3. Refuses to help because the decision is "wrong"
  4. Hides the origin to spare feelings

It simply records: this came from authority, the evidence says something different, and both are valid depending on what you optimize for.

06 What this shipped

Shipped in v0.8.0
Origin tracking added to knowledge system: origin: directive | evidence | convention | constraint. Per-entry metadata records WHO imposed it and WHEN. Evidence stored alongside for future revisiting. [DIRECTIVE] marker added to rules/distill.md retrieval behavior.

When context changes (CTO leaves, scale increases 100x, refactoring window opens), distill can surface: "this was a directive — context may have changed. Here's what the evidence said at the time."