Framework / Conscious Stack
The 1:3:5 Rule
Why nine slots is the shape of a stack that holds
A bounded-slot architecture for the tools and commitments you actually work in — one Anchor, three Active, five Supporting.
For years, the same question came to me from others in the same shape: which tool should I use?
I answered it for people for a while. Then I stopped, because the answer rarely changed engrained behaviors. The question treats a tool as a standalone decision. A tool behaves more like a new resident in a building that already has tenants. Whether it works depends on what is already there — the context. What it duplicates, what it replaces, what it pulls attention away from.
Nothing in a person's week prompts the inspection. The friction reads as the cost of doing business, so it stays unnamed. The tools on the other side have an interest in that. Most are built to hold attention, which competes directly with "coherence."
So I looked at my own tools and tech stack. When I finally audited every application I was logging into or paying for, I counted 83. I had been running a company on top of a pile I could not have named from memory.
The 1:3:5 Rule came out of that simple exercise, and out of the dozens of observations I made with founders, operators, and teams over 15+ years. The constraint has a fixed shape: 1 Anchor, 3 Active, 5 Supporting. Nine slots per functional stack.
Nine is the ceiling in line with natural cognitive limits, not a target.
The three tiers
The Anchor of a Conscious Stack carries the stack's coherence. It's the tool you would rebuild first if everything else vanished, because it holds the memory, the context, or the canonical version of the work. Anchors tend to be unglamorous and durable. They rarely change.
Active tools are the next three you work inside of the most. This is where output gets made. Active tools rotate with seasons and projects, so a good month can retire one and install another.
Supporting tools feed the stack without being the place you live: inputs, references, pipes, storage, the small utilities that let the Active three do more than they could alone.
Each tier names a role. A Supporting tool can be more capable than an Anchor, and capability doesn't move it up a band. What matters is that every slot is occupied consciously, and you can say out loud what it's doing there (and why).
Why nine
1:3:5 is a governance heuristic, drawn from three sources: bounded cognitive capacity (Miller's Law), the way attention sorts itself hierarchically, and a pattern I kept meeting in real life, where stacks that grew past roughly nine live tools stopped being legible to the person running them.
Miller's Law (7±2) describes how many discrete items a person can hold in the mind at any one time, based on research from the 1950s. A stack has to be named and known in order to be governed. Nine slots sits near the absolute edge of that capacity, even though today's average sits mostly around 4, which is what makes it force a decision instead of just shuffle.
The shape carries weight as well. A pyramid holds because weight moves downward and each tier rests on the one below it. A flat list of forty tools has no load path. Nothing rests on anything, so nothing can be trusted to stay put.
What the constraint exposes
The rule is a forcing function, and its value shows up in the moment it makes you uncomfortable.
Try naming your three Active tools when you have eleven candidates. The choosing surfaces the truth: three of them do the same job, two have not been opened in a month, and one is still there only because a client sends files through it.
Then come the discoveries that surface later. A Supporting tool that quietly became the only place a critical handoff lives. A subscription you are paying for out of habit. An Anchor that drifted, so last year's Supporting tool now holds the canonical version of everything and nobody decided that.
Drift is the hardest thing to catch. A stack changes by accretion, and accretion hides its own history. The constraint gives you a fixed reference point, which makes drift visible while it's still small enough to reverse.
How I found it
The first version of this circulated as 5:3:1, written base-first. The current form is 1:3:5, written apex-first, because that is the order in which the decision should be made.
Roughly two years of direct practice refined it: dozens of individual stack audits, workshops, meetups, and a long argument with my own tooling. The pattern held across founders, operators, consultants, and growing teams. The problem was almost never the wrong tool. The structure had no roles in it.
The same geometry governs how I ask for work. The 1:3:5 decides what belongs in a stack; the fuller form, 1:3:5:3:1, decides how intent travels through one. You compress what you want into a single apex intent, three boundaries, and five declared context points. The answer compresses back into five findings, three action vectors, and one directive. The shape is an hourglass, and the mechanism is that nothing enters you didn't declare and nothing leaves you can't act on.
I published it as an open protocol called the Pingala Handshake. The spec and the system prompt live at georgesiosi/pingh-protocol, ready to paste into your AI runtime and run on a real task. The name comes from the Indian mathematician and poet, Pingala, who turned the fluid rhythm of Sanskrit poetry into short and long syllables. The earliest known description of binary (and the Fibonacci sequence actually, long before Fibonacci).
Codifying something fluid into a countable structure is the same move, made two thousand years apart.
The same shape applies to commitments
Tools are the easiest place to see the rule and the least interesting place to use it.
Any functional stack can take the shape: communication, capture, delivery, money, health, learning. Your whole digital ecosystem becomes a master stack with core stacks and substacks inside it, each one bounded on its own terms.
The constraint works on commitments too. I run my own mission architecture on the same geometry: one apex intent, three operating modes, five support functions. It's the same decision at a different scale. Name the thing everything rests on, name the few things you actually work in, then name what feeds them. Whatever is left over is a candidate for removal.
The failure it prevents
Every tool you add takes on a judgment. Some of those judgments you meant to hand over. Others left without asking.
The risk runs in sequence: delegation becomes abdication, and abdication becomes nullification, the point where you can no longer evaluate the systems acting on your behalf. Unbounded stacks accelerate that sequence, because you can't audit a ledger you can't read.
A bounded stack keeps the ledger small enough to read, which keeps the transfer of judgment visible and reversible. Owning fewer tools is a side effect. This is why I like to keep Notion as my personal Anchor tool, because it's proven to be a solid presence in my personal stack since 2014.
Where the rule stops
Nine may be the ceiling, and going under it is fine. Eleven tools with clear roles beats four you can't explain, because the aim is governability.
The threshold itself remains a research question. Nine has held across many stacks. I haven't proven that nine is the number, but it works symbolically too (the number of completion). Treat it as a working constraint for now that you can revise with more evidence.
The individual model is the clearest starting point. Scaling the same geometry across an organization is active practice and research.
Running it once
To test the rule on your own stack, the first pass is simple.
Write down everything you use. Group it into functional stack categories (e.g. Productivity, Finance, Social Media, Communications, etc.). Name one Anchor for each. Then cut to the ceiling by asking, of every candidate, whether you would miss it within a month. Repeat when the season changes, because a stack is a living thing and the roles shift.
That first pass leaves you with a map. Reading the map, choosing which stack to redesign first, and knowing which interventions move a stack from fragmented to coherent is where Conscious Stack Design™ does its work.
The return
If you do not design the stack consciously, the stack will design you unconsciously.
A stack you can name is a stack you can govern, and that's the entire return on the constraint. It compounds every quarter you keep it, because the decision you make once about what belongs keeps making itself.
The 1:3:5 Rule is part of Conscious Stack™ and the practice of Conscious Stack Design™, developed by George Siosi Samuels through 15 years at the frontier of emerging tech. The full methodology — stack maps, the maturity ladder, stack profiles, and the audit protocol — is taught inside his CT Lab and applied in consulting engagements.