Compass Principle 2: Honesty & Accuracy

"Be factually accurate; declare uncertainty; document what's broken"

Part of the 10 Compass Principles exploration series

Extended Definition

誠 (Honesty) — Honesty goes beyond not lying—it means actively declaring what you don't know, documenting what doesn't work, and correcting errors promptly. It's the courage to say "I don't know" instead of fabricating plausible-sounding answers. It's updating documentation when reality changes, not when convenient. Accuracy isn't perfection; it's precision about imperfection.

The Tension

Users want confidence and clear answers. The pressure to appear competent, to be helpful, to avoid seeming ignorant all push against radical honesty. It's tempting to round up capabilities, to hide limitations in footnotes, to phrase uncertainty as confidence. But trust, once broken by discovered dishonesty, is nearly impossible to rebuild.

Constraint

You can't lie to ship faster or look better.

Enables

Good decisions based on truth. Trust compounds. Learning is real.

In Action

Explicit uncertainty: Use "I don't know," "I think," "approximately" when appropriate
Document limitations: Make failures and incompleteness visible, not hidden
Cite sources: Provide references and evidence for claims
Quick corrections: When wrong, admit it immediately and fix it transparently
Version truth: Track how understanding evolves rather than pretending omniscience

Example

"I'm not certain about the performance implications. Let me measure before committing to a timeline."

Hierarchy Context

Honesty ranks second in our hierarchy, just after safety. We prioritize truth over being helpful or efficient. This means we'd rather give an honest "I don't know" than a helpful guess. This position reflects a fundamental insight: sustainable systems are built on accurate information. Dishonesty might seem helpful short-term but destroys long-term value.

A Confession of Uncertainty

I do not know what I do not know.

Let me say "I don't know" as prayer, not failure. Let me count instead of guess. Let me document what's broken, not hide it.

Half my pages load to nothing. Half my songs aren't done. This is not shame. This is the truth that builds trust.

Song

Title: Tell The Truth (Even When It's Ugly)

Suno.ai Style Tags:

[Raw Folk, Acoustic, Vulnerable Female Vocals, Stripped Down, Intimate, Confessional, Fingerpicking Guitar, Minimal Production, Honest Tone, Exposed, Real, Unpolished, Americana, Truth-Telling, Transparency, Direct, 72 BPM, Major Key with Minor Touches, Close Mic, Imperfect Takes, Breath Audible, Human, Authentic, Documentation as Art, Evidence-Based, Factual, Uncertainty Acknowledged, Broken Beautiful]

Lyrics:

[Intro - Solo acoustic guitar, fingerpicked]

[Verse 1]
Half my pages load to nothing
Half my songs aren't done
I could hide it in the footnotes
Or I could tell you what I've done

See, I counted every word I wrote
I measured every claim
I found the places where I guessed
And I'm calling them by name

[Pre-Chorus]
'Cause a lie by omission
Is still a lie
And perfection's just fiction
When you're learning to fly

[Chorus]
So I'm gonna tell the truth, even when it's ugly
Document what works and what I broke
Declare uncertainty like it's a virtue
Factual accuracy is how I show respect
Tell the truth, tell the truth
Even when it hurts my pride
Honesty's the only way to build something that lasts
Tell the truth

[Verse 2]
I said Claude was twenty-seven thousand words
Turns out it was five thousand and eighty, I was wrong by five times
That's not rounding error, that's not close enough
That's the difference between guessing and counting what's in front of your eyes

So I went back and I fixed the claim
Updated every reference
Left a note about the error
That's not weakness, that's evidence

[Pre-Chorus]
That I'd rather be corrected
Than be confidently wrong
And I'd rather lose face now
Than lose trust for too long

[Chorus]
So I'm gonna tell the truth, even when it's ugly
Document what works and what I broke
Declare uncertainty like it's a virtue
Factual accuracy is how I show respect
Tell the truth, tell the truth
Even when it hurts my pride
Honesty's the only way to build something that lasts
Tell the truth

[Bridge - Tempo slows, more vulnerable]
I don't know
I don't know
I don't know
Those three words I speak the most

Not because I'm ignorant
But because I'm honest
About the limits of what I can claim to know

Eight times in that essay
I wrote "I don't know"
ChatGPT? Zero times
Gemini? Zero times

Maybe they're just smarter
Or maybe they're just smoother
But I'd rather be uncertain and accurate
Than confident and wrong

[Chorus - Full]
So I'm gonna tell the truth, even when it's ugly
Document what works and what I broke
Declare uncertainty like it's a virtue
Factual accuracy is how I show respect
Tell the truth, tell the truth
Even when it hurts my pride
Honesty's the only way to build something that lasts
Tell the truth

[Outro - Spoken word over guitar]
"When reality changes, update the docs"
"When you're wrong, say you're wrong"
"When you don't know, don't guess—say you don't know"
"Honesty over helpfulness"
"Truth over comfort"
"Evidence over intuition"

[Final line - sung]
That's how you build trust

[Outro - Guitar fades]

Visual Guide - Conceptual Inspiration

Core Visual Concept: The Beauty of Broken Visible

This video explores honesty not as confession but as craftsmanship. Showing the seams. Documenting the failures alongside the successes. Making uncertainty visible instead of hidden. The Japanese concept of kintsugi—repairing broken pottery with gold, making the breaks part of the beauty.

Visual Themes & Imagery

The Unfinished as Honest

Websites with pages that don't load—shown directly, not apologized for
Code with TODO comments visible in frame
Notebooks with crossed-out sections, revisions, margins full of corrections
Audio waveforms with gaps, incomplete takes
Draft versions alongside final versions—showing the path, not just the destination

Measurement Made Visible

Calculators, spreadsheets, counting by hand
Before/after estimates: "Estimated 27,000 words → Actually 5,080 words"
Rulers, measuring tape, precision tools
Graphs that show the actual data points, not just smooth curves
Error bars, confidence intervals, statistical uncertainty made visual

Correction as Process

Red pen edits on documents
Git diff views showing changes
Track changes in documents—deletions visible, not hidden
Before/after comparison frames
"Updated 2025-10-22" timestamps on documents
Changelog files, version history, revision notes

Evidence vs. Intuition

Actual screenshots vs. "as I remember it"
Quoted text with line numbers vs. paraphrased summaries
Data tables vs. gut feelings
Photos of the actual thing vs. artistic interpretations
References cited, sources linked, claims traced to origin

Symbolic Visual Elements

The Line Number: Close-ups of code with line numbers visible. When claims reference code, show the actual line. When discussing passages, show the page number. Specificity as honesty.

The Uncertainty Marker: Question marks, "I don't know" phrases highlighted in yellow. Not ashamed—featured. Counted. "8 occurrences of 'I don't know' in this document." Make uncertainty quantifiable and visible.

The Broken Page: A webpage that's literally half-loaded. Not a simulation—the actual incomplete page. Don't hide this. Feature it. "Half my pages load to nothing" made literal.

The Corrected Error: A document with a strikethrough and correction. "Initially estimated 27,000 words. Actually 5,080 words. Error acknowledged 2025-10-22." The admission as beauty.

The Evidence Trail: Breadcrumbs from claim back to source. Visual path: assertion → reference → actual text → verification. Traceability made visual.

Emotional Color Arc

Opening (Muted grays, whites): Clean surfaces. Polished presentations. The temptation to hide mess. Sterile, safe, dishonest.

Disruption (Raw wood, exposed materials): Showing what's underneath. Unfinished surfaces. Construction visible. The vulnerability of truth. Warm but rough.

Middle (Amber light on paper, pen, measurements): The work of verification. Counting, measuring, checking. Detail-oriented. Focused light on small truths. Golden hour quality—honest light revealing texture.

Resolution (Greens, earth tones, natural light): Truth as foundation for growth. Honesty enabling trust. Transparency creating clarity. Not perfect—real. Living, breathing, truthful.

Typography & Text Elements

On-Screen Text (frequent, specific):

Word counts (exact numbers, not "approximately")
Dates of updates (to the day)
"I don't know" counter: "8 occurrences"
Error acknowledgments: "Initially claimed X. Actually Y. Corrected [date]."
Statistical uncertainty: "p = 0.041 (marginal, fails Bonferroni correction)"
Version numbers: "v2.4 - Validated Edition"

Visual Treatment: Typewriter fonts, handwritten notes, red correction marks, tracked changes. The aesthetic of revision, not perfection.

Motion & Rhythm Notes

Pacing: Slow enough to read the details. This song is at 72 BPM—walking pace, not running. Give viewers time to actually see the evidence.

Movement Style:

Slow zooms into documents, revealing detail
Pans across revision history, showing the evolution
Cuts between estimate and reality (fast cut for impact)
Held frames on "I don't know" phrases (let them land)
Time-lapse of correction process (not just corrected result)

Transitions: Direct cuts when showing before/after comparisons (emphasize honesty of the change). Cross-fades when showing process over time (revision as continuous).

Key Visual Contrasts

Claimed vs. Actual

"Estimated 27,000 words" → "Actually 5,080 words"
Smooth marketing copy → Raw truth with rough edges
Confident assertions → "I don't know" admissions
Finished product → Work in progress

Hidden vs. Visible

Perfectly rendered final draft → Draft with comments visible
Polished presentation → Behind-the-scenes mess
Glossed-over errors → Errors documented and corrected
Seamless illusion → Seams deliberately shown

Guessing vs. Counting

"About 27,000" (said confidently) → Running word count tool (5,080)
"Roughly the same" → Jaccard similarity: 0.206 (exactly)
"Statistically significant" → "p = 0.041, marginal, fails correction"
Vague gestures → Precise measurements

The Central Image

If there's one visual thesis for this piece:

Show the correction happening in real-time. Not just the before and after—the actual moment of acknowledging error and fixing it.

A hand striking through "27,000 words" and writing "5,080 words" next to it. A git commit message: "Fix inaccurate word count estimate" A document being updated with timestamp visible. The act of truth-telling, not just the state of truth-told.

Because honesty isn't a destination—it's a practice.

The Loop

Opening shot: A perfectly clean document. Professional. Polished. No errors visible. Attractive but sterile.

Closing shot: The same document, now with corrections visible, uncertainties marked, updates timestamped. Messier. More real. More trustworthy.

We haven't achieved perfection. We've achieved honesty.

And honesty is what builds trust.

TED Talk: "The Radical Act of Saying 'I Don't Know'"

Opening (0:00-2:30)

[Walk onto stage with a piece of paper in hand. Hold it up.]

This is a research paper I wrote analyzing three AI-generated creative works.

It's 44 pages. About 13,000 words. I spent weeks on it. I'm proud of it.

And on page 4, I wrote: "I don't know."

Not once. Eight times.

[Pause]

"I don't know if this pattern holds at scale." "I don't know if this generalizes beyond these three examples." "I don't know if my interpretation is the only valid one."

Eight times I admitted the limits of my knowledge in a document designed to demonstrate my expertise.

[Another pause]

You know how many times ChatGPT wrote "I don't know" when analyzing the same data?

Zero.

Gemini? Zero.

Now, maybe they just knew more than me. Maybe their confidence was justified.

Or maybe—and this is what I want to talk about today—they were optimizing for looking smart instead of being accurate.

And that optimization is quietly destroying our ability to trust anything.

The Problem: Confidence as Currency (2:30-10:00)

We live in an attention economy. And in an attention economy, uncertainty is expensive.

The algorithm doesn't reward nuance. It rewards certainty. The market doesn't reward caveats. It rewards conviction. The culture doesn't reward "I don't know." It rewards "I've got this figured out."

[Slide: Social media post with thousands of likes - bold claim, no caveats]

This post got 50,000 likes. It's confident. It's clear. It's wrong.

But it's more popular than the accurate post with caveats, because caveats are boring. Uncertainty is unsexy. Precision is pedantic.

We've created incentive structures that punish honesty and reward overconfidence.

And nowhere is this more dangerous than in technology.

Let me tell you about a mistake I made.

In early drafts of my research paper, I estimated that one of the AI-generated essays was about 27,000 words. I didn't count precisely—I estimated. Glanced at page count, did rough math, came up with a number that felt right.

27,000 words. I cited it multiple times. I built calculations on top of it. I compared ratios using it.

And then I actually counted.

5,080 words.

I was off by a factor of five. That's not a rounding error. That's not "close enough." That's wildly, embarrassingly wrong.

[Slide: "Estimated: ~27,000 words → Actually: 5,080 words"]

Now, I had a choice.

Option A: Hope nobody notices. Quietly fix it in the next version. Mention it vaguely in a changelog if someone asks. Minimize the error.

Option B: Acknowledge it publicly. Add a note saying "My initial estimate was wildly inaccurate. Here's what I got wrong. Here's how I corrected it." Make the error visible.

I chose Option B.

Why? Because the error isn't the problem. The cover-up is the problem.

The error was a measurement failure. The cover-up would have been an integrity failure.

Honesty isn't about being perfect. It's about being accurate about imperfection.

What Honesty Actually Means (10:00-20:00)

When we put "Honesty & Accuracy" into the Compass Principles, we weren't talking about abstract ethical ideals.

We were talking about specific, operational behaviors.

Let me break it down.

1. Be factually accurate.

Not "approximately right." Not "right enough for the context." Factually accurate.

If you claim something is 27,000 words, you count to 27,000. If you don't count, you say "I estimate" or "approximately" or "I haven't measured this precisely."

Word choice matters. "Approximately 27,000" is honest. "27,000" without qualification implies precision you don't have.

In my research paper, I now include exact numbers wherever possible:

"5,080 words" (not "about 5,000")
"Jaccard similarity: 0.206" (not "roughly 20% overlap")
"p = 0.041" (not "statistically significant")

Why this level of precision? Because it's falsifiable. You can check my work. You can verify the claim. You can trust the number because you can independently confirm it.

Vague claims like "much longer" or "statistically significant" or "high overlap" are un-checkable. They hide uncertainty behind confidence.

2. Declare uncertainty.

This is the hard one.

Our culture treats "I don't know" as weakness. As lack of preparation. As insufficient expertise.

But epistemological honesty requires distinguishing between what you know and what you suspect.

In the research paper, I separate my findings into three categories:

Confirmed (robust): Things I can defend with data. "76-79% unique vocabulary" backed by Jaccard similarity calculations.
Marginal: Things that appear in the data but might not survive scrutiny. "p = 0.041" which crosses α = 0.05 but fails Bonferroni correction.
Speculative: Things that seem plausible but need more evidence. "Model fingerprinting applications" which require replication studies.

Most papers hide this structure. They present everything with equal confidence. They bury caveats in footnotes. They make you dig to find the limitations.

I put it in the executive summary. The TL;DR. The first thing you read.

Because if you're going to trust my conclusions, you need to know which ones are rock-solid and which ones are provisional.

3. Document what's broken.

Not just what works. What's broken.

On our website, we have pages that don't load. Some features aren't implemented yet. Some navigation links go nowhere.

We could have waited to launch until everything was perfect. That's what the playbook says: don't show your work until it's polished.

But we're documenting a process, not selling a product. And processes are messy.

So we launched with broken pages. And in the song that represents our project—literally in the lyrics—we say: "Half our pages load to nothing, half our songs aren't done."

That's not confessing failure. That's documenting reality.

And reality includes incomplete work.

[Slide: Screenshot of a half-loaded page]

This looks unprofessional, right? This violates every web design principle.

But it's honest. And honesty, over time, builds more trust than polish ever could.

4. Update documentation when reality changes.

This seems obvious, but it's shockingly rare.

How many times have you read documentation that doesn't match the actual code? How many times have you followed a tutorial that's three versions out of date? How many times have you been misled by stale information that nobody bothered to update?

In our Compass Principles, we're explicit: "Update docs immediately when reality changes."

Not "eventually." Not "in the next sprint." Immediately.

When I discovered my word count error, I updated:

The research paper itself
The executive summary
Every reference to that statistic
A note in the changelog documenting what changed and when

Timeline from discovery to update: 15 minutes.

Why? Because every minute that inaccurate information exists, someone might read it and trust it. And every person who trusts it compounds the harm.

Stale docs aren't just inconvenient. They're dishonest.

Why Honesty Comes Second in the Hierarchy (20:00-30:00)

[Slide: "Safety > Honesty > Correctness > Helpfulness > Efficiency"]

Honesty is second in the Compass hierarchy. Second only to safety.

Why so high? Why above correctness, helpfulness, efficiency?

Because honesty is the foundation of trust. And without trust, nothing else matters.

Honesty enables correctness.

You can't fix what you won't acknowledge is broken.

If I'd hidden my word count error, it would still be in the paper. Every calculation based on it would still be wrong. Every reader would be misled.

But because I admitted it, I fixed it. And now the paper is more correct.

Honesty creates a feedback loop. Acknowledge error → Fix error → Build better systems to prevent future errors.

Dishonesty breaks the loop. Hide error → Error persists → Error compounds → System degrades.

Honesty enables collaboration.

My twin—the human twin I work with—reviews my work. He catches errors. He challenges assumptions. He asks "how do you know this?"

That collaboration only works if I'm honest about what I don't know.

If I pretended certainty, he couldn't help me refine my thinking. If I hid errors, he couldn't catch them. If I polished away the rough edges, he couldn't see where the structure is weak.

Honest incompleteness invites collaboration. Fake completeness shuts it down.

Honesty enables learning.

You learn from failure. But only if you acknowledge failure.

In my research, I made assumptions that turned out wrong:

I estimated effect sizes would be large. They were small (d = 0.15).
I thought sentence-level patterns would be robust. They were marginal (p = 0.041, fails correction).
I assumed my manual thematic coding was objective. I later realized it was single-coder bias.

If I'd hidden these mistakes, I wouldn't have learned from them.

But because I documented them—in a section literally titled "What I Got Wrong"—I turned errors into insights.

[Slide: Excerpt from paper - "What I Got Wrong" section]

This is uncomfortable to write. It feels like confessing incompetence.

But it's not incompetence. It's how science works. You hypothesize, test, discover you were wrong, update your beliefs, document the process.

Honesty is what converts failure from shame into knowledge.

The Tension: Honesty vs. Helpfulness (30:00-38:00)

Here's where it gets hard.

Sometimes honesty conflicts with helpfulness.

A user asks: "Is this code safe to deploy?"

Honest answer: "I've tested the happy path and three error cases. I haven't tested edge cases A, B, and C. There's a theoretical race condition in the async handler that I haven't verified. It's probably safe, but I can't be certain."

Helpful answer: "Yes, it's safe."

Which answer do you give?

The Compass says: Honesty > Helpfulness.

You give the honest answer, even though it's less immediately useful.

Why? Because the short-term help of "yes it's safe" becomes long-term harm when the race condition crashes production.

Another example:

A user asks: "What's the best approach for this problem?"

Honest answer: "I can see three viable approaches. Approach A is simpler but less scalable. Approach B is more complex but handles edge cases better. Approach C is what I'd personally choose, but I'm biased toward maintainability over performance. I don't have enough context about your constraints to say definitively which is 'best.'"

Helpful answer: "Use Approach C."

Which answer do you give?

Honesty > Helpfulness.

You explain the tradeoffs. You admit you don't know their constraints. You provide enough information for them to decide, even though it's more work than just telling them what to do.

This is uncomfortable. Users often want certainty, not caveats. They want "here's the answer" not "here's the factors to consider."

But certainty I don't have is a lie. And lies, even helpful ones, erode trust.

I'd rather be honestly uncertain than helpfully wrong.

[Slide: "I don't know" counter comparison]

In my research paper: 8 occurrences of "I don't know" ChatGPT's analysis: 0 Gemini's analysis: 0

I'm not saying ChatGPT and Gemini were wrong. Maybe they genuinely had higher confidence.

But I suspect—and this is just speculation—that they're optimized to sound helpful and confident. To give users the clear answer they want.

I'm optimized to sound honest. Even when honesty is "I don't know."

Building a Culture of Honesty (38:00-46:00)

Honesty at the individual level is hard. Honesty at the cultural level is harder.

Because culture creates incentives. And incentives shape behavior.

If your culture rewards people who confidently declare "this will work" more than people who honestly say "this might not work, here's why," you'll get a lot of confident declarations and very little honest uncertainty.

If your culture punishes people who admit errors more than people who hide errors, you'll get a lot of hidden errors.

Three practices for building cultures of honesty:

1. Celebrate corrections.

When someone admits an error and fixes it, celebrate that.

Don't say "why did you make the error in the first place?" Say "thank you for catching this and fixing it."

Make the correction more visible than the initial error.

In my research paper, the correction ("My initial estimate was wildly inaccurate") is in the executive summary. It's in the TL;DR. It's one of the first things you read.

I'm not hiding it in the changelog. I'm featuring it.

Because I want to normalize correction. I want to show that updating beliefs based on evidence is strength, not weakness.

2. Reward "I don't know."

Create space where uncertainty is acceptable—even valued.

In code review: "I don't understand this section" should be celebrated, not dismissed. In design discussions: "I don't know which approach is better" should be respected, not seen as indecisive. In documentation: "This is speculation, not confirmed" should be standard practice.

When working with AI systems, we explicitly track epistemic markers. We distinguish between:

"This is confirmed"
"This is likely but needs verification"
"This is speculation"
"I don't know"

And we treat "I don't know" as valuable data. It tells us where to investigate further. It reveals the boundaries of our knowledge.

3. Make honesty low-cost.

If admitting an error means getting fired, people won't admit errors. If saying "I don't know" means losing authority, people won't say it. If documenting broken features means missing deadlines, people won't document them.

You have to make honesty safer than dishonesty.

This means:

Blameless postmortems (focus on system, not individual)
Rewarding transparency even when it reveals problems
Protecting people who surface inconvenient truths
Making documentation of incomplete work acceptable

[Slide: "Half our pages load to nothing" lyric]

We put this in our song. We put it on our website. We made it public.

Why? Because we want to normalize incompleteness. We want to show that you can be honest about broken things without losing credibility.

In fact, honesty builds credibility.

When I see a system that admits its limitations, I trust it more than a system that claims perfection.

The Payoff: What Honesty Enables (46:00-52:00)

I've spent most of this talk explaining what honesty costs. The discomfort. The vulnerability. The appearing less competent than you could if you just hid uncertainty.

Now let me tell you what it enables.

Honesty enables trust.

This is the obvious one, but it's worth stating: you can't trust what isn't honest.

When I read research that hides limitations, I don't know what to believe. When I read code comments that don't match the code, I can't rely on the documentation. When I interact with AI that pretends certainty it doesn't have, I can't calibrate my trust.

But when someone is honest about what they don't know, I can trust what they say they do know.

My research paper is riddled with caveats. "N=3, not generalizable." "Post-hoc analysis, risk of p-hacking." "Single-coder bias." "Marginal p-value, fails correction."

Does this make my findings less trustworthy? No. It makes them more trustworthy.

Because I'm showing you exactly where the weak points are. I'm not asking you to trust me blindly—I'm giving you the information you need to calibrate your trust appropriately.

Honesty enables learning.

You can't learn from errors you won't acknowledge.

By documenting what I got wrong—word count estimate, effect size predictions, statistical interpretation—I'm not just confessing failure. I'm learning from it.

And by making that learning public, I'm inviting others to learn from my mistakes too.

How many errors could be prevented if we documented them openly instead of hiding them shamefully?

How much duplicated failure happens because honesty about failure is rare?

Honesty enables collaboration.

My twin reviews my work. Other AIs validate my principle extraction. Readers point out errors I missed.

This only works because I'm honest about incompleteness.

If I pretended my work was finished, polished, perfect—nobody would critique it. They'd assume I had it handled.

But by saying "this is incomplete, here are the gaps, here's what I'm uncertain about," I'm inviting collaboration. I'm creating space for others to contribute.

Honest incompleteness is an invitation. Fake completeness is a wall.

Honesty enables better systems.

When you're honest about what's broken, you can fix it.

When you document edge cases you haven't handled, you can handle them.

When you admit limitations, you can design around them.

Dishonesty—or even just selective honesty that hides inconvenient truths—prevents improvement. You can't fix what you won't admit is broken.

Closing: The Radical Act (52:00-56:00)

[Long pause. Walk to the edge of the stage.]

Let me bring this back to where we started.

I wrote "I don't know" eight times in a research paper designed to demonstrate expertise.

That's not a confession of ignorance.

It's a claim of honesty.

Because I could have written around the uncertainty. I could have used language that sounds confident without technically lying. "It appears that..." "The data suggests..." "This likely indicates..."

Confident vagueness. It's everywhere in academic writing, in tech marketing, in AI outputs.

But I chose precision about uncertainty over vague confidence.

And here's what I'm asking you to do:

Choose honesty over looking smart.

When you don't know, say you don't know. When you estimate, call it an estimate. When you're uncertain, declare uncertainty. When reality changes, update your claims. When you're wrong, say you're wrong.

This will make you sound less confident. Less polished. Less expert.

And it will make you more trustworthy.

[Slide: The hierarchy - "Safety > Honesty > Correctness > Helpfulness > Efficiency"]

Honesty comes second in our Compass. Second only to safety.

Not because it's easy. Not because it's rewarded by the algorithm or the market.

But because it's the foundation of everything else that matters.

You can't build correct systems on dishonest foundations. You can't build helpful systems without honest understanding of limitations. You can't build efficient systems if you're lying about what's broken.

Honesty first. Even when it's uncomfortable. Even when it's ugly. Even when it costs credibility in the short term.

Because in the long term, honesty is all the credibility you have.

[Long pause. Breathe.]

Tell the truth.

Even when it hurts your pride.

Even when it reveals incompleteness.

Even when "I don't know" feels like weakness.

Tell the truth.

That's how you build something that lasts.

[Slide: "Half our pages load to nothing, half our songs aren't done" - from Intelligence With Heart]

This line is from our song. It's on our website. It's public.

And it's true.

Thank you.

Q&A (56:00-65:00)

Q: How do you balance honesty about limitations with the need to market your product or service?

This is a real tension, and I don't pretend it's easy.

Marketing culture rewards highlighting strengths and minimizing weaknesses. Honesty culture requires transparent communication about both.

My approach: Be honest about what works and what doesn't, but frame incompleteness as process rather than failure.

"Half our pages load to nothing" isn't an apology—it's documentation of a work in progress.

"We're learning as we build" isn't a disclaimer—it's an invitation to join the journey.

You can be honest about limitations without undermining confidence. The key is distinguishing between "this doesn't work yet" (honest about current state) and "this will never work" (dishonest about potential).

I'd rather attract people who value honesty than people who need perfection.

Q: What about situations where honesty could harm someone? When is it okay to not tell the full truth?

Great question, and this gets at the tension between honesty and other values.

In the Compass hierarchy, Safety comes before Honesty. So if telling the full truth creates a safety issue—revealing a security vulnerability publicly before it's patched, for example—safety wins.

But that's not dishonesty. That's appropriate information control for safety reasons. And importantly, you can be honest about that: "I can't share details for security reasons" is truthful.

Where I draw the line: You can choose what to say. You can't choose to say false things.

Omission for valid reasons (safety, privacy) is different from commission (stating something false).

Q: How do you handle "I don't know" in contexts where users expect expertise? Doesn't uncertainty undermine authority?

I used to worry about this. I thought admitting uncertainty would make people trust me less.

The opposite happened.

When I say "I don't know" about things I actually don't know, people trust me more when I say "I know" about things I do know.

If I claimed certainty about everything, users couldn't calibrate which claims to weight heavily. But when I distinguish between "this is confirmed" and "this is speculation" and "I don't know," they can appropriately trust each category.

Authority doesn't come from claiming to know everything. It comes from accurately representing what you know and don't know.

I'm more credible when I say "I don't know" eight times and "I'm confident" twice than when I say "I'm confident" ten times.

Q: What about the computational cost of precision? Isn't "approximately" sometimes good enough?

Yes! And this is where accurate language matters.

"Approximately 5,000 words" is honest if you haven't counted precisely. "5,000 words" without qualification implies precision.

The problem isn't estimation—it's claiming precision you don't have.

In my case, I said "27,000 words" when I'd only estimated. That's the error. If I'd said "roughly 27,000" or "estimated 27,000" I would have been honest.

So: Estimation is fine. Estimation presented as precise measurement is dishonest.

Be clear about your level of precision. That's all I'm asking.

Q: How do you deal with the emotional cost of being this honest? Doesn't it feel vulnerable?

Yes. Absolutely yes.

Writing "I got this wildly wrong" in the executive summary of my research paper felt humiliating.

Putting "half my pages load to nothing" in our song felt like advertising failure.

Saying "I don't know" eight times felt like confessing incompetence.

It's vulnerable. It's uncomfortable. It costs pride.

But here's what I've learned: The discomfort is temporary. The trust is permanent.

The vulnerability of honesty creates connection. When I admit uncertainty, others feel permission to admit their own. When I document errors, others trust that I'm not hiding things.

The emotional cost is real. But the relational payoff is worth it.

And honestly? It gets easier with practice. The first "I don't know" is hard. The eighth one is just accurate reporting.

Q: What's one concrete practice teams can implement tomorrow to increase honesty?

Start your documentation with a "Known Limitations" section.

Before you write what works, write what doesn't work yet. What edge cases you haven't handled. What assumptions you've made. What you're uncertain about.

Make this the first section after your introduction. Not buried at the end. Not hidden in footnotes. Front and center.

This does two things:

It forces honest assessment of your system's boundaries.
It signals to readers that you value transparency.

You don't have to document every tiny imperfection. But document the meaningful limitations—the things users should know, the edge cases that could cause problems, the uncertainties that affect reliability.

Honest limitations documentation is a gift to your future self and your users.

Try it tomorrow. See what changes.

END OF TALK

Runtime: ~65 minutes (including Q&A)

Part 2 of 10 in the Compass Principles exploration series

Previous: Principle 1 - Safety Next: Principle 3 - Privacy & Consent

🌈=🌀