How to run an analysis

Every analysis is the same five moves. The first four are yours on the canvas; the fifth is one click and then judgment.

A team system is the organized effort of people (and now, of people and AI) that transforms inputs into an output someone values. Before drawing, decide the boundary: which team are you examining, and what is the supersystem it serves? The project name you choose stands in for the supersystem throughout the analysis, so name it for the real context (“PPM Enterprise,” “North Region Claims”), not for the exercise.

Scope to one question. A plant with three shifts and a quality lab is drawable in twenty minutes; the whole enterprise is not, and does not need to be. Subsystems you are not examining today can be drawn as simple systems, and other projects can be embedded as referenced systems where their internals matter.

Six kinds of element carry the whole method. Draw what is, not what you wish were there; the compiler reads the drawing literally, and that literalness is exactly what makes the output defensible.

System

A team system or subsystem: the dashed panel. Place elements inside it and they belong to it. Membership is read from the geometry, so containment on the canvas is the org structure in the analysis.

Zone

A lighter grouping panel for staging areas and contexts that are not themselves team systems.

Role

A person or an AI doing work, drawn as a card. Mark it HUMAN or AI. The designation is analytic, not decorative: AI roles face the framework’s value and ideality tests explicitly.

Input / Output

The objects the system consumes and produces, drawn as chips. The outputs you draw are what the compiler reads as the system’s actual output, A.

Value flow

An arrow from element to element, named with a verb (“machining,” “hands job to robot”). Flows can carry marks of their own, and the analysis assigns each flow to the deepest system containing both of its ends.

Referenced system

Another project embedded as a live snapshot. The compiler recurses into it: its systems get their own worksheets, at their own layer.

Marks are declared judgments: you are placing evidence on the drawing. Each mark has a precise meaning in the framework, and each lands in a specific place in the compiled analysis. This is where the terms of the Solution Algorithm come from.

BENEFIT

Output that is as expected; positive. An external-only measure. Feeds B in the value test, B > C.

COST

A real expense, loss, or penalty; money or time. External-only, and always weighed on the value side. Feeds C.

HARM

A real damage or injury. Feeds H in the ideality test, A > R·P·H.

VALUE

Where the value the system exists to deliver actually lands. Anchors the required output, R.

NEED

The need the system answers. Anchors R where no value mark exists.

CONTRADICTION

Two goals pulling against each other at one place. Feeds P, the problems term, and drives the contradiction analysis in the diagnosis.

NOCONTROL

A span the team does not control. Also feeds P.

IDEALITY

Where the system’s ideality is actually measured. Its absence next to a harm is one of the compiler’s warnings.

DELTA

Where a change is already contemplated or underway.

PROTECT

What must not be damaged by any move you make.

The Solution Algorithm frames its questions only from a stance you have declared. Two marks declare it, and they mean opposite things:

IFR

Elimination. You intend to make this element unnecessary. The compiler writes the equation for the marked element itself, IFR(element) = [the element as drawn], and frames Test One: what would remove the need for it entirely, with no new cost, problems, or harms? Driving it to zero does not mean eliminating the team: at zero the system has become resource-positive, and the capacity the element consumed can be reassigned to new value.

BPS

Minimization. The component stays, and the work is to minimize its cost and harm without eliminating it. The compiler derives the six terms from your drawing and frames Tests Two and Three, the value balance and the ideality balance, as the instruments for finding its leanest necessary version.

Mark as many elements as your intent covers. Several IFR marks are not a contradiction; each marked element carries its own equation, each driven to zero on its own. And a system with no bias declared is not skipped silently; it is recorded as a finding, because an unmarked, non-utilized component is itself a finding, and the mark that fits is yours to choose.

One click produces the report and the deck together, every figure rendered from your drawing. The report runs in a fixed arc:

• The system under examination: your diagram, described in prose, structure by structure.
• The analysis: the diagnosis, meaning what is marked, where, and what the geometry says about it.
• The Solution Algorithm: the turn from what is to what to do. A primer derives the framework’s equations step by step, each formula appearing exactly once, at the moment its terms have just been defined; then one worksheet per system carrying a declared bias, at every layer, including inside referenced systems.
• Matched solution models: each model that structurally fits your drawing, with a mini diagram of the exact elements it addresses in your system, your fit line, the framework’s definition, and its illustration.
• The Seven Motifs: the operational test of ideal, keyed to the marks that summoned them.

Each worksheet derives the variables from your diagram as far as the diagram carries them: B and C from your benefit and cost marks, A from the outputs you actually drew, R anchored to your value or need marks, P from the contradiction and no-control marks, H from the harm marks. What the diagram does not offer, the worksheet says so, plainly, and hands to you.

The compiled worksheets end where your judgment begins. This is the part no software should do for you, and this one is built to refuse:

Like any compiler, the Canvas points at what will make the build stronger. These are not errors; each one marks the place where the next piece of evidence will sharpen the case:

• A cost with no benefit marked against it. Either a benefit exists and is ready to be drawn, or the cost stands alone; either way, a finding worth having.
• A benefit with no cost. Rare in nature; usually a cost ready to be drawn, completing the balance.
• A harm with no ideality measure. Adding the measure to weigh it against turns a claim into an analysis.
• Components with no declared bias. Recorded once as a finding: an unmarked, non-utilized component is a decision waiting for its mark.

• Draw what is. The as-is drawing is the source; the to-be lives in the deltas you choose, not in the diagram.
• Name flows with verbs. “Reads spec,” “hands job to robot.” The analysis reads your labels back to you, and verbs compile into prose that sounds like work.
• Let containment carry meaning. If a role is inside a system on the canvas, it is inside that system in every worksheet. Move it out rather than mentally excepting it.
• Use referenced systems for shared subsystems. A quality lab three teams depend on should be one project, embedded three times: drawn once, analyzed at its own layer everywhere it appears.
• Recompile often. The build is cheap and deterministic. Compile after each marking pass and read what changed; the deliverable shows you your diagram more clearly than memory can.
• Bring the drawing to the room. The report cites the diagram, so the diagram is your defense. When someone challenges a line, the answer is on the canvas.