Event-Driven by Kernel, Not by Feature

TL;DR

The engineering enterprise software industry has a philosophical failure at its core. Legacy vendors — SAP, Oracle, Siemens, Dassault, IFS, Infor — sell a worldview that says “if you model and optimise processes, the system will work”. Twenty years of signature failures (Birmingham City Council, the Royal Australian Navy Super Seasprite programme, every multi-year PLM transformation that delivered less capability than the legacy it replaced) have proven the opposite: processes are variable, context-dependent, and often wrong or incomplete. Data is the source of truth. Systems should be built around data, not around process.

The workflow-first, process-first, business-object-first architecture that dominates enterprise software has five interlocking failure modes:

1. Process over data. Systems encode an idealised business that does not exist, and then force the real business to distort itself to fit.
2. Business objects that collapse multiple concepts. SAP’s “Material” fuses product, inventory, accounting, and planning into a single record that is none of them.
3. Workflow engines that encode rigidity. Real-world exceptions break workflows; users build workarounds; the system drifts into inconsistency.
4. Customisation as mandatory symptom of bad modelling. Every deployment is unique, unrepeatable, and locked to the consultants who built it.
5. Captive consulting as a business model. Complexity is not accidental — it is economically reinforced.

Clarity’s answer is to move the event model down into the kernel. Not a workflow engine wired to features. Not a process orchestrator bolted onto an ERP. A kernel-level event-driven architecture where:

• Every write is an immutable JSON file in tenant-isolated S3.
• Every change emits an event consumed by typed Lambdas that aggregate, validate, and propagate.
• Aggregation is debounced by EventBridge so that bursts of writes collapse into a single coherent aggregate without losing individual events.
• Every field carries @source provenance — lineage, timestamp, author, confidence, evidence, tool — as a structural property, not an afterthought.
• The schema is typed and explicit, with invariants enforced at three rings (annotation, approval, solver).
• There are no workflow engines, no business objects, no process-first abstractions. Workflow is a view over the data, not a cage around it.

The digital thread is not a feature you add to a legacy stack. It is an architectural property that emerges naturally when the kernel is event-driven and the data is immutable, typed, and provenance-carrying — and cannot be retrofitted into any stack that started from workflow and process.

If you only read one sentence: workflow-first architectures encode fiction, and no amount of tooling on top can fix fiction; Clarity is event-driven at the kernel, which is the only place the digital thread can live.

The bargain on offer

Every enterprise software vendor of the last thirty years offers the same bargain. Buy our platform. Buy our consultants. Map your processes. Configure the workflows. Customise the business objects. In three years you will have a working system.

At the end of those three years, a subset of customers have something that approximately works, at multiples of the original budget, with institutional knowledge concentrated in a handful of contractors the customer cannot afford to release. The rest have a procurement scandal, a parliamentary inquiry, or a quiet write-down. The vendor cashes the cheque either way.

This is not a failure of execution. It is a failure of architecture. The stack is process-first and workflow-driven, which means the system is trying to encode a business that does not exist — a clean, normative, process-mapped fiction — and then forcing the real, messy, exception-ridden business to contort itself to fit. When reality inevitably breaks the workflow, users build workarounds, the data drifts out of the system, and the system becomes a rigid representation of an idealised business layered on top of a shadow ecosystem of spreadsheets.

Clarity takes a different position, and this whitepaper explains it in three sections:

• Section 1 — why the process-first, workflow-driven, business-object architecture of legacy enterprise software cannot close the digital thread, illustrated with the five interlocking failure modes and two signature real-world failures.
• Section 2 — how Clarity’s event-driven kernel works: immutable JSON, EventBridge debounce, typed schemas, @source provenance, the Lx.json aggregation pipeline, and the quiesce pattern that makes burst-writes consistent.
• Section 3 — why event-driven-by-kernel wins: the architectural properties that emerge automatically (query-ability, audit-ability, traceability, change-ability), the operational outcomes, and why no amount of AI or workflow tooling can retrofit these into a process-first stack.

Section 1 — Why legacy stacks cannot close the loop

Every enterprise system in daily use was designed, at its core, around process. The Lx thread it needs to close — intent to disposal, decision to evidence, change to consequence — is a data problem. The mismatch is not a bug in any individual product. It is a category error at the architectural level, and it cannot be patched.

This section documents the category error, its five failure modes, two signature real-world collapses that followed directly from it, and the particular flavour of innovation legacy vendors have substituted for fixing it.

1.1 The core trap — process over data

Enterprise software platforms — SAP Signavio and S/4HANA are the canonical examples, but the pattern is everywhere — push a worldview that can be summarised in a single sentence: “If you model and optimise processes, the system will work.” Business process modelling notation, process mining, workflow orchestration, approval chains, status transitions, RACI matrices — all of this apparatus is the pursuit of that single proposition.

The proposition is false. Processes are variable, context-dependent, and often wrong or incomplete. Data is the source of truth. A real engineering programme does not follow the idealised process on day 37; it follows a different path because the supplier is late, the regulator asked a new question, the site access window shifted, or the component turned out to fail a qualification test the process diagram did not anticipate. The data reflects what happened. The process diagram reflects what someone hoped would happen.

The failure mode that follows from the process-first worldview is predictable:

1. Consultants map the idealised processes.
2. The system is forced to match those processes.
3. Reality does not match either.
4. Users build spreadsheets, shared drives, and shadow tools to get the work done.
5. The system becomes a rigid representation of an idealised business that does not exist — an expensive fiction running alongside the real business.

The more rigid the process enforcement, the more work is pushed out of the system and into the shadow ecosystem. The data that matters — the data that could close the digital thread — is the data in the shadow ecosystem, not the data in the system of record. The system of record is, in the most literal sense, a record of the process the organisation wished it had run.

1.2 Business objects — the silent killer

The second failure mode is the one that does the most damage and gets the least attention. Legacy ERPs are built out of business objects. SAP’s Material, Oracle’s Item Master, Siemens Teamcenter’s Item Revision, Dassault ENOVIA’s CAD Document — these are the atoms of the platform. Every customer interacts with them. Every integration reads and writes them. Every customisation extends them. They sound innocuous. They are the root cause of more failed transformations than any other single factor.

Business objects fail in five specific, structural ways.

They collapse multiple concepts into one

SAP’s Material is the canonical example. It is, simultaneously, a product (a thing the business sells), an inventory item (a thing in a warehouse at a location), an accounting entity (a thing with cost, valuation, and ledger impact), and a planning record (a thing with MRP horizons and safety stock). It is none of these things cleanly. When the accountant needs to change a valuation rule, they end up editing fields that the inventory clerk needs to stay stable. When the inventory clerk needs to add a new storage condition, they end up editing fields that the planner needs to stay stable. When the planner needs to change a planning horizon, they end up editing fields the accountant needs to stay stable. The object cannot represent any of its constituent concepts well, because it is representing all of them badly.

They encode process assumptions

The fields and statuses of a business object are not neutral descriptions of the data. They are prescriptions about how the business should operate. A Material cannot move from Created to In Stock without passing through Released to Procurement — not because the real world requires that step, but because the vendor’s implicit process model requires it. The business object is a workflow in disguise. Every field is a process checkpoint. Every status is a choke point. Every transition is a rule the real business will eventually have to break.

They are not composable

You cannot take SAP’s Material, combine it with Oracle’s Service Record, and get a clean integrated object. You cannot extend a Teamcenter Item Revision to carry the fields a simulation engineer needs without breaking the CAD author’s workflow. You cannot split a Dassault Document into its analytical and its procurement facets because the document is one atomic row. The business object is a monolith. Composition is performed by bolt-on middleware that inherits all the monolith’s problems and adds network latency on top.

They force customisation

Because the vendor’s business object never matches the real business, every deployment requires customisation. Fields are added. Statuses are overridden. Workflow logic is extended. Custom tables are bolted on. Each customisation is a local solution to a universal problem, and each one makes the system harder to upgrade, harder to support, and harder to audit. Customisation is not optional. It is the inevitable symptom of modelling failure.

They destroy query-ability

The final consequence is the one that kills the digital thread outright. Because a single business object collapses multiple concepts, encodes process assumptions, cannot compose, and has been customised locally, the data inside it is fragmented, overloaded, and context-free. Answering a simple question — “which decisions depended on this supplier’s technical compliance statement?” — requires massive joins across tables whose foreign keys were never designed for that traversal, custom SQL that only one consultant understands, and assumptions about which fields actually contain the information you think they contain. Most of the time the answer is “we cannot tell”, and the programme moves on with less confidence than it should have.

Business objects are not “business-friendly”. They are vendor abstractions that obscure reality in the name of a process model that never existed.

1.3 Workflow engines — the enforcement layer

The third failure mode is the one that sits on top of business objects and makes them feel inescapable. Legacy stacks model every business action as a workflow: a state transition, an approval chain, a status update gate. The workflow engine is sold as the thing that enforces governance and ensures consistency. In practice it enforces rigidity and ensures that exceptions — which in engineering are the norm, not the exception — cannot be handled inside the system.

The life cycle of a workflow-engine deployment follows a predictable arc:

1. Happy path. The workflow is designed around the idealised process. It works for the first quarter. Management celebrates.
2. First real exception. A supplier ships early. The workflow refuses to accept goods that are not yet released to procurement. Somebody emails the goods receipt to a colleague who manually reconciles it in the evening.
3. Workaround compounds. The email workflow becomes routine. A shared drive accumulates the paperwork. A spreadsheet tracks the reconciliations. A shadow system is born.
4. Divergence. The system of record and the shadow system diverge. Neither is trustworthy on its own. Audits require both.
5. Collapse or customisation. Either the workflow is torn out and replaced with a custom one (that will itself collapse on the next exception), or the organisation accepts permanent dependence on the shadow ecosystem.

At every stage the workflow engine is the thing blocking the work. Users hate it. Managers defend it. Auditors fear it. And none of the effort put into it produces data that closes the digital thread — because the data that closes the digital thread is in the shadow ecosystem, outside the workflow.

1.4 Captive consulting as a business model

The fourth failure mode is the one that explains why none of this gets fixed. Legacy vendors do not sell software. They sell software plus years of consulting to make the software usable. The consulting is not an accident of complexity; it is the business model.

Three structural properties of legacy stacks make captive consulting inevitable:

• Complex configuration — thousands of configuration parameters, most undocumented, most interacting with each other in non-obvious ways, most only understood by a small number of certified consultants whose certification fees the vendor also collects.
• Proprietary tooling — extension frameworks, transformation languages, workflow editors, and customisation studios that only work with the vendor’s stack and require expensive training to use at all.
• Opaque data models — schemas that are published but not comprehensible, documentation that describes individual tables but not their relationships, and extension points that require insider knowledge to use safely.

The result is a customer who cannot leave. The customisation layer is specific to the deployment, owned by the SI, and not portable. The data model is documented only at the level each consultant has reason to care about. Upgrades are avoided because upgrades break the customisations. Replacements are avoided because the replacement would start from zero. The customer’s investment is not in working software — it is in the accreted institutional knowledge of the consultants, and the consultants belong to the SI, not to the customer.

Complexity, in this architecture, is not accidental. It is economically reinforced. Every additional knob, every additional workflow, every additional business object field is a reason to keep the consultants on the premises. Simplification is against the interests of everyone on the vendor side of the table. That is why legacy stacks never get simpler.

1.5 Signature failures

The five failure modes compose, and when they compose on a large enough programme, they produce signature failures that become case studies for a generation. Two recent examples illustrate how the architecture-level category error translates into concrete human and financial damage.

Birmingham City Council — Oracle HR/payroll transformation

Birmingham City Council, the largest local authority in the United Kingdom, attempted to replace its HR and payroll system with an Oracle ERP-based transformation. The programme ran multi-year, multi-hundred-million over budget, and produced payroll errors and equal-pay liabilities so severe that the council issued a Section 114 notice — the UK local-government equivalent of declaring bankruptcy. The root causes were exactly the five failure modes described above: over-customisation to force a vendor business object to fit a real organisation, process assumptions baked into the system that did not match actual pay practices, workflow engines that could not handle the exceptions real payroll generates, and SI-dependent knowledge that the council could not internalise. The programme was an architectural category error executed at scale, and the bill arrived in the form of a financial crisis contributing to the effective bankruptcy of a city.

Royal Australian Navy — Super Seasprite (SH-2G(A)) programme

Project Air 87 / SEA 1411 — the Royal Australian Navy’s Super Seasprite programme — ran from 1997 to 2008 and delivered zero operational helicopters at a cost to the Australian taxpayer of approximately A$1.4 billion. The intent was to refurbish eleven ex-US Navy SH-2F airframes and integrate a new avionics suite, the Penguin anti-ship missile, and a networked mission system, to operate from the RAN’s Anzac-class frigates. The contract was signed with Kaman Aerospace. The programme was cancelled by the Minister for Defence in March 2008, eleven years later, with none of the aircraft cleared for unrestricted operational flight. The airframes were eventually sold back for a fraction of their cost.

Multiple reviews — including the Australian National Audit Office’s Management of the Super Seasprite report — documented the root causes. The summary is that the programme was scoped as a process-first systems integration exercise: take an existing airframe (the “reused component”), bolt on a new avionics suite (the “new requirement”), certify the result, and deliver. The process model assumed the pieces would compose cleanly. They did not. The Integrated Tactical Avionics System never reached a stable configuration. Interface control documents between the airframe, the avionics, the weapons, and the flight-control software drifted continuously. Airworthiness certification authorities repeatedly rejected configurations that the vendor believed were complete. Requirements were recorded inconsistently across multiple vendor and government systems, each with its own business-object model, none of which could answer the question “which requirements are currently satisfied, by which evidence, at which airframe configuration?”

The architectural failure is the same pattern as Birmingham, in a different uniform. A process was modelled at contract-award time — integrate avionics with airframe, certify, deliver. The data required to close that process never existed in a form the process engine could consume. Interface definitions lived in vendor-specific tools; qualification test results lived in another set of tools; airworthiness authority positions lived in correspondence; configuration state lived in spreadsheets; the audit trail for which requirement depended on which test on which configuration was reconstructed, after the fact, in each progress review. When reality produced exceptions — and it produced hundreds — there was no structural mechanism to capture the exception, propagate it, and re-close the thread. The programme burned A$1.4 billion and eleven years trying to force a process model to absorb a complexity it was never designed to carry, while the data that would have shown the programme was unrecoverable was scattered across incompatible systems nobody could query.

The United Kingdom’s equivalent cases are the Nimrod MRA4 maritime patrol programme (£3.5 billion, cancelled 2010, zero operational aircraft) and parts of the UK Ministry of Defence’s earlier DII (Defence Information Infrastructure) programme; the US equivalent is the A-12 Avenger II naval strike aircraft (cancelled 1991 with multi-billion-dollar write-offs) and the KC-46 Pegasus tanker’s ongoing boom-system integration saga. Every one of them is the same architectural category error: a process-first integration model that assumed the data would compose cleanly, confronted by a reality in which the data was trapped inside incompatible business objects, opaque supplier tools, and workflow engines that could not represent the exceptions the real programme was throwing off.

Both failures are usually framed as management, political, or contracting failures. They were also architectural failures. A system built around data rather than process, with explicit provenance, typed schemas, and immutable event logs, could not have produced either outcome — because the divergence between the contracted process and the real-world evidence would have been visible in the data on the day the first interface drift occurred, and the audit trail would have made the unrecoverability of the programme obvious years before A$1.4 billion was spent on it.

1.6 Innovation that isn’t

Legacy vendors do, in fairness, innovate. They spend billions of dollars annually on R&D. But they innovate in the wrong places. The list of things SAP, Oracle, Dassault, and Siemens have invested heavily in over the last decade is long and impressive:

• Proprietary databases (HANA).
• Platform ecosystems (BTP, OCI, 3DEXPERIENCE, Xcelerator).
• Low-code / no-code tooling.
• Process mining (Signavio).
• Workflow orchestration engines.
• AI copilots and chat interfaces layered over existing business objects.
• Extension frameworks, marketplace apps, and integration middleware.

Every one of these investments is in the lock-in and packaging layer, not in the data model underneath. None of them fix the five failure modes described above. None of them make business objects composable, make workflows flexible, make data query-able across domains, or reduce the need for captive consulting. In most cases they make all of those problems worse, because every new layer adds new complexity on top of the old complexity without retiring any of it.

What legacy vendors do not innovate in is the list of things that would actually make engineering enterprise software work:

• Clean, composable data models.
• Native query-ability across the full lifecycle.
• Interoperability without middleware.
• Simplicity as a first-class design constraint.
• Provenance as a structural property of every field.
• Audit trails that are immutable by construction.
• Event-driven aggregation that makes the digital thread automatic.

These are all architectural decisions that have to be made at the kernel, on day one. They cannot be bolted on. They cannot be retrofitted. They cannot be bought as a module. Legacy vendors are not going to make them because making them would require rebuilding from zero and abandoning the customisation-and-consulting revenue stream that keeps the lights on.

1.7 The philosophical failure

Underneath the five failure modes, the signature collapses, and the misallocated innovation budgets is a single philosophical error. Legacy enterprise systems assume that business can be standardised and encoded upfront — that a competent consultant can sit down with a whiteboard, map the organisation’s processes, encode them into a platform, and produce a working system.

This assumption is wrong. Business is dynamic. It responds to exceptions, to suppliers, to regulators, to markets, to failures, to discoveries, to changes of mind. Any system that encodes a fixed model of the business at configuration time is a system that will start drifting from reality on day one and will never catch up. The only stable ground underneath a changing business is the data itself, with relationships, provenance, and history. Build on that, and the system follows reality. Build on a process diagram, and reality forks away from the system.

That is the philosophical failure Clarity was designed to fix. The next section describes how.

Section 2 — Clarity’s event-driven kernel

Clarity’s architecture starts from an inversion. Instead of starting with a workflow engine and adding data as an afterthought, it starts with an immutable data primitive and makes every other behaviour a consequence of events on that primitive. Workflow is a view over the data, not a cage around it. Business objects do not exist — there are typed entities with explicit relationships, and each one lives where it belongs in the Lx hierarchy. Aggregation happens automatically, driven by events, with no user action required.

This section describes the primitives, how they compose, and why the digital thread emerges from them as an architectural property rather than a feature.

2.1 Immutable JSON as the kernel primitive

Every write in Clarity produces an immutable JSON file in tenant-isolated S3. Not a row update in a relational table. Not a field mutation in a business object. A new file, at a deterministic path, with a new version, written once and never modified in place.

The path structure is canonical and layered:

projects/{tenantId}/{portfolioId}/{productId}/L0/needs.json
projects/{tenantId}/{portfolioId}/{productId}/L0/invariants.json
projects/{tenantId}/{portfolioId}/{productId}/L1/boundary.json
projects/{tenantId}/{portfolioId}/{productId}/L2/option-sets/{optionSetId}.json
projects/{tenantId}/{portfolioId}/{productId}/L3/scenarios/{scenarioId}.json
projects/{tenantId}/{portfolioId}/{productId}/L3/analyses/{analysisId}.json
projects/{tenantId}/{portfolioId}/{productId}/L4/change-records/{crId}.json
projects/{tenantId}/{portfolioId}/{productId}/L5/decisions/{decisionId}.json
projects/{tenantId}/{portfolioId}/{productId}/library.json

Several properties follow automatically from this choice, without any additional design work:

• Audit by construction. The history of a programme is the history of its files in S3. Nothing is ever destructively overwritten in place — every mutation produces a new version, attributable, timestamped, and recoverable.
• Tenant isolation enforced by the path. There is no cross-tenant SQL join because there are no tables. Every Lambda validates tenant membership on read; there is no path by which one tenant’s data can accidentally leak into another’s query.
• Multi-region, multi-environment deployment by default. An S3 path is portable; a relational schema is not. The same code runs in a commercial SaaS region, a sovereign region, and an air-gapped classified enclave without modification.
• Encryption at rest, per tenant, with customer-managed keys. KMS aliases resolve per tenant, so one tenant’s data is encrypted with a key no other tenant — including Clarity operators — can decrypt.
• Schema evolution without downtime. Adding a new field to a JSON document does not require a table migration. Old documents remain valid; new documents carry the new field; aggregators tolerate both.

The immutability is the critical word. In a legacy ERP, a Material record is updated in place, losing history. In Clarity, the equivalent update produces a new file with a new version, and the old file remains available for audit, for rollback, and for DeZolve trust-vector traversal. The past is a first-class citizen of the architecture.

2.2 EventBridge debounce — the aggregation pipeline

Immutable JSON is the atom. EventBridge is the nucleus. Every write in Clarity emits an event — directly from S3 object-create notifications, or indirectly from Lambda triggers — and the event is routed by EventBridge to the appropriate aggregation Lambda.

The aggregation pipeline has a specific architectural shape that distinguishes it from both legacy workflow engines and naïve event-driven stacks: it is debounced.

A single user action in Clarity often produces a burst of writes. Importing a requirements document produces hundreds of L0 entity writes in seconds. Running an L3 analysis produces dozens of scenario outcomes, Monte Carlo samples, and Pareto evaluations in quick succession. A batched Bedrock generation call may write thirty entities in the span of two hundred milliseconds. If every individual write triggered a full re-aggregation of the Lx.json file, the system would spend all its time re-aggregating and none of its time responding.

EventBridge debounce solves this. Rather than firing the aggregator on every write, the pipeline waits for a quiet period (a configurable window, typically a few seconds) after the last write before invoking the aggregator exactly once. The aggregator then reads the current state of all constituent files in the layer, produces a new Lx.json document that represents the coherent aggregate, and writes it back to S3. One aggregation per burst. No lost events. No partial aggregates. No workflow state machine.

The shape of the pipeline, for a single Lx layer, is:

┌──────────────────┐   S3 writes (many)     ┌──────────────────────┐
│  Tab / Lambda /  │  ──────────────────▶   │  EventBridge rule    │
│   Import job    │                         │  (per layer, per     │
└──────────────────┘                         │   product)           │
                                             └──────────┬───────────┘
                                                        │ debounced
                                                        ▼
                                             ┌──────────────────────┐
                                             │  Aggregation Lambda  │
                                             │  (reads constituent  │
                                             │   files, writes      │
                                             │   Lx.json)           │
                                             └──────────┬───────────┘
                                                        │
                                                        ▼
                                             ┌──────────────────────┐
                                             │  Lx.json             │
                                             │  (canonical snapshot │
                                             │   consumed by        │
                                             │   chat, reporting,   │
                                             │   downstream layers) │
                                             └──────────────────────┘

Everything downstream of the aggregator reads Lx.json, never the constituent files. Chat reads Lx.json. Reporting reads Lx.json. L3 solvers read Lx.json. The next layer’s generation Lambda reads Lx.json. The aggregator is the single source of truth for what the layer currently says, and EventBridge debounce guarantees that the aggregator runs exactly when it needs to — no more, no less.

2.3 The quiesce pattern — consistency under burst writes

The second architectural defence against burst-write inconsistency is the quiesce pattern. Before any write Lambda mutates an Lx layer, it calls check_quiesce(tenant, env, deployment) against an SSM parameter. If a bulk operation is in progress (an import, a batch generation, a migration), the quiesce check returns busy and the write backs off. If no bulk operation is in flight, the check returns clear and the write proceeds.

This is not a global lock. It is a soft coordination primitive that prevents two independent burst-write jobs from interleaving their aggregations and producing a torn snapshot. It is fail-open — if SSM itself is unavailable, the check returns clear and writes proceed — so that an infrastructure outage cannot block the platform. And it is tenant-scoped, so quiesce on one tenant does not delay operations on another.

The quiesce pattern is deliberately boring. It does not attempt transactional isolation across Lambdas. It does not try to serialise writes. It does not impose a workflow state machine. It just ensures that burst writes and aggregation windows do not collide catastrophically, and it leaves everything else to the debounce mechanism above.

2.4 Typed schemas and the Lx world model

Immutable files without schemas would be a swamp. Clarity’s schemas are explicit, typed, versioned, and authored alongside the code that reads and writes them.

Every Lx layer has:

• A list of canonical entity types with required and optional fields.
• A list of allowed relationship types and their cardinality.
• A list of lifecycle states and their valid transitions.
• A list of overlays (financial, supply chain, regulatory, security, quality, risk, technology readiness, lifecycle, external systems, export control) that can annotate any entity without restructuring the base schema.
• A list of invariants — predicate-level truths that must hold, enforced at three rings (annotation, approval, solver).

The schemas live in data/proprietary/world-model/ and are treated as first-class proprietary IP. They are not generated by a configuration tool; they are the result of twenty years of real-world engineering experience across defence, nuclear, aerospace, health, energy, and advanced manufacturing. They are the world model, and they are what makes Clarity fundamentally different from every stack that lets the customer invent their own schema during implementation.

Because the schemas are explicit, every Lambda can validate its inputs and outputs against them at runtime. Because they are typed, every field carries known semantics that the aggregators, the solvers, the chat layer, and the reporting layer can all rely on. Because they are versioned, schema evolution is a visible, reviewable act — not a silent migration in a vendor tool.

And because they are not business objects, they do not suffer the five pathologies described in Section 1. The Lx world model keeps a product separate from its inventory position, an analysis separate from its decision, a requirement separate from its overlay annotations. Each concept lives where it belongs. Each relationship is explicit. Nothing is collapsed.

2.5 @source provenance — lineage at the field level

The kernel primitive that makes the digital thread possible is not the files, or the events, or the schemas on their own. It is the @source provenance record attached to every field.

Every write to any Lx entity carries a thirteen-field @source record that captures:

• Lineage — was this field written by a human, by an AI agent, by a deterministic algorithm, or imported from an external source?
• Timestamp — when was the write committed?
• Author — which user, service account, or Lambda performed the write?
• Confidence — what confidence did the writer attach (if any)?
• Evidence references — which documents, upstream entities, or external sources did this write depend on?
• Tool attribution — which Lambda, model, or script produced it?
• Validation status — has a human verified it? Has a downstream check approved it?
• Supersession — what previous write, if any, did this one replace?
• Export-control status — what classification does this field carry?
• Design-authority provenance — which engineering authority signed off on it?
• Comments and decisions — what annotations were attached at the point of write?
• KG validation — has the knowledge graph been cross-referenced?
• Crowd signals — has any aggregated review feedback been attached?

The provenance record is not an audit log sitting in a separate table. It is a structural property of the write itself. You cannot write a field in Clarity without a provenance record, because the schema will reject it. You cannot alter a field’s provenance after the fact, because writes are immutable — altering provenance produces a new version with new provenance, and the old version remains. The history of every field is the history of the provenance records attached to it.

The digital thread is the transitive closure of these provenance records. A decision at L5 links to its analyses at L3, which link to their option sets at L2, which link to their requirements at L0, which link to the source documents they were extracted from, which link to the authorities that issued those documents, which link to the legal or contractual basis for those authorities. Every hop is a structural link in the JSON, not a join across tables, not a manual cross-reference in a spreadsheet, not a note in someone’s head. The thread is the data. It cannot be fabricated after the fact, and it cannot be lost, because every write carries its own hop.

2.6 Invariants and three-ring enforcement

The schema and the provenance model would still admit malformed data if nothing enforced semantic constraints. Clarity’s enforcement layer is the three-ring invariant model.

Ring 1 — Annotation at generation time

Every generation Lambda — human-initiated or AI-initiated — annotates its output with an invariantStatus header that lists any invariant violations. Violations are not hidden. They surface in the UI as banners, and they flow through the aggregation pipeline so that downstream consumers see them.

Ring 2 — Blocking at change-approval time

The change-approval pipeline refuses to promote any change that would leave an active invariant violated. A pending change with an unresolved violation returns HTTP 409 and cannot progress to a baseline. The invariant is not advisory at this ring — it is a structural gate.

Ring 3 — Blocking at solver time

The L3 analysis solver pipeline refuses to run if pre-conditions are violated, and annotates post-solve outputs with any invariants violated during the run. A failed invariant aborts the solver with HTTP 422. No analysis result is produced on top of invalid data.

Invariants are not rules in the old expert-system sense of the word. They are predicates attached to the L0 intent layer, authored by engineers, versioned, and provenance-carrying. An invariant might say “every safety-critical requirement must have an approved mitigation”, or “every option must have at least one parameter with a verified source”, or “no baseline may be promoted while a blocking change is pending”. The predicates are domain-specific; the enforcement mechanism is universal.

2.7 The Lambda shape — stateless, event-driven, Lx-repository-backed

Every backend function in Clarity is a stateless Lambda that fits one of a small number of canonical shapes:

• A write Lambda accepts a request, validates it, performs the quiesce check, computes provenance, runs Ring 1 invariant annotation, writes an immutable JSON file, and returns.
• An aggregation Lambda is triggered by EventBridge, reads the constituent files of a layer, computes the canonical Lx.json, and writes it back.
• A solver Lambda reads Lx.json, runs the analysis, performs Ring 3 invariant checks, annotates outputs, and writes the result.
• An AI generation Lambda assembles world-model-bounded RAG context, calls a Bedrock model via the LLMClient abstraction, validates and sanitises the response, annotates provenance, and writes the result.
• A read Lambda reads Lx.json (never the constituent files), applies tenant and RBAC filtering, and returns.

There are no long-running processes. There is no workflow state machine. There is no central orchestrator. The architecture is a set of narrow, focused, stateless functions connected by immutable data and EventBridge events. Adding capability is a matter of adding another Lambda and wiring it to an event. Removing capability is a matter of removing the wiring. Upgrading capability is a matter of deploying a new Lambda version. No knock-on effects. No transitive customisation rework. No captive consulting.

2.8 Workflow as a view, not a cage

Because Clarity does not have a workflow engine, it handles workflow differently. Workflow is a view over the data, not a cage around it.

A user’s “approve this change” button is a Lambda that writes a new immutable change record with the user’s approval stamped in the provenance, and emits an event that re-aggregates the layer. There is no state machine that refuses to accept the approval because the change is in the wrong state — if the approval is semantically invalid, Ring 2 will block it; if it is semantically valid, it is accepted and the data moves forward. The workflow exists, but it exists as a pattern that the aggregator can recognise and display, not as a gate that blocks writes.

This is the critical inversion relative to legacy stacks. In a legacy ERP, the workflow is the system, and the data is what the workflow leaves behind. In Clarity, the data is the system, and the workflow is what the data looks like when you view it through a particular lens. When reality breaks the lens, the lens changes — the data is untouched. When a new regulatory requirement adds a new approval step, the new step is a new Lambda and a new provenance field, not a reconfiguration of a workflow engine that will fight the change for six months.

Section 3 — Why event-driven-by-kernel wins

Every property of the Clarity architecture described in Section 2 exists for a reason, and every reason cashes out in an outcome that legacy stacks structurally cannot produce. This section walks through those outcomes, explains why they cannot be retrofitted into a process-first stack, and summarises the operational consequences.

3.1 Query-ability — the digital thread is always on

Because the Lx layers are immutable JSON files, because every field carries provenance, and because @source records form a transitive closure from decision to evidence, any question that traverses the digital thread is answerable by reading the data. There is no custom SQL. There are no massive joins across foreign keys that were never designed for the traversal. There is no business-object decomposition to get from Material to actual product.

Sample questions that a Clarity deployment can answer directly, with no consulting engagement required:

• “Which L5 decisions depended on the test results from this supplier’s qualification report?”
• “Which requirements were superseded between the preliminary design review and the critical design review, and who authorised each supersession?”
• “Which options in the final Pareto set carried AI-generated parameters that were never reviewed by a human?”
• “Which invariants were violated during the last solver run, and which decisions depended on scenarios that produced Ring 3 violations?”
• “Which fields across the whole programme were last written by an AI agent more than thirty days ago and have not been human-verified?”

Every one of those questions is a traversal of the @source graph. Every one of them is answerable in seconds. Every one of them would require a multi-week consulting engagement against a legacy ERP — and in many cases would not be answerable at all, because the data required is in the shadow ecosystem.

3.2 Audit-ability — the past is a first-class citizen

Legacy audit trails are reconstructions after the fact: someone goes into the database, pulls out tables, tries to correlate timestamps, and builds a narrative that approximates what happened. The approximation is always lossy. Fields that were overwritten in place are gone. Provenance that was not captured structurally cannot be invented. Workflows that were bypassed via the shadow ecosystem leave no trace.

Clarity audit trails are the primary data, not a reconstruction. The history of a field is the sequence of immutable writes that produced it. The history of a decision is the transitive closure of provenance records that led to it. The history of an approval is the provenance record attached to the approval itself. There is nothing to reconstruct, because nothing was ever lost.

The consequence for regulated industries — defence, nuclear, aerospace, health, energy — is transformational. An audit that takes three months to prepare against a legacy ERP takes minutes to run against a Clarity deployment. And the audit result is verifiable, because the provenance records are immutable and the version history is preserved in S3 by construction.

3.3 Change-ability — the platform follows reality

The process-first legacy stack cannot absorb change. Every change to the real business breaks a workflow, invalidates a customisation, or requires a consultant to reconfigure a business object. Clarity’s event-driven kernel, by contrast, absorbs change as a matter of course.

• A new regulatory requirement becomes a new invariant in the L0 intent layer. The aggregation pipeline picks it up automatically. Every affected entity is re-annotated with its invariant status. Nothing else changes.
• A new stakeholder concern becomes a new entry in the L0 needs list. It propagates through L1, L2, L3, and L5 automatically via the @source links that already exist.
• A new supplier becomes a new L6 acquisition mode entry. The existing option sets at L2 automatically gain access to it via the library overlay. No reconfiguration required.
• A new analysis type becomes a new L3 solver Lambda. It reads the existing Lx.json. It writes its results into the existing schema. Every existing decision and scenario gains the new analysis capability without any migration.
• A new AI model becomes a new entry in the LLMClient group registry, resolved via a single SSM parameter. Every Lambda that calls the old model automatically uses the new one. No code change.

Every one of these changes would be a multi-month project against a legacy stack. In Clarity, they are Lambda deployments and SSM parameter updates. The cost of change is proportional to the semantic weight of the change, not to the accumulated complexity of the platform.

3.4 Interoperability — integration is subtraction, not addition

Legacy stacks treat integration as something you add: integration middleware, ESBs, iPaaS platforms, custom adaptors. Every integration is a new layer, a new vendor, a new failure mode, and a new captive consulting engagement.

Clarity treats integration as something that happens for free, because the data is already typed JSON in a predictable S3 path. An external system that needs to read Clarity data reads the S3 path directly, with appropriate IAM. An external system that needs to write data writes a JSON file that conforms to the schema, and the aggregation pipeline picks it up. An external system that needs to subscribe to changes subscribes to the EventBridge bus.

There is no integration product. There is no middleware layer. There is no iPaaS. The kernel is the integration surface. And because the kernel is event-driven, any integration is automatically event-driven too — which means downstream systems react to upstream changes in seconds, not in nightly batch jobs.

3.5 Sovereignty — the same code runs everywhere

A legacy ERP is deeply coupled to its deployment environment. Moving from on-premises to cloud is a multi-year transformation. Moving from cloud to air-gapped classified is, in many cases, impossible — the vendor does not ship a version that runs in a classified enclave, and even if they did, the customisations would not port.

Clarity is deployable, unchanged, from commercial SaaS to air-gapped classified. The kernel is a set of Lambdas, an S3 bucket structure, an EventBridge configuration, and a proprietary data payload (world model, prompt corpus, lessons-learnt knowledge graph, DeZolve taxonomy). All of those travel with the deployment. Nothing phones home. Nothing depends on the public internet. The customer’s security authority approves the deployment once, and the platform runs.

This is not a sovereignty feature. It is a sovereignty property that falls out of the event-driven kernel architecture. A stack that depends on a central orchestrator, a proprietary database, or an internet-resident AI service cannot go to air-gap. A stack made of stateless Lambdas reading and writing immutable JSON can go anywhere a cloud runtime is available.

3.6 Why it cannot be retrofitted

The critical point — and the reason why legacy vendors cannot catch up by bolting on an event bus or buying a startup — is that every property in this section depends on decisions made at the kernel. The immutability of the writes. The debounce of the aggregation pipeline. The typed, explicit schemas. The @source provenance on every field. The absence of a workflow engine. The absence of business objects. These are not features that can be added. They are the shape of the system, and the shape determines what the system can do.

A legacy ERP cannot become immutable without losing its update-in-place optimisations that the whole product is built around. A legacy PLM cannot add @source provenance to every field without invalidating every customisation that depends on in-place mutation. A legacy workflow engine cannot become a “view over the data” without abandoning the state machine that is the product. A legacy business object cannot be decomposed into typed entities without breaking every integration that was written against the business object.

The retrofit is architecturally impossible. The vendor would have to throw away the product and start over — which, as Section 1 explained, is against the business model that keeps them alive. Every bolt-on event bus, every AI copilot, every low-code extension layer, every process-mining tool is another coat of paint on a house whose foundations are the wrong shape.

3.7 Economic outcomes — the numbers that follow from the architecture

The architectural choices in Sections 2 and 3 translate into a specific economic profile that legacy stacks structurally cannot match.

Every row in that table is a direct consequence of a decision made in Section 2. Immutable JSON eliminates the audit reconstruction cost. Stateless Lambdas eliminate the operational cost. Event-driven aggregation eliminates the change propagation cost. The absence of business objects eliminates the upgrade cost. The open S3 storage eliminates the replacement cost. None of them were separately designed. They all follow from the kernel.

3.8 A note on AI

One final point about the architecture: AI belongs inside the kernel’s event loop, not on top of it. Clarity’s AI agents (see 325 AI Agents, Bounded by DeZolve) are Lambdas triggered by events, constrained by the Lx world model, bounded by the LLKG, and subject to the same three rings of invariants as any human write. They produce immutable JSON with full @source provenance marking the lineage as ai. They participate in the aggregation pipeline. They are audit-able by construction.

An AI agent bolted on top of a legacy ERP cannot be any of those things. It cannot participate in an aggregation pipeline that does not exist. It cannot carry provenance that the data model does not structurally support. It cannot be bounded by invariants that are not enforced at the kernel. It can only produce text into a chat window or, at best, write mutations into a business object that loses their provenance the moment the object is updated in place by the next user.

The AI layer is only as good as the kernel underneath it. A kernel-level event-driven architecture produces bounded, audit-able, provenance-carrying AI. A process-first workflow-driven architecture produces a chatbot sitting on a filing cabinet — which is the subject of a different whitepaper and a different category of failure.

Conclusion — the loop closes at the kernel

The digital thread is not a feature, a module, a product, or a marketing slogan. It is an architectural property that emerges when every write is immutable, every aggregation is event-driven, every schema is typed, every field carries provenance, and every invariant is enforced at the kernel. Take any one of those away and the thread breaks. Take all of them away — which is what every legacy enterprise stack has done — and the thread was never possible in the first place.

Legacy vendors will continue to sell the bargain described at the start of this paper: buy our platform, buy our consultants, map your processes, and in three years you will have a working system. The bargain will continue to produce signature failures, over-budget transformations, and programmes that deliver less capability than the legacy they replaced. Not because any individual vendor is incompetent — many of their engineers are excellent — but because the category error at the root of the architecture cannot be fixed without rebuilding from zero, and the business model that funds the engineering does not allow that rebuild.

Clarity is the rebuild. Event-driven at the kernel. Immutable at the write. Typed at the schema. Provenance-carrying at the field. Invariant-enforced at three rings. Stateless at the Lambda. Workflow-as-view, not workflow-as-cage. Built in hours for SMBs. Deployable to air-gapped classified without changing a line of code. Auditable in minutes. Query-able across the full lifecycle. The digital thread closes because, at the kernel, it was never open.

That is what event-driven by kernel, not by feature means. It is not a slogan. It is the only architectural shape that makes the digital thread possible, and it is the one every regulated engineering programme of the next twenty years is going to need.