Derived from building an AI operating methodology from scratch over a year of real practice. Ordered by leverage, highest first.
Each principle follows the same format: what it is, why it's non-obvious, how to implement it, how to know it's working.
1. The Constitution Before the Tool
The principle: Your AI operating model matters more than which AI tool you choose. The model that runs on your actual values compounds. The model that runs on generic defaults produces generic outputs.
Why it's non-obvious: Everyone evaluates AI tools by capability, quality, and pricing. These are real differences. But they're secondary to whether the tool can run on YOUR principles. A well-configured mid-range AI outperforms a state-of-the-art AI running on generic instructions.
How to implement: Before evaluating AI tools, develop your operating principles to where they're specific enough to be wrong. If you can't say "in this situation, the AI should X rather than Y because Z," the principles aren't load-bearing yet.
How to know it's working: Give your constitution to someone who doesn't know your work. Ask them to make a decision you'd make. If their decision matches yours, the constitution is specific enough.
2. The Inside-Out Sequence
The principle: For methodology-building, build inward first (theory → infrastructure → practice). For validation, external contact closes the loop. The inside-out sequence is correct for quality; it has a specific cost in timing.
Why it's non-obvious: Most advice says "talk to users first." This is right for product-market fit. It's wrong for methodology development that requires intellectual depth. If you let early feedback constrain your theory before it's mature, you get a theory shaped by your first users' limitations.
How to implement: Develop the methodology to maturity before submitting it to external validation. But set a maturity gate — a specific condition that triggers the shift. Without the gate, maturity becomes indefinitely deferred.
How to know it's working: The maturity gate was triggered by a specific event, not a feeling of readiness.
3. The Vault-to-Action Ratio
The principle: Track the ratio of planning to doing. More than 10:1 is a diagnostic. High-quality preparation can still be avoidance.
Why it's non-obvious: When preparation is genuinely rigorous, it doesn't feel like avoidance. It feels like rigor. The distinction: rigor that prepares you to act vs rigor that substitutes for the action.
How to implement: For each major initiative, define the specific action that tests whether the preparation was worth it. Set a date. If the date passes without the action, the ratio is your diagnostic.
How to know it's working: The action happened. Not "was almost ready to happen."
4. The Monoculture Substrate Risk
The principle: Building on a single AI provider creates concentration risk. Not that the company fails — that policy drift, pricing, or capability changes affect your methodology at the substrate level.
Why it's non-obvious: Deep commitment to one platform produces better short-term results than shallow multi-platform hedging. But the concentration compounds over time.
How to implement: Choose the platform that best enables your methodology today. Simultaneously, verify your techniques are portable: would the constitution method work on a different AI? If not, decouple the technique from the platform.
How to know it's working: Your methodology could switch platforms in one week if required.
5. The 33-Pass Problem
The principle: Each internal iteration marginally improves quality and substantially increases shipping resistance. There's a pass count at which continued iteration produces more resistance than improvement.
Why it's non-obvious: It's easy to rationalize one more pass. Each pass feels like improvement. It often is — but marginal quality gains shrink while resistance to shipping grows.
How to implement: Before starting iterations, set a maximum pass count. The first external reader will tell you more about what needs changing than 10 additional internal passes.
How to know it's working: You ship at the pass count you set, not when you feel ready.
6. The Filter Before the Funnel
The principle: Build a filtering mechanism before a distribution mechanism. The filter selects who engages; this produces better long-term outcomes than the funnel that maximizes who sees.
Why it's non-obvious: Conventional thinking says build the audience, then convert. Filter-first looks like slow growth. But wrong people drain resources and produce noise; right people compound.
How to implement: Design your initial contact surface (post, product, first meeting) as a filter: does this person process information at the level where they'll generate value? If yes, proceed. If no, exit gracefully.
How to know it's working: The people who engage feel like they were selected for, not just acquired.
7. The Meta-Layer Architecture
The principle: When your AI operating system becomes sophisticated, build a node that can observe it from outside. You cannot audit your own constitution from within it.
Why it's non-obvious: Most people build their AI system and reflect on it in the same session. But the same session running on the constitution can't reliably find where the constitution is wrong — it's running with the same priors.
How to implement: Create a session type explicitly separate from operational use. Different starting context. Explicit mandate: find where the primary system is wrong. Run quarterly.
How to know it's working: The audit produced at least one finding that made you uncomfortable.
8. Timing as the Primary Variable
The principle: Optimize for WHEN, not just WHAT. The timing of a decision is a first-class dimension of decision quality that most frameworks ignore.
Why it's non-obvious: Most decision frameworks evaluate accuracy, calibration, and reasoning — none capture timing. The right decision 6 months early creates the wrong context. The right decision 3 months late misses the window.
How to implement: For each consequential decision, identify: when is this decision load-bearing? What information do I need by then?
How to know it's working: You can name the three decisions in the next 18 months where timing matters most.
9. Write First, Understand Second
The principle: The writing process IS the thinking process. Writing before you understand produces better output than thinking before you write.
Why it's non-obvious: Professional culture says "plan first, then write." Expert practice says the opposite: generate rough material, revise, compress. The planning-first approach is constrained by what you can think abstractly.
How to implement: For complex questions, write before you're ready. The first draft reveals what you were trying to say. The second compresses it.
How to know it's working: The finished piece says something the original plan didn't contain.
10. The Picbreeder Protocol for Decisions
The principle: When exploring a decision space, generate enough variation to see the shape of the good options before selecting. Premature convergence produces locally optimal choices that are globally mediocre.
Why it's non-obvious: Under time pressure, the default is the first good-enough option. For strategic decisions that set years of trajectory, premature convergence is costly.
How to implement: For strategic decisions, generate 20-30 options without evaluation. Cull to the 5 most interesting (not most obviously good). Then evaluate the 5.
How to know it's working: Options generated during the session surprised you. At least one was something you wouldn't have thought of at option 1.
11. Name the Actual Blocker
The principle: The mental model of what's blocking you is almost never the actual blocker. The actual blocker is usually simpler and requires a different kind of commitment.
Why it's non-obvious: The mental model of the blocker is constructed to be solvable by the kind of work you're already doing. "I need one more revision" is the mental model when the actual blocker is "I need someone else to evaluate this." The mental model lets you keep doing what you're doing.
How to implement: When you believe something is blocked, describe the blocker in one sentence. Ask: is this the real blocker, or is this the rationalized version?
How to know it's working: The blocker description, stated honestly, reveals a simpler, harder thing than what you'd been telling yourself.