Fable
A city defense map of ten common cracks
The new city built a talking service hall. It could read documents, receive merchants, call on warehouses, and fill out forms for people. The city lord thought that as long as there were guards at the gate, the city would be safe.
Not long after opening, trouble emerged from different directions. Someone hid malicious commands in incoming letters, someone tricked the office hall into handing over account books it should not have seen, someone made it call the wrong tool, and someone used a flood of requests to overwhelm the window. Each incident looked different.
The city lord first thickened the gate and required guards to question visitors. But some attacks hide in legitimate materials, some occur through internal permissions, some come from suppliers, and some arise from outputs being wrongly trusted. Guarding only the gate cannot stop cracks inside the city.
The old city defense officer mapped incidents into ten common types of cracks: contaminated instructions, leakage of sensitive information, unstable supply chain, excessive permissions, unverified output, over-dependence, unauthorized calls, insufficient evaluation, missing monitoring, and resource abuse.
This diagram is not every threat, but it gives craftsmen and officials a shared checklist. Each time a new window is built, they go through the ten categories of cracks one by one: how is the entrance isolated, how is power limited, how are failures detected, how is evidence retained.
The service hall would still encounter new tricks later, but it no longer relied only on panicking on the spot. The city lord understood that security for complex applications must start with a list of common risks, turning recurring cracks into fixed checks before launch, during operation and after incidents.
The city defense officer also emphasized that the ten types of cracks are not a talisman. If you only hang the diagram on the wall without turning it into acceptance checks, permissions, records, and drills, the next incident will still come in through the same places. The checklist must enter daily processes.
Later, each time a new service window was added, the craftsmen would walk through the city defense map: what is the worst input, what can be called upon, who will trust the output, who can see anomalies. The ten risk categories turned security discussions from vague worries into concrete engineering checks. Later the city lord found that this map also helped different craftsmen align their language. The people fixing gates, managing keys, and verifying outputs finally knew which type of cracks each was guarding against, and security no longer relied on just one expert. Checklists cannot replace judgment, but they can prevent teams from repeatedly missing the same type of danger. Later, incident reviews were also archived by these ten categories, making it easier to block issues before the next launch.