Philosophy · How we think about this work
We think AI should be understood before it is trusted.
The principles behind how we scope, build and hand over AI systems — and why we hold to them even when a faster path is available.
← Back to HomeFoundation
What drives the way we work.
AI is not inherently useful. It is a set of techniques that may or may not apply to a given situation. Whether it applies depends on the specifics of the work — the type of data, the volume, the range of variation, the consequences of an error. Knowing that requires looking at the work, not at the technology.
We started from a dissatisfaction with how AI is typically sold into organisations: as a general-purpose solution before anyone has looked at whether it fits. The work we do begins one step earlier — with the assessment of fit — and that starting point shapes everything that follows.
Vision
What we believe is possible — and what is not.
What we think AI can do well
AI handles repetitive, high-volume tasks where the pattern is stable and the consequence of individual errors is manageable. It reads structured data from documents at scale, surfaces existing information that would take staff time to locate, and identifies which incoming enquiries match a defined answer.
These are real capabilities. They take time to configure for a specific context, and they require measurement to verify — but they are available to organisations that are willing to do the configuration properly.
What we think AI cannot replace
Judgement on cases the system has not seen. Handling of genuinely novel situations. Decisions that carry significant consequences and require accountability. Work that depends on relationship, empathy or contextual understanding built over time.
These remain human work. We build systems that know the boundary and route to a person when they reach it — rather than attempting to cross it and failing quietly.
Core beliefs
Five things we hold to consistently.
Measurement is not optional
If you cannot measure whether the system is performing correctly, you do not know whether it is. Every engagement we take on includes a defined measurement approach, applied to your data, before deployment decisions are made. Accuracy figures that include failure categories are more useful than accuracy figures that average them away.
The person doing the work knows things the spec does not
Process documentation describes how work is supposed to happen. The person handling it every day knows what actually happens — the exceptions, the informal fixes, the cases that fall outside the written procedure. We spend time with those people during scoping, because what they know is not in the written specification.
A recommendation to not proceed is a legitimate outcome
If scoping shows that automation would not improve on manual handling — because the volume is too low, the document variety too wide, or the exception rate too high — we say so. That conclusion is a useful one. It means the organisation does not spend on something that would not help. We treat it as part of the service, not as a failure.
Dependency is a cost worth making explicit
Every AI implementation creates some form of dependency — on a vendor, on a model, on the people who built it. We try to make that dependency explicit and, where possible, smaller. Documentation written for internal maintenance, training delivered to the people who will use the system, and design choices that reduce proprietary lock-in are all expressions of this belief.
Speed is not the only measure of a good implementation
A system that is deployed quickly and produces errors quietly is slower to correct than one that takes longer to scope and is understood by the team from the start. We favour the approach that produces fewer corrections over the full project lifetime, even when that approach takes longer at the beginning.
In practice
How these beliefs show up in actual engagements.
Sampling before committing
We work with a sample of your actual documents or records to measure performance before any full deployment decision is made. The sample is representative, not curated.
Exception routing from day one
Every system includes a defined path for items the automation cannot handle with sufficient confidence. This route to human review is built in, not added when errors appear.
Reporting failure categories
Accuracy reports name the categories where the system performs poorly, not just an aggregate figure. A high average that conceals a consistent failure on a specific document type is not a good outcome.
Human-centred
What it means to design for the people in the process.
Every system we build operates alongside people. The staff who will use it, oversee it, or handle the cases it cannot process are part of the design from the start — not an afterthought at the training stage.
Staff understand what the system does
We train the people who will use the system on what it processes, where its confidence is lower, and what to expect when it routes something to them. That understanding reduces friction and catches errors earlier.
Roles change, not disappear
Automation handles volume. The people who previously spent time on that volume shift toward review, exception handling, and the work that requires judgement. That shift needs to be thought through and communicated clearly before the system goes live.
Personalisation to the actual workflow
We configure systems to your existing process structure rather than asking you to change how work flows to fit the software. Where process changes would help, we raise that — but as a separate decision, not a hidden requirement.
Internal knowledge is respected
The people doing the work know things about it that are not written down anywhere. We talk to them during scoping because that knowledge changes what we build and how we configure it.
Innovation
We follow the technology where it is genuinely useful, not where it is interesting.
AI capabilities change quickly. New models appear frequently, each with claims about what it can handle. Our approach to this is to evaluate new capabilities against the specific tasks our clients need to complete, and adopt them when that evaluation shows a real improvement — not because a capability is new.
What we evaluate
Accuracy on document types that match our clients' work. Processing speed at the volumes they handle. Data handling requirements that meet their governance constraints. Cost at the scale they operate.
What we do not evaluate on
Capability claims from the model provider. Benchmark performance on general test sets. Whether the technology is generating interest in the industry at a particular moment.
Integrity
What we commit to being open about.
Scope before build
We will not build a system before assessing whether it fits your work. If the assessment suggests it would not, we will not recommend building it anyway.
Failure categories in every report
Accuracy reports include breakdown by category. A result that looks strong in aggregate but fails consistently on a specific document type is reported as what it is.
Data handling, stated clearly
We will state explicitly where your data is processed, how long it is retained during the engagement, and what happens to it at completion. This is relevant to your own governance obligations and we treat it as a requirement, not an option.
Fixed cost agreed in advance
The price for each engagement is agreed before work begins and does not change based on hours spent. There are no change-request billings for items that fall within the agreed scope.
Collaboration
This is not work we do to you.
An AI integration that the internal team does not understand is fragile. When the person who configured it leaves, or when the organisation's work changes in ways that affect what the system handles, that gap in understanding becomes costly. We try to close that gap during the engagement, not leave it for later.
Working alongside
Scoping involves the people who handle the work. Implementation includes the people who will use the system. Training happens with the people who will maintain it.
Leaving capability behind
The goal of every engagement is a team that can operate and update the system without needing to return to us. That is a design objective, applied from the start.
Long-term
We think about what the system is like in two years, not two weeks.
Organisations change. The documents they process evolve. Staff who were trained on a system move on. The technology the system runs on changes. We design for this from the start — not as an afterthought when something breaks.
Documentation for unfamiliar staff
Written for someone who was not in the room when the system was configured. That is the test we apply to documentation before we hand it over.
Exception paths that handle the new
When something appears in the data that the system has not seen before, there is already a route for a person to handle it. That path was there from the start.
No hidden licence dependency
Where we have a choice between approaches with and without an ongoing external dependency, we favour the approach that does not require you to keep paying a third party for the system to continue working.
What to expect
What working with us looks like in practice.
The first meeting is about your process, not about AI. We want to understand what you do, at what volume, with what variation, before we discuss technology.
You will receive a scoping assessment that includes a recommendation — which may be to proceed, to proceed on a reduced scope, or not to proceed. That assessment is honest regardless of which direction it goes.
If you proceed, you will see accuracy figures that include what the system gets wrong, not just what it gets right. That information helps you set the right expectations with the people who will use it.
At the end of the engagement, you will have documentation and trained staff. The system does not require our continued involvement to operate.
Get in touch
If this way of working fits what you are looking for.
We are willing to have an initial conversation about your situation without any obligation to proceed further. That conversation helps both sides understand whether this is a good fit.
Start a conversation