Philosophy
What we believe about working with automated systems — and why it shapes everything we do
The way an engagement is structured reflects a set of beliefs about what actually helps organisations. These are those beliefs, stated plainly.
Back to homeFoundation
What drives the way this work is done
For management
The approach here comes from a straightforward observation: most problems with AI systems in organisations are not technical in origin. They are documentation problems, process problems, and communication problems that happen to involve technical systems.
That observation shapes the scope of each engagement. Technical expertise is applied to problems where it makes a difference. The output is written in a way that does not require technical expertise to use.
For technical staff
The foundational position is that undocumented systems are systems waiting to fail in ways no one predicted. Data dictionaries, monitoring thresholds, and governance policies are not overhead — they are the mechanism by which systems remain reliable after the people who built them move on.
The engagement format reflects this. Every output is designed to be read, maintained, and updated by whoever inherits the work.
Vision
What well-integrated AI looks like in an organisation
This is not a vision of automation replacing human judgement. It is a vision of systems that are documented well enough to be questioned, monitored clearly enough to be caught when they drift, and governed transparently enough that staff know what they are and are not permitted to do with them.
Documented
Every system in use should have a record of what data it depends on, what it was originally accurate to, and who is responsible for checking that it still is.
Monitored
Accuracy changes over time. The infrastructure for catching those changes — dashboards, thresholds, review routines — should exist before problems surface, not after.
Governed
Staff should know what tools are approved for which uses, what information may not be submitted to external services, and who makes decisions when a situation is not covered by existing rules.
Core beliefs
What we believe, and why
Belief 01
Documentation
The output of an engagement should outlast the engagement
An engagement that produces only advice or recommendations transfers the hardest work back to your team. A written output — a dictionary, a dashboard specification, a policy — does the opposite. It captures the decisions made and makes them available to anyone who needs them later.
This belief is why every engagement here has a concrete written deliverable. It is not supplementary to the work — it is the point of the work.
Belief 02
Scope
Narrow scope produces more useful output than broad scope
Broad engagements tend to produce broad outputs. When the scope is everything, the deliverable tends to be a general assessment that stops short of the specific decisions that need to be made. Narrow scope forces specificity.
A data dictionary for a specific set of tables, a monitoring threshold for a specific model, a policy covering a specific set of tools — these are actionable in a way that a general framework is not.
Belief 03
Knowledge
Decisions made during an engagement should be understood by your team
When threshold values, cleaning decisions, or policy provisions are made without explanation, your team cannot evaluate them, update them when circumstances change, or push back when something seems wrong.
Work is done with staff present and decisions are explained as they are made. This is slower than working independently, but it produces a team that can maintain the output rather than one that depends on re-engagement.
Belief 04
Measurement
What is measured before and after an engagement should be stated in advance
An engagement that does not define what success looks like cannot be evaluated after the fact. Stating the measurement criteria before work begins creates accountability in both directions — for the work done and for the organisation receiving it.
The measurement panel for each engagement is agreed during scoping, not constructed retrospectively to show a positive result.
Principles in practice
How these beliefs translate into how engagements run
For management
Scope is written before work begins
You receive a written scope document before any engagement starts. It covers what the engagement addresses, what it does not address, and what the deliverable looks like. Changes to scope are discussed and written down before work continues.
Price is stated, not estimated
Each engagement has a stated price. There are no hourly rates, no budget estimates that expand as the project develops, and no retainer required to maintain what was produced.
Deliverable is reviewed together at close
The written output is reviewed with your team at the end of the engagement. Questions are addressed before handover. The expectation is that your team can use and maintain the output independently after that review.
For technical staff
Work is done with your team present
Cleaning logic, threshold values, and policy provisions are decided in sessions where your staff are present and can ask questions. The decisions are recorded in the output, not held in the head of whoever did the work.
Outputs are in open, maintainable formats
Data dictionaries are delivered as structured documents your team can update. Dashboard specifications are written in terms your monitoring infrastructure can implement. Policy documents are written for your team size, not for a generic audience.
Measurement criteria are agreed before work starts
The engagement begins by establishing what is currently true — duplicate rates, accuracy figures, systems in use without policy coverage. These form the baseline against which the deliverable is evaluated at close.
People first
Automated systems are operated by people and should be understood by them
The reason documentation matters is not procedural compliance — it is that the people who operate, rely on, or are affected by a system deserve to understand how it works and what its limits are. That includes the staff who use it daily, the managers who are responsible for it, and the clients whose data it processes.
When a system produces an output that affects a decision, the person making that decision should be able to ask meaningful questions about how the system arrived at it. Documentation is what makes that possible.
This shapes how engagement outputs are written. A data dictionary written only for specialists is only useful to specialists. A governance policy written only for legal review may never be read by the staff it governs.
Outputs from these engagements are written for the people who will actually use them — which may be the data team, the operations manager, or the new staff member who starts six months after the engagement closes.
Deliberate approach
How the engagement format has been shaped over time
For management
The five-to-seven week format came from observation, not theory. Longer engagements tend to lose focus as priorities shift. Shorter ones do not have enough time to reach the implementation decisions that make the work useful. The current format is the result of adjusting scope and timeline against what actually produced usable outputs.
The same applies to the written output requirement. Engagements that ended in verbal handover produced work that could not be maintained. Written output, reviewed together, consistently produced better results for the organisation afterward.
For technical staff
The format for each engagement — what is assessed at intake, what is produced, how thresholds and rules are decided — has been refined based on what proved durable in practice. Rules that were too strict to follow were revised. Documentation structures that were not maintained were replaced with ones that were.
The format is not fixed permanently. If a situation requires a different approach, that is discussed during scoping rather than forcing the engagement into a structure that does not fit.
Integrity
What honesty means in the context of this work
Scope honesty
If a situation falls outside the scope of what these engagements address, that is said at the outset — not discovered partway through. Engagements are not proposed for problems they are not suited to address.
Outcome honesty
The engagements here produce documented outputs, not results. A cleaned dataset and a set of validation rules does not guarantee that future records will be clean — it provides the tools your team needs to check. The difference matters and is stated plainly.
Process honesty
The scope document written before each engagement is the agreement. Additions are discussed, not assumed. If the work reveals that the original scope was wrong about something, that is said rather than quietly addressed within the same engagement.
Working together
Why engagements involve your team throughout
The alternative to working with your team is working for your team — producing an output and handing it over. That approach is faster in the short term and produces outputs that are harder to use, harder to maintain, and harder to question.
Involving your team in the work means the decisions made during an engagement are understood by the people who will live with them. That understanding is not a side benefit — it is what allows the output to be maintained rather than superseded by the next engagement.
This does not mean every session requires all staff to be present for all of it. It means the right people are involved at the right stages — the people who know the data for the data dictionary sessions, the people who will own the monitoring routine for the threshold discussions, the people who will enforce the policy for the governance work.
The engagement is structured around their availability, not around an abstract schedule.
Long-term thinking
What usefulness looks like twelve months after an engagement closes
For management
The test of an engagement is not how it feels at close — it is whether the output is still in use and still accurate twelve months later. A governance policy that was filed and forgotten is not a governance policy in practice.
The register template produced in a governance engagement is designed for ongoing use, not for a one-time audit. The monitoring routine produced in a monitoring engagement assigns named responsibility precisely because anonymous responsibility tends not to be exercised.
For technical staff
Validation rules from a data preparation engagement are written in a format that can be applied to new records without re-engagement. Dashboard thresholds from a monitoring engagement are explained well enough that they can be adjusted as the model's operating environment changes.
The goal is not to create dependency on these engagements for maintenance. It is to produce outputs that your team can maintain without them.
What this means for you
How these values translate to what you can expect
The scope is agreed before money changes hands
You will know what the engagement covers, what it costs, and what it will produce before any work begins. There are no surprises in the invoice and no scope that grows without discussion.
The output is explained, not just delivered
At close, the deliverable is reviewed together. If there are sections your team does not understand or does not agree with, that is addressed before the engagement ends.
The engagement ends when the work is done
There is no ongoing billing requirement to keep the output useful. If you have questions six months after close, those are addressed — but there is no retainer structure designed to maintain that connection.
If it is not the right fit, that is said at the start
If your situation calls for a different kind of engagement — broader, more technical, or in an area these engagements do not cover — that is the conversation we have before any work is proposed.
Your team's knowledge of the output is part of the deliverable
An output your team does not understand is not a complete output. The engagement is not done until the people who will use and maintain the deliverable understand the decisions it contains.
Results are bounded and stated plainly
The engagement produces specific, documented outputs against a specific, documented problem. The outputs are what they are. They are not presented as broader solutions to problems the engagement did not address.
Get in touch
If these values fit how you want to work, a conversation is a reasonable starting point
The initial conversation covers your situation, which engagement fits, and what the scope would look like. No commitment required before that discussion is complete.
Get in touch