If you cannot say what changed, you probably have not explained the mechanism yet.
Many explanations sound complete because they contain the correct nouns. They name the parts, describe the setting and use the vocabulary of the field. Yet the reader still cannot predict what happens next.
Mechanism mapping fixes that problem by forcing the explanation to follow motion and change.
For eduKateSG’s How X Works programme, a useful first map contains six anchors: boundary, inputs, constraints, state change, output and return.
They are not a universal scientific law. They are an explanatory discipline: a compact set of questions that makes hidden structure visible.
1. Boundary: Decide What System You Are Explaining
A boundary says what is inside the explanation and what is being treated as environment.
This sounds simple until the system is real.
Where does a school begin? At the classroom door? The campus gate? The curriculum? The family routines that make attendance possible? The assessment system that influences teaching? The answer depends on the question.
A useful boundary is therefore neither “everything” nor an arbitrary box. It should be wide enough to contain the mechanism being studied and narrow enough that cause and effect remain traceable.
Boundary mistakes produce two opposite failures:
- Too narrow: the explanation treats important causes as mysterious external shocks.
- Too wide: everything is connected, so nothing is explained with precision.
2. Inputs: What Enters the System?
Inputs are whatever the system receives before it can act.
- A power plant receives fuel, water, operating instructions and demand signals.
- A bank receives deposits, payment instructions, loan applications, capital and information.
- A learner receives explanations, examples, practice, feedback and cues.
- A logistics network receives orders, goods, addresses, capacity and time commitments.
The important move is to separate the input from the result. A student entering a lesson is not yet “learning.” A parcel entering a network is not yet “delivered.” A loan application is not yet “credit.”
The mechanism sits between entry and outcome.
Inputs Have Quality, Timing and Form
Not all inputs are equivalent.
Clean water and contaminated water are both water. Accurate data and corrupted data are both data. A clear instruction and an ambiguous instruction are both messages. Ten minutes of available capacity now is different from ten minutes available after the queue has formed.
Mechanism mapping therefore asks not only what enters but in what state, at what time, with what uncertainty and under whose control.
3. Constraints: What Shapes the Possible Path?
Constraints are what stop a system from doing anything it wants.
Some are physical: pipe diameter, heat, friction, mass, bandwidth, storage space.
Some are institutional: law, budget, authority, policy, contractual obligation.
Some are cognitive: attention, memory, prior knowledge, processing load.
Some are temporal: deadlines, lead times, sequencing, decay and recovery time.
A weak explanation treats constraints as annoying details. A strong explanation often discovers that the constraint is the mechanism.
Queues form because service capacity is constrained. Interest rates matter because capital and risk are constrained. Grammar matters because language does not allow words to combine in every imaginable order. Engineering exists because materials and forces impose limits.
4. State Change: What Becomes Different?
This is the centre of the map.
A state is a condition the system can be in. A state change is the transition from one condition to another.
- An unverified identity becomes verified.
- A raw material becomes a component.
- An order becomes allocated inventory.
- An uncertain student response becomes diagnosed evidence.
- A train route changes from normal operation to degraded operation.
- A proposal becomes an approved plan.
State-change language prevents vague verbs such as “handles,” “manages” or “processes” from doing too much work.
If a sentence says “the system processes the request,” ask what the request is before and after processing. That usually reveals the real operation.
5. Output: What Leaves the Boundary?
An output is the system’s immediate result, not necessarily the final human outcome.
A traffic signal outputs a right-of-way state. The human outcome may be safer, more orderly movement. A bank may output a payment confirmation. The broader outcome is completed exchange. A school may output assessment evidence. The broader outcome is improved capability — if the evidence is used well.
Separating output from outcome matters because systems can produce the specified output while still disappointing the receiver.
A parcel can be marked “delivered” at the wrong location. A test can be graded correctly yet measure the wrong construct. A hospital can complete a procedure while the patient’s broader problem remains unresolved.
6. Return: What Comes Back?
The return path turns a one-way process into a learning system.
What comes back may be data, complaint, error signal, payment, acknowledgement, maintenance record, examination result, sensor reading or social response.
The return path answers a crucial question: how does the system know what happened?
Without return, failure can remain invisible. A delivery system without proof of receipt cannot reliably distinguish success from loss. A learner without feedback can repeat the same misconception. A government without trustworthy observation can keep acting on an outdated picture of reality.
A Worked Map: How a Restaurant Order Works
A small example shows the discipline.
- Boundary: from customer order entry to food reaching the table.
- Input: menu choice, table number, timing, payment context, ingredient availability.
- Constraints: kitchen capacity, recipe sequence, equipment, staff, food safety, stock.
- State change: requested dish → queued ticket → preparation → cooked dish → plated dish.
- Output: completed order delivered to the table.
- Return: acknowledgement, complaint, empty plate, payment, remake request, stock decrement.
Now several deeper questions become visible. What happens when two tables order the same scarce item? Where does queue priority sit? Who owns the handoff between kitchen and server? What happens if the dish is correct but delivered to the wrong table?
The map creates questions because it has exposed the interfaces.
A Worked Map: How Learning a New Algebra Method Works
- Boundary: from first encounter with the method to independent use in a new problem.
- Input: prior arithmetic, symbols, worked examples, explanation, attention.
- Constraints: working memory, misconceptions, time, prerequisite knowledge.
- State change: unfamiliar procedure → represented relationship → guided use → retrievable method → flexible selection.
- Output: a correct solution produced with coherent working.
- Return: feedback, error classification, later retrieval, transfer performance.
This explains why simply showing an example is not the same as teaching. The important state change is not “student saw solution.” It is “student can later select and execute the method under changed conditions.”
Map the Handoffs
Mechanisms often fail between strong components.
A handoff occurs when responsibility, information, material or authority crosses a boundary. The receiving side must understand enough of the sending side’s output to continue the process.
This is why How Interfaces Work and How Interoperability Works are natural companions to mechanism mapping.
Map the Failure States
For every important transition, ask what the nearby failure state looks like.
- Input missing.
- Input malformed.
- Capacity exhausted.
- Constraint violated.
- State transition partially completed.
- Output reaches the wrong receiver.
- Return signal never arrives.
- System reports success when the receiver experienced failure.
This turns reliability from a separate afterthought into part of the map itself.
Run the CivDJ Pass
Once the first map exists, run it three ways.
- Forward: input → constraint → state change → output → return.
- Backward: observed outcome → required output → required transitions → required inputs.
- Rotate: operator → receiver → maintainer → regulator → adversary → future user.
If the explanation only works from one direction, something important may be hidden.
Do Not Confuse the Map With the Territory
Every mechanism map is a reduction.
It leaves detail out so the reader can see structure. That is useful only if we remember the omission.
A map should therefore state its scope, important assumptions and boundary conditions. In complex human systems, values, incentives, power, culture and history may change the mechanism in ways a neat diagram does not capture.
Precision includes knowing when the model stops.
A mechanism map is successful when it makes the next causal question easier to ask.
The Return to How X Works
This six-anchor method is one of the recurring grammars behind the How X Works library. Different fields require different evidence and different technical models, but the discipline remains useful: define the boundary, identify the input, find the constraint, track the state change, inspect the output and follow the return.
Do that carefully enough, and a collection of nouns begins to reveal a working world.