How we got to Clarity
30 years of engineering programme delivery. A patent-pending decision intelligence framework. One realisation: the engineering decision crisis is not a tooling problem — it is a DIKW problem.
DIKW — Data, Information, Knowledge, Wisdom — is the hierarchy that separates tools that store things from platforms that connect things into models and evaluate whether the resulting decisions are trustworthy.
The DIKW lightbulb
Every tool in the market — SharePoint, DOORS, Teamcenter, Cameo, Jama, Sparx EA — operates at the bottom two levels of the DIKW hierarchy: Data (files, versions, documents) and Information (structured records, BOMs, configuration). They store things and organise things. They do not connect things into a knowledge model, and they do not evaluate whether the resulting decisions are trustworthy.
Wisdom — DeZolve Decision Intelligence
Every decision carries a computed Decision Truth Vector — trustworthiness derived from structural evidence, not asserted by the person who owns the gap. Explicit traceability, AI-inferred connections, and gap severity combine into one score at every node across the full lifecycle chain. L4 baselines mean the score can be recomputed as it was when any past decision was made. The entire decision history of the programme is permanently auditable. No competitor operates at this level.
Knowledge — Lx Schema
Entities connected across 13 lifecycle verticals with typed relationships, provenance, and overlay assessments.
Information — Every existing tool
Requirements databases, PLM BOMs, configuration records.
Data — Every existing tool
Files, documents, version history.
Bolting AI onto a Data/Information tool does not make it a Knowledge/Wisdom tool. It makes it a chatbot sitting on a filing cabinet. The chatbot can read the documents in the drawer it’s pointed at — but it cannot see into the other cabinets across the room, it cannot follow connections that exist only in someone’s head, and it cannot tell you whether the decision those documents support is trustworthy.
This is why “AI-powered” DOORS is still DOORS, and “AI-powered” Teamcenter is still Teamcenter. The underlying DIKW level has not changed.
The DeZolve patent (2012)
In 2012, after two decades of delivering engineering programmes and watching the same pattern repeat — decisions made on fragments, evidence scattered across disconnected tools, outcomes that surprise nobody except the executives who approved them — the DeZolve decision intelligence framework was filed as a patent.
DeZolve identifies that all decisions, regardless of domain, scale, or organisational structure, pass through three roles: Seeker (gather evidence), Solver (analyse trade-offs), Decider (make the call). The framework introduces Truth Vectors that compute trustworthiness across three route types, Evidence Coverage metrics that show the decider exactly what they are — and are not — deciding on the basis of, and a four-level interface architecture that models the full complexity of a programme from within a single product out to global system-of-systems boundaries.
That interface architecture — internal product interfaces, external interfaces between products, system-level interfaces, and system-of-systems to global — is what makes Clarity structurally different from every competitor. It is not a notation. It is not a diagram. It is a live, policy-enforced model of every boundary in the programme, traceable through the full lifecycle chain using L4 baselines and L5 decision truth vectors. It is what gives Clarity its singular view across 16 BOM views. It is what the diode and airlock patterns use to map policy and data flows across classification boundaries. And it is what elevates Clarity from a data broker into the knowledge and wisdom tier of the DIKW model — where no competitor operates.
The patent existed for a decade before the technology to productise it at scale — serverless cloud, AI generation, cloud-native infrastructure — became viable. Clarity is the product.
The experiences that shaped Clarity
Thirty years of programme delivery across defence, nuclear, automotive, ecommerce, banking, and government produced one inescapable conclusion: the problem is never a shortage of tools. It is always a shortage of connection. Every category of enterprise software — PLM, MBSE, ERP, MES, MRO, EAM — was designed to solve one problem, for one stakeholder group, at one point in the lifecycle. None of them were architected to connect. Every customer eventually discovers this, usually mid-programme, at a cost they did not budget for.
PLM — the configuration problem, frozen in 1985
Eighteen simultaneous defence programmes on mandated PLM. 800 data objects. 2,000-plus requirements across 30 stakeholder groups. Users resorting to nightly spreadsheet exports because the tool could not generate the reports the business needed. Field failures manually reconciled with design requirements months after the fact, in meetings, by people. A corporate mechatronics integration in 2024 exposed the same structural truth that had been visible since 2005: four digital threads — engineering, manufacturing, spares, bidirectional change — demanded four separate BOM views that PLM had no architecture to unify. Reconciling them required a programme of its own. A separate global tech engagement that same year required reverse-engineering the PLM database for reporting because the vendor’s BI module had never been purchased — and when it was, it was slower than the spreadsheets it replaced. PLM solved the configuration management problem it was designed to solve in the 1980s. The underlying data model has not materially changed since. Its vendors have added AI. The DIKW level has not changed.
MBSE — the right methodology, the wrong instrument
The methodology is sound. A military systems integration project generated 13,000 nodes and relationships in under two hours — Army force structures across 12 scenarios, 8 capability groups, and 18 stakeholders, completed in five weeks and briefed to the Chief of Army. The problem is not the notation. It is the isolation. MBSE tools are specialist instruments: architect-dependent, disconnected by design from the operational systems that consume their outputs. A model in Cameo that cannot speak to the DOORS requirements database, the Teamcenter BOM, or the Maximo asset record is a beautiful artefact that earns a shelf while decisions are made in PowerPoint. Delivering a Masters project with 1,350 engineering students over four years confirmed the same pattern at smaller scale: the top quartile thought in systems. The bottom quartile refused to ask for help because the tools gave them no model to ask against. MBSE tools do not replace the need for a live, connected model. They produce a static representation of one that is perpetually out of date from the moment it is drawn.
ERP, MES, MRO, and EAM — vertical slices with no shared floor
De-risking a two-billion-dollar-per-year government ERP migration that had previously been assessed as too risky to touch. Owning the global ecommerce digital thread at a Fortune 500 company where every answer was another fragmented dashboard built on untrusted data — and where reverse-engineering the broken data model exposed formulae so convoluted that no individual had understood them for years. The pattern across SAP, Oracle, Maximo, and every MES and MRO variant encountered over three decades is identical: each system was built to run its vertical slice of the business. None were architected to share a data model with the system that designed the product they are maintaining. SAP gives you one BOM view. Maximo gives you one. They are not the same BOM. The entities do not share identity. Reconciling them requires integration programmes that generate more complexity than the systems they connect. The closure of the operational loop — a field failure surfacing as active risk against the originating design requirement, in real time, without a meeting — does not exist in any of them. It is structurally impossible in a two-system world with no shared model.
Enterprise bloatware — decades-old foundations with AI lipstick
Salesforce, ServiceNow, SAP, and Oracle share a common architecture: data models designed for a different decade, extended by acquisition into every adjacent domain, with a generation of AI features positioned as intelligence but delivering search. Their competitive response to the knowledge gap has been to acquire or build a copilot that reads documents in the drawer it is pointed at — but cannot follow connections across systems they do not own, cannot evaluate whether a decision is trustworthy, and cannot tell you that the field failure recorded in MRO invalidates the safety case in PLM. Co-authoring the AWS Cloud Adoption Framework and creating the Operational Excellence pillar for the Well-Architected Framework confirmed that the same structural failure exists in cloud architecture: organisations accumulate tools rather than building models, and the absence of a shared knowledge layer means every team builds its own version of the truth. Adding AI to a filing cabinet makes a faster filing cabinet. It does not move the platform up the DIKW hierarchy.
The lesson from a 1998 conversation with the Challenger engineer who warned of the O-ring failure. Confirmed in a uranium facility where the traceability model proved non-compliance while the project documentation claimed the opposite. Confirmed again in a naval programme where safety case approval ran to 214 days until the model shortened it to 31. Confirmed in every PLM deployment, ERP migration, and ecommerce digital thread since:
Decisions fail not because evidence does not exist — but because it is scattered across disconnected tools, buried in documents nobody reads, and assembled too late for anyone to change the outcome.
The structured model is the defence. The closed loop from design to field and back is the defence. Trusted provenance, open formats, and a decision framework that shows the decider exactly what they are — and are not — deciding on the basis of, is the defence. Clarity is the product.
Three interlocking tuples
Clarity’s competitive position rests on three interlocking tuples. Each has three elements. Each reinforces the others. Together they form a structure no competitor can replicate without rebuilding from scratch.
WHERE Clarity plays
- ● Orchestrator of PLM, ERP, MES, MRO, EAM
- ● MBSE Replacement
- ● Whole-Life Solution
WHY Clarity wins
- ● Decision-making as first-class capability
- ● True audit traceability (data, not documents)
- ● Beautiful documents as projections of truth
WHO uses Clarity
- ● Seeker → Solver → Decider
- ● Organisation-specific role mapping
- ● Emergent achievement roles
Data sovereignty is architecture, not policy
Legacy enterprise software is a hostage model. Your data lives in the vendor’s proprietary schema. You cannot read it without a licence. You cannot move it without an extraction project. You cannot delete it without years of legal leverage. Every legacy PLM, ERP, and MES vendor monetises your exit costs as much as your entry costs — and the data model they hold you in has not materially changed since the 1990s.
Clarity’s data architecture is structurally different. Open JSON on AWS S3. Customer-managed KMS encryption keys. No Clarity employee can access your programme data by technical means. No licence required to read, process, or migrate your data in 10, 25, or 50 years. The schema travels with the data.
Zero latency to insight
Real-time visibility without the Export to Excel button. Every metric, decision, and gap indicator computed live from the structured model — not from a nightly ETL that nobody trusts by morning.
Engineering for change
Schema-on-Read means you build for the pivot. Add a field, extend a relationship, change an assessment model — your historical data does not break. No migration scripts. No schema lock-in imposed by a vendor who charges you to change it.
Anti-middleware
Every integration tax you pay for your PLM-to-ERP bridge, your ERP-to-MRO connector, your MRO-to-reporting pipeline — eliminated. One model. Every lifecycle layer. No middleware consultants required to maintain connections between systems that should never have been separated.
14 Eyes sovereign compliance — by architecture, not by contract
Compliance for multi-decade regulated programmes is not a checkbox. It is a structural property of the data architecture. Clarity’s JSON-on-S3 model satisfies the sovereignty requirements of every allied jurisdiction — not through policy assertions, but through cryptographic enforcement.
| Framework | Requirement | Clarity architecture |
|---|---|---|
| Schrems II / CLOUD Act | Zero vendor visibility into customer data | Customer-managed KMS — Clarity has no decryption path, by design |
| IRAP / FedRAMP High | Attribute-Based Access Control to object level | ABAC on S3 object tags — policy enforced at the storage layer, not the application layer |
| GDPR Art. 17 / 20 | Right to erasure; right to portability | Discrete JSON objects — delete or export any entity without ghosted relational references |
| NIST 800-53 / SOC 2 | Immutable audit trail with cryptographic integrity | CloudTrail immutable logs — every read, write, and delete, with cryptographic proof |
NIS2 — cybersecurity is now personal board liability
NIS2 became enforceable EU-wide in late 2024. For the first time, cybersecurity failures are not a corporate fine — they are personal liability for the Management Body. Executives of essential entities face personal liability for gross negligence, including disqualification from management roles. Fines reach €10 million or 2% of global annual turnover. Breach notification windows are 24–72 hours. Management bodies are legally prohibited from delegating cybersecurity responsibility downward.
Legacy PLM and ERP architectures are structurally incompatible with NIS2 compliance. The Business Object layer assumes inside-the-firewall trust — Zero Trust is architecturally impossible. SAP and Oracle forensics cannot reconstruct a breach within 72 hours. The Shadow Admin patterns required for PLM BOM synchronisation make Least Privilege unenforceable. These are not configuration problems. They are architectural ones that no patch cycle can resolve.
Clarity’s open JSON-on-S3 architecture follows the AWS Well-Architected Framework out of the box. Micro-segmentation on JSON objects, not perimeter trust. IaC-driven immutable infrastructure, not Big Bang update windows with multi-day RTO. ABAC enforced at the storage layer, not the application layer. CloudTrail cryptographic proof for forensics, not application logs assembled post-incident.
The architecture of your engineering data platform is no longer a procurement decision. For boards and executives in regulated industries, it is a personal legal liability.
Architectural neutrality
We do not want to own your data. We want your data to live in your sovereign infrastructure — your AWS account, your KMS keys, your S3 buckets — with Clarity as the intelligence layer on top. If you stop using Clarity tomorrow, your data remains in an open, readable format with no extraction project required. No vendor has ever built a business model on that principle, because no vendor has built a data architecture that makes it viable. Ours does.
What we bring
30 years of programme delivery
Hands-on experience delivering systems engineering outcomes using every tool in the market — Office stacks, PLM suites, DOORS, Cameo, Sparx EA, custom integrations. Three decades of helping customers succeed despite their tools, not because of them.
Patented decision intelligence
The DeZolve framework — the Wisdom layer — tested in environments where bad decisions cost lives and billions. Defence, nuclear, automotive, big tech. Cross-domain validation no competitor can replicate on a short timeline.
Proprietary world model & knowledge graph
A Meta-Ontological Map developed over 20 years from thousands of private and public artefacts. It describes not one domain but the structure of how domains relate to systems engineering decisions. AI draws on this structured experience during every generation.
Built as a Knowledge/Wisdom platform
Not a legacy tool with AI bolted on. The structured model layer is the Knowledge layer; DeZolve is the Wisdom layer; AI accelerates the construction of both. You cannot get from Data/Information to Knowledge/Wisdom by adding a plugin — you have to rebuild from the DIKW model down.
Structural data sovereignty
Customer-owned encryption keys, not Clarity’s. No Clarity employee can access programme data by technical means. Open JSON format — no licence required to read or process programme data in 10, 25, or 50 years. For regulated programmes with multi-decade lifetimes, this matters. Every legacy vendor charges you to access your own data. Clarity gives it to you in a format anyone can read, indefinitely.
The closed-loop nobody else closes
Thirty years of delivering programmes exposed the same structural gap in every tool: the design/operation boundary. Requirements are written in the design phase. Systems are built. They break. The field failure is recorded in MRO. The originating design requirement is never updated — because no tool connects them. Clarity does. A field failure surfaces as active requirement risk in the design model, in real time. No meeting required.
Who we serve
Engineering-led organisations in regulated sectors: defence, aerospace, medical devices, nuclear, automotive, rail, energy, space. Programmes where traceability is not optional and decisions must be defensible.
Initial market focus: AUKUS (Australia, UK, US), Five Eyes, and 14 Eyes allied nations. Australian company, built on AWS infrastructure trusted by allied defence and intelligence communities.
Get in touch
Interested in Clarity? Connect with us on LinkedIn.
One thread. 13 verticals. 16 BOMs. 25 USPs.
The only complete digital thread for regulated programmes, powered by the patent pending DeZolve Decision Intelligence Framework. Sovereign deployment under your own AWS account and encryption keys — at 10× less than the enterprise alternatives.