Move the line one notch and watch the work double

Same company as two lessons ago. One hundred and forty systems, 31 of them holding customer data. Two hundred and ten people, 24 of them able to reach production. Twenty-eight contractors. Seventeen other companies inside the delivery.

The line has four positions and each one adds exactly one category to the position below it:

• Narrowest — systems holding customer data, and people with production access.
• One notch — plus the contractors.
• Two notches — plus the other companies.
• Everything — plus every remaining system and every remaining person.

That is a well-defined notch, which is the only reason the phrase move the line one notch means anything. Commit to a number before you move it.

Predict

Going from the narrowest line to everything: by what factor does the count of systems and people inside the line move?

Choose one answer

About forty per cent moreRoughly doubleAbout seven timesAbout fifty times

Lock in answer

Scope arithmetic

≈ Hypothetical model, not a forecast

Counts the systems and people inside a stated certification boundary, the ones left outside it, and how far the count moves when the boundary shifts by one category.

It assumes

• Each position of the line adds exactly one category to the position below it, which is what makes a notch a defined step.
• Contractors are counted as people and other companies as systems, never as both.
• The widest position is everything there is: all systems, all people, all contractors, all other companies.
• The four counts are an inventory somebody produced rather than a measurement.
• Effort is not modelled. This counts things, and one noisy system can cost more hours than forty quiet ones.

It ignores

• Whether the boundary chosen is defensible, which is a judgement and the whole argument
• Nested subprocessors — the ones your subprocessors use, which are in scope for your customers whatever your boundary says
• Shadow systems nobody put on the list, which are out of scope by omission rather than by decision
• Data flows: a system holding no customer data but able to reach one that does
• Effort, which does not scale with the count — one noisy system can cost more than forty quiet ones
• That the boundary a customer assumes is almost always wider than the one certified

Find the position of the line where moving one more notch would add more than two hundred systems and people — and stop there rather than going past it. The figure you need is one of the summary tiles, not the chart.

Contractors28

Subprocessors17

Boundary0

0 data systems and production access, 1 adds contractors, 2 adds subprocessors, 3 is everything.

Systems inside the boundary

31

People inside the boundary

24

Systems and people inside the boundary

55

Systems and people left outside it

340

Boundary tier: 0 narrowest, 3 everything

0

Systems and people one category wider would add

28

The count one category wider

83

Systems and people one category narrower would drop

0

The count one category narrower

55

Everything there is to put inside or outside

395

Share of the whole estate inside the boundary

0.139

• Inside the line
• Left outside it

◷ Not there yet — keep moving the controls.

Where the seven times actually lives

Four positions, four counts inside the line: 55, then 83, then 100, then 395.

The notch arithmetic is lopsided and it is lopsided in the direction nobody expects.

Adding the contractors costs 28. That is the notch with the longest meeting attached to it, because somebody from legal has an opinion about whether a contractor is personnel and somebody from engineering points out that four of them have production access already.

Adding the other companies costs 17. That is the notch with the second-longest meeting, because it is the one where the word supplier appears and everybody has read something about third-party risk.

Adding everything else costs 295 — six and a half times the two arguments combined. That notch has no meeting, because it is not a category anybody names. It is what happens when the filter comes off: the first three positions are defined by a predicate (holds customer data, can reach production) and the fourth abandons the predicate entirely.

So the lever is not really the four positions. The lever is whether a predicate exists at all, and the three notches you argue about are the cheap ones.

The honest consequence

Two things follow, and the second is the uncomfortable one.

A boundary decision made by reasoning about percentages is wrong by an order of magnitude. If the instinct is widening it a bit would not hurt, the instinct is calibrated on levers that move by fractions, and this one does not.

And the direction of pressure in a real company runs the wrong way. Every individual request to widen the boundary is small — one environment, one team, one region — and each is argued on its merits by somebody with a good reason. Nobody ever proposes abandoning the predicate. It happens by accretion, one reasonable addition at a time, and the arithmetic above is what it costs when it finishes.

Check

Your narrow boundary covers the 31 systems holding customer data and the 24 people with production access. All 140 systems authenticate through one identity provider, which is inside the line. What is the strongest objection a buyer's reviewer can make?

Choose one answer

That the identity provider should have been excluded, because it serves systems outside the lineThat a credential problem in the identity provider reaches the 109 systems you excluded, so the predicate does not separate the two groupsThat the count of people with production access is too low to be credibleThat the boundary leaves most of the company outside it

Check answer

›Why the predicate leaks, and what to do about itOptional

A boundary built on holds customer data separates systems by what is in them. Compromise does not travel that way; it travels along access paths, trust relationships and shared credentials.

So the narrow position survives a reader only if the things crossing the line are themselves inside it. The identity provider, the deployment pipeline and the secret store are the usual three: each sits on the path between what is inside and what is outside, and each has to be in, which is why a well-drawn narrow boundary always contains a handful of systems that hold no customer data at all.

The version that does not survive is the one where a system outside the line can reach a system inside it and nothing in between is enclosed. That is not a counting problem and the model will not show it to you — it reports a count, not a topology. It is the one thing you have to check by hand, and the check is mechanical: for each system inside the line, list what can reach it, and see whether that list stays inside.

Worth remembering

• Four positions of the line, four counts: 55, 83, 100, 395 — a factor of about seven from narrowest to widest.
• The two notches people argue about add 45 things between them; the notch nobody names adds 295.
• The first three positions are defined by a predicate; the widest abandons the predicate, which is where the multiple lives.
• The boundary is the only lever in this subject that moves cost by multiples, so percentage instincts are wrong about it by an order of magnitude.
• Boundaries widen by accretion — each request is small and well argued, and nobody ever proposes removing the predicate.
• The count does not show you topology: a narrow boundary only survives a reader if everything on the path across the line is itself inside it.