Turn Your Business Knowledge
Into Software
Experienced staff make valuable decisions that the CRM never records. We capture how those decisions are made, document the exceptions and turn the repeatable parts into software the wider team can use.
Tacit
TO EXPLICIT TO CODE
Real cases
USED TO TEST THE RULES
Yours
KNOWHOW, CODE AND DATA
Capture the decisions experienced staff make
Michael Polanyi called it tacit knowledge in 1966: "we can know more than we can tell". MIT's David Autor used Polanyi's paradox to explain why tasks needing flexibility, judgement and common sense are hard to automate. Your senior estimator, your head of underwriting, your bookings manager. They all run on it.
The old way to capture that knowhow was slow: interview people, write a manual, hope the business didn't change before anyone used it.
LLMs are very good at the bit that was always the bottleneck: interviewing a person until you have the rule out of them, then writing it down properly.
WHERE IT LIVES NOW
- In your head
- In three veterans' heads
- In a Word doc from 2019
- In a 47-tab pricing spreadsheet
- Walks out the door at retirement
WHERE IT BELONGS
- Named rules in one place
- Software your team runs through
- Context your AI can read
- Training material for new hires
- A clear artefact for diligence
The risk when one person holds the knowledge
In an established business, important decisions often depend on a small number of estimators, account directors, technical specialists or managers who have learned the exceptions over years.
When one of them retires, sells their interest or takes the wrong holiday, the rules they used leave with them. A buyer, auditor or new employee needs evidence that is better than "ask Dave".
The oil and gas industry has a phrase for experienced people ageing out at once: the "great crew change". The same risk is easy to recognise in British engineering firms, accountants, surveyors and family businesses.
SCENARIO ONE
Your best estimator quotes a job in twenty minutes and wins it. The new estimator takes two days and prices it wrong. Nobody can explain the gap.
SCENARIO TWO
You bought an AI assistant. It cheerfully gets things wrong, because it doesn't know what your business considers a good answer. There's nowhere to point it.
SCENARIO THREE
You're planning to sell. The buyer's diligence team asks how decisions get made. The honest answer is "ask Dave". Dave is 64.
SCENARIO FOUR
You've written process docs three times. They're already out of date. Nobody opens them. The actual rules live in Slack threads and a few people's instincts.
SCENARIO FIVE
You're scaling. Hire ten people, quality drops. The ten don't know what the original four knew, and the original four don't have time to teach them.
Why this is now practical
LLMs help with the interview.
Edward Feigenbaum, the Stanford computer scientist behind early expert systems, called knowledge acquisition "the critical bottleneck problem in Artificial Intelligence" in 1982. It needed a human knowledge engineer, and the expert you were interviewing usually couldn't explain what they did anyway.
An LLM is useful in the room because it tracks the cases, spots the "it depends" answers, and keeps asking until you've named what it depends on. Your expert and our knowledge engineer still approve the rule.
Bespoke software is cheaper to start.
McKinsey's 2023 software engineering study found generative AI cut task completion time by 45 to 50% for code documentation, 35 to 45% for code generation, and 20 to 30% for refactoring. The GitHub Copilot trial reported developers finishing one JavaScript task 55.8% faster than the control group.
Modern development makes a focused internal tool more affordable. The hard work is deciding which rules are stable, which exceptions need judgement and who owns the result.
The decisions worth encoding
Different industries, same buckets every time. Pick the one that costs you most when it's wrong. That's the one we encode first.
Qualifying
Who's a good fit, who isn't, what to ask on the first call, when to walk away. The reason your best salesperson closes and the new one doesn't.
Pricing & estimating
Square-metre rates, risk uplifts, sequencing assumptions, "this one's awkward" gut-feels. The rules that live in the senior estimator's head.
Risk & scoring
Underwriting heuristics, credit calls, supplier scoring, recruitment fit. The "I wouldn't touch that one" instinct, named and weighted.
Triage & routing
What goes to whom, what's urgent, what's been seen before. NHS Pathways uses a clinical decision support system for 111 and 999 triage. Your support queue has the same kind of routing problem, without the medical stakes.
Sequencing & playbooks
What you do, in what order, when X happens. Onboarding, escalation, month-end, the choreography of the business when nobody's watching.
What the leadership team gets
Four steps. Recruitment, engineering, financial advice, manufacturing. Different domain, same arc every time.
The first phase captures one decision area with the people who know it, tests the rules against real cases and defines how the software will be maintained. You own the documented knowledge and the software we build.
BOOK AN ADVISORY CALLPick the bucket
A working session with the process owner and experienced staff identifies the decision area worth capturing first, such as pricing, qualification or a recurring exception that still needs a senior expert.
Elicit it properly
A short series of sessions with the people who know. We bring an LLM into the room as a structured interviewer and a human knowledge engineer to push back. You leave with the rules written down for the first time. Nonaka called the move from tacit to explicit knowledge externalisation.
Build it into software
A working tool your team uses. A quoting app, a scoring screen, a triage queue, an onboarding flow. The rules are the source of truth. The software is just what runs them. The AI in your stack gets the same rules as context, so it has something concrete to read.
Keep it alive
Rules drift. Every override your team enters becomes a candidate change. We give you a light review rhythm so the knowledge stays current instead of going stale the way the 2019 process doc did. Add the next bucket when you're ready.
Examples of encoded expert judgement
Expert systems were doing useful commercial work in the 1980s. The lesson worth keeping is maintenance, ownership and trust.
XCON configured VAX orders.
Carnegie Mellon and DEC encoded configuration knowhow into about 2,500 rules. By 1986 it had processed 80,000 orders at 95 to 98% accuracy. DEC estimated $25m a year saved. The maintenance lesson is the bit that matters now.
NHS Pathways triages 111.
NHS Pathways is a clinical decision support system for remote assessment in NHS 111, 999 and urgent care. Its clinical authoring team are registered practitioners. Same pattern as your triage queue: questions, routing and review.
Underwriting starts with judgement.
Before you have a prediction model, you still have criteria, thresholds and exceptions. Those rules are worth writing down before the business pretends a spreadsheet is governance.
Sources: Polanyi (1966), Autor (2014), Nonaka & Takeuchi (1995), McDermott on XCON (CMU), NHS England Digital, DBT Business Population Estimates 2024, GitHub Copilot productivity research, McKinsey on developer productivity (2023).
We have spent years turning business rules into software
Alex co-founded and built AccountancyManager before its sale to Hg-backed Bright. Current Vu systems encode recruitment, compliance, financial-advice and workshop decisions that previously sat with experienced staff.
When this is worth discussing
We work best when there is a real operating problem, enough volume to measure and people from the affected teams who can make decisions.
Usually a good fit
- An established UK business, usually with annual revenue above £10m
- A repeated process with a known cost, delay, error rate or capacity problem
- A senior sponsor and a day-to-day owner who understand the work
- Access to the relevant staff, systems, sample records and security requirements
We may point you elsewhere
- A standard product already covers the process well
- The requirement is a one-off small build with no wider operating case
- There is no owner or access to the people and data needed to test the result
- The plan relies on AI making high-impact decisions with nobody responsible for review
Questions before committing
Isn't this just process documentation with extra steps?
No, because the output is software your team has to run through, not a PDF on a shared drive nobody opens. The rules get used because the work goes through them. That's the difference between knowledge that's written down and knowledge that's applied.
My experts can't explain what they do. They just "know".
That's Polanyi's paradox, and it's the normal starting point. We don't ask "what's the rule?". We walk through real cases. The expert reacts, we ask what changed their mind, and we keep going until the rule survives counterexamples.
Will the AI just hallucinate our rules?
The LLM doesn't write your rules. It interviews, paraphrases, and structures. Your expert and our knowledge engineer approve every rule before it goes in. The software then runs them deterministically, the same way every time, so you can audit any decision later.
What happens when the business changes?
One old expert-system failure mode was rule maintenance. We set up a short monthly review where overrides your team has entered get triaged into rule changes. The knowledge stays current because changing it is cheap and the people closest to the work do it.
My senior people will think this is about replacing them.
In practice it does the opposite. They stop being the bottleneck on every small decision and get their time back for the genuinely hard cases the software flags up to them. The good ones quite enjoy seeing their knowhow written down properly. The ones who don't, you needed to know about anyway.
How is this different from your spreadsheet replacement service?
Spreadsheet work starts from something that exists. This starts from something that doesn't, because it's in heads. The two often end up adjacent: we encode the rules, then the next project is the system the rules run inside. Sometimes that's a sheet replacement, sometimes it's a new tool.
Who owns the rules and the code?
You do. The rule documents, the code, the data. Hand-over to your team or your next agency is part of the deal. No lock-in. If it ever needs to read as an asset in a sale, it's structured so it does.
How much, how long?
We scope knowledge capture separately from the first software phase. Timing depends on access to experienced staff, the number of decision branches and how much evidence is needed to test the rules.
Talk to us about the decisions in people's heads
Choose the area most dependent on one or two experienced people. We will identify which decisions can be documented, which need judgement and what a useful first system would cover.