Which stage is your company on? And why most place themselves one too high.

In short: The data question is really two questions. Where processing happens is your vendor’s answer. What the system may touch is yours to design, per tool, with read and write kept apart.

Ask ten founders how well their company runs operationally and you get ten answers that cannot be compared. "Pretty well." "We have got better." "Chaotic, but it works." Those are moods, not positions.

Operational maturity can be stated more precisely, in four stages: ad hoc, governed, verified, compounding. I described them in their own article. This piece is about something else: which one applies to you, and why that question is harder than it looks.

Knowing your stage is not a label. It determines which next step is worth taking at all.

The four stages, and how you recognise them in daily work

Ad hoc. The company runs because particular people keep it running. Knowledge sits in heads, quality varies with whoever picked up the task, and standards are spoken or absent. The most reliable indicator is not disorder but dependency: if one particular person is out for two weeks, work either moves or waits.

Governed. The rules are written. Decision rights are explicitly assigned, routines documented, ownership named. What is missing is proof: "done" is a claim nobody checks against a defined standard. This is where most OKR and Lean rollouts stall, and where structure first starts to feel like effort without return.

Verified. "Done" gets evidence. There is a defined check against a defined standard, and FTT (First Time Through) makes visible how much of it holds on the first attempt. The felt difference day to day: trust becomes a property of the system rather than of a person. You no longer need to know who did it to know whether it is right.

Compounding. When something goes wrong, the governing artifact itself changes, the routine, the standard, the Role Contract. The same error does not take the same path twice. That is the point where a learning actually changes something instead of landing in a document.

Why the honest answer is usually one stage lower

Almost everyone who reads those four descriptions places themselves too high. That is not vanity, it is structural: we assess ourselves by our intent, and the system works on evidence.

Three confusions account for most of it.

The first: documented gets mistaken for governed. A process exists because somebody wrote it down once. Whether it is followed when things get tight is a separate question. Ad hoc with good documentation is still ad hoc.

The second, and this is the expensive one: checked gets mistaken for verified. Someone reads it over before it ships, so it feels like quality assurance. But if no defined standard exists to check against, that is an attentive person, not a procedure. If the person is away or the week gets busy, the check goes with them. That is governed, not verified, and it is precisely the stage where structure gets expensive without paying for itself.

The third: learned gets mistaken for improved. There was a retrospective, everyone was honest, it was a good conversation. If no artifact looks different afterwards, nothing changed except the mood.

We assess ourselves by our intent. A system assesses on evidence. The gap between the two is almost always exactly one stage.

The stage is per domain, not per company

Another reason quick self-assessment rarely holds: there is no single stage for a whole company. Sales can be ad hoc while bookkeeping is long since verified, because an accountant and statutory deadlines forced a standard into existence there.

An overall grade hides the very thing you need to see. The interesting number is not the average but the spread: which domain lags furthest, and whether that is the one currently capping your growth.

Company 0

I can show this on our own operation, honestly, which means with the caveat attached.

Content production at Rocket Routine sits at compounding, and I can say exactly why: there are documented rules, currently thirteen edit patterns, there is a defined check before every release, and when a review catches something it is not the single article that changes but the rule that governs all the following ones. That is the fourth stage.

The caveat: this holds for one domain, with one human and one AI operator. Other areas here are not there, and I would not claim a thirty-person company makes the same move in the same time. But it shows the pattern this piece is about: maturity arrives domain by domain rather than company-wide, and it arrives first where someone actually defined the check.

Why the precise stage matters

The practical reason this question earns its time: every stage has a different next step, and the step belonging to the wrong stage does nothing.

At ad hoc, a quality metric buys you nothing, because there is no standard for it to measure yet. The next step is writing down decision rights and routines at all. At governed, more documentation is the most expensive mistake available to you. The next step is one defined check for exactly one output. At verified, the next step is not another standard but the return path from an error into the artifact.

Underneath this runs a second movement: how much decision-making you have actually handed over. I described that elsewhere as five stages of development, and the two are connected: you climb the maturity stages by moving decisions and work up the delegation stages, to people and to governed AI operators alike.

That is why an approximate self-assessment is worth little and a precise one is worth a lot. Place yourself one stage too high and you will reliably invest in the step after next, then wonder why none of it lands. That is the real cost of imprecision, and it does not show up immediately. It shows up after a quarter without effect.

What this means for you

Take a single domain, not the whole company. Ideally the one carrying the most right now. And ask it a question that is harder to talk around than "is this going well":

If something faulty goes out of this area this week, what exactly would stop it, and would it still stop it while you are on holiday?

If the answer is a person, that points to governed, however well documented you are. If the answer is a defined procedure, that suggests verified. And if you can name what changed permanently after the last mistake, that points toward the fourth stage.

That single question is a rough cut, not a finding. It tells you the direction, not the stage, and certainly not which lever would be the most effective one for you. That takes more than one question, and the precision is worth having, because what hangs on it is whether your next quarter moves something or merely keeps everyone busy.

Frequently Asked Questions

What is a tool access policy?

A mandatory part of the Role Contract: read and write boundaries, defined per tool, on the least-privilege principle. Not "has access to our systems", but set per system and per direction.

Why does the difference between read and write access matter so much?

An operator with read access can draw a wrong conclusion, and quality checks catch that. An operator with write access changes the state of your company. That is why write access is the justified exception rather than the default.

Where is my data processed with an AI Operator?

Your vendor answers that, not the operating system. Rocket Routine OS is deliberately provider-agnostic: the client decides which language model runs underneath, and that decision can change without the governance above it changing.

How do I start setting access boundaries?

With a four-column table: which system, read or write, which slice, and who notices if something wrong gets written. If you can fill it in for your first role, you have a tool access policy.