You do not extract a business. You instrument it.
Ten percent.
That is what a battery of analyses recovered when I pointed it at my own company’s data with the answer key hidden. Six of the 63 hard constraints that make a trip invalid, unsafe or illegal. I had said beforehand that recovering most of them would prove the method transfers. Six is not most. By my own stated bar I had proved I am good at my job, which is a different thing and does not sell.
Then I looked at where the six had come from, and the day got more interesting.
The useful data was the argument log
The same run turned up 18 real constraints that two years of building the system had never written down. 14 of them came from one table.
The override log. Every time a person overruled the software.
Not the schedule. Not the bookings. Not any of the tables I would have called the operational record. The log of people disagreeing with me.
Obvious afterwards. A rule that is written down is already in the system. A rule that is not written down stays invisible until something breaks it and a human reaches in to fix it. The fix is the rule. That correction is the only moment it exists in a form a machine can read.
Ask, show, or be wrong
Asking people for their rules does not work, and this has been known for forty years. Experts give you the tidy version and forget the exceptions.
So I stopped asking and started showing. Put a person’s own data in front of them and let them react. Faster, and it works on people who cannot explain themselves at all.
This result goes one further. You do not have to show them anything either.
Build something confidently wrong. Put an override next to every decision. Then get out of the way.
Recall is hard. Recognition is easy. Correction is free, because they were going to do it anyway to get through their shift.
The system stops being the thing you built out of the knowledge. It becomes the thing that collects it.
What I would do in a business I have never seen
Pull the data. Expect ten percent. That is not a disappointment, it is a budget. Ten percent tells you what the objects are, what a job is, what a resource is, what collides with what. A few days.
Fill the rest with judgment and admit that is what it is. Not “what are your rules”, because nobody can answer that. Instead: here is what I think your business does, tell me where I am wrong.
Ship it wrong, on purpose. This is the part that sounds reckless and is the opposite. A system nobody can overrule gets abandoned in week two. A system that is easy to overrule gets used, and every override is somebody handing you a rule you did not have, timestamped, with the context still attached.
Read the arguments. 14 of my 18 came from there. A second pass across nineteen days of internal channels, against a 39-rule baseline, found 48 more.
Then do it again. Each round is less wrong, so there are fewer overrides, so the ones left are the rare and expensive rules.
That loop does not need me to know your business. It needs your business to keep correcting something. Which is a much smaller promise, and one I can actually make about a company I have never walked into.
It also changes the first ninety days. Not discover, then build. Build early, build wrong, build cheap, and let the operation teach it.
Where it breaks
Three kinds of rule never showed up anywhere, and I do not think they will. Which two things must never be put together, when both are fine on their own. What makes someone uneasy without stopping them, because unease leaves no trace. And what to assume when the data is missing, which the record can never tell you, because the record is what the assumption produced.
There is also an honest failure mode. An override can be wrong. Somebody may have overruled the system because they were late, not because the system was. That is why a person stays in the loop as a check and not as a courtesy.
The version I will defend
I set a bar, ran the test, and missed it. Ten percent is not a method.
What is left is smaller and harder to argue with. The analysis does not have to find your rules. It has to find enough of them to build something worth arguing with.
The argument is where the rest of them are.
This is step five of the order I work in, the operating system underneath everything else. The first four are product, people, demand and pricing, and doing them out of order is a different essay. If you are building something in this direction, or you run an operation and have watched people overrule your software all season, I would like to compare notes.