a planning method
Most delivery problems are scope problems, settled upstream, where they are invisible and compound.
nobody skips the thinking
the unit
An atom is the smallest coherent unit of work worth governing: one deliverable, one owner, reviewable on its own. It is sized by judgment, not a fixed line count. Before it is built, an atom earns the right through a short structured plan, and the plan is thrown away once the work lands. The plan is scaffolding, not a monument.
the capsule
Fixed spine, adaptive flesh. Decompose work into atoms. Plan each against a spine that is always there. Verify every assumption against the real code before you build. Build to the plan. Review at a depth that matches the risk. Ship a PR you can defend. Everything else is calibration: archetype sets the shape, risk sets the scrutiny, rigor sets how finished it must be.
the five tests
Small is not the test. An atom is the smallest unit of work that passes all five at once. Miss one and it is not an atom, it is a task with ambitions.
You can see when it starts and when it ends. No ambiguity.
Capture time, quality, cost, and risk with meaningful precision.
A pattern exists. Not a one-off; it happens often enough to matter.
It builds into larger outcomes. Building blocks, not dead ends.
One person or role is accountable for its completion.
the category error
A fair question: isn't this just task tracking with nicer words? The difference is a category error worth naming. A ticket is a coordination object, tuned to help people remember and sequence work. An atom is a unit of work defined tightly enough to plan, build, and verify. One tells you where the work is. The other is the work.
a ticket
a coordination object
an atom
a unit you can steer
None of this means abandon your tracker. An atom can live as a single ticket. What changes is the rigor the atom demands, not the tool it sits in.
the spec
Naming an atom is necessary but not sufficient. Each atom carries a spec: the few things that have to be pinned down before it counts as work and not a wish. In atomic planning, that spec is the plan, and the mapping is nearly one to one.
A name with no spec is not an atom. It is a wish with a deadline.
the shape
Every plan has the same skeleton. Seven sections are always there. Everything else switches on only when it applies, and a section that does not apply is left out entirely, never stubbed "N/A". So a config tweak stays a one-page plan and a complex change grows only where the complexity actually is.
The rest is the flesh: Gate Contract, Integration, Substrate Verification, Public API Contract, Security, and a dozen more switch on only when their trigger fires.
calibration
The same skeleton flexes along three independent axes. They compose: a plan is a point in this space, and the sections it carries follow from where it sits.
What you are building. Sets the length band, the diagram that fits, and the sections the surface implies.
How bad it is if this breaks. Sets the scrutiny: the safety sections (Gate, Substrate, Assumptions) and how deep the review goes.
How polished it must be. Scales the completeness sections without ever stripping a safety section that a risk turned on.
the flow
Most of a good plan is the context you gather, not the words you write. The loop:
The smallest coherent unit of work. One deliverable, one owner.
Gather context, draft the spine, switch on only the flesh the work triggers.
Phase 0. Every path, symbol, and number is a claim to check against the real code, not a fact to trust.
Implement to the plan. If the ground shifts, stop and update the plan; do not code around it.
Twice: the plan before you build, the diff adversarially before you merge. Scaled to risk.
A reviewed, defensible change lands. The atom is done.
why it exists
The standard is five specific defenses against five specific ways plans go wrong. Know these and you understand the whole thing.
A plan can read perfectly and still cite a function that does not exist. Every path, symbol, and number is verified against the real code; if reality contradicts the plan, you fix the plan, not code around it.
The costliest duplication is a whole capability rebuilt because nobody searched. Before you build anything new, look for an existing owner and record what you found.
Draw the shape that matches the work: a pipeline gets a data-flow, a state machine a state diagram, a protocol a sequence. Not a one-size box-and-arrow. A trivial change gets none.
Adversarial review of the actual diff before merge. A control ships advisory and soaks against known-good and known-bad before it is allowed to block. A review loop states when it stops.
Small plans for small work. Only the seven core sections are ever required; if a plan feels heavy for the change, it is over-built, and that is its own red flag.
under development
The method is under active development, implemented and refined against real delivery. Here is the shape: the positions and the tooling, at a high level.
named at a high level. the mechanism stays in the repo.
the storybook
The same idea, told as a story
Atom Ant's Treehouse walks the method spread by spread, in plain narrative, with a bridge from the vocabulary teams already use. The gentlest way in.
go deeper
Every delivery method has to answer the same few questions, and most leave them to taste. How much work counts as one unit. How much plan a piece of work deserves. Who reads that plan, and what they are reading for. When a check has earned the right to stop you. A method is the set of answers, not the vocabulary.