Menu

01

System architecture


The structural decisions that are expensive to revisit — made early, written down, and justified.

Most system failures are not implementation failures. They are architectural decisions taken implicitly, under time pressure, by whoever happened to be writing that component, and discovered years later when the cost of reversing them has compounded.

We establish those decisions deliberately: the boundaries between subsystems, where state lives, what the system guarantees under failure, and which properties are permitted to degrade when it is under load. Each is recorded with the reasoning and the alternatives that were considered, so that a future team can revisit the decision on its merits rather than reconstruct it from the code.

Where hardware is part of the system, it is part of the architecture. The boundary between what runs in silicon, at the edge, and in a data centre is a design decision with the same standing as any other.

Typical deliverables

  • Architecture assessment of an existing estate
  • Target architecture and staged transition path
  • Decision records with alternatives and trade-offs
  • Interface and failure-mode specifications

02

Engineering delivery


Working systems, built by a small senior team, handed over to yours in a state it can maintain.

We build. An advisory practice that stops at the document produces recommendations that have never been tested against contact with a real system, and our experience is that the difficult questions surface during implementation rather than before it.

Engagements are staffed with small senior teams working alongside the client’s own engineers. This is slower to start and considerably faster to finish than the alternative, and it means the capability remains in the organisation when we leave.

The domains we work in do not tolerate approximate results: sub-millisecond capital markets infrastructure, industrial control, instrumentation, and quantitative systems where a defect is a financial or physical event rather than a support ticket.

Typical deliverables

  • Implementation of critical-path systems and components
  • Performance and latency engineering against stated budgets
  • Instrumentation, observability and operational tooling
  • Handover with documentation, tests and runbooks

03

Assurance and evidence


Demonstrating that a system does what is claimed, to a standard a third party can check.

In regulated and safety-critical settings it is not sufficient for a system to be correct. Its correctness has to be demonstrable to a regulator, an auditor, an investment committee or a counterparty who was not present when the work was done.

We treat that evidence as an engineering artefact with the same standing as the system itself: test strategies that address the failure modes that matter rather than the ones that are convenient to test, measurement that is traceable to its source, and models whose fitted and mechanistic parts are clearly distinguished.

This is also the discipline that makes a claim about performance meaningful. A benchmark without a stated method is a marketing number, and we do not produce them.

Typical deliverables

  • Verification and validation strategy
  • Traceable measurement and audit trails
  • Independent technical due diligence
  • Model risk documentation and review

04

Commercial structures


The corporate and financial form around a system, designed alongside the system itself.

A technical asset that cannot be financed, owned or transferred cleanly is worth less than it should be. The structure around it — the vehicle that holds it, the terms on which capital enters, the way risk is apportioned — is a design problem, and it is usually addressed after the technical decisions have already foreclosed the good options.

We work on both at once. Special purpose vehicles, off-balance-sheet arrangements, protected cell companies and securitised instruments are familiar territory, and we have designed the risk basis on which such instruments are underwritten.

We work with our clients’ own counsel and auditors. We do not provide legal, tax or regulated financial advice, and we say so early rather than at the point it becomes a problem.

Typical deliverables

  • Structuring options with risk and control implications
  • Risk-scoring bases for financed assets
  • Techno-economic and feasibility assessment
  • Investment committee documentation

Which of these is the question you have?

Most enquiries do not arrive neatly sorted into one of the four, and they do not need to. Describe the situation and we will tell you plainly whether it is work we are suited to.