Built from 30 years inside the world’s most complex engineering programmes.

Where the pattern first appeared

Ian’s career began in motorsport, at the highest levels — where a single car, or a very small fleet, changed configuration every lap. Managing that demanded one discipline above all: immutable traceability of every change, so the team always knew exactly what was on the car, and why.

In a world that changed by the lap, the data had to record every change — immutably — and the thread between them could never break.

The next step was automotive development. The fleets grew to tens of vehicles, and the volume exploded: thousands of configuration changes across development, testing and launch, each needing to be traced against every other. It was an exercise in holding traceability together while engineering at pace.

In both worlds, the vehicle log was the most important artefact on the team — the complete history of every asset, recorded and traceable from the first wheel turn to the last.

Then came defence, where programmes routinely span thirty to forty years and every engineering decision must remain traceable long after the original teams have moved on. Across numerous ITAR-controlled programmes, the same structural problem recurred: product lifecycle management systems, ERP platforms, maintenance systems and engineering tools each managed part of the picture — but none managed the reasoning that connected them.

Configuration drift became inevitable. Versions multiplied. Evidence became fragmented. The cost was measured not only in programme delays, but in safety, sustainment and operational readiness.

Three industries, three scales of fleet — one constant need, and no tool built to hold it.

The pattern repeated everywhere

What initially appeared to be a defence challenge proved to be universal.

In nuclear operations, identity traceability exposed a critical safety gap that could have allowed cumulative radiation limits to be bypassed.

In automotive engineering, evidence-based analysis identified the root cause of a steering instability that had resisted traditional investigation, avoiding significant recall exposure.

In regulated manufacturing, compressed product cycles demonstrated that governance must move at the same speed as engineering if organisations are to innovate safely.

Across global engineering organisations, the technologies changed, but the structural problem never did.

The technologies changed. The problem never did — every tool managed the data; none managed the decision that connected it.

Then came hyperscale

The same pattern emerged again inside Amazon.

Rather than decades-long programmes, the challenge became hundreds of facilities generating petabytes of operational data while evolving continuously.

Ian led strategic Connected PLM initiatives within Amazon Robotics & Mechatronics, helping establish digital thread architecture across global operations. He also led harmonisation of operational metrics across hundreds of fulfilment facilities, creating a common engineering language for global maintenance and operational performance.

The lesson was striking.

Defence struggles because change moves slowly. Hyperscale struggles because change moves too quickly. The underlying architectural failure is identical.

Without durable engineering decisions, neither environment can maintain configuration integrity.

From observation to invention

By 2012, the evidence had become overwhelming.

Different industries. Different technologies. Different regulations. One recurring structural gap.

Ian began developing what became the DeZolve Decision Intelligence Framework — a new architectural approach that treats engineering decisions as first-class system objects alongside requirements, designs, products and data.

Decisions are the most important activity in business — yet no system ever managed them from the human perspective. DeZolve, the intelligence framework, solved that problem.

Over the following decade, the framework was refined through deployments spanning defence, advanced manufacturing, enterprise architecture and cloud-native engineering.

Clarity is the commercial expression of that work.

Why Clarity is different

Most engineering platforms organise information. Clarity organises understanding.

Every decision becomes a durable, traceable object connected to its evidence, assumptions, approvals, consequences and downstream impacts.

Knowledge no longer disappears when projects end. Institutional memory no longer depends on who happens to remain. Programme decisions remain explainable years — or decades — after they are made.

After a decade at AWS, scale had become a solved problem. Revisiting PLM twenty years on, the gap was obvious — thirty years of tech debt, piled up trying to scale PLM, ERP and MES systems constrained by 20th-century architecture and relational databases, with almost no innovation to clear it. The answer was not another layer on top; it was to start from the right schema, on cloud services already proven at near-infinite scale.

The result is trusted product intelligence for sovereign and regulated programmes.

Built for the lifetime of the system

Modern engineering programmes increasingly outlive the technologies used to build them.

Software changes. Vendors change. Platforms evolve. Evidence must not.

Clarity is designed around open data, customer-owned infrastructure and enduring traceability so that engineering knowledge remains accessible throughout the life of the system, independent of any particular technology stack.

In thirty years, no customer ever asked to be locked into a proprietary, expensive, licence-restricted architecture that couldn’t be maintained past its last licence payment. The need for open architecture was obvious.