Watch what actually happens when someone picks up a piece of work in your company. Before they can do anything, they go hunting. They open the CRM for the account, the billing system for the balance, a mail thread from two quarters ago for what was agreed, a spreadsheet on somebody's drive for the current figures, and then they ask a colleague the one question none of those systems answers: does this one get the exception?
That hunt is the real cost, and it is invisible in every process document. The work does not carry its own context. Everything needed to act on it lives somewhere else, and what connects it is a person's memory. That is why software so often disappoints here. A tool that automates the steps while leaving the hunt in place has automated the cheap half of the job. And a colleague who cannot find the context asks. Software does not ask. It produces a confident answer built on whatever it could reach, and you find out downstream.
The most literal version of this problem we have shipped against is HL7 messaging. On the cloud ECG backend built for HeartSciences, the same clinical result — same standard, same message type — has to be constructed differently for every hospital that receives it, because the specification refuses to decide. An analysis of HL7 v2 optionality (JAMIA, 2009) counted 4,132 data elements in the standard result message with 85% of them designated optional. Which subset a given hospital accepts is not written in the standard. It lives in that hospital's interface configuration and in the head of the analyst who maintains it, and the only way an automated system learns it is by being told, field by field.
Two Halves Of Context
The first half is digital: data and the decisions that exist somewhere inside a system but are not reachable in a form the work can use. The second half is unwritten: knowledge that never entered a system at all, because the people doing the work carry it as patterns, exceptions, and inherited judgment. A system that solves only one of the two halves produces confident output that is wrong in ways that the business notices late.
The digital half is fragmented and gated. Permission models built around job titles do not decompose into the capabilities a workflow actually needs, and the same customer is CUST-00417 in billing, acme-corp in support, and Acme Corporation, Inc. in the CRM. No prompt bridges that gap. Something has to build the layer that does.
The unwritten half lives in people's heads: why a particular customer gets a manual review even though the account looks routine, or when a credit is worth more than the policy says. Asking people to write down what they know produces the sanitized procedure, not the exceptions, and the exceptions are the whole value. On the HL7 layer, the site-specific knowledge deciding whether a message is accepted was not written down by asking anyone. It came from instrumenting the rejections, reading the field-level error locations the receiver returns, and turning each into a per-organization configuration value.
This work does not look impressive. It looks like data integration, permission redesign, and structured interviews with experienced staff — none of which produces a good demo. On the ECG platform, the context layer is what makes onboarding a new organization a configuration task rather than an engineering project: a new hospital is defined by its HL7 field mappings, its enabled models, its invoice pricing, and its storage provisioning.
A company that fixes the hunt once gets everything it builds afterwards for less. A company that buys more capacity instead keeps funding pilots that never reach the work that matters.
What This Means For The Proposal On Your Desk
A proposal that spends its pages on which model was chosen, how it has been tuned, and how it scores against the published tests is describing the part that gets bought rather than built. The part that decides whether the thing works inside your company usually gets one line: connecting it to your existing systems. Three questions separate a proposal that has done that work from one that has not, and all three have answers you can check.
What does it take to reach each record this needs? Name the systems out loud — the one holding the customer, the one holding the invoice, the file somebody maintains on their own machine. For each one, ask how the software reads it: through an interface the vendor has used before, through an export a person runs by hand, or off a screen a person reads. The last two are not connections. They are new work, and they belong in the price.
Who grants that access, and by when? This is rarely a technical question and it is often the longest item on the schedule. Ask for the name and the date, not the assurance.
What happens when one of those systems changes underneath? A vendor will change a field. Ask what breaks, how you find out, and who fixes it. Where there is no answer, the answer is that you find out from the person whose report stopped arriving.
A vendor who answers all three may still be too expensive. A vendor who cannot answer them has priced the easy half, and will discover the other half on your budget.
First Steps
- Map every system the workflow reads or writes, and write down each access boundary: who can do what today, and what a system would need to complete the work.
- Pick one workflow; sit with the two or three who handle it best. Capture the reasoning behind exceptions — when and why they deviate from the documented process.
- Write the context down before building: the sources of truth, the access needed, the unwritten rules, and the cases the system should escalate rather than handle.
Make Context Part Of The Product
Treat the context layer as work with an owner, a plan, and a definition of done. Everything shipped later inherits it, so the cost is paid once, not forever. If the sources of truth are not named and nobody owns the layer, the model is not the blocker and no model will be.
A fifteen-minute call turns one of your own workflows into a plan — what it would take, what it would cost, and a clear yes or a no — and the build that follows is agreed before the work starts, with the code and the intellectual property transferring to you as it gets paid for.
References
- Sujansky WV, Overhage JM, Chang S, Frohlich J, Faus SA. The Development of a Highly Constrained Health Level 7 Implementation Guide to Facilitate Electronic Laboratory Reporting to Ambulatory Electronic Health Record Systems. Journal of the American Medical Informatics Association, 2009.
