Book Zero

Chapter Zero: WHAT IS AN ALGORITHM?

This chapter begins with a delay at a bank and ends with a failure at The Company's busiest dock.

Between those two events is a lesson about how systems think - and how naive thinking quietly destroys organizations.

10:00 AM - THE BANK

Two lines. On the left: consumer banking. Long. Restless. Audible sighs. On the right: business banking. Short. Silent. Moving.

A security guard stood between them like a boundary layer.

Ron Snow checked the time.

10:00 AM.

His daughter tugged his sleeve.

'Daddy, why is that line moving so slow and the other one moving fast?'

His face lit up.

'Different algorithms.'

'What's an algorithm?'

He picked her up so they were eye to eye.

'It's a routine. A way of doing the same thing over and over again until you find what you're looking for.'

He pointed.

THE SLOW TELLER - ENUMERATION (O(n))

She takes the customer's money: $120 (all $1 bills).

Counts each dollar one by one.

Recounts when distracted.

Corrects small mistakes.

Prints the receipt and gives it to the customer with the total deposit amount.

3 minutes.

THE FAST TELLER - INFERENCE (O(1))

She takes the next customer's money: $5,000 (all $1 bills).

Places the entire stack on a calibrated scale.

The scale already knows the weight of a single bill.

The total appears instantly.

Prints the receipt and gives it to the customer with the total deposit amount.

5 seconds.

'That teller is counting,' Ron Snow said.

'The other one is measuring.'

'But they're doing the same job.'

'Same job. Different approach.'

A man in line laughed.

'So she's just bad at her job?'

'She's working harder than everyone in the other line combined. She just wasn't taught a better way.'

His daughter frowned.

'So counting is dumb?'

'No. Counting is slow because you have to count every bill to get to the total. That's not dumb; it's naive.'

The security guard nodded.

'That explains a lot.'

Ron Snow checks the time again. He will be late for work.

9:00 AM - THE COMPANY (EARLIER)

The Company was already red before the day even started.

Junior came in first. Always does. Panic is punctual.

'Dock A is backing up again.'

The dashboard confirmed it:

• Truck lines spilling into city streets
• ABC Company escalating calls
• Overtime approvals stacking
• Employees rotating shifts without rest
• Customer complaints trending online

Dock A wasn't just slow.

It was infecting the rest of the object.

Because that's what The Company is.

An object.

With state.
With behavior.
With boundaries.
With processes.

And one of those processes was broken.

10:30 AM - DISCOVERY

Ron Snow walked in.

Late.

I glanced at the clock. He noticed. He always notices.

'You're late.'

'Algorithm issue,' he said.

He wasn't wrong.

I let it go.

If he fixes it, I look good.
If he fails, it falls on me.

'Dock A is choking us,' I said.
'ABC is escalating. Staff is burning out.'

He didn't respond emotionally.

'Show me the process.'

Junior pulled up the workflow.

THE PROBLEM

Dock A unloads pallets for ABC Company.

Each pallet contains:

• n identical boxes
• Each box weighs 50 lbs
• A manifest claims 100 boxes
• Total pallet weight: 5,000 lbs

The dock currently verifies by scanning every box individually.

Constraint:
Only one verification pass is allowed before release.

Goal:
Determine how many boxes actually arrived.

DOCK A - THE NAIVE ALGORITHM (O(n))

Process:

• Lift one box
• Scan one box
• Log one box
• Repeat 100 times

~30 seconds per box
~50 minutes per pallet

Every box must be touched to confirm the total.

Touch everything to know anything.

Truck lines grow.
Morale drops.
Fuel burns.
Calls escalate.

The Company's state mutates.

DOCK B - THE MEASURED ALGORITHM (O(1))

Alternative process:

• Lift entire pallet once
• Place on industrial scale
• Scale reads 5,000 lbs
• Known weight per box = 50 lbs

Inference:

5,000 / 50 = 100 boxes.

One operation.
Same truth.

'You didn't change the work,' Ron Snow said.
'You changed how the truth is extracted.'

That line stayed with me.

RESULTS

By 11:19 AM:

• Dock A: 50 minutes ? eliminated
• Dock B: 5 seconds ? deployed
• Backlog dissolved
• Overtime dropped
• ABC calmed down
• Staff stabilized

It wasn't a staffing issue.

It was an algorithm issue.

The Company had been running a naive process.

And naive processes don't just slow systems.

They create opportunities.

7:52 PM - NIGHT

The scale went offline.

'Maintenance issue.'

Manual verification reinstated.

Throughput dropped.

Overtime resumed.

ABC was quietly offered priority handling, for a fee.

No intrusion.

No breach.

No code changed.

The Crew, LLC did not attack the system.

They reverted it.

They restored the naive algorithm.

Fragile systems do not need to be broken.

They only need to be returned to default.

TECHNICAL ANALYSIS - ENUMERATION VS INFERENCE

Definition

Naive Algorithm (O(n)):
Work scales linearly with input size.

Measured Algorithm (O(1)):
Work remains constant regardless of input size.

In Dock A:
100 boxes ? 100 operations.

In Dock B:
100 boxes ? 1 operation.

Big O Doctrine

Measurement collapses what counting expands.

Chapter Law

The method a system uses to arrive at truth determines:

• how fast it moves
• how much it leaks
• how easily it can be exploited

The Company is an object.

Its processes are algorithms.

If the algorithms are naive, the object becomes fragile.

Chapter 1 - The Game Is a Proof Engine

You win by shrinking possibility, not by searching everywhere.

1.1 What You Are Actually Doing

The game gives you a world (cities, countries, suspects) and asks you to locate one hidden truth. That is an answer space: a set of possible answers large enough to overwhelm guessing, but small enough to collapse under constraints.

Your job is not to 'try places.' Your job is to make places illegal to eliminate regions of the world until only one region remains feasible.

This is why the best players do not feel frantic. They feel steady. They are not searching for a lucky hit; they are executing a narrowing process that makes the answer inevitable.

1.2 The Three Hidden Worlds

Even in its simplest form, Carmen gives you three separate problem worlds at once:

• The map world: a network of locations connected by routes (a travel structure).
• The suspect world: a set of candidates described by attributes (language, hobby, vehicle, etc.).
• The time world: a move budget that punishes waste and rewards irreversible progress.

A 'good move' is not a vibe. It is a move that shrinks one or more of these worlds while keeping the real answer inside the remaining space.

1.3 Why This Is Algorithmic

An algorithm is a finite, rule-bound process that preserves an invariant and ends with a proof of success (or impossibility). Carmen quietly hands you the full setup:

• A scanner: you move through cities, one frame at a time, collecting evidence.
• Constraints: each clue forbids a region of the world or a set of suspects.
• An invariant: the remaining candidates are still feasible under all processed clues.
• A termination condition: the feasible region becomes a singleton (one suspect / one destination), or collapses to empty (impossibility).

That is the core contract of correctness. The game is not 'about geography.' It is about running a proof loop on top of a familiar surface.

1.4 Clues Are Not Facts - They Are Knives

A raw fact is harmless. A clue becomes powerful only when it cuts the world.

'Speaks French' is not trivia. It is a boundary. The moment you treat it as a boundary, you get a lawful split: suspects who satisfy the clue remain; suspects who contradict it become permanently illegal.

1.5 The Invariant You Were Already Protecting

Every strong Carmen run has an unspoken invariant:

When you violate that invariant by keeping a suspect that a clue disproved, you do not merely 'make a mistake.' You corrupt the proof. From that moment on, every decision is built on a lie.

CCF treats this as non-negotiable: you are not allowed to proceed with a broken invariant. Either you repair it or you stop.

1.6 The Proof Engine in One Frame

A single Carmen turn is a frame. It contains the same moving parts you will later use in arrays, graphs, and systems:

1. Observe: collect a clue (a constraint candidate).
2. Decide: interpret it as a rule that forbids states.
3. Eliminate: delete all candidates that contradict the rule.
4. Record: store the rule in your clue ledger so you never re-scan the same meaning.
5. Maintain: confirm the invariant still holds before moving on.

Notice what is missing: there is no guessing step. The frame is designed to make guessing unnecessary.

1.7 Why Brute Force Feels Wrong Here

You could try cities randomly. You could chase suspects by intuition. The game allows it, just like many programming problems allow brute force.

But the move budget exposes the truth: brute force is not 'bad' because it is slow; it is slow because it refuses to eliminate. It keeps the entire space alive and pays the cost of re-checking it over and over.

CCF calls the alternative irreversible elimination: once a state is proven impossible, it is never reconsidered. That single discipline is what turns chaos into calm.

1.8 The Calm Feeling Is a Signal

When you play well, you feel calm because your next move is justified. That calm is not personality. It is a property of the method.

CCF's goal is to make that same calm available in any domain: algorithms, interviews, system design, debugging, or decisions where correctness matters.

Chapter 2 - Narrative Layer vs Problem Space

The story motivates the hunt. The structure determines what is legal.

2.1 The Narrative Layer

Carmen 'steals a statue.' A witness 'saw the suspect near a caf'.' A villain 'boards a plane at midnight.' The game wraps every step in story so your brain stays engaged. That wrapper is the narrative layer: the human-facing presentation of events, clues, and urgency.

In Carmen, a 'world' can be as simple as a neighborhood. Some neighborhoods feel like a straight street: you walk forward and collect facts. Others feel like a map: you move by connections. You don't need the full catalog yet. You only need the instinct that different mysteries demand different movement.

The narrative layer is not fake. It is simply not governing. It does not determine whether a move is correct. It determines whether the move feels like it belongs in a chase movie.

In algorithm work, the narrative layer is the problem statement: the thief, the treasure, the schedule, the 'cool' setting. It is what you read first, and what must be peeled away first.

2.2 The Problem Space

Under the story sits the problem space: the actual world that your reasoning operates on. In Carmen, that world is built from concrete objects and relations:

• Locations (cities/countries) connected by travel options
• Time as a shrinking budget that makes some routes impossible
• Suspects described by a finite set of traits
• Clues that restrict which locations and suspects remain feasible

This is the world where correctness lives. The game never asks, 'What would make a good story next?' It asks, 'Given what you know, what can still be true?' That question is always asked inside the problem space.

2.3 Why This Separation Matters

Most algorithm confusion starts here: people keep reasoning inside the story. They treat the narrative as the mechanism. That produces two classic failures:

• Story-chasing: you follow the most dramatic clue instead of the most constraining one.
• Object-fetish: you focus on the 'thing' (crown jewels, statue, painting) and ignore the structure (routes, constraints, legality).

CCF is strict about this: the narrative may explain why you care, but only the problem space can explain what is correct.

2.4 The Carmen Translation (Story ? Structure)

Here is the core move you will repeat for every chapter in this book: translate narrative into structure without adding new meaning. Think of it as a proof step: you are rewriting the same situation into a form where legality can be tested.

Examples:

• 'The suspect ordered sushi.' ? a constraint on location/culture (a filter on which locations remain plausible).
• 'They left in a hurry.' ? a tighter time boundary (some routes become impossible under the budget).
• 'They were seen near the Eiffel Tower.' ? a hard location constraint (the feasible region collapses dramatically).

Notice what we did not do: we did not 'interpret' the story into extra assumptions. We did not invent probabilities. We did not add psychology. We reduced story to legality.

2.5 The Two Maps You Carry

When you play well, you are carrying two maps at once:

• Narrative map: what happened, what feels plausible, the chase vibe.
• Constraint map: what is still legal given the clues so far.

The narrative map keeps you motivated. The constraint map keeps you correct. In CCF terms, the constraint map is the feasible region of the search: the set of states that still satisfy the known rules.

A strong player updates the constraint map after every clue. A weak player updates only the narrative map, and then wonders why the chase feels random.

2.6 CCF Alignment: Intent Lives Above, Correctness Lives Below

This chapter connects directly to the first CCF move: intent. Intent is allowed to be human. It can be narrative. 'Catch Carmen.' 'Find the stolen object.' 'Stop the villain.' Intent explains the goal.

But the next move, shape, cannot be narrative. Shape is the problem space. Shape defines what counts as a state, what counts as a move, and what counts as elimination. If you keep the story in the driver's seat, your shape will be vague, and your scanner will wander.

So treat this as a hard boundary in your thinking:

• Narrative answers: 'Why do we care?'
• Problem space answers: 'What is legal?'

Once you adopt this boundary, you stop asking the wrong questions. You stop hunting for 'clever' tricks. You start hunting for the rules that collapse the search.

2.7 A Mini Proof Exercise

Take the following story lines and rewrite them into problem-space statements. Do not add meaning. Only convert to constraints, boundaries, and legality.

1. 'The suspect spoke Spanish and paid in pesos.'
2. 'The suspect boarded a boat after sunset.'
3. 'The suspect mentioned a desert and a famous pyramid.'

Your answers should look like this:

• Trait constraint (language/currency)
• Time boundary (night travel reduces reachable locations)
• Location filter (geography/landmark narrows feasible region)

That is the mental move that makes everything else in this book possible. You are not learning trivia. You are learning to convert stories into structures and then prove your way to the answer.

Chapter 3 - Clues Are Constraints

A clue is only powerful when it forbids something.

3.1 The Moment a Clue Becomes Algorithmic

A clue begins as a sentence. It becomes algorithmic only when you convert it into a constraint: a rule that makes part of the world illegal.

If a clue does not forbid any suspects, any locations, or any movements, then it is not guiding correctness. It is only decoration in the narrative layer.

3.2 First Guess vs Final Answer

A good detective forms an early theory, then keeps reading. That's not indecision. That's discipline. Your first guess is a working hypothesis, useful for attention, not a verdict.

As more clues arrive, you either strengthen the theory or eliminate it. If one clue forbids it, it's gone. That is why you finish the prompt before you make the arrest.

3.2 Constraints Are Boundaries, Not Facts

Players often treat clues as trivia: 'French,' 'yen,' 'motorcycle,' 'pyramids.' But correctness does not come from remembering words. It comes from drawing boundaries.

A boundary divides the world into two regions:

• Legal: states consistent with the clue.
• Illegal: states that contradict the clue and must be discarded.

This is why strong Carmen play feels calm. Every clue draws a line. Every line removes work.

3.3 The Two Constraint Targets

In Carmen, a clue can constrain two different worlds:

• The suspect world: which person can still match.
• The location world: which place can still be true.

The best clues usually constrain both. A landmark clue (Eiffel Tower) collapses location. A trait clue (motorcycle) collapses suspects. A currency or language clue often collapses both.

3.4 Three Types of Clues (Hard, Soft, and Structural)

Not every clue has the same strength. In CCF terms, you should classify the clue before you let it drive elimination.

Hard constraints enable immediate elimination. Soft constraints become powerful when they stack. Structural constraints shape what information you can reach in time.

3.5 Constraint Stacking Is Intersection

A single constraint draws a line. Multiple constraints draw a shape.

Every new clue intersects the remaining feasible region. This is why the game accelerates: the space shrinks faster as the constraints accumulate.

3.6 Converting a Clue Into a Decision Rule

A clue is a sentence. A constraint is a rule. A rule needs a test.

So every time you read a clue, force yourself to produce a decision rule in this form:

Example:

• Clue: 'Speaks French.'
• Rule: eliminate every suspect whose language set does not include French.

That single conversion step is the bridge between story and computation.

3.7 The Most Common Failure: Treating Ambiguity as Permission

Some clues are vague. Vague does not mean 'do nothing.' It means 'do not over-eliminate.'

When a clue is soft or ambiguous, the correct move is to constrain gently and wait for stacking to sharpen it. In CCF terms, you preserve the invariant by avoiding unjustified elimination.

3.8 What This Teaches You About Real Algorithms

Most programming problems hide constraints inside innocent-looking sentences: 'sorted,' 'contiguous,' 'must be unique,' 'minimize,' 'no extra memory.' Those are not details. They are the blades that make elimination legal.

Carmen trains the exact instinct you need for CCF: treat every hint as a boundary, convert it into a rule, apply it to shrink the space, and confirm the invariant still holds.

Author

Garonzick D. Hall
Software Engineer - Correct Code Press