How we work
We document as though an auditor is coming. Usually nobody is. That is rather the point.
What we are not
We are not a validation consultancy. Computer system validation is its own profession, and if you need a specialist to own your qualification programme, we will tell you so and stay out of the way.
What we bring is different, and harder to buy: we came up in environments where nothing counted unless it was written down, and we have not stopped working that way. When we build something for your business, the documentation exists whether or not a regulation demands it.
Most AI work in this market produces a result and no record of how it was reached. We produce both.
Where the habit comes from
Ten years as a Documentum migration specialist — pharmaceutical, healthcare and regulated enterprise clients, GE Healthcare and Novartis among them.
Migration is a particular discipline. You are moving records out of one system and into another, and afterwards you must prove that nothing was lost, altered or silently dropped. Nobody accepts “it looked fine”. Every installation qualified, step by step, with screenshots. Every test recorded against what was expected. Every anomaly written down — including the ones that turned out to be nothing, because a closed anomaly is evidence and an unrecorded one is a gap.
That was ten years of being unable to say “trust me”. It changes how you build things permanently.
What that means for your AI work
AI has a specific problem that ordinary software does not: the same input can produce a different output tomorrow, and nothing announces that it changed. A system that worked in March can quietly stop working in June because a provider updated a model. Without a record, you will not know which of those it was.
So we keep one. As standard, whether or not anyone asked:
- A written specification — what the system is supposed to do, and how you would know it did
- An installation and configuration record — what was built, as built, with screenshots
- A test record — what we ran, what we expected, what actually happened
- An anomaly log — what went wrong, what we did about it, what remains open
- A change record — model version, prompt, parameters, tools and data sources, and the date each one changed
- A handover pack — enough for your own people, or your own auditors, to follow without us
None of this is exotic. It is simply unusual in this market.
The record is not paperwork. It is what the harness produces.
Documentation written afterwards, by hand, describing what someone remembers doing, is the kind that rots. We would rather the system produce its own evidence as it runs.
A probabilistic tool will do probabilistic things — that is what it is for. So we wrap it in a harness that knows what a valid output looks like and refuses to pass anything that does not qualify. The model stays probabilistic; the boundary does not.
The useful consequence is that the harness and the record are the same activity. Every check the harness performs is a test with a recorded result. Every refusal is a logged anomaly with a timestamp and a cause. Every run captures the model version and configuration that produced it, because the harness needed those to do its job in the first place.
Evidence generated by the system in the course of working is worth more than evidence assembled about it afterwards.
That is the whole approach, and it is why the documentation costs you very little: it is a by-product of building the thing properly rather than a separate exercise bolted on at the end.
The changes that quietly invalidate what you tested
If any of these change, what you proved last quarter no longer describes the system you are running. This is the list we keep, and hand to you.
| Change | Why it matters |
|---|---|
| Model version | Provider-side updates alter behaviour without notice. Pin the version; treat a bump as a change. |
| System prompt | The prompt is specification, not configuration. Editing it edits the requirement. |
| Sampling parameters | Temperature, top-p and seed determine reproducibility. Change them and your earlier evidence no longer applies. |
| Tool set or tool schema | Adding a capability adds a failure mode and widens what the system is being trusted to do. |
| Source documents | New, removed or re-indexed content changes what the system can and will assert. |
| Embedding model or chunking | Changes what context reaches the model, even when the underlying documents are identical. |
| Guardrails or output checks | Determines what reaches the user — and what is being suppressed without anyone seeing it. |
A business that cannot say which of these changed last month is not in control of the system, whatever its accuracy looks like on the day.
If you do work under a regulator
Some of our clients answer to NAFDAC. Some are Nigerian arms of multinationals working to a parent company’s global procedures. Some run trials for overseas sponsors and inherit those sponsors’ requirements by contract.
In those settings the documentation above is the starting point rather than the finish. We are comfortable working alongside your quality function, producing evidence in the format they require, and being told our output is not yet sufficient. We have sat on the receiving end of that conversation for a decade.
Where a sponsor or parent company works to 21 CFR Part 11 — electronic records and electronic signatures — there is one point worth raising early, because it is routinely missed:
An AI system that calls an external model API is an open system, not a closed one. The record passes through infrastructure you do not control, and the controls signed off for your on-premise systems were not written with that in mind.
We raise it. Your validation people decide what follows. That division of labour is deliberate.
Engagements
| Who it is for | Price | |
|---|---|---|
| AI Opportunity Assessment | Businesses with no AI deployed, or tools bought and unused | ₦200,000 — credited against the build |
| Standard review | Operations already running AI, with no record of how it was built | ₦2,500,000 |
| Regulated environments | Operations working to a regulator, a parent company or a sponsor’s requirements | ₦4,000,000 – ₦6,000,000 |
Start a conversation — WhatsApp +234 800 000 0000
PLACEHOLDER contact details — replace before launch.