Approach
How we build, and what we refuse to do
These are not values on a wall. Each one is a decision already made in a live system, usually after paying for the alternative.
Principles
Eight working rules
Every rule below can be pointed at in code or in a table. That is the test we apply before writing one down.
AI reads, people write
Intelligence extracts, matches, researches and drafts. A person makes every write to a system of record and every payment decision.
In practice. On the payables build there are exactly two gates. Gate one, a named reviewer verifies the extraction and pushes with one click, and nothing reaches the ERP before that click. Gate two, finance approves the payment. Neither gate has an automatic mode.
Nothing writes to a record directly
Applications hold no insert, update or delete rights. Writes pass named operation functions behind an approval gateway with a second person rule and a role floor per target.
In practice. On the platform, the application role holds zero write grants on any table. Operation functions are the only path in, and a standing assertion that looks for direct write holes returns zero rows on every run rather than at audit time.
Ledgers are append only
Audit and accounting ledgers refuse update and delete. Corrections are opposing entries, and balances are derived at read time because a stored quantity drifts while a summed history cannot.
In practice. The audit ledger is SHA-256 hash chained, so a silently altered row breaks the chain. Correcting a shipped quantity posts an opposing entry that carries its own reason, which means the wrong number and the correction are both still visible three years later.
Rules live in data, not in code
Permitted state transitions, tolerances and guards are rows. A policy change becomes a configuration change instead of a release, and the rule that stopped a transaction can be shown to an auditor.
In practice. Tightening a supplier tolerance from five per cent to two is a single row update that takes effect on the next invoice. No deployment, no regression cycle, and the change itself is in the audit trail with who made it.
A refusal names the next correct action
Blocking is not enough. Blocks that cannot be overridden are distinguished from warnings that can, with the stated reason carried into the ledger.
In practice. The system does not say "invalid quantity". It says the quantity cannot be reduced to ten because one hundred and eighty units have already shipped, and that a return is the correct instrument. The user acts instead of raising a ticket.
Governance is in the first drawing
Zero data retention, no training on client data, a sandboxed build environment and a per transaction audit trail are designed in, not conceded later.
In practice. On the payables programme all four were in the architecture before the first slide reached the client. The compliance conversation then had nothing left to negotiate, which is why the security review added no new conditions to the design.
Systems are proved by running them
We plan for the defects a running system will surface, because reading code does not find them.
In practice. Twenty defects reached a running platform. Eight came from exercising an operation end to end, three from adversarial security testing, two from load testing at twelve thousand orders, two from pre-deploy inspection, one from the platform linter, and four from scanning for a pattern after finding it once. None came from reading the code.
We publish what is not built
Every handover carries an open list: what works, what works only in the database, what has no screen yet, and what is deliberately out of scope.
In practice. The platform handover names consolidated invoicing, bank statement import, supplier statement reconciliation and Excel export as not built, and customer hierarchy and vendor de-duplication as working at the database level with no screen. A client who learns the gaps from us keeps trusting the parts we called finished.
Delivery
How an engagement runs
Six stages. The third is the one most vendors would rather skip. We do not, because a sandbox that fails is far cheaper than a rollout that does.
Discovery
We walk the process as it is actually performed, count the volume and the variance, and find the control points. We also find the work that should be removed rather than automated.
Design and business case
Reference architecture with the human gates named, governance design, and a cost model built from your own cost base. If the numbers do not support the build, we say so at this stage.
Sandbox proof of concept
A narrow slice, running on real documents in an isolated environment, with success criteria agreed before it starts. This is where an idea earns the rest of the budget.
Build
Data model first, then operations, then interface. Short cycles with something demonstrable at the end of each. Security and audit are built alongside, never afterwards.
Controlled rollout
One process, one team, one region at a time, with the old path still available. Adversarial and load testing before volume, not after the first bad week.
Run and improve
Either your team runs it with our support, or we run the process under a service level. Either way the exception rate and the cost per transaction are reported openly.
Protecting what is yours
Your data, your system, your intellectual property
We describe capability at the level a client needs to make a decision, and we do not carry one client's implementation detail into another's conversation. The same discipline that protects the last client protects you.
- Client data is never used to train or fine tune a model
- Model endpoints are configured for zero retention
- Systems are built inside your cloud and policy where you require it
- Code and documentation are handed over, so the asset is yours
- Case studies are published anonymously unless you ask otherwise
Second person rule on privileged changes
Append only, hash chained audit of machine and human actions
Role based access enforced at the data layer, not the screen
Reason codes on every exception and every override
Environments separated, with production data out of test
No autonomous write to a system of record. By design, in every build.
Ask us the awkward question.
What happens when the model is wrong, who is accountable, and how would an auditor see it. We would rather answer that in the first meeting than the third.