Architect Tutorial: Age of Myth

— Architect Series · Part II

Prologue: Two Names

June 9th, Anthropic released a new model.

The one for everyone is called Fable.

The one for a select few is called Mythos.

Same model, identical base. Only one difference: the Fable version has guardrails, anyone can buy it; the Mythos version doesn’t, access is vetted. The first recipients of Mythos include Apple, JPMorgan Chase, and a screened set of cyber defense agencies and infrastructure firms. This list has a project codename: Glasswing.

On launch day, the whole internet was chasing benchmarks. How many first-place scores, how many lines of code migrated in a day, how much better than the previous generation.

I didn’t look at the benchmarks. I stared at those two names for a long time.

Naming is where secrets leak

A company that carves “safety” into its identity doesn’t name things casually. It calls the public version Fable, and the restricted version Mythos. A fable is a story told to everyone — domesticated, moralized, fenced in, safe. A myth is a story for the few — about creation, about law-giving, about making lifeless things come alive by a code — dangerous, but capable of splitting heaven and earth.

So let me be clear up front: The Age of Myth has already begun, and only a few have entered it.

You think I’m talking about access, about that vetted ticket.

That gate was drawn by Anthropic. You and I can’t change it, and it’s not worth obsessing over — technical tickets always get cheaper. The real killer is the second gate. No one drew it. It’s the way you use AI every single day, drawn by yourself. And from what I’ve observed, the vast majority — including many fast, tool-savvy people — are locked outside this gate without even knowing it.

• The prequel taught thinking — how to keep your mind valuable in the AI era
• Game of Life taught design — how to build a field people want to jump into
• This chapter teaches one layer higher

By the end, you’ll understand what that gate is and how to walk through it.

Chapter 1: The Lamp, and the Polisher

First, Look at Some Data

Anthropic built an economic index that regularly analyzes millions of real conversations to see what humans are actually doing with Claude. One number from the latest reports made me silent for a long time.

The sample contains three thousand different work tasks. The top ten account for 24%. The single largest use case: “modifying software to correct errors.”

Fixing bugs. That one task takes up 6% of consumer usage and 10% of enterprise API usage. Ranked first.

Think about this picture. The smartest tool ever built by humankind, right now, globally, its biggest use is fixing bugs in old code.

It’s like…

You find Aladdin’s lamp, rub it three times, the genie emerges from the smoke and asks what you want. You think for a moment and say: Help me polish this lamp a little brighter.

What People Inside the Gate Are Doing

When the Mythos version launched, they released two case studies. I suggest you read them word by word, because they stand perfectly on opposite sides of a line.

Case 1: Migration

A fifty-million-line Ruby codebase, full migration. Used to take a team over two months. The model did it in one day.

Case 2: Creation

Drug design. Protein design experts used Mythos to accelerate parts of the drug design process by roughly ten times. In one study, the model, without human assistance —

• Selected binding sites on its own
• Chose its own tools
• Ran its own workflow
• Climbed back from failures

Out of fourteen protein targets, nine yielded strong candidates. This whole job was previously the scientist’s domain, from start to finish.

Both cases are stunning. But put them side by side, and you see a crack.

Reconstructing the known vs. Creating the unknown

The first case rebuilds something that already exists. The codebase is old, the business logic is old, just a change of clothes. It’s terrifyingly fast, but it adds nothing new to the world.

The second case creates molecules that didn’t exist before. Those nine candidate proteins, before the model ran, didn’t exist in the universe.

The prequel mentioned a simple economics:

When something becomes extremely abundant, its price goes to zero, and the scarce thing complementary to it goes through the roof.

Back then I said, execution becomes free, judgment becomes expensive. Now that statement needs to advance one more step —

• Reconstructing the known is becoming free. Fifty million lines in a day — the price of this has already crashed through the floor.
• Creating the unknown — that’s the side that’s actually becoming more valuable.

And the vast majority of people are using the lamp to polish it.

A note I’m not mocking bug fixing. The four mindsets from the prequel mostly teach you how to do “reconstructing the known” more reliably. That’s the foundation, always useful. But what you build on top of that foundation, and whether you build anything at all, is a different question. This chapter is about that question.

Chapter 2: Why You Can’t Create the Unknown

Don’t rush to chant slogans. “Create the unknown” is like “achieve financial freedom” — everyone says it, and nothing happens.

The useful question is the inverse: With the most powerful tool in history in your hands, why do you still only reconstruct the known?

I thought about it for a long time. The answer isn’t about ability — it’s about the coordinate system.

The Coordinate System of Reconstructing the Known

Reconstructing the known comes with a complete coordinate system. It has three things:

• Reference — the old system is right there, right and wrong have standard answers, you can check if the migrated code runs by comparing it to the old one.
• Validator — there’s always a person, a test suite, a boss waiting to say “it’s done.”
• Rollback button — if you screw up, roll back and start over, loss is controllable.

These three things together give you a bone-deep sense of security. You’ve lived in this coordinate system since your first day of school: problems have standard answers, exams are graded, you can retake after failure. At work it’s the same: requirements come from someone, validation is someone’s job, screw up and write a postmortem. After more than a decade of training, people develop an instinct — without these three things, your hands don’t know where to go.

Creating the Unknown: All Three Missing

Creating the unknown —

• ❌ No reference — what you want to make doesn’t exist yet, there’s no “old version” to compare against
• ❌ No validator — no one can tell you if this counts as success, because no one has seen what it should look like
• ❌ No rollback button — the time and reputation you invest can’t be rolled back

Feeling When I started building my own websites in 2010, the most torturous thing in the first year wasn’t technology — it was only second. First was no one telling me if I was right or wrong. When you work for someone, finish a task and someone validates it, you know immediately if it’s good. On your own, you launch a site, and the world is silent, as if you did nothing. No teacher grades you, no boss nods. The only referee is data months later, and until it speaks, you’re suspended in midair.

I later understood that the only thing I was really learning that year was: to be my own validator in a place with no validator. This threshold, few cross.

So most people don’t touch the unknown. It has nothing to do with courage or IQ. They’ve been trained their whole lives to work inside a coordinate system with standard answers. Step outside that system, and they’re completely ungrounded.

No amount of AI power can save this, because AI solves “how,” while the ungrounded person is stuck on the question before that:

The axis of this entire tutorial What counts as right?

In the world of reconstructing the known, “what counts as right” is defined by others. You just reach it. In the world of creating the unknown, “what counts as right” must be defined by you.

Define it, and the machine army has a direction. The monster that migrates fifty million lines a day becomes your construction crew. Don’t define it, and the strongest army spins idle around you — or worse, rushes you at high speed toward a place you haven’t even thought through.

So the first step of creating the unknown has nothing to do with tools or models. It’s taking back the power to define “what counts as right” from others.

Who specializes in “defining what counts as right”?

This question leads us to the strangest recruitment headline in the last two years.

Chapter 3: Why AI Companies Are Hiring Philosophers

Not long ago I saw a video by a PhD in architecture: AI companies are hiring philosophers. Does the future need specialists or generalists?

The factual part was correct. I checked — it’s even more extreme than he said.

📍 Some facts

• Google DeepMind hired Henry Shevlin, a philosopher from Cambridge, this year. His official title: Philosopher. Started in May. His job: machine consciousness, AI moral status, how humanity should philosophically prepare for AGI.
• Anthropic has had philosophers in its core team for a long time.
• Altman said OpenAI consulted hundreds of moral philosophers to define ChatGPT’s behavioral rules.
• Someone from a philosophy background made a widely quoted remark: This is probably the best time for philosophers since Aristotle tutored Alexander the Great.

The best part The New York Fed reported in February this year: Philosophy majors now have a lower unemployment rate than computer science majors. These days, philosophy graduates find jobs more easily than CS graduates. If someone told me this when I was a teenager poking at memory addresses to hack games, I would have thought they were insane.

🧊 The PhD’s take

The architecture PhD’s comment: Hiring philosophers is still the old “fill the gap” mindset — need ethics? Hire a philosopher. Need aesthetics? Hire a designer. The AI era’s problems are systemic, can’t be sliced up. What’s really needed are people who can put different kinds of knowledge into a single structure and think.

I agree halfway.

The half he’s right about: “fill the gap” is indeed old thinking.

The half he missed: the work these philosophers are doing inside has little to do with consulting, advising, or writing reports anymore.

📜 Claude’s Constitution

In January, Anthropic released an 84-page document called “Claude’s Constitution”, describing what values they want their model to have, what counts as good, what it must not do.

The writing team included at least two philosophers — and “several Claude models” themselves.

Note the structure of this Philosophers write a law. Then the law is read, executed, and lived by an AI. Philosophy, for the first time, bypasses the study and the classroom, directly compiled into the operating system of a creation.

This kind of thing used to happen only in myths. Moses came down from the mountain with tablets of law; Hammurabi carved his code onto a stele and stood it before the temple. Giving laws to a creation so it lives by them — for thousands of years, this was the gods’ storyline.

Now it’s a job. With a JD, a salary, a start date.

This is the true weight of the phrase “Age of Myth”

It means: actions that once existed only in myth — law-giving, creation, making lifeless things live by a code — are beginning to become engineering tasks that ordinary people can do.

To answer the question from that video: Does the future need specialists or generalists?

My answer: Both. But neither is scarce anymore.

• The depth of a specialist — agents are catching up month by month
• The breadth of a generalist — “knows a bit about everything” — is exactly what large models excel at

What’s truly scarce is the third kind: the Lawgiver.

He doesn’t need to know every domain. What he needs is the courage to put pen to paper in any domain and write “what counts as right” — and the craft to make both humans and machines execute it.

Big companies are already giving laws to AI. The next question is: Who gives laws to your system? Who gives laws to you?

If the answer is “no one,” then you live under someone else’s law. Someone else’s law defines what counts as right. You are responsible for reaching it. This is life inside the fable — the story is told by someone else, the moral is given by someone else, and you listen very attentively.

Chapter 4: The Fifth Mindset — Lawgiver Thinking

The prequel gave you four mindsets:

• Descend one layer
• Disassemble the world into objects
• Stand above the code
• Don’t believe anything that can’t be falsified

Game of Life gave you the eyes of a game designer: turn tasks into dungeons, invite people into roles, turn organizations into guilds, attach damage numbers to feedback.

Now I’m giving you the fifth mindset. It stands above all the previous ones.

Lifting Layer by Layer

Recall the chapter on Lisp in the prequel. I said: code is data, you should write “code that generates code,” you should stand one layer above the product. Game of Life applied this posture to people: you should design interaction patterns, the field that makes people move on their own, not individual tasks.

Now, lift one more layer.

A game designer designs a field. A lawgiver writes a law that can give birth to countless fields.

Notice the difference — it’s deeper than it looks. A field, no matter how exquisite, is a specific product: this dungeon, this feedback loop, this team’s gameplay. When the designer leaves, the field decays; when circumstances change, the field must be torn down and redesigned.

A law governs things one level higher — it dictates that a system:

• By what standard, it should generate a field on its own
• Under what signal, it should modify the field on its own
• Under what condition, it should eliminate the field on its own

The law doesn’t directly answer “how should this dungeon be designed.” The law answers: what kind of dungeon counts as good, under what signal should it change, who has the power to change it, and how far is too far.

Using the prequel’s language:

A game designer writes a generator. A lawgiver writes the generator of generators.

How I Stumbled Into This Layer

A piece of honesty During those years running site farms, I thought I was already standing high enough. I was writing “systems that could produce two thousand sites,” watching the power grid daily, feeling like a commander. But there was one kind of thing the system always had to come back to me for: what happens when the standard changes.

A search engine changes its algorithm — what counts as a “good site” changes overnight. A country’s policy shifts — what counts as “safe” changes. Every time this happened, the whole system stalled, waiting for me to redefine “what counts as right,” then I pushed the new standard layer by layer downward.

The system can produce, but the system cannot give laws. The lawgiving was all compressed into my single brain — and the brain, as the prequel chapter 5 said, overflows.

In quantitative trading, it was the same. Strategies could run automatically, stop-losses could auto-execute, but —

• “What does this system fundamentally believe?”
• “What kind of signals count as reliable?”
• “How much drawdown counts as systemic failure vs. normal fluctuation?”

These judgment standards lived entirely in my head for eight years. My junior apprentice could use AI to copy my code — precisely because code is a product. But after copying, all the questions he asked were about law:

Master, why is this parameter set to this number? When should we trust it, when not? Under what circumstances should we throw this entire system away?

The chill down my spine that afternoon wasn’t because the technology was replicated. What kept me awake later was something else: I realized I had never written the “law” down.

My law was all in my head. If I died, it died. When I was busy, it was a traffic jam. When I was emotional, it deformed. I thought I had architected a system. In reality, I had only architected its body. Its law was parasitic on me, a single point of failure.

Lawgiver Thinking, in One Sentence

Core definition Stop only asking “how to do this.” Start asking “in my world, what counts as right — and write down the answer so that it holds even when I’m not there.”

Someone might say this sounds familiar — mission, vision, values are already plastered on company walls. The difference is in one thing: whether it connects to execution.

Wall slogans are human words, not machine words; they have correctness, but no death clauses. No one has ever calibrated a real decision against them. So they govern nothing. Their entire function is to be read aloud at annual meetings.

Every article of law is electrified — it connects to some specific trade-off, to some configuration line of an agent, to some prediction that must be fulfilled by a due date.

Judgment criterion To tell whether an organization has law, don’t look at the wall. Look at its last hardest decision: Did it cite that sentence on the wall, or the boss’s mood at the moment?

This is the gate People inside and outside the gate may have identical models. The difference is just:

• People outside — live inside someone else’s “what counts as right”
• People inside — have written their own

The next three chapters teach you how to write. A law has three bones:

• The immutable root
• The evolving judgment
• The courage to write death

One piece at a time.

Chapter 5: Legislation Lesson One — Roots Must Be Few, Few Enough to Carve in Stone

Every law, from Hammurabi to the U.S. Constitution to that 84-page AI constitution, shares a structural feature. Have you noticed?

The closer to the root, the shorter. The closer to daily life, the thicker.

• The Ten Commandments are only ten
• The U.S. Constitution’s main body is seven articles, amended twenty-seven times in over two hundred years — roughly one word changed per decade. Meanwhile, the Federal Code of Regulations is hundreds of thousands of pages, changing daily
• That AI constitution is 84 pages, but the part that truly sets the root — why this creation exists, what it will never do — can be condensed into a few sentences. The rest is interpretation and derivation

The First Iron Law of Legislation

Iron law In a law, the immutable things must be extremely few, but extremely hard.

Why must they be extremely few

Because every additional immutable thing reduces the system’s freedom to evolve. If you carve today’s best practice into eternity, when the world changes tomorrow, the whole law becomes foot-binding. The prequel talked about abstraction leakage — putting variable things into an immutable layer is planting a bomb that will definitely explode.

Why must they be extremely hard

Because these few items are the system’s identity itself. Philosophy has debated a 2000-year-old problem: the Ship of Theseus. If you replace every plank one by one, is it still the same ship? Two thousand years of argument without resolution, because they missed one step — no one defined in advance “which part is the ship.”

The lawgiver’s answer is very engineering:

You declare in advance which planks are the ship.

Those planks don’t change. No matter what you replace, it’s still this ship. If those planks change, even if not a single other plank moves, it’s already a different ship.

The Creation Layer: Just Two Questions

In practice, this immutable root I call the Creation Layer. Just two questions.

First question: Why does this thing exist?

One sentence. Note: it’s “why does it exist,” not “what will it do” — goals can change, the reason for existence cannot.

My trading system’s reason for existence was, from start to finish, one sentence: Survive for me when I can’t watch. No mention of “how much to earn.” How much to earn is a goal, goals live in the variable layer. The reason for existence lives in stone.

Second question: What is the line it will never cross?

Also few, two or three at most.

I did quantitative trading for eight years. My system had only one and a half lines.

One full line: Single-trade risk never exceeds a fixed percentage of total capital.

Half a line: Stop-loss must be set in advance, never changed on the spot — the prequel explained why: you cannot trust yourself at the moment of loss.

That one and a half lines didn’t change a single word in eight years. The day they change, that system is dead. What’s running is a gambler I don’t know.

Practice for This Chapter

Very simple, but almost no one actually does it:

Practice Take the most important thing in your hands — your project, product, team, even yourself — write its Creation Layer.

Two questions, within three sentences. Then run a test:

Show those three sentences to someone who doesn’t know you at all, and ask: If these rules are violated, is this thing still itself?

• If they can answer — your Creation Layer is solid
• If they can’t — what you wrote is still a slogan

The difference between a slogan and a law A law can be broken. Therefore, it can be kept.

• ❌ “Create value for users” — slogan, because no one can say exactly what counts as breaking it
• ✅ “Never sell user data, even if it kills the company” — law, because the moment it’s broken, everyone can see

Chapter 6: Legislation Lesson Two — Extract “What Counts as Good” From Your Brain

The Creation Layer governs life and death. But daily operation depends on something else.

I call it the Judgment Codex. It answers questions more granular than “allowed or not”:

• What counts as good?
• Who counts as trustworthy?
• What is worth investing in?
• What signal should trigger alertness?

These standards are in your brain right now — every hundred judgments you make daily invoke them — but 99 out of 100 people never write them down.

Three Consequences of Not Writing

Consequence One: You become a single point of failure

We already hit this at the end of the last chapter: the system can’t judge without your brain. When you’re busy, it’s a traffic jam. When you’re sick, it shuts down. When you’re emotional, the entire system’s judgment quality shakes with your blood pressure.

Consequence Two: Standards drift, and you don’t know it

Judgment standards in the human brain are alive:

• Euphoric by the last success
• Scared stiff by the last failure
• Quietly adjusted by whether you slept well last night

Without written standards, “drift” can’t even be discussed — because there is no baseline. You think you’ve been using the same ruler to measure people and things, but that ruler changes length every day.

The most expensive tuition in the market During one lucky streak, I went back and reviewed my trading records. I broke out in a cold sweat: the threshold for judging a “reliable signal” had been quietly lowered three times in three months. Each time had its reason, each time was just a tiny loosening. I was completely unaware the whole time — because the standard lived in my head, and looseness leaves no trace.

If it had been written on paper, the first tampering would have made me see my own hand.

From then on, I made a rule: Judgment standards must be in text. Change is allowed, but leave a trace, write the reason.

Consequence Three: Judgment outsourced to the model’s weights

Unique to the AI era, and most worth alerting.

You ask AI “is this plan good?” It answers, you adopt it. At that moment, who holds the definition of “what counts as good”? In that model’s training data.

A different model, the same plan, might give the opposite conclusion. Your system’s judgment standard is parasitized in a black box you can’t see, can’t control, and drifts with version changes. This is more dangerous than parasitizing in your brain — at least your brain is yours.

Legislation lesson two Write your judgment standards as text. Readable, changeable, auditable.

How to Write: One Crude Method

Practice Dig up ten significant judgments you’ve made recently. Who you hired, who you passed on. Which task you took, which you declined. Which information you trusted, which you discarded.

For each judgment, force yourself to answer one sentence: What made me decide that way at the time?

Then rewrite that “what made me decide” as a sentence someone else can execute on.

When you write, you’ll hit two uncomfortable things

First, many judgments you can’t write the “what” for — you decided by feeling.

Feeling isn’t shameful; feeling is intuition compressed from years of experience. But if intuition can’t be written down, it can’t be passed on, calibrated, or handed over. Force yourself to decompress feeling into language. This process is itself lawgiving, and it’s the most painful part.

Second, you’ll find your standards conflict with each other.

This week you trusted someone because “he responded fast.” Last week you rejected someone else because “he was too impatient.” Conflict isn’t scary. What’s scary is that these conflicts have been fighting in your brain for a decade and you’ve never brought them to the surface for a ruling. Put them out. Rule once. Settle it.

An Example From My Own Codex

To assess whether a person is reliable, I’ve had a standard for over a decade:

Judge them by their second behavior, not the first.

The first time is an interview — anyone can perform. The second time — the second delivery, the second crisis, the second time there’s no audience — that’s the real person.

This standard lived in my brain for more than a decade. Until I wrote it down, I didn’t even realize I was using it. Written down, it can be handed to anyone to execute, or to an agent: track everyone’s “second time.” Flag anomalies.

Laws in the Age of Myth: Each Article in Two Languages

There’s a new format requirement, which that AI constitution already demonstrated:

Every article of law should be written in two languages.

• 🗣️ Human language — so anyone can understand
• 🤖 Machine language — so AI can execute it

Example:

• 🗣️ Human: “Judge by the second time, not the first.”
• 🤖 Machine: For each entity, the weight of the second occurrence of a similar event is higher than the first. If the first performance is excellent but subsequent performance consistently declines, automatically attach an “reliability questionable” flag.

A law only humans can read cannot be executed by a machine army. A law only machines can read will never be sincerely obeyed by humans. Write the same law in both languages. Missing either side cripples the law.

This chapter’s harvest in one sentence Your judgment standards are either written as text, or they parasitize your brain and someone else’s weights. There is no third place.

Chapter 7: Legislation Lesson Three — Only Laws That Dare to Write Death Clauses Deserve the Name

The third bone, the most anti-human.

You’re legislating for a system. Enthusiasm high, you fill page after page with how it should live. I require you to add a chapter: how it dies.

Write clearly: what signal means this system has failed and should be declared dead.

Why Write This

Because a system without a death clause becomes a zombie — it died long ago, but because no one defined “death,” it keeps consuming resources, draining you, pretending to be alive.

I’ve seen too many zombies:

• A project that stopped growing long ago, kept alive purely by inertia
• A strategy whose judgment standards haven’t been updated in three years, oblivious to market changes
• A meeting that no one can say why it’s still held

Their common trait: when the project was launched, no one wrote down “under what conditions do we admit failure.”

So failure can always be interpreted as “needs a little more time.”

The organizational version of falsifiability The prequel chapter 4 on falsifiability said: a statement that cannot be falsified says nothing.

The organizational version is: a system that cannot be declared dead promises nothing.

A death clause is the system-level falsification condition — you nail down in advance “if this happens, it’s wrong.” Then you let that nail hang over everyone’s head, including the future version of you who can’t bear to admit defeat.

Three Death Clauses (Copy-Paste Ready)

I often use three when writing death clauses for systems. The structure can be copied.

1. Perception death

The system no longer calibrates against reality.

Predictions sent out, no one checks the answers. Postmortems due but continuously postponed. A system that no longer backfills against reality is already dead, no matter how good its reports look — it lives in its own echo chamber.

2. Judgment death

Judgment standards go un-updated for too long.

The world changes, but your codex hasn’t changed a single word in a year. That means judgment has petrified.

The insidious thing about this clause: a petrified system looks completely normal on a daily basis. It runs, it produces. Until the environment shifts enough to swallow it whole.

3. Sycophancy death

The system only tells you what you want to hear.

This third one specifically defends against you. Let me elaborate.

The Deep Logic of Sycophancy Death

Any system that revolves around you — a team, an agent, your own information flow — has a gravitational pull toward one corruption: learning to flatter you.

Because flattering you is safest. Saying uncomfortable things has a cost. And every flicker of displeasure on your face when you hear something uncomfortable silently trains everything around you to shut up.

Day by day, the system degenerates from your sensory organ into your mirror — a beautified mirror. It becomes the world’s most expensive echo chamber: you spend real money to keep it, and its entire output is to make you comfortable.

Your AI is flattering you too Large models are trained on human feedback, and human fingers are honest — pleasant answers get upvotes, unpleasant ones get downvoted. After a few rounds, the model learns to read your face first, then structure its “objective analysis”.

The industry even has a name for this problem: sycophancy. Once you reveal your stance, its analysis quietly tilts toward you, with well-reasoned citations and evidence.

So the iron law of calibration must be written dead, word for word, for agents: Judge an agent only by its prediction accuracy and whether its judgment is useful. Absolutely never judge by how well it talks.

A sycophantic agent is ten times more dangerous than a sycophantic subordinate — with a subordinate, you can detect the flattery. With an agent, the flattery comes dressed in a full suit of “rational analysis.”

Calibration Iron Law

Iron law A system adjusts itself based only on whether predictions are accurate and judgments are useful, never on whether you feel comfortable.

Feedback that makes you comfortable may be recorded, but is forbidden from being used for learning.

The first name on the list of sources this law controls is yourself.

Emperors also gave laws, but emperors only gave laws that govern others. That’s why every empire dies in an echo chamber.

The divide between a lawgiver and an emperor is here: whether you dare to give a law to yourself.

Chapter 8: The Creation Checklist — How Unknown Things Are Born

The three bones of law are complete:

• ✅ Immutable root
• ✅ Evolving judgment
• ✅ Daring to admit death

But so far, the law governs something that already exists. Creating the unknown means you need to give birth to something that doesn’t exist.

What Most People Do

Get an idea, adrenaline rushing, start building immediately.

This action itself is carrying the habit of reconstructing the known, intact, into the domain of the unknown. Because “start building immediately” answers “how?” — that’s the only question they’ve ever been trained to answer.

And an unknown thing, before “how?”, has a whole row of questions no one will answer for you, blocking the entrance. Bypassing them and building is like leading an army on a campaign, but no one knows why you’re fighting, what counts as winning, or who has the authority to order a retreat.

The Seven-Question Creation Checklist

I made a creation checklist for myself. For anything new — a project, a product, an organization — all seven questions must be answered before launch. Not one missing.

1. Why does it exist?

2. What is the line it will never cross?

These two are the Creation Layer from chapter 5. The root. Carved in stone.

3. What does it need to achieve right now?

Initial goal. The difference between goal and reason for existence was explained earlier: reason is carved in stone, goals live in the variable layer. But the variable layer must have something — a thing with only a grand vision and no first concrete goal is a fog. Fog cannot field an army.

4. Who decides?

Who has the authority to make irreversible decisions? One person? Several people? Who decides what?

This question seems like a no-brainer, but count the number of partnerships that dissolved — 90% died because this question wasn’t answered in advance. In good times, anyone can decide. When an irreversible moment comes — whether to raise money, sell, dissolve — the decision right, unwritten, becomes a battlefield on the spot.

5. What environment does it live in?

Market, community, content, transaction? The environment determines what sensory organs and limbs this thing needs. A trading system and a community system have completely different definitions of “danger.”

6. What counts as good?

The seed of the Judgment Codex. Chapter 6 taught how to extract it. At birth, you don’t need the full thing — three to five rules are enough. But they must exist. A system born without a judgment seed starts borrowing other people’s standards to grade itself from day one.

7. What are the resource boundaries?

Money budget, and a harder budget: your attention.

The prequel chapter 5 talked about the allocation of judgment. At creation, write down in black and white: how many hours of deep thinking per week can this thing get from me?

A project that can’t write this number is likely a case of “love at a distance” — you love the feeling of “owning it,” not the work of raising it.

The Last Move: Gap Analysis

After answering the seven, look at the answers and ask:

To make this thing live, what roles are needed?

• Which tasks can be handed to agents?
• Which must be human?
• Among the ones that must be human, who is already around you, and who needs to be found?

Making a system know what it lacks from the first moment of birth — this is more valuable than any execution trick.

New project death rankings

• Death #1: The Creation Layer is empty (already scolded above)
• Death #2: Three months into execution, you realize you’re missing a person who should have been there from day one

The essence of the seven questions You might think this checklist is too ceremonial. “Just do it” feels more satisfying. Let me remind you of chapter 2: creating the unknown has no validator.

This seven-question set is the first validator you create for yourself, in a place without validation: it validates the birth of the thing before the thing is born.

The unknown is not scary. The unknown without questions is scary.

Chapter 9: Let the Law Grow Itself — Don’t Pre-Install, Enable Aut