Breaking the DIKW Ceiling

TL;DR

The engineering decision crisis is not a tooling problem — it is a DIKW problem. Every legacy enterprise system in daily use — PLM, ERP, MES, MRO, EAM — operates at the bottom two levels of the Data–Information–Knowledge–Wisdom hierarchy. They store files. They index records. They do not connect things into a structured knowledge model, and they certainly do not evaluate whether the resulting decisions are trustworthy. Bolting AI onto them does not fix this. It gives you a chatbot sitting on a filing cabinet.

Clarity was designed from the ground up as a Knowledge and Wisdom platform. Its data schema is:

1. 13 lifecycle verticals (L0 Intent → L12 Disposal) — the spine of the digital thread
2. 10 overlay groups — cost, supply chain, readiness, compliance, lifecycle, security, risk, external, quality, external systems — cross-cutting assessment dimensions on every vertical
3. @source back-propagation — every entity carries provenance and closes the loop from implementation reality to design intent
4. A world model built over 20 years — a proprietary Meta-Ontological Map that anchors semantic identity across domains
5. A lessons-learnt knowledge graph — cross-domain experience (defence, nuclear, health, energy, robotics, advanced manufacturing) encoded as reusable knowledge
6. The patent pending DeZolve Decision Intelligence Framework — truth vectors, evidence coverage, decision trustworthiness — the Wisdom layer

These five elements together are a complete data schema for the DIKW challenge. No competitor has all five. Most have none. Section 2 of this paper documents, in unsparing detail, the data-architecture anti-patterns that trap legacy enterprise systems at the Data and Information levels — and why those systems cannot climb to Knowledge and Wisdom without cannibalising their core product.

If you only read one sentence: legacy enterprise systems are tightly coupled, semantically overloaded, and poorly modelled data platforms that prioritise process enforcement over data usability — and you cannot fix them from the inside.

The DIKW ceiling

The Data–Information–Knowledge–Wisdom hierarchy is a well-understood model in information science. It describes four ascending levels of usefulness:

                    ┌─────────┐
                   ╱  WISDOM   ╲     Clarity: DeZolve Decision
                  ╱─────────────╲    Intelligence Framework
                 ╱               ╲
                ┌─────────────────┐
               ╱    KNOWLEDGE      ╲   Clarity: 13-vertical Lx
              ╱─────────────────────╲  thread + world model + LLKG
             ╱                       ╲
            ┌─────────────────────────┐
           ╱       INFORMATION         ╲  Every existing tool:
          ╱─────────────────────────────╲ requirements DBs, PLM BOMs
         ╱                               ╲
        ┌─────────────────────────────────┐
       ╱            DATA                   ╲  Every existing tool:
      ╱─────────────────────────────────────╲ files, versions, records
     └───────────────────────────────────────┘

     ◄──── PLM, ERP, MES, MRO, EAM ────►  ◄──── Clarity ────►
              (Data + Information)              (all four levels)

Every tool in the legacy enterprise stack — SharePoint, DOORS, Teamcenter, Cameo, Jama, Sparx EA, SAP, Oracle, Dynamics, Opcenter, FactoryTalk, Maximo — is a Data or Information tool. They store things and organise things. The ceiling they cannot break is the jump from Information to Knowledge: making relationships explicit, connecting slices, and representing the full-lifecycle context.

Bolting AI onto a Data or Information tool does not make it a Knowledge or Wisdom tool. It makes it a Data or Information tool with a chatbot — a chatbot sitting on a filing cabinet. The chatbot can read the documents in the drawer it is pointed at. It cannot see into the other cabinets across the room, it cannot follow the connections that exist only in someone’s head, and it cannot tell you whether the decision those documents support is trustworthy.

Clarity was designed from the ground up as a Knowledge and Wisdom platform. The rest of this whitepaper is split in two:

• Section 1 — how Clarity’s data schema (13 verticals, 10 overlay groups, @source back-propagation, world model, lessons-learnt knowledge graph, DeZolve) solves the DIKW challenge.
• Section 2 — why the legacy enterprise stack cannot get there, with specific anti-patterns documented per system class (PLM, ERP, MES, MRO, EAM), including the “one database for everything” trap.

Section 1 — How Clarity solves DIKW

Clarity’s answer to DIKW is a data schema, not a set of features. Five elements combine to move from Data and Information (where every legacy tool lives) to Knowledge and Wisdom:

1. 13 lifecycle verticals — the spine of the digital thread
2. 10 overlay groups — cross-cutting assessment dimensions
3. @source back-propagation — the evidence loop
4. The world model — the semantic anchor
5. The lessons-learnt knowledge graph — encoded cross-domain experience

Plus the DeZolve Decision Intelligence Framework as the Wisdom layer that sits on top. And AI that is bounded by all of the above rather than generating free-form prose.

1.1 Thirteen lifecycle verticals — Knowledge by construction

The Lx schema defines 13 verticals from stakeholder intent (L0) to lifecycle closure (L12):

Every entity at every vertical is a first-class object with typed relationships to every other layer. Not a table row with a foreign key. Not a document with a stapled cross-reference. A typed, queryable, provenance-carrying entity in a single connected graph that spans 13 verticals.

This is the Knowledge layer. The moment an organisation’s data lives inside this schema, it is no longer a pile of files — it is a model. And a model can be queried, analysed, recalibrated, and reasoned about in ways a filing cabinet cannot.

Non-linear entry — first-class, not an afterthought

Real programmes rarely start at L0. They enter the digital thread wherever the programme actually is — an operational brief (L10), a regulatory mandate (L12), an inherited baseline from a predecessor programme, a long-lead procurement decision. Clarity makes non-linear entry a first-class feature: enter at any lifecycle phase, build traceability in any direction, and carry every upstream input as a first-class CI in the same graph as the design. This is impossible in any legacy tool built around the assumption that programmes start at requirements and proceed in order.

1.2 Ten overlay groups — assessment dimensions on the knowledge

The 13 verticals alone would still be an incomplete model. Engineering reality is not just “what is the BOM at L6” — it is “what is the cost, risk, TRL, supplier risk, regulatory exposure, security posture, export-control status, and quality assessment of the BOM at L6”. Each of these assessment dimensions cuts across all 13 verticals and must be applied at every node.

Clarity models this as 10 overlay groups aligned to ISO 15288, each of which can be instantiated at any Lx vertical:

Every overlay is a lens on the same underlying data. Swap the lens, keep the data. Add a new domain pack, and the domain-specific overlays light up across every relevant vertical automatically — because the verticals are the anchor, and the overlays are the cross-cutting assessment layer.

This is how Clarity handles “any standard as an overlay, not a cage”. CIS, NIST, FedRAMP, HIPAA, ISO 15288, ISO 10007, STEP / ISO 10303 (AP214), NATO STANAG, DO-178C, ISO 26262, plus proprietary, sector-specific, and mandated standards — every one of them is an overlay registered against the relevant verticals, not a schema fork.

Legacy tools cannot do this. They bake their compliance framework into their data model. If your programme needs to satisfy both ISO 26262 and DO-178C and ISO 13485, you buy three tools (or three “configuration packs”) and maintain three parallel data stores. Clarity applies all three overlays to the same verticals and resolves conflicts at query time.

1.3 @source back-propagation — the evidence loop

The jump from Information to Knowledge is about relationships. The jump from Knowledge to Wisdom is about evidence. Every entity in every Lx vertical carries an @source provenance block with 15 typed fields — including designAuthorityProvenance, exportControl, validation, operational, update, and disposal.

These fields enable back-propagation: implementation-plane evidence (L6–L12) flows back to design-plane decisions (L0–L5). Concretely, the closed loop runs across these eight named paths:

This is not a “feature”. It is a structural property of the schema. Because every entity carries @source, the loop closes by architecture, not by a workflow integration. No legacy tool closes this loop because no legacy tool has a schema-level @source primitive.

The closed loop is the missing link in every “digital thread” marketing claim. When Teamcenter says “digital thread”, they mean “you can click a link in the BOM to see the CAD file”. When Clarity says “digital thread”, we mean “the scenario MoE recalibrates automatically when operational telemetry diverges from prediction, and the L5 decision trustSummary updates to reflect it, and the audit trail is the thread itself.”

1.4 The world model — semantic anchor built over 20 years

Knowing which entities to model, how they relate, and what the canonical vocabulary is takes time. Clarity’s data schema rests on a proprietary Meta-Ontological Map world model, built over more than 20 years across hundreds of engagements in defence, aerospace, nuclear, automotive, medical, and big tech. The world model is:

• Framework-independent — it does not assume SysML, or ArchiMate, or TOGAF, or any specific methodology. It models the underlying concepts (stakeholders, needs, functions, components, interfaces) that every framework re-represents in its own language.
• Domain-extensible — sector-specific vocabulary is added via overlay registries without touching the kernel.
• Validated cross-domain — the same ontology has been applied to aerospace platforms, nuclear facilities, medical devices, and software-intensive systems. If a concept only works in one domain, it is not in the kernel.
• The foundation for AI — the world model is what lets Clarity’s 325 AI agents generate structured entities from unstructured input. The agent does not have to guess what a “stakeholder” is or how it relates to a “requirement” — the world model has already defined it.

A legacy PLM or ERP vendor cannot replicate this overnight. The world model is not a configuration file; it is the distilled experience of cross-domain programme delivery, encoded as a reusable semantic layer. Competitors can buy the verticals (they already have them). They cannot buy 20 years of semantic modelling against cross-domain programme failure.

1.5 The lessons-learnt knowledge graph — experience as a first-class citizen

Alongside the world model sits the lessons-learnt knowledge graph (LLKG): a graph-structured encoding of thousands of private and public engineering artefacts — failure analyses, post-mortems, test reports, compliance findings, programme reviews — built up over 20 years of hands-on cross-domain delivery.

The LLKG is queryable by the AI layer during generation. When Clarity generates L2 parameters for a new option set, it can retrieve structurally similar cases from the LLKG and use them to ground the generation. This is fundamentally different from a chatbot that has been “trained” on engineering data. The LLKG is a structured graph with typed relationships and provenance. The AI cites it during generation rather than sampling it during inference.

This turns out to be the architectural answer to AI hallucinations in an engineering context:

• Structured retrieval, not sampling. The AI cannot invent a lesson because it must cite an LLKG node or not cite one at all.
• Cross-domain transfer. Lessons learnt in nuclear programme delivery apply to aerospace platform design when the structural pattern matches. The LLKG is where that transfer lives.
• Provenance preserved. Every cited lesson carries its origin, which becomes part of the generated entity’s @source block.
• Self-reinforcing. Outputs from Clarity (reports, audits, decision records) become new LLKG entries, feeding the next generation cycle.

1.6 DeZolve — the Wisdom layer

The fifth element is the Wisdom layer: the patent pending DeZolve Decision Intelligence Framework. DeZolve computes a truth vector for every decision — a quantified score of decision trustworthiness based on explicit traceability, inferred connections, gap severity, and evidence coverage across the full Lx chain.

Unlike a “traceability matrix” (which is a flat link coverage report), the DeZolve truth vector is a structured trustworthiness computation. It answers the question legacy tools cannot: “is this decision good enough to execute?”

DeZolve is patent pending and is the single most important architectural property of the platform that competitors cannot replicate without licensing. It is also the reason Clarity’s AI generation is bounded: DeZolve scores the output before it reaches the user, and contested outputs block promotion until resolved.

DeZolve is the Wisdom layer because:

• It operates on the Knowledge layer (the Lx verticals + overlays + world model + LLKG)
• It produces a verdict (verified / corroborated / asserted / contested / unknown)
• The verdict is reproducible — the same inputs produce the same output, so all parties to a multi-supplier, multi-nation programme can attack the same score simultaneously
• The verdict is explainable — every truth-vector score can be drilled into to see which evidence contributed and which is missing

1.7 AI bounded by the schema — hallucinations constrained by architecture

Clarity’s 325 AI agents are not the intelligence. The intelligence is in the schema: the world model, the LLKG, the Lx verticals, the overlay registries, and DeZolve. The LLM is just the generation engine — the thing that turns structured queries into prose and back again.

This means any LLM can be used. By default Clarity uses cost-effective AWS Bedrock Nova models. Customers can switch to Claude, Llama, Mistral, or bring their own bounded on-premise model (for air-gapped or classified environments). The validation, schema enforcement, and provenance tracking work identically regardless of which model sits behind them.

AI is a commodity input to Clarity. The differentiator is what constrains, validates, and grounds the AI output: the proprietary world model, the LLKG, the Lx schema, and DeZolve. No competitor can commoditise AI this way because they do not have a structured knowledge model to constrain it. They depend on the LLM to be smart, and hope for the best.

1.8 Documents as outputs, not sources of truth

In every legacy tool, documents ARE the source of truth. Requirements live in DOORS. Architecture lives in Cameo. BOMs live in Teamcenter. Reports live in Word. Status lives in Jira. Each document is a separate, disconnected artefact that someone must manually keep in sync with every other document. When they drift — and they always drift — nobody knows which version is authoritative.

In Clarity, the Lx digital thread IS the source of truth. Everything else is a view.

This is an architectural property, not a feature. Because the Lx schema is the single structured model, every output is a computed projection of the same underlying truth. Nothing can drift because nothing is maintained independently. The thread is the truth; everything else is a view.

1.9 The recursive loop — outputs become inputs

The thread is not a one-way street. Documents, reports, and analysis outputs generated from Clarity are saved to the Library — and can be ingested back into Clarity as source material for future work. A report generated from an L3 analysis becomes a Library document that AI can cite when generating L2 parameters on the next programme. An audit pack from one baseline becomes evidence context for the next design review. The thread feeds the outputs; the outputs feed the Library; the Library feeds the next generation cycle.

  Lx thread  ──▶  Generate report / document  ──▶  Save to Library
                                                           │
  Lx thread  ◀── AI generation (Library RAG)  ◀───────────┘

This recursive loop also powers the diode integration pattern for legacy data. Organisations sitting on years of fragmented legacy data — requirements in DOORS exports, BOMs in Teamcenter spreadsheets, test evidence in SharePoint folders, design rationale in email archives — can ingest that data into Clarity’s Library via the diode pattern. AI reads the ingested documents, extracts structured entities, and populates the Lx thread with provenance tracing back to the legacy source. The legacy systems stay exactly as they are — same tools, same licences, same workflows, same costs. But the data they hold, previously locked in disconnected silos, now participates in the digital thread.

This means an organisation can realise Clarity’s benefits — full lifecycle traceability, decision intelligence, structured baselines, audit-ready evidence chains — without changing a single legacy system. Over time, as the strangler pattern takes effect, the legacy tools become increasingly optional. But there is no day-one disruption, no big-bang migration, no rip-and-replace risk.

No competitor offers this. Document-based tools cannot ingest their own outputs as structured model input — a DOORS export reimported into DOORS is still a flat requirements list, not a connected model. PLM exports reimported into PLM are still disconnected BOMs. Only a tool built on a structured knowledge model (DIKW: Knowledge layer) can recursively enrich itself from its own outputs and from legacy data alike.

1.10 Summary of Section 1

Clarity’s data schema solves DIKW through five structural primitives plus a Wisdom layer plus an architectural commitment to documents as outputs, not sources:

The rest of the industry is still arguing about whose Data and Information tool is better. Clarity sits a level above, on a schema that makes Knowledge and Wisdom structural rather than aspirational. The next section documents, in unsparing detail, why legacy enterprise systems cannot climb to this level — even when they try.

Section 2 — Why legacy enterprise systems cannot get there

This section maps the systemic data-architecture failures across the five legacy system classes against their consequences. It is deliberately blunt and structured around the actual pain points: performance, queryability, operability, and lock-in.

2.1 System vs core architectural flaws

Every legacy enterprise system was architected around a different starting point — product data, finance, the shop floor, maintenance, or asset lifecycle — but all of them converged on the same class of anti-pattern.

The one-line diagnosis per system class that emerges from this table is devastating:

• PLM — data exists but is not accessible
• ERP — data exists but is not meaningful
• MES — reality exists but is not captured correctly
• MRO / EAM — history exists but is not usable

2.2 Six failure dimensions

Severity legend: 🔥 severe · ⚠️ moderate · ❌ fundamental failure.

A. Queryability & data access

Net effect: data exists but is not computable.

B. Performance & scalability

Net effect: systems are slow where it matters, fast where it doesn’t.

C. Data modelling & semantics

Net effect: the system cannot represent reality accurately.

D. Integration & architecture

Net effect: the “integrated enterprise” is actually loosely synchronised silos.

E. Operability & maintainability

Net effect: systems become unsupportable over time.

F. Vendor lock-in

Net effect: lock-in is architectural, not contractual.

2.3 Impact on key use cases

The failure dimensions above translate directly into broken use cases that engineering programmes actually need to run.

“Query my business / product”

Result: users export to Excel or build shadow systems.

“Real-time insight”

Result: decisions made on stale or inconsistent data.

“Traceability / digital thread”

Result: root cause analysis is slow and unreliable.

“Evolve the system”

Result: systems freeze in time.

2.4 PLM anti-patterns — “data exists but is not accessible”

PLM systems (Teamcenter, Windchill, ENOVIA, Aras) were born to manage CAD files and engineering BOMs. They grew into “product lifecycle management” without ever escaping their core assumption: the hierarchical CAD assembly tree is the data model.

Relational schema anti-patterns

1. Adjacency-list-only parent FK. Part(id, parent_id, …). Recursive queries become slow and complex; multi-level BOM explosion is impractical at scale. The correct answer is closure tables, nested sets, or path enumeration — but most PLMs never adopt these.
2. No explicit versioning. Parts and BOMs overwritten in-place. No historical traceability (critical in aerospace and automotive). Impossible to reproduce past builds. Breaks compliance.
3. Mixing part master and BOM structure. Hierarchy fields stuffed into the part table. A part can appear in multiple BOMs → normalisation violation. Duplication and inconsistency follow.
4. No quantity or unit normalisation. Quantities stored as “2”, “2 kg”, “2000 g” interchangeably. Rollups silently corrupt.
5. Deep join explosion. Many joins for every traversal level. Queries become unreadable and slow.
6. EAV (entity-attribute-value) abuse. Generic attribute tables kill query performance, strip type safety, and become impossible to maintain — yet PLM vendors lean on EAV to support customisation.
7. No effectivity or configuration control. Single static BOM. Real systems need date-based effectivity, serial-number applicability, and variant configurations. Missing this makes the system unrealistic.
8. Circular references not prevented. No DAG constraint. Infinite recursion, logical corruption.
9. Stored computed aggregates. Rolled-up cost / weight in tables go stale and become inconsistent.
10. Ignoring many-to-many. Assuming one parent per component, when real parts are reused across assemblies.

Graph schema anti-patterns (when vendors escape relational)

PLM vendors who switch to graph databases trade one set of problems for another:

1. Treating graph as a dumping ground — no schema discipline.
2. Overusing relationships instead of attributes — (Part)-[:HAS_COLOR]->(Red) bloats the graph.
3. No versioning in the graph — same traceability problem as relational.
4. Ignoring multi-level explosion costs — deep traversal blows up exponentially.
5. No control over cycles — graphs allow arbitrary cycles; BOMs must be DAGs.
6. Edge overloading — [:USES {qty: 2, version: "A", effectivity: "..."}]. BOM Item should be a first-class node, not a property bag on an edge.
7. No separation between part-as-definition and part-as-instance — reuse and configuration management break.
8. Lack of indexing strategy — entry points still need indexes; graph traversal does not replace them.
9. Supernodes — one common fastener connected to thousands of edges becomes a traversal bottleneck.
10. Mixing structural and semantic relationships — BOM structure, functional relationships, and manufacturing flows jammed into one graph.

Cross-cutting PLM failures

• No clear identity strategy — part number vs revision vs instance confusion.
• Ignoring configuration management — variants, options, effectivity missing.
• No change tracking — cannot answer “what changed and why”.
• Treating BOM as static — real BOMs are versioned, contextual, configurable.
• No separation of concerns — EBOM, MBOM, SBOM mashed into one structure.

PLM diagnosis: data exists but is not accessible.

2.5 ERP anti-patterns + “business object nonsense”

ERP systems (SAP S/4HANA, Oracle EBS, Dynamics 365) followed the same trajectory as PLM from a different starting point — finance and transactions instead of product data. The result is a parallel set of anti-patterns that lead to the same symptoms: rigidity, poor queryability, brittle integrations, and platform sprawl.

The 12 core ERP anti-patterns

1. Configuration-as-programming (“customising hell”). Business logic encoded in config tables, rules engines, UI-driven settings. No single source of truth for logic. Impossible to reason about behaviour. Small changes have unpredictable effects.
2. Data model fragmentation. The same concept (“Customer”) duplicated across Sales, Finance, CRM, Logistics. Inconsistent definitions. Complex synchronisation logic.
3. Document-centric modelling. Everything is a “document”: Sales Order, Purchase Order, Invoice, Delivery. Relationships are implicit, not explicit. No true graph of the business.
4. Hidden state machines. Status fields + workflow engines define behaviour. Logic scattered across status flags, workflow configs, and code.
5. Batch-oriented thinking in a real-time world. Nightly MRP runs, reconciliation, data sync. Data latency. Inconsistent views of reality.
6. No event model (or fake events). Systems react to DB changes indirectly. No audit-friendly event stream. Hard to reconstruct history. Fragile integrations.
7. Tight coupling between modules. Modules share tables, logic, transactions. Monolith. Independent evolution impossible.
8. API afterthought. APIs layered on top of internal logic. Slow, inconsistent, not designed for external consumption.
9. Query hostility. Highly normalised, encoded, spread across hundreds of tables. Ad-hoc queries are extremely difficult. Analytics requires ETL duplication. Business users depend on reports, not data.
10. Customisation = permanent fork. Each deployment becomes unique. Upgrades are painful or impossible. Long-term cost explosion.
11. Overloaded master data. Master data objects carry too much meaning. In SAP, Material represents product definition + inventory item + costing entity + planning unit simultaneously. Semantic overload.
12. Lack of explicit relationships (no graph thinking). Relationships inferred via foreign keys + documents. No native dependency graph. Impact analysis is painful.

Why “business objects” force customisation

ERP “business objects” were meant to standardise enterprise data. In practice they have become one of the biggest sources of rigidity, inconsistency, and forced customisation. The ten core flaws in ERP business objects are:

1. Overloaded semantics — one object represents too many concepts (Material = product + inventory + cost + plan).
2. False universality — “one size fits all” fails because every company has different processes.
3. Implicit relationships — spread across FKs, embedded in documents, encoded in logic; no explicit graph.
4. Behaviour embedded in data structures — status fields + workflow triggers + validation rules jammed into the object; logic is scattered.
5. Rigid schemas with limited extensibility — extensions require custom fields, append structures, metadata hacks; messy and fragile.
6. Context-free data — objects lack time context, usage context, relationship context; cannot answer “what was true at time T?”.
7. Document-centric modelling — objects revolve around orders, deliveries, invoices; no system-level understanding.
8. Duplication across modules — same concept appears multiple times; data inconsistency.
9. Inflexible lifecycle models — predefined states that don’t match real workflows.
10. Opaque storage and access — data spread across many tables, access via APIs or proprietary layers.

The customisation trap is inevitable once these flaws collide with reality:

• Schema mismatch → custom fields → Z-tables → extensions everywhere
• Process mismatch → custom workflows → status hacks → conditional logic
• Semantic mismatch → repurposed fields → overloaded meanings → shadow objects
• Integration gaps → manual sync → middleware layers
• Query limitations → data warehouses → Excel exports → BI layers

ERP diagnosis

Data exists but is not meaningful.

2.6 MES, MRO, EAM anti-patterns — “operational reality”

MES (Opcenter, FactoryTalk), MRO (aerospace / heavy industry tools), and EAM (IBM Maximo, SAP EAM) inherited many of the same problems as PLM and ERP, with an extra twist: they sit close to real-time operations and physical assets, so the anti-patterns show up as latency, poor visibility, and operational friction rather than just bad data models.

12 shared anti-patterns

1. Process-centric, not data-centric — the systems model work orders and procedures, not the underlying asset relationships.
2. Asset identity fragmentation — the same physical asset has a different ID in MES, EAM, and MRO.
3. No true digital thread — maintenance, production, and design data are disconnected. Root cause analysis becomes guesswork.
4. Event loss — shop-floor events are overwritten, aggregated, or lost. No replay, no time-travel debugging.
5. Batch integration with ERP / PLM — periodic sync means latency, inconsistent state, and planning-vs-execution mismatch.
6. State hidden in work orders — real system state encoded in workflow status fields. Cannot reconstruct reality at time T.
7. Rigid workflow engines — predefined process flows that cannot adapt to real-world variability.
8. Poor modelling of hierarchies and networks — equipment modelled as flat lists or simple trees when real assets are networked and interdependent.
9. Time as an afterthought — current state stored, history partial. Weak predictive maintenance.
10. SCADA / IoT data not integrated to the asset model — sensor data lives in separate stores with no asset linkage. Context is lost.
11. Customisation = hardcoding reality — each plant customises the system heavily. No standardisation. Impossible to scale globally.
12. UI-driven logic — business logic embedded in screens and forms. Not reusable, not queryable, not automatable.

System-specific twists

• MES “shadow ERP” — MES replicates orders, inventory, BOMs, and diverges from the real ERP.
• MES PLC-centric modelling — data tied to machine signals instead of product / process model.
• MES WIP black holes — poor tracking of intermediate states; no real-time visibility.
• MRO as workflow only — focus on maintenance tasks, not asset behaviour. No predictive capability.
• MRO document-centric compliance — PDFs instead of structured data. No analytics.
• EAM as static asset register — ignores configuration changes and context of use.
• EAM preventive-maintenance overkill — time-based schedules instead of condition-based. Inefficient and costly.

The closed loop that isn’t closed

In theory: PLM → ERP → MES → EAM → back to PLM. In reality: broken links at every step, no shared identifiers, no shared event model. The “digital thread” between these systems is fictional.

MES / MRO / EAM diagnosis

Reality exists but is not captured correctly. History exists but is not usable.

2.7 The “one database for everything” mess — SAP S/4HANA as case study

The “one database for everything” pitch — most prominently pushed with SAP S/4HANA on top of SAP HANA — sounds compelling on the surface: “single source of truth, real-time analytics, no redundancy, simplified landscape.” In practice, it often makes things more complex, less flexible, and harder to evolve.

The marketing claim vs reality

The real problem: layer collapse

The “one DB” idea collapses layers that should remain separate: storage + processing + analytics + integration = one system. This creates hidden coupling, operational fragility, and scaling bottlenecks. Emergent anti-patterns include:

• God database — everything depends on one system; it becomes both a performance and an organisational bottleneck.
• Implicit architecture — hidden dependencies and accidental complexity replace explicit pipelines and models.
• Performance theatre — benchmarks look great; real-world queries are still slow or confusing.
• Simplification by marketing — reduced table count does not mean reduced complexity. It just hides it.

The real lesson

No single data model or engine can optimally serve all use cases. Trying to force it leads to architectural rigidity, hidden complexity, and — eventually — another generation of “enshittified” enterprise systems.

2.8 Root-cause synthesis

Stripped of vendor-specific detail, five root causes explain all of the above:

1. Data is not first-class — hidden behind objects, APIs, workflows.
2. Relationships are not explicit — no graph, no understanding.
3. Time is not modelled properly — no event history, no truth.
4. Systems optimise for control, not computation — process beats data.
5. Architecture is implicit, not designed — it emerges through configuration and integration.

Conclusion — the DIKW ceiling, and the way through

The engineering decision crisis is a DIKW problem, not a tooling problem. No amount of money spent on PLM / ERP / MES / MRO / EAM licences, integrations, SI engagements, or “AI-powered” upgrades will change the DIKW level of the tools involved. You cannot get from Data / Information to Knowledge / Wisdom by adding a plugin.

You have to rebuild from the DIKW model down — which means cannibalising the existing product. Legacy vendors cannot do this because their business model is the document they hold. DOORS holds your requirements; that is why you pay DOORS rent. Teamcenter holds your BOM; that is why you pay Teamcenter rent. If they ever talked seamlessly to each other, you might realise you could replace one of them. The fragmentation is not a failure of integration engineering; it is a feature of the business model.

Clarity is designed differently. The Lx schema is open JSON. The data is yours under your own encryption keys. The platform connects your existing tools rather than replacing them. If you ever want to leave, you take your entire digital thread with you — it is readable without Clarity. This is not altruism; it is architecture. When the product solves the actual problem, customers stay because it works, not because they are trapped.

The Clarity answer, in one page

• 13 lifecycle verticals (L0–L12) give you the connected spine — Knowledge by construction.
• 10 overlay groups give you cross-cutting assessment dimensions — any standard is a lens, not a cage.
• @source back-propagation closes the loop — implementation reality flows back to design decisions automatically.
• The world model gives you 20 years of cross-domain semantic modelling for free.
• The lessons-learnt knowledge graph grounds AI generation in real precedent.
• The patent pending DeZolve Decision Intelligence Framework is the Wisdom layer — truth vectors, evidence coverage, decision trustworthiness.
• AI is a commodity input — bring your own LLM; Clarity supplies the schema, the world model, the LLKG, and DeZolve that constrain it.
• Documents are computed projections of the thread — nothing can drift because nothing is maintained independently.
• The recursive Library loop lets Clarity ingest legacy data via diode connectors, without changing a single legacy system.

This is not a feature list. It is a data schema for the entire DIKW challenge. It is also the reason Clarity is not competing in a product category; it is defining a new one.

This whitepaper is one of a series. Related deep dives include The DeZolve Decision Intelligence Framework, Thirteen Lifecycle Phases, One Graph, Sixteen BOM Views on One CI Graph, Diode & Airlock Connectors, Event-Driven by Kernel, Not by Feature, and 325 AI Agents, Bounded by DeZolve. See all whitepapers for the full list.