Fable
Not Just Recording the Master, but Recording the Entire Workshop
After the town made work badges for every master, accidents decreased somewhat. But one order still went wrong: the master was fine; the fault lay between the work assignment process, warehouse tools, and acceptance rules.
The client asked where the responsibility lay. The manager produced the master's work badge, proving the master's craft was qualified; the warehouse produced the tool manual, proving the interface was normal. But no one could explain how the entire system was designed, evaluated, and controlled.
The mayor first put all the documents into one cabinet. There was a lot of material, but it still did not look like a statement that would let an external reviewer understand system risk.
Later they wrote a workshop master register: workshop goals, customers, masters, tools, goods flows, keys, risks, remedies, trial results, manual supervision, and known limitations.
The master ledger shifted discussion from a single craftsman to overall delivery. A reception clerk's risk comes not only from eloquence, but also from the filing cabinet, external tools, keys, transaction records, shift-change procedures, and the senior craftsman taking over.
At the launch review, the team checked item by item against the master ledger: which capabilities could be publicly promised, which failure modes had monitoring, and which scenarios had to be refused or escalated. The workshop also had far fewer arguments because of this. Previously, after an error, everyone proved that their own segment was not broken; now they first looked at where the whole chain of responsibility had broken, then decided whether to fix the tool, the process, the permissions, or the acceptance criteria.
The master ledger also had to be updated as the system changed. Changing craftsmen, adding tools, expanding customers, or changing data sources all change the risk surface. When external reviewers came again, they were no longer taken on a tour of scattered cabinets. They first looked at the master ledger, learned who this workshop served, which doors would be locked, and which tasks must be handed to the master craftsman, then spot-checked the corresponding evidence.
The mayor finally understood that the enterprise was not buying a craftsman, but a system that would affect real business. System-level documentation must cover the entire chain of responsibility. Later, the steward wrote this lesson into the daily rules: first look at the scenario, then the boundaries, and finally who can take over when things fail. Only when all of this is clear does a beautiful demo become deliverable work.