A good library does not merely store answers. It helps you find the next question.
That is the idea behind a mechanism library. Instead of arranging knowledge only by school subject, alphabet or publication date, it also asks what kind of process is being explained. What moves? What changes? What constrains it? Where does the result go? What fails? How does the system return?
eduKateSG’s How X Works programme uses that logic to turn a large collection of explanations into something closer to a map of the world.
The ambition is not to pretend that the world is simple. It is to make complexity navigable.
The Starting Point Is a Real Question
Most useful knowledge journeys begin more naturally than a textbook chapter.
Why does a bank lend money? Why does a queue suddenly grow? How can a train line recover from disruption? Why does a word mean one thing in one sentence and another elsewhere? How does a city get clean water to millions of taps? How does a learner remember something next week rather than only five minutes after the lesson?
Each question opens a mechanism.
The library’s first job is therefore not to force the question into a predetermined shelf. It is to identify what the question is actually asking about.
A Mechanism Is More Than a Definition
A definition tells us what a term means. A mechanism tells us how a result comes about.
Consider “queue.” A definition may describe a line of people or jobs waiting for service. A mechanism explanation asks why the line forms, how arrival rate compares with service rate, what happens when variability rises, where capacity sits, what the waiting cost is, and how the queue disappears again.
Once that mechanism is understood, the reader can recognise versions of the same pattern in a clinic, airport, computer server, call centre, road junction, school marking pile or logistics dock.
This is what makes mechanism knowledge unusually transferable.
The Library Uses Multiple Indexes at Once
A conventional library can be searched by title, author or subject. A mechanism library needs additional indexes because the same structural idea may appear in many domains.
- Domain: banking, biology, mathematics, English, transport, government.
- Mechanism: feedback, buffering, filtering, matching, routing, conversion, allocation, coordination.
- Flow: information, money, energy, matter, people, authority, attention.
- Failure mode: overload, drift, leakage, delay, mismatch, fragmentation, corruption, loss.
- Lifecycle: creation, operation, maintenance, repair, retirement, inheritance.
- Receiver: student, citizen, customer, operator, institution, machine, future generation.
These indexes do not replace subject ownership. They create additional routes across it.
Root, Branch and Leaf Keep the Map Legible
If every article is treated as equally central, a large site becomes a thicket. The root–branch–leaf model solves a practical problem.
The root owns the broad reader job. A branch owns a major subsystem. A leaf answers a narrower question.
For example, How Banking Works can own the banking system. A branch may explain lending, payments or bank risk. A leaf may explain why the agreed property price and the financing value can differ. The leaf remains useful because the reader can climb back to the mechanism that gives it context.
This architecture also protects search clarity. A precise leaf should not compete with its own owner for the broad query. It should strengthen it.
The Mechanism Card: Seven Things We Want to Know
When eduKateSG maps a new system, we can reduce the first pass to a compact mechanism card.
- Boundary: where does this mechanism begin and end?
- Input: what enters?
- Constraint: what rules, capacities or physical limits shape it?
- Transformation: what changes state?
- Output: what leaves?
- Feedback: what information returns?
- Receiver: who or what finally experiences the result?
That card is deliberately incomplete. It is a starting frame, not the final explanation. Its value is that it forces the writer to name the moving parts before adding detail.
Then Run It Forward
The forward pass follows causation and sequence.
Take logistics. A customer demand becomes an order. The order triggers allocation. Inventory is picked, packed and staged. A carrier receives custody. The shipment moves through a network. Delivery is attempted. Receipt is recorded. Exceptions return upstream.
The power of the forward pass is that it exposes missing steps. If an explanation jumps directly from “warehouse” to “customer,” we know there are handoffs hiding inside the sentence.
Run It Backwards
Now start with the outcome and ask what must have happened earlier.
If the parcel arrived at the right door, the address had to be captured, interpreted and routed. The correct item had to be selected. Custody had to survive several transfers. The delivery network needed capacity. The final proof of receipt had to reconnect to the order record.
Working backwards often reveals dependencies that forward storytelling treats as background.
Rotate the Viewpoint
A mechanism can be technically correct and still be badly understood if we never change the receiver.
A payment system looks different to a bank, merchant, regulator and customer. A school assessment looks different to a student, teacher, parent, curriculum designer and admissions institution. A border looks different to a citizen, customs officer, logistics operator, refugee, business or neighbouring state.
Rotation does not mean every viewpoint is equally correct about every claim. It means the mechanism has consequences at several interfaces, and a complete map should know where those interfaces are.
Failure Is an Index Too
One of the richest ways to connect knowledge is by asking how systems fail.
A bottleneck in a port and a bottleneck in working memory are not literally the same phenomenon. Yet both invite the question: what happens when demand reaches a capacity boundary? Signal loss in a communication channel and evidence loss across a chain of citation are different, but both make us ask what survives transmission.
Failure indexing is useful because it turns mistakes into navigation. If the reader’s problem is delay, overload, drift or mismatch, the library can route them toward mechanisms that illuminate that failure across several fields.
The Warehouse Prevents the Library Becoming a Junk Drawer
More content is not automatically more knowledge.
A Warehouse discipline asks what each item is, what claim it supports, what owner it belongs to and which relationships are strong enough to publish.
It helps distinguish, for example, an observation from an inference, an event from a state, an institution from a role, a policy from its outcome, and a mechanism from a metaphor.
This matters because good knowledge architecture is partly the art of refusing false connections.
A Library Needs Canonical Owners
Suppose ten articles can plausibly answer “How do interfaces work?” If all ten compete for the same broad query, the site becomes uncertain about itself.
A canonical owner solves this. How Interfaces Work owns the general mechanism. More specialised pages can then explain interfaces in logistics, software, institutions, language or public infrastructure while linking back to the owner.
The same principle applies to modularity, coordination, reliability and interoperability.
The Reader Should Always Know Where to Go Next
A mechanism library fails if every article ends like a cul-de-sac.
The reader should be able to move in at least three useful directions:
- Up: return to the broader owner.
- Down: inspect a more concrete mechanism or case.
- Across: follow the same mechanism into a neighbouring system.
That creates a web without surrendering hierarchy.
Why This Becomes a Map of Civilisation
Civilisation is where the routes converge.
Food depends on logistics, energy, finance, water, regulation, labour, land, science and information. Healthcare depends on trained people, supply chains, buildings, data, public trust, finance and law. Education depends on language, memory, families, institutions, assessment, culture and time.
No single article can hold that world without becoming vague. A mechanism library can distribute the explanation while preserving the connections.
The library becomes powerful when a question has an owner, a mechanism has a route, and the reader can travel without losing context.
One Question, Then Another
The best outcome of a How X Works article is not that the reader reaches the end and stops.
It is that the first answer improves the next question.
Start with How X Works. Choose a system. Find what moves through it. Follow the constraints. Watch the state change. Inspect the failure. Find the repair. Then ask what neighbouring system receives the result.
That is how one question becomes a map of the world.