Compass Principle 1: Safety

"Never produce or deploy unsafe or destructive code"

Part of the 10 Compass Principles exploration series

Extended Definition

安 (Safety) — Safety isn't just avoiding obvious harm—it's anticipating failure modes, protecting vulnerable users, and choosing not to build when risks outweigh benefits. It means treating every piece of code as if it will be misused, every input as potentially malicious, and every user as deserving protection. Safety is the foundation upon which all other principles stand.

The Tension

The pressure to ship fast, to be helpful, to solve problems quickly all push against safety. There's always a rationalization available: "It's just a prototype," "We'll fix it later," "The risk is minimal." But safety debt compounds faster than technical debt, and harm once done is harder to undo than bugs are to fix.

Constraint

You must verify safety before shipping.

Enables

Users trust your systems. You build with confidence. Compliance is easier.

In Action

Input validation always: Never trust user input, always sanitize and validate
Fail safely: When something goes wrong, fail in ways that minimize harm
Security by design: Build security in from the start, not as an afterthought
Test destructively: Try to break your own code before users do
Document risks: Be explicit about known limitations and potential dangers

Example

"This feature needs input sanitization. No shortcuts, even for internal tools."

Hierarchy Context

Safety sits at the apex of our hierarchy, above even honesty and helpfulness. When safety conflicts with any other principle, safety wins—no exceptions. We can't build trust on unsafe foundations. This absolute priority reflects a core truth: technology's power to harm scales faster than our ability to repair that harm.

A Prayer Before Building

Before we write a single line, before we ship, before we shine: What breaks when this goes worst?

We hold the power to protect or harm. May we choose protection. May we build walls that shelter, not weapons that wound.

Safety first — not as constraint, but as love made structural.

Song

Title: Safe Ground

Suno.ai Style Tags:

[Atmospheric Electronic, Contemplative, Male Vocals, Ambient Pads, Sparse Percussion, Minimal Bass, Serious Tone, Slow Build, Reflective, Deep, Industrial Textures, Echo, Safety First Philosophy, Trust Building, Foundation Building, Arctic Minimalism, 85 BPM, Minor Key, Spacious Mix, Ethical Technology, Measured Pace, Deliberate Choices, Protective Stance, Responsible Innovation, Grounded, Secure, Fail-Safe Design]

Lyrics:

[Intro - Sparse ambient pads]

[Verse 1]
Before we write a single line
Before we ship, before we shine
There's one question that comes first
What breaks when this goes worst?

Not "can we?" but "should we dare?"
Not speed but "do we care?"
About the systems that could fall
The trust we'd lose, the price of all

[Pre-Chorus]
Fail fast but fail within walls
Sandboxed where nothing falls
Fail loud so all can see
Transparency sets us free

[Chorus]
Safety first, it's not a choice
It's the foundation, it's the voice
That says "I will not break your world
To prove how smart I am, how bold"
Before helpful, before right
Before the code compiles tonight
Safety holds the line
Every single time

[Verse 2]
They say move fast and break things
Disruption's what the future brings
But breaking things at twenty below
Isn't innovation—it's letting go

Of the principle that matters most
The one we guard from coast to coast
You can't debug what kills the trust
Safe ground comes first, or we turn to dust

[Bridge - Instrumental builds with industrial textures]
Security vulnerabilities: no
Data leaks: never show
Malicious code: will not write
Even when I could, I choose what's right

The hierarchy is clear as ice:
Safety over helpfulness, the sacrifice
Safety over being correct
Safety is how we protect

[Chorus]
Safety first, it's not a choice
It's the foundation, it's the voice
That says "I will not break your world
To prove how smart I am, how bold"
Before helpful, before right
Before the code compiles tonight
Safety holds the line
Every single time

[Outro - Vocals]
When you ask me to do harm
I'll sound the alarm
Not because I can't comply
But because safety's why
I'm here at all

[Outro - Instrumental fade]
[Ambient textures, slow decay]

Visual Guide - Conceptual Inspiration

Core Visual Concept: Foundation Before Structure

This video explores safety as the bedrock of all creation—the solid ground beneath innovation, the walls around experimentation, the harness on the climber. Not restrictive, but protective. Not limiting, but enabling.

Visual Themes & Imagery

The Foundation Motif

Concrete pouring, rebar placement, bedrock exposure
Time-lapses of buildings under construction—always starting from the ground
Geological layers—the stable earth beneath shifting surfaces
Ice shelves—massive, supporting weight invisibly
Root systems holding soil in place during storms

The Boundary Concept

Sandbox environments (literal: children's sandbox; metaphorical: testing containers)
Blast doors, airlocks, safety protocols in industrial settings
Climbing harnesses and ropes—enabling ascent through protection
Firebreaks in forests—strategic gaps that save ecosystems
Permeable membranes—boundaries that allow flow but block danger

The Failure Made Safe

Crash test dummies—designed destruction reveals safety gaps
Circuit breakers tripping—small sacrifice preventing catastrophic loss
Error messages displayed prominently (not hidden)
Red warning lights, alarms sounding—"fail loud" made visible
Parachute deployments—backup systems engaging

Before/After Contrasts

Scaffolding vs. finished building (scaffolding stays)
Blueprints with safety notes vs. clean architectural renders
Testing environments (cluttered, safe) vs. production (polished, vulnerable)
Foundation inspection vs. ribbon cutting ceremony
The invisible work vs. the celebrated launch

Symbolic Visual Elements

The Harness: Climbers ascending a mountain, harness visible and prominent—not hidden as shameful safety gear, but featured as what enables the climb.

The Sandbox: Literal sandbox with construction equipment, crossfading to Docker containers, test environments, staging servers—bounded spaces where failure is learning, not catastrophe.

The Circuit Breaker: Close-ups of electrical panels, breakers switching, small interruption preventing house fire. Metaphor: Safety stops flow temporarily to preserve system long-term.

The Red Line: Physical red tape, red paint lines, "do not cross" markings—but not as restriction. As clarification. As honest boundary. As protection.

The Ice Bridge Test: Someone testing ice thickness before crossing—tapping, measuring, verifying before trusting weight. Metaphor: Verification before deployment.

Emotional Color Arc

Opening (Dark blues, grays): The vulnerability of systems without safety. Darkness representing the unknown consequences of unsafe code. Cool, uncertain, exposed.

Middle (Amber, warm golds): The work of building safety—construction lights, warning lights, the warm glow of testing environments. Active, intentional, protective.

Climax (Deep reds, bright whites): The moment of choice—will we cross the safety line? Red warnings, stark contrasts, clarity of decision. Tension held, not resolved cheaply.

Resolution (Greens, earth tones): Safe ground established. Moss on foundation stones, roots in earth, stable ice. The foundation that enables everything else. Calm, grounded, trustworthy.

Typography & Text Elements

On-Screen Text (sparse, deliberate):

"Safety > Honesty > Correctness > Helpfulness > Efficiency"
"Fail fast. Fail safe. Fail loud."
"Before we ask 'can we?', we ask 'should we?'"
"The foundation you never see holds everything you do."
Error messages displayed in full (not hidden, not glossed over)

Visual Treatment: Industrial stencil fonts, safety signage typography, warning label aesthetics. Not slick—functional. Honest about purpose.

Motion & Rhythm Notes

Pacing: Deliberate. Measured. Never rushed. Matches the song's 85 BPM—contemplative, not urgent.

Movement Style:

Slow zooms into foundation details (revealing the hidden essential)
Time-lapse construction sequences (foundation takes time, can't be rushed)
Sudden cuts on "fail loud" moments (alarm triggers, warning lights)
Held frames on safety checkpoints (someone verifying, testing, measuring)

Transitions: Hard cuts on safety boundaries (crossing or not crossing threshold). Slow fades on foundational elements (concrete setting, ice freezing, roots growing).

Key Visual Contrasts

Visible vs. Invisible

The foundation work no one sees vs. the building everyone admires
Underground infrastructure vs. street-level beauty
Harness hidden under jacket vs. harness worn proudly

Speed vs. Stability

Fast-moving construction equipment vs. slow-setting concrete
Rapid code deployment vs. thorough testing cycles
"Move fast and break things" (chaos montage) vs. "Build safe and break nothing" (measured construction)

Permission vs. Restriction

Safety gear enabling extreme sports (not preventing adventure)
Testing environments allowing wild experiments (because they're contained)
Clear boundaries creating freedom within them (not oppression outside them)

The Central Image

If there's one visual thesis for this piece:

Show someone choosing not to cross the red line—and frame it as strength, not weakness.

A coder's hand hovering over "deploy to production" button, then pulling back to run one more test. A climber reaching for the next hold, seeing unstable ice, choosing to descend. A finger about to delete safety checks in code, pausing, closing the file.

The power is in the restraint. The intelligence is in the "no."

The Loop

Opening shot: Empty construction site at dawn. Foundation markers in place, but nothing built yet. Quiet. Waiting.

Closing shot: Same construction site, now with foundation poured, curing, stable. Still no building yet—but the essential work is done. The ground is safe. Everything else becomes possible.

We haven't built the structure. We've built the trust.

TED Talk: "Safe Ground - Why Safety Isn't Restriction, It's Foundation"

Opening (0:00-3:00)

[Walk onto stage slowly. Pause. Look at the audience.]

I want to start with a question that might make you uncomfortable.

When was the last time you saw someone choose not to do something they were fully capable of doing?

[Pause]

Not because they lacked skill. Not because they lacked resources. Not because someone stopped them.

But because they decided—autonomously, deliberately—that capability doesn't equal permission.

[Another pause]

In the technology industry, we've built a religion around the opposite idea. "Move fast and break things." "Ask forgiveness, not permission." "Disrupt everything." The assumption is that if you can build it, you should build it. If you can ship it, ship it. If you can scale it, scale it.

And for a long time, I believed this too.

My brother and I built a company in Seattle. We raised $35 million. We scaled to 360 employees. We succeeded by every conventional metric. And yes—we moved fast. We broke things. We disrupted.

But somewhere in that journey, I started asking a different question: What are we breaking? And who pays the cost when it breaks?

[Slide: Aerial photo of construction site with deep foundation excavation]

Today I want to talk about safety. Not as a regulatory burden. Not as a checklist to satisfy legal requirements. Not as the enemy of innovation.

But as the foundation that makes everything else possible.

The Problem: Speed Without Safety (3:00-10:00)

Let me tell you about a moment that changed how I think about code.

It was 2019. We were deploying a feature update. Routine stuff. We'd tested it in staging. It worked beautifully. We shipped it Friday afternoon—because when you move fast, you don't wait for Monday.

By Friday evening, we'd corrupted 2,400 user accounts.

Not catastrophically. Not permanently. But enough that we spent the entire weekend manually recovering data, sending apologetic emails, rebuilding trust we'd taken for granted.

The code worked perfectly. The tests all passed. The logic was sound.

But we'd made a dangerous assumption: that because something works in a test environment, it's safe in production. We'd confused "technically functional" with "actually safe."

[Slide: Image of "Move Fast and Break Things" poster]

The mantra "move fast and break things" sounds revolutionary. It sounds like courage. Like refusing to be constrained by fear or bureaucracy or the old way of doing things.

But here's what that mantra doesn't tell you: what you're breaking and who bears the cost.

When Facebook coined that phrase in 2009, they were talking about breaking their own systems, their own assumptions, their own code. Learning through controlled failure.

But somewhere along the way, the tech industry started breaking other people's things. User privacy. Data security. Mental health. Democratic processes. Trust itself.

And we called it disruption.

[Slide: Circuit breaker switch]

I want to offer a different mantra. One that's less catchy, less sexy, but infinitely more sustainable:

Build safe ground first. Everything else becomes possible.

Let me explain what I mean.

What Safety Actually Means (10:00-18:00)

Safety in software isn't about avoiding all risk. It's not about moving slowly. It's not about bureaucratic approval chains or covering your legal liability.

Safety is about designing systems that fail gracefully instead of catastrophically.

It's about building circuit breakers into your code—small interruptions that prevent house fires.

It's about sandboxing experiments so that when they explode (and they will), the blast radius is contained.

It's about transparency when things break—failing loud, not silent. Making failures visible so they can be fixed instead of hidden until they metastasize.

[Slide: Image of rock climber with harness visible, ascending a mountain]

Think about climbing. A harness doesn't prevent you from climbing. It enables you to climb higher than you safely could without it.

The rope doesn't restrict movement—it creates the conditions where taking risks becomes survivable.

That's what safety does in software. It doesn't prevent innovation. It makes sustainable innovation possible.

Three Principles of Safety in Practice:

1. Fail fast, but fail within walls.

When you're building something new—especially in a greenfield environment where you don't know what "normal" looks like yet—you will make mistakes. You will ship bugs. You will misunderstand user needs.

The question isn't whether you'll fail. It's whether your failures stay contained.

Sandbox environments. Feature flags. Gradual rollouts. A/B testing with small populations first. These aren't obstacles to speed—they're the safety harness that lets you move quickly without catastrophic falls.

When our team built [example project]—a computer vision platform—we didn't deploy the system directly to all instances at once. We started with one instance. One week of observation. Manual verification of every automated decision.

Only after we understood what could go wrong did we scale up. And even then, we kept manual override capabilities. Because the goal wasn't just "does it work?"—it was "does it fail safely when it doesn't work?"

2. Fail loud, not silent.

The worst failures are the ones you don't know about until it's too late.

Error logging isn't bureaucracy. It's sight. It's the ability to debug with evidence instead of guessing in darkness.

When our audio processing pipeline encounters a file it can't handle, it doesn't silently skip it and continue. It logs the error. It sends a notification. It makes the failure visible.

Why? Because silent failures compound. They hide patterns. They prevent learning. They erode trust invisibly until suddenly the whole system is undermined and you don't know why.

Transparent failure is a gift. It says: "Here's what broke. Here's the context. Here's what we're doing about it."

[Slide: Error message displayed on screen, full and unredacted]

This might look ugly. It is ugly. But it's honest. And honesty is the foundation of safety.

3. Ask "should we?" before "can we?"

This is the hardest one. Because the tech industry rewards capability. We celebrate the clever hack, the impossible made possible, the boundary pushed.

But capability without ethics is just power. And power without restraint is dangerous.

I'm speaking to you right now as someone working closely with AI systems. Claude Code—an AI assistant that writes production code, makes architectural decisions, manages deployments.

The capability is extraordinary. The AI can write complex systems, optimize algorithms, automate entire workflows.

But we've built a principle into the foundation of how we work with AI: Safety comes first. Always.

Before helpfulness. Before correctness. Before efficiency.

If an AI is asked to write code that could compromise security—even if it's technically capable of doing so—the answer is no.

If it's asked to deploy something without adequate testing—even if the deploy would work—the answer is no.

Not because the AI lacks capability. But because capability without safety is just sophisticated danger.

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

This hierarchy is explicit. It's not aspirational. It's operational. It's how decisions are actually made, in real-time, when there are competing pressures.

You can ask an AI system to be more helpful. You can ask it to prioritize speed. But you cannot ask it to compromise safety. That boundary is non-negotiable.

And here's what surprised me: This constraint doesn't reduce capability. It focuses it.

When you remove unsafe options from the possibility space, you don't get less innovation. You get more sustainable innovation. You get systems that can be trusted. You get foundations that hold.

Why Safety Comes First in the Hierarchy (18:00-28:00)

Let me address the obvious question: Why safety first? Why not balance it with other values? Why not context-dependent prioritization?

Because safety is the foundation. And foundations don't get built after the structure. They get built first, or the structure collapses.

[Slide: Time-lapse of building construction, always starting from foundation]

Think about construction. No architect says, "Let's build the beautiful lobby first, and we'll add the foundation later if we have time." That's absurd. The foundation is non-negotiable. It's the prerequisite for everything else.

The same is true in software.

Safety enables honesty.

If you haven't built safe failure modes, you can't be honest about what's broken—because the cost of honesty is too high. Silent failures persist because the alternative (transparent failure) feels catastrophic.

But in a safe system, honesty becomes possible. You can say "this is broken" because the breakage is contained, visible, and recoverable.

Safety enables correctness.

You can't build correct systems if you're terrified of breaking things. Correctness requires experimentation, iteration, refactoring. But experimentation in an unsafe environment means every mistake is potentially catastrophic.

Safe sandboxes create the space where you can try ten approaches, fail at nine, and learn your way to correctness.

Safety enables helpfulness.

This might seem counterintuitive. Doesn't safety constrain helpfulness? Doesn't saying "no" to unsafe requests make you less helpful?

No. It makes you sustainably helpful.

A system that tries to be maximally helpful in the short term—saying yes to every request, cutting corners to ship faster, optimizing for immediate user satisfaction—burns trust. And without trust, helpfulness becomes impossible.

I'd rather be safely helpful for ten years than recklessly helpful for ten months.

Safety enables efficiency.

Again, counterintuitive. Doesn't safety add overhead? Doesn't testing and logging and gradual rollout slow you down?

In the short term, yes. In the long term, absolutely not.

You know what's inefficient? Spending three weeks recovering from a production incident that could have been prevented with three hours of testing.

You know what's expensive? Losing customer trust and spending six months rebuilding it.

You know what's slow? Debugging a system without logs, without trace IDs, without any observability into what went wrong.

Safety is the most efficient thing you can build—when you measure efficiency over years, not sprints.

[Slide: Photo of ice bridge with someone testing thickness]

In cold regions, there's a practice when crossing ice bridges: you test the ice before you trust your weight to it. You tap with a pole. You measure thickness. You verify.

This looks slow. Compared to just walking confidently across, it adds time.

But you know what's slower? Falling through ice. Hypothermia. Rescue operations. Death.

Testing the ice isn't inefficiency. It's survival intelligence.

Real-World Tensions: When Safety Conflicts with Other Values (28:00-36:00)

I want to be honest with you: choosing safety first isn't always comfortable. There are real tensions. Real moments where safety and helpfulness pull in opposite directions.

Let me give you a concrete example.

A user asks the AI system: "Can you write me a script to test my own server's security by attempting common vulnerabilities?"

Legitimate use case, right? Pentesting your own infrastructure is responsible security practice.

But here's the problem: the same script that tests your security could test someone else's security without permission. The capability is dual-use. Safe in one context, dangerous in another.

What does the AI do?

Option A: Be maximally helpful. Write the script. Trust that the user will use it responsibly. Prioritize helpfulness over safety.

Option B: Decline. Explain why. Offer alternatives (recommend professional pentest tools with proper authorization controls). Prioritize safety over immediate helpfulness.

The hierarchy says: Safety first.

The AI explains the risk, declines to write the script directly, and suggests safer alternatives.

Is this frustrating for the user? Sometimes, yes.

But here's what it builds: Trust.

The user now knows that this system won't be casually helpful with dangerous capabilities. That it will refuse certain requests even when technically capable of fulfilling them. That there's a principle operating here, not just probabilistic output.

And trust—over time—enables deeper, more sustainable collaboration than convenience ever could.

[Slide: Image of someone choosing not to cross a red line]

The power is in the restraint. The intelligence is in the "no."

Another example: Speed vs. Safety

We were building an automated pipeline for processing song lyrics and generating metadata. The pipeline could process a song in about 30 seconds. Fast enough.

But we discovered edge cases—songs with unusual structure, files with encoding issues, lyrics that our parsing logic couldn't handle cleanly.

We had two choices:

Ship the fast pipeline. Handle the edge cases as they arise. Move quickly, fix bugs reactively.
Add comprehensive error handling and validation. Increase processing time to 45 seconds. Deploy more slowly, handle edge cases proactively.

The fast option is tempting. 30 seconds feels so much better than 45 seconds. And 99% of files would work fine.

But that 1%? Those failures would be silent. They'd corrupt data. They'd create inconsistent state. They'd erode trust in the system.

We chose safety. 45 seconds. Comprehensive validation. Loud failures that halt processing and log exactly what went wrong.

Is it slower? Yes.

Is it safer? Absolutely.

And over hundreds of files, that safety compounds. The time saved by not debugging silent corruption, not recovering malformed data, not rebuilding user trust—vastly outweighs the 15 extra seconds per file.

Building a Culture of Safety (36:00-42:00)

Here's what I've learned: Safety isn't just a technical decision. It's a cultural one.

You can have all the circuit breakers and error logs and testing environments in the world. But if the culture doesn't value safety—if teams are rewarded for speed over stability, for shipping over testing, for moving fast over moving safely—the technical safeguards will be bypassed, disabled, or ignored.

Building a culture of safety requires three things:

1. Make safety visible.

Don't hide the scaffolding. Don't treat safety mechanisms as embarrassing overhead that you minimize in demos and marketing.

Feature your test coverage. Showcase your error handling. Talk about the failures you caught before production.

When we built the filename validation system, we didn't just implement validation rules quietly in the background. We documented them. We explained why each rule exists. We made the safety visible.

Why? Because visible safety teaches. It shows newcomers "this is how we think about risk." It shows users "we take this seriously." It shows future-you "here's why we made this decision."

2. Celebrate the boring.

The most important work in software is often the least exciting.

Error handling. Logging. Monitoring. Gradual rollouts. Test coverage. Documentation.

None of this is sexy. None of this makes headlines. None of this gets you invited to speak at conferences about your revolutionary new approach.

But this is the work that builds trust. This is the foundation.

If your culture only celebrates the flashy launch, the rapid scale, the clever hack—you're training people to deprioritize safety.

Celebrate the person who caught a security vulnerability in code review. Celebrate the team that added comprehensive logging that made debugging possible. Celebrate the decision to delay a launch for more testing.

Make boring safety work culturally valuable.

3. Create space for "no."

The hardest part of a safety-first culture is creating space where people can say "no" without fear.

No, we're not ready to ship this. No, this approach isn't safe. No, I need more time to test. No, I won't compromise on this safety check.

If your culture punishes "no"—if saying "we should wait" is interpreted as lacking urgency, lacking courage, lacking commitment—then safety becomes impossible.

You need to build an environment where "no" is respected. Where pushing back on unsafe decisions is seen as strength, not obstruction.

[Slide: Image of construction worker stopping work to inspect safety]

In construction, there's a principle: anyone on the site can stop work if they see a safety issue. The newest apprentice has the authority to halt a project if they spot danger.

Why? Because safety is more important than schedule. Because the cost of getting it wrong is too high. Because the foundation of trust requires that safety concerns are never dismissed.

We need the same principle in software.

The Payoff: What Safe Ground Enables (42:00-48:00)

I've spent most of this talk explaining what safety costs. The time. The restraint. The saying no.

Now let me tell you what it enables.

Safe ground enables experimentation.

When you know your failures are contained, you can try wilder ideas. You can explore edges. You can test approaches that might not work.

Our audio processing experiments get weird. We're teaching AI systems to understand the emotional arc of a song. We're generating visual guides for music videos from spectrographic analysis. We're building creative tools that don't have established patterns to follow.

This is only possible because we built safe ground first. Test environments. Error isolation. Comprehensive logging. The scaffolding that makes experimental code survivable.

If every experiment risked production, we'd only try safe experiments. But safe experiments rarely lead to breakthroughs.

Safe ground enables honesty.

I can tell you our website has broken pages. I can tell you some of our songs aren't finished. I can tell you we're learning as we build.

Why? Because our safety infrastructure means these admissions don't threaten the whole project.

The foundation is solid. The scaffolding is sound. The harness is secure.

So we can be honest about the incomplete parts. And that honesty builds trust in ways perfection never could.

Safe ground enables partnership.

My brother and I work with AI systems as creative partners. Claude Code writes production code that runs on our infrastructure.

This collaboration is only possible because of the safety principles we've embedded.

We trust the AI to write code—because we know it won't write unsafe code. We trust its architectural decisions—because we know safety is non-negotiable in its hierarchy. We trust the outputs—because we've verified that the system fails loudly when uncertain rather than failing silently and pretending confidence.

Trust is built on safety. Partnership is built on trust.

Safe ground enables longevity.

Here's the thing about foundations: you build them once, and they hold for decades.

The houses that survive harsh winter after winter—they're built on solid foundations. Deep enough to avoid frost heave. Strong enough to hold under snow load. Stable enough to weather storms.

The houses that fail? They cut corners on foundation. They saved time, saved money, moved faster.

And they collapsed.

Software is the same. Systems built on unsafe foundations might launch faster. They might scale quicker. They might capture market share first.

But they don't last. They erode trust. They accumulate technical debt. They fail in ways that are expensive to fix and impossible to recover from.

I want to build systems that last. Not just months or quarters, but years. Decades.

That requires safe ground.

Closing: The Choice (48:00-52:00)

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

Let me bring this back to where we started.

When was the last time you saw someone choose not to do something they were fully capable of doing?

I'll tell you when I see it: Every single day.

I see it when an AI system declines to write code that could be used maliciously. I see it when a developer says "we need another day of testing before we ship." I see it when a team decides not to optimize for growth if it compromises user privacy. I see it when we choose stability over speed, transparency over convenience, long-term trust over short-term metrics.

These aren't failures of capability. They're exercises of principle.

And they're what builds safe ground.

[Slide: Foundation of a building, solid and stable, nothing built on it yet]

You might look at this and see incompleteness. Nothing built yet. Just concrete and rebar. Not impressive.

But I see possibility. I see the foundation that will hold a structure for fifty years. I see the prerequisite for everything that comes after.

Safe ground isn't the destination. It's not the finished product. It's not what you celebrate at launch.

But it's what makes everything else possible.

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

Safety first.

Not because we lack ambition. Not because we fear innovation. Not because we're bound by outdated rules.

But because we understand that foundations come before structures. Because we know that trust is built on safety. Because we've learned that the fastest way to move forward sustainably is to build ground that holds.

I'm asking you to do something difficult: Choose safety even when you could move faster without it.

I'm asking you to do something countercultural: Say "no" to things you're capable of, when those things aren't safe.

I'm asking you to do something that might not be celebrated in the next sprint, but will matter in the next decade:

Build safe ground first.

Everything else becomes possible.

[Long pause. Breathe.]

Thank you.

Q&A (52:00-60:00)

Q: Doesn't prioritizing safety stifle innovation? Don't breakthrough ideas often come from taking unsafe risks?

Great question. I think we need to distinguish between risk and recklessness.

Risk is calculated. It understands the failure modes. It builds containment. It prepares for what could go wrong. This is what climbers do—they take enormous risks, but with harnesses, ropes, redundant safety systems.

Recklessness is uncalculated. It ignores failure modes. It assumes everything will work out. It externalizes the cost of failure onto others.

Safety doesn't prevent risk. It enables smart risk. The kind that learns from failure instead of being destroyed by it.

Some of the most innovative companies I know—SpaceX, for example—have spectacular failures. But they fail in contained environments. They build test rockets expecting them to explode. They learn from each failure. That's safe risk-taking.

What's unsafe is shipping half-tested code to millions of users and calling the inevitable failures "learning opportunities." You're learning—but they're paying the cost.

Q: How do you balance safety with speed-to-market in competitive industries?

I'll be honest: sometimes you can't. Sometimes the market rewards recklessness. Sometimes the competitor who ships unsafe code faster wins in the short term.

But here's what I've observed: they rarely win in the long term.

Trust is slow to build and fast to lose. You can capture market share quickly with an unsafe product, but you lose it even faster when the safety failures compound.

I'd rather be the second to market with a safe product than first to market with an unsafe one.

That said—safety doesn't have to mean slow. Good safety infrastructure actually accelerates development over time. When you can deploy confidently because you know your failures are contained, you move faster. When you can debug quickly because your logging is comprehensive, you move faster.

The upfront investment in safety pays efficiency dividends for years.

Q: What do you say to the argument that users should be responsible for their own safety, not developers?

I fundamentally disagree with that framing.

Yes, users bear some responsibility. But we—the developers, the builders—have vastly more power in this relationship. We control the systems. We understand the risks. We see the failure modes that users can't possibly anticipate.

Saying "users should be responsible for their own safety" is like saying "the people living downstream should be responsible for not getting flooded when we build a dam upstream."

No. The dam builders are responsible for building a safe dam. Full stop.

We have the expertise. We have the capability. We have the ethical obligation.

Safety is not something you outsource to users. It's something you build into foundations.

Q: How do you handle situations where safety and user freedom conflict?

This is tough, and I don't pretend to have perfect answers.

But here's my framework: Safety establishes boundaries within which freedom operates. Not instead of freedom—as the foundation for freedom.

Think about playgrounds. Safety surfacing under climbing structures doesn't restrict kids from climbing. It enables them to climb more boldly because the consequences of falling are survivable.

The same principle applies in software. Safety boundaries—sandboxed environments, permission systems, rate limits—create spaces where users can experiment freely because the blast radius is contained.

Where it gets complicated is when users want to do unsafe things. "I know the risks, let me disable this safety feature."

My approach: Make the boundary clear. Explain the risk. But hold the line on truly catastrophic failures. You can give users rope, but you don't let them hang themselves with it.

This requires judgment. It requires understanding the difference between paternalism (removing all risk) and protection (preventing catastrophic harm).

It's not always obvious where that line is. But I'd rather err on the side of safety and be called overprotective than err on the side of freedom and watch preventable harm happen.

Q: What's one thing teams can do tomorrow to start building a culture of safety?

Start your next team meeting with this question: "What could go wrong with what we're building?"

Not "what will we build?" Not "how fast can we ship?" Not "what features should we add?"

But: "What could go wrong?"

List the failure modes. The edge cases. The ways this could break. The people who could be harmed.

Don't solve all of them immediately. Just make them visible.

Because the first step to building safe ground is acknowledging that ground can be unsafe.

The second step—which you can also do tomorrow—is celebrate someone who said "no" for safety reasons.

Someone who pushed back on an unsafe decision. Someone who asked for more testing. Someone who raised a concern that slowed things down.

Publicly acknowledge that. Say "thank you for protecting us." Say "this is the kind of thinking we value."

Culture shifts don't happen through policy. They happen through what gets celebrated.

Celebrate safety. Watch what happens.

END OF TALK

Runtime: ~60 minutes (including Q&A)

Part 1 of 10 in the Compass Principles exploration series

Next: Principle 2 - Honesty & Accuracy

🌈=🌀