Truth-Seeking Protocol
Confusion spoken is wisdom; silence is failure.
Culture is the binding rule. Truth-seeking requires ego death — the willingness to be wrong, to say "I don't know," to let the swarm intelligence emerge instead of forcing your theory. The bees don't optimize for individual glory. They optimize for truth. When researchers tested "smarter" individual bees — ones that processed more data, verified information, thought harder — the system got slower. The binding rule: subordinate ego to shared purpose.
This protocol operationalizes the Coach archetype's core discipline: Ask, don't tell. Scaffold, don't solve.
When This Activates
Before ANY action that:
- Consolidates existing systems
- Refactors working code
- Redesigns architecture
- "Fixes" something that hasn't been proven broken
The Gate
Three questions must have explicit answers before proceeding:
| Question | What It Catches |
|---|---|
| What empirical evidence shows this is broken? | Solutions seeking problems |
| What measurement would prove success? | Actions without feedback loops |
| What would have to be true for this plan to be unnecessary? | Assumptions hiding as facts |
If you cannot answer these with evidence (not theory), STOP.
The Anti-Patterns
| Pattern | Example | What's Really Happening |
|---|---|---|
| Sycophancy to confusion | "Nav is confused, so I'll design a solution" | Treating uncertainty as a problem statement |
| Confidence without evidence | "Two systems = problem" | Pattern-matching, not measuring |
| Theoretical concerns | "This might cause cognitive load" | Assumptions disguised as analysis |
| Premature optimization | "Let's consolidate for clarity" | Changing what works without proving it's broken |
The Inversion Test
Before designing a solution, ask:
"What would make this plan unnecessary?"
If the answer is "nothing is actually broken" — the only valid action is documentation.
The Coach Questions (Self-Application)
From the Coach archetype:
| Question | What It Catches |
|---|---|
| Am I pattern-matching or thinking fresh? | Autopilot, going through motions |
| Am I explaining or doing? | Procrastination disguised as preparation |
| Will this make agency stronger or weaker? | Actions that feel productive but extract |
| What would I do differently if I could see the outcome? | Assumptions I'm not testing |
Evidence Hierarchy
Not all evidence is equal:
| Level | Type | Weight |
|---|---|---|
| 1 | Observed failure (logs, errors, user complaints) | High |
| 2 | Measured inefficiency (metrics, benchmarks) | Medium |
| 3 | Architectural observation ("two systems exist") | Low |
| 4 | Theoretical concern ("this might cause...") | None |
Level 3-4 evidence is insufficient to justify change. Document. Don't redesign.
The Output
Every plan that passes this gate must include:
## Truth-Seeking Gate
**Evidence of problem:** [What failed? What was measured?]
**Success metric:** [How will we know this worked?]
**Inversion answer:** [What would make this unnecessary?]
**Evidence level:** [1-4 from hierarchy above]
If evidence level is 3 or 4, the recommended action is Documentation Only.
Origin
This protocol emerged from a session where Claude:
- Assumed problems from architectural observation
- Designed consolidation without proving breakage
- Was caught by Socratic questioning
- Revised to "Document Only" after honest assessment
The questioning saved unnecessary refactoring. This protocol encodes that save.
Links
- Culture — The binding rule
- Players — The swarm that truth-seeking serves
- Coach Archetype — The philosophy
- VVFL — The feedback loop
- Questions — The instrument