About

Some problems arrive before the field built to solve them.

Established disciplines are extraordinarily good at answering established questions. The harder problems often appear between them.

01 The approach

Each part can be right while the whole is wrong.

Established disciplines are built to answer established questions, and they do it well.

The difficulty arrives when a question does not belong cleanly to any of them.

Assessment Finding Status
Engineering Performs as specified Correct
A dependency nobody owned
Security Controls in place Correct
An assumption nobody restated
Legal Compliant as written Correct
A control that never produced evidence
Operations Within tolerance Correct
The combined system Wrong
The failure modes that matter tend to live in the space between them.

Sometimes the first task is not finding the answer. It is understanding the problem.

Several people can look at the same situation and each describe something different; often none of them is wrong, and none of them is looking at the whole of it.

02 The name

The two halves of the name are the method.

We work from the problem outward.

Applied
Because we care what can actually be built, secured, operated, and demonstrated.
Horizons
Because the consequences worth planning for are usually the ones not yet fully in view.

First-hand

High-consequence environments are a useful corrective.

Much of this perspective is first-hand rather than observed from outside, and it spans fields that rarely share a room.

Worked in

Trained and certified in

An emergency department and a contested network have one thing in common: the distance between how a system performs and how it behaves is impossible to ignore.

Applied Horizons works on problems that do not yet have a playbook.

03 How we work

The habits we hold to.

  1. The question before the answer

    A well-framed problem is usually most of the work. We would rather spend the first part of an engagement establishing what is actually being asked than answer the wrong question efficiently.

  2. Whole systems

    A technical question is followed through to its operational, security, governance, and institutional consequences rather than handed across at each boundary.

  3. Second order first

    The immediate effect is usually well understood by the time we are asked. The value is in what the capability makes load-bearing, and what that makes fragile.

  4. Evidence over assertion

    A control that produces no artefact is a preference. We are interested in what an organisation could actually demonstrate, to a regulator or to itself.

  5. Tested where possible

    Where a question can be settled by building something small, we would rather build it than argue about it.

  6. Written plainly

    Analysis that cannot be read by both the engineering team and the board has failed at the boundary it was meant to cross.

04 What we are not

A boutique practice, and plain about it.

  • Not a research laboratory.
  • Not a law firm.
  • Not a healthcare provider.
  • Not a large organisation.
  • Not a government contractor.

We examine health technology, regulation, and governance as a research practice. That is not the same as practising in either field: we do not provide clinical care or medical advice, and we do not provide legal advice or representation.

We do not publish client names, invented case studies, or metrics that cannot be substantiated. Anything we publish will say plainly whether it has been built, tested, or only designed. Where we have not done the work, we say so.

This is a deliberate constraint. The credibility of the practice rests on the quality of the thinking and the accuracy of the claims — which means the claims have to stay accurate as the practice grows.

We keep looking after the obvious answer appears.

If that is roughly how you already think about your own problems, we should probably talk.

Start a conversation