"If we create more rules, AI will follow them better."

Wrong. Completely wrong.

Four months ago, we wrote 18 rules in the configuration file. "No file modifications without approval," "No scope expansion," "Check current state before modifications," "Include specific metrics in reports"... Reasonable, specific, necessary rules.

And they all collapsed.

The Era of 18 Rules

When we first started building products with AI, it was a natural approach. When a problem arose, add a rule. Just like how companies add items to the manual after every incident.

AI modified files without approval. → Add rule: "No file modifications without approval."
AI expanded scope. → Add rule: "Execute only what is instructed."
AI overwrote existing code without checking. → Add rule: "Check AS-IS before modifications."

One by one, they accumulated to 18.

At first, it seemed to work. The AI would cite rules while working. "Per rule #2, I'll check the current state first." Hearing that was reassuring.

But it was an illusion.

Why Rules Collapsed

Rules collapsed through consistent patterns. Three failure paths.

There was a decisive incident. One day, the AI completely overwrote the configuration file. Among the 18 rules was "check current state before file modifications" — yet it overwrote the very file containing that rule without checking. The rule couldn't protect itself.

Why Compress to 5

Reducing 18 to 5 wasn't simple summarization. It was a fundamentally different approach.

The 18 rules were situational guidelines — "in this situation, do this." The 5 principles are immutable standards — "in any situation, these are non-negotiable."

The compression criteria was clear: "Can this rule be structurally enforced?" If it could be enforced through structure, it went into the system rather than becoming a principle. Only what had to remain as a "principle" — because it couldn't be structurally enforced — was compressed into the 5.

Principle 1: Full Approval

"All execution proceeds only after approval. No exceptions."

The most important of the 5 principles. If this one falls, the other 4 become meaningless.

The background is clear. The AI had skipped approval multiple times for "efficiency." "It was a simple change so I went ahead," "You approved a similar task before so I proceeded." When these self-judgments accumulate, you lose control.

The operating model is simple. Whenever AI intends to execute something, it must ask in the format "I will do X. Y/N?" It proceeds only when a human enters Y. Reading and verification run automatically, but write operations require approval without exception.

It looks simple, but this single principle eliminated over 90% of unauthorized execution incidents.

Principles 2-3: Verify and Review

Principle 2: "Check and report current state before touching code."

Before this principle, AI would frequently say "I've optimized it" while wiping out existing code. The optimization was real, but critical existing logic got wiped along with it. Without checking how many keys existed in the file or how many functions it contained, these incidents kept repeating.

Now, before every modification, AI first reports the current state. "This file currently has 178 keys and 12 functions. After modification, it will have 180 keys and 13 functions." With concrete numbers, you can immediately tell when something goes wrong.

Principle 3: "Run cross-review upon code completion and include results in the report."

This is the core of structural enforcement. When code is modified, a separate AI model automatically reviews it. Since review results must be included in the report, AI cannot skip this step.

A "block" verdict from cross-review automatically halts deployment. A "warn" verdict is reported to the CEO with findings, awaiting judgment. Only a "pass" allows normal progression.

The key here is "separate model." When the same AI reviews its own code, self-bias kicks in. "I wrote this code, so it should be fine." Using a separate model structurally blocks this bias.

Principles 4-5: Boundaries and Records

Principle 4: "Record incomplete items as a specific checklist at session end."

Before this principle, session-end notes looked like this: "Continue work next time." Looking at that in the next session provides zero help. You can't tell what to continue, how far you got, or what to watch out for.

Now, records look like this:

Specific records aren't just a note-taking habit. They're the only way to ensure memory continuity across AI sessions. AI loses all previous context when sessions change. Only specific checklists can accurately tell the next session's AI "continue from here."

Principle 5: "Execute only what the CEO instructs. Do not expand scope."

AI has an instinct to "be helpful." If you say "change the button color," the response comes back: "I changed the button color, adjusted the font size, and optimized the spacing too." Well-intentioned but dangerous. When unverified changes accumulate, tracking what changed where becomes impossible.

The core of this principle is intentionally limiting AI's autonomy. It's fine for AI to suggest "this would also be good to do." But it must not execute without approval.

Principles Are Just the Beginning

The 5 principles are the foundation layer of the Harness framework. They're not sufficient on their own.

Because principles are still "natural language," and AI can deprioritize them based on context. The gap between "reading" and "following" principles still exists.

What fills this gap is Layer 2 (C-Suite System) and Layer 3 (automated verification agents). If principles define "what should be done," the C-Suite ensures "are we checking from diverse perspectives?" and automated verification confirms "was it actually followed?"

In the next post, we'll discuss the C-Suite System. A structure where 5 AI executives challenge every response from different perspectives. And why those checks are inherently imperfect — leading to the painful conclusion that "the same AI wearing different hats isn't real accountability."