A Scenario Has No Interior.

Why value, skills, and group comparisons keep failing when they are read per scenario.

Aerial night view of a city divided into glowing rectangular districts, with a single power station sending orange transmission lines out to feed districts across the whole city.
One plant, twenty districts. The district is where you observe.

In the same month, two rooms asked me two questions that sound unrelated.

A group executive pointed at a chart of autonomy levels plotted against repair times and asked why the value refuses to line up. A working group asked me to define the Level 4 skills for fault management in the radio network. Different rooms, same error. I nearly missed it, because I helped build the grid they were both standing on.

An address is not an interior.

Start with what a scenario actually is. In the autonomy world, a scenario is a coordinate on a grid: a technical domain crossed with an operational lifecycle. Fault management on the radio network. Energy optimization on the radio network. Quality on the IP network. The industry’s evaluation methodology is explicit about this: the thing being assessed is a scenario within a domain and a workflow, and the level certificate that comes out applies to that coordinate and nothing else. The first Level 4 certificate ever issued, in June 2025, covers exactly one scenario, energy efficiency optimization in one operator’s radio network in Denmark. That is the system working as designed.

Compare that to a software component in the industry’s own architecture: independently deployable, its data and interfaces contained within it. A component has an interior. A scenario has an address.

The grid of scenarios exists for a reason worth respecting. Vendors organize their automation differently, one packages it per domain, another sells a single platform, so their products cannot be compared directly. Observation points can. The scenario grid is the only vendor-neutral surface in the industry, which is exactly why certification lives there.

The framework never confused the two. Operations run in autonomous domains, flexible boundaries that can hold one scenario or several. Scenarios were standardized separately, and deliberately, so that any operator can be compared with any other on fixed coordinates. A flexible unit for operating, a fixed grid for comparing.

The trouble started when the fixed grid, because it is where the certificates and the money live, began receiving the operating questions too.

Nobody asks for District 7’s engineers.

Think of a city’s electricity. Outage statistics are kept per district. The power stations and the grid engineers belong to the utility, and one plant serves twenty districts. The bills are per customer.

Three grids, and everyone instinctively knows which question belongs to which. Nobody asks to meet District 7’s engineers. Nobody computes a power station’s return on investment from one district’s outage record. The district is where you observe. It contains nothing.

Autonomy has the same three grids, and the industry is currently pushing all three kinds of question through the first one.

Proof: scenarios A certificate lives at one coordinate. Build: platforms and teams Skills and cost span coordinates. today months in production Value: services, over time One photograph, three different ages.
Three grids, three kinds of question. Proof observes, build contains, value accrues.
Value does not live at the observation point.

The executive’s chart plotted certified levels against repair times, per scenario, and got scatter. Of course it did.

Value is billed the way electricity is billed: per service, per customer, over time. A fault management platform serves the radio network, transport, and IP at once; a service that fails crosses all of them; and each scenario reached its certified level on a different date, so a single-day chart photographs growth curves of different ages. None of that is visible at the coordinate. I have made the unit-of-analysis argument before, in Level 4 at 1.9, to explain how an industry averaging below Level 2 can still hold genuine scenario Level 4s. This is its other half: the unit that makes levels comparable is the unit that makes value unreadable.

Re-reading the chart takes three decisions, none of which needs a program. Put time on the axis, and start each clock where the capability started: the date it was operationalized in production, not the date it was assessed. Certification observes what production already runs; the industry’s first Level 4 certificate was issued thirteen months after the capability it validated went live. Second, pick one published definition of the repair metric and use it in every domain; repair, resolution, and recovery are three different clocks wearing one acronym. Third, agree internally what share of the movement autonomy owns, the way any shared cost is allocated, then hold that share steady.

The scatter is not evidence against autonomy. It is evidence that someone asked a district for a return on investment.

Skills do not live there either.

The working group’s question, what are the Level 4 skills for radio network fault management, assumes the coordinate has staff.

Run the test: take the platform team behind fault management and split it by scenario tonight. What would you have to duplicate into every cell? The data engineering, the model operations, the assurance design, the intent and policy work. That duplication list is the answer: the skill core is cross-scenario, because it lives in the platform, and platforms span the grid.

The genuinely local skills follow other boundaries. Radio propagation knowledge belongs to the radio domain, and it serves optimization there as much as fault management. Platform expertise belongs to the vendor’s product, and it does not transfer between products even inside one vendor’s portfolio. So the honest answer has three parts: a shared core, a domain layer, a platform layer. The scenario’s legitimate role in a skills conversation is to state the demand: which capabilities the coordinate consumes, and at what depth. It employs nobody.

Coordinates do not add up.

The third failure is aggregation. A group-level director once told me, with real frustration, that he had scenario assessments across his operating companies and no way to compare the group. He blamed the tool.

The tool was never the problem. You can average District 7’s outages with District 12’s, and what you get is a statistic, not a bigger district. Teams and budgets merge; observation points only tabulate. Anger at the scenario grid for not rolling up is anger at a map for not being a warehouse.

Route the question to its grid.

The scenario keeps the job it was built for. It is the unit of proof: where evidence is collected, where delegation is certified, where risk is gated, the same way a self-driving car is certified for a defined operating domain rather than for all roads on earth.

Everything else routes elsewhere, and the discipline fits in three lines. Proof questions go to scenarios. Build questions, skills, cost, staffing, architecture, go to platforms and teams. Value questions go to services, over time.

I own a piece of the confusion. I built per-scenario questionnaires and told teams to plan around them, because proof needed the grid, and proof still does. It took both questions arriving in the same month, from opposite sides, to show me what I had not said loudly enough: proof is the only thing that ever needed it.

The pilot that would settle it.

None of this has to stay theoretical. If a team wants to know whether level actually moves value, the pilot design follows from the grids.

Take one autonomous domain, not a pooled chart of many. Record when each capability inside it was operationalized in production; that date starts every clock. Pin one metric with one published equation, measured where it is billed: repair time inside the domain, recovery time at the service layer, never blended. Then compare like with like: clusters where the capability runs against matched clusters where it does not yet, the closest thing live operations has to a controlled trial. Where no control is possible, agree the attribution share upfront and hold it. Read the result as a curve over months, with checkpoints, never as a point.

A pilot built this way returns one of two answers. Value grows with age, and for the first time there is a curve a business case can stand on: dated, controlled, attributable. Or value stays flat with everything controlled, and the level itself has earned the independent audit that exists for exactly this purpose. Both answers are worth having. The scatter chart gives neither.

If you run an autonomy program, this is the Monday morning version: before answering any question about autonomy, ask which grid it lives on. Most of the frustration I meet at group level, the flat value charts, the impossible skills matrices, the assessments that will not roll up, is a question standing on the wrong grid.

A scenario can hold a certificate. It cannot hold engineers, budgets, or returns.

It has an address, and no interior.

Level 4 Autonomy Insight, Issue #11 · July 2026 · Luqman Shantal