Architecting the Connective Substrate
Digital Continuity as the Living Thread of the System Lifecycle
James Wolstencroft · June 2026
The Tekmerium · Paper III of VI
Abstract
A digital-engineering programme can hold flawless models, a rigorous evaluation method, and disciplined governance, and still fail because none of those assets is worth more than the connections between them. This paper specifies those connections. Digital Continuity is the property by which a system’s meaning, traceability and integrity survive as it crosses organisational boundaries and decades of service. It argues that continuity comes not from central storage but from authoritative addressability across distributed systems of record; that baselines must remain coherent across a sustainment tail that dwarfs development; and that the same federated structure that lets a supplier retain custody of a black-box model also delivers the openness that modular-open-systems policy demands. The connective fabric is treated here as a static network; the engine that acts on it is deferred to its companion.
1. The value is in the connections
A complex system is not its artefacts, but the web of relationships among them, and that web is the first thing conventional practice loses.
Treating a system only as requirements, geometry, simulations, and test data can be tempting, but the connections between these elements matter most. The traditional Filing Cabinet Model stores artefacts in isolated repositories that cannot link, update, or recognise each other (The Continuum, Ch. 5). Digital Continuity keeps meaning, traceability and integrity alive across the lifecycle, information interconnected rather than merely stored. This paper carries the static web itself; the engine that acts on it, the Digital Backbone, is the business of ‘Engineering the Decision Trail’.
2. The Filing Cabinet Model and the Zombie Link
Textual cross-references rot: Continuity’s issue is linking, not storage.
When a requirement lives in one tool, the geometry in another, and the join between them is a phrase like “see §4.2 of the aerodynamics report”, the reference breaks on re-versioning and the whole survives only in a few chief engineers’ heads. This sharpens into the Zombie Link: a trace that ties a requirement to a component captures the what but never the why, so when “300 kph” becomes “350 kph” the link joins a live requirement to a mechanically intact design choice with its rationale rotted away. Organisations accumulate terabytes of models yet remain information-poor because the reasoning connecting them to the problem is missing.
3. The Single Source of Addressability
Keep the data where it is and focus on connecting it: the key is addressability.
Consolidating everything into a single monolithic warehouse is ineffective in a federated supply chain: a supplier’s sensor model lives on its own server, and pulling everything into a central store would demand translation scripts that break with every schema change, leaving it to drift from the live data. The solution isn’t relocating the data but making it addressable, similar to a library catalogue that logs each artefact’s identity, version, and access method, while the artefact remains in its original system. Call it the Authoritative Source of Truth (ASoT): nothing is copied, and each artefact is queried live in place, through whatever open standard the parties agree on, such as OSLC. The ASoT is, in effect, a federated knowledge graph: its value lies in the typed links between its nodes, turning many silos into one queryable whole.
4. Continuity that outlives the programme
Architecture does not end at the final design review; continuity is won or lost across the decades-long sustainment tail.
Against the Lifecycle Fallacy stands the Living Blueprint (The Continuum, Ch. 19): an authoritative source maintained from concept to disposal, on the principle that architectural decisions shape something like 80 per cent of a system’s lifetime cost. A living baseline accumulates Model Debt, including refuted branches, invalidated simulations, and requirements that reference retired components. The ’Archive As You Go’ discipline addresses this by locking and tagging each refuted branch along with its evidence, rather than deleting it. The active model stays current, the history of why stays queryable, and nothing that was learned gets thrown away. Sustainment Views then record repair-time targets, spare codes, upgrade slots and end-of-life sequences as connected data, making long-horizon trade-offs visible with their rationale intact.
5. The shape of the network
The network has no centre; the handshake carries proof across every seam.
Each contributor keeps its own store, and the stores interoperate through agreed standards and a handshake in which systems exchange certified data rather than paper, with integrity and provenance carried by the connective layer itself, such as metadata, hash-based verification, and/or identity certificates. Anything crossing a boundary arrives with its version attested (The Continuum, Ch. 22). This paper treats federation strictly as structure: the topology of nodes, links and handshake terms that keep heterogeneous systems-of-systems continuous across contractor boundaries. The intelligence that queries the federation and weighs its evidence belongs to the Digital Backbone of ’Engineering the Decision Trail’; the contribution here is the fabric on which any such engine must run.
6. Closing the loop without breaking the link
The durable virtual-to-physical link that keeps every later judgement honest.
The traditional “V” shape of design, build and test evolves into an Infinity Loop where design, build, deploy, and operate are interconnected in a continuous cycle. This cycle is characterised by a persistent connection between a physical asset and its digital twin, serving as the operational link rather than just an evaluation model. Data such as operational logs, environment maps, and maintenance records flow back to update the twin, ensuring it reflects the asset’s current wear and tear rather than its original specifications. The twin is the maintained channel from physical state to virtual representation; what to decide on the strength of that incoming data is ‘Engineering the Decision Trail’ business. Without the link, every later judgement leans on a picture that is quietly ceasing to be true.
7. Open at the seams, closed at the core
Openness lives in the link, not the artefact; sealed models still fit open systems.
Protecting a proprietary model often creates vendor lock-in, but a modular, open-systems approach aims to prevent it. A choice as small as ‘buying the robot’ can lock a programme in before anyone has considered the alternatives (The Continuum, Ch. 3). The connective foundation resolves this contradiction: since the ASoT links rather than copies, the provider retains full control of its black-box model in its System of Record, while the integrator accesses its behaviour and interfaces through OSLC in an authoritative and standards-based way. Openness shifts from the artefact itself to the interface and the link. This allows the node to remain sealed while the connection remains open and certified, enabling simultaneous protection of IP and modular openness.
8. Limitations and open problems
The substrate is necessary but not sufficient, and it leans on a trust infrastructure not yet standardised.
Federation assumes cross-vendor metadata schemas, identity verification, and signed-artefact governance within specific roles, but standardising these across a coalition remains unfinished work. The figures quoted, the ~80 per cent lifetime-cost estimate among them, are illustrative rather than measured on real programmes. Even with a fully connected graph, an engine is needed to traverse and resolve it; this engine and its audit trail are discussed in the companion paper, ‘Engineering the Decision Trail’. This paper’s claim stops at the fabric: the connections exist, and they persist.
References
US Department of Defense, Digital Engineering Strategy, Office of the Deputy Assistant Secretary of Defense for Systems Engineering, 2018.
OASIS, Open Services for Lifecycle Collaboration (OSLC) Core, v3.0.
DoD digital-engineering mandate (policy context for the series).
Modular Open Systems Approach, 10 U.S.C. § 4401 (statutory basis for §7’s anti-lock-in requirement).