Breaking the Reconciliation Trap
Navigating the Friction Between Model-Based Engineering and Document-Centric Governance
James Wolstencroft · June 2026
The Tekmerium · Paper I of VI
Abstract
Engineering organisations juggle a dynamic, model-based world and a fixed, document-centric regime. Reconciling the two levies a synchronisation tax: every change must be re-propagated, re-documented, re-approved. As models evolve, the gap between statements and certifications widens, especially at larger scales.
This paper proposes making the model itself the contract and governing it directly, setting out the disciplines that make this possible:
A single authoritative source of truth.
Dual-speed configuration management.
IP-protecting obfuscation and federation.
A reckoning of the economic liability of unreconciled baselines.
It is the governance premise on which the rest of the series builds.
1. The digital baseline challenge
Static documents can’t govern changing systems, and this deadlock is mutual.
Policy increasingly mandates digital engineering1. Yet procurement still runs on flat PDFs and textual interface documents, essentially a waterfall regime that is a dead end for live models.
If buyers demand strict compliance with legacy baselines, they destroy engineering velocity; if suppliers hand over fully open models to prove compliance, they expose their trade secrets. The way out is model-centric governance: buyer and supplier exchange secure, executable models under five principles:
An authoritative source of truth (the model is the contract),2
Automated traceability,
Continuous configuration management,
Partitioned IP,
Evidence-based trust through milestone assessments rather than point-in-time document reviews.
2. Foundational baselines: the compounding synchronisation tax
Every time a living model is flattened into a static document for a contractual gate, the enterprise pays the synchronisation tax.
In a mature model-based environment, changing a single parameter updates the mass, power, and thermal budgets across interconnected domains. The programmatic gate then asks for a printed snapshot of it. So we extract, we flatten, N dimensions pressed into two, and the flattening strips out exactly what made the model worth building: the semantic relationships, the temporal constraints, the behavioural logic, the cross-domain traceability. What survives is a baseline that was out of date the day it was published.
3. Dual-speed configuration management
Forcing engineering and governance to synchronise leads to configuration drift.
Automated engineering processes can bring a complex landscape to a desired state in minutes; legacy governance responds to each change with a dense Engineering Change Proposal and a Control Board review that can span months. So the enterprise synchronises by hand, and drift is not a risk of that arrangement; it is the arrangement. The customer’s specification and the model’s reality part company quietly, and the divergence surfaces where it always surfaces, in verification, at the worst possible time. Dual-speed configuration management allows each side to maintain its own rhythm: continuous micro-baselines for engineering and formal gates for governance, with automatic bridging rather than manual process.
4. Obfuscation and federated models
A black box in a federated thread can validate a model without revealing it.
Integration requires a high-fidelity digital twin, but an open “white-box” model would expose the supplier’s trade secrets wholesale and conflict with data-rights mandates. The answer is a black-box model that hides the internal mathematics and exposes only permissioned, authenticated access to external behaviour. This allows the “how” to stay private while the “what” is shared. A federated Common Data Environment then links these permissioned models in place, authoritative data referenced rather than copied across organisational boundaries under strict role-based access, so updates propagate without file swaps. The connective architecture beneath that federation is the subject of ‘Architecting the Connective Substrate’.
5. Computing the economic liability
Under fixed-price contracts, a synchronisation tax hits the contractor’s margin.
Where cost-plus terms allow customers to absorb documentation inefficiencies, fixed-price terms pass overruns to the contractor. Three structural drivers erode that margin.
The synchronisation tax (the labour of flattening and re-verifying the model),
The translation defect rate (semantic errors from mapping N-dimensional structure onto flat text, rising sharply with complexity),
The undiscovered rework liability (defect-laden documents become the legal baseline, and hidden defects drive long correction cycles).
The erosion is direct and difficult to recover from. Set against that liability, making the model the contract is not the expensive path but the economical one; the strongest argument for governing the model directly is what it costs not to.
6. The customer-to-supplier feedback loop
Judge maturity from the live model, not periodic document reviews.
Governed against the model, the buyer can simulate the digital twin across many configurations rather than judging maturity from static PDFs. Document-heavy technical reviews give way to ongoing, model-driven assessment: the customer supplies a baseline reference model, the contractor enhances the architecture. Maturity is read as an objective difference, the exact mathematical discrepancy between the twins’ predicted and actual performance, measured in real time.
7. Secure infrastructure
Contracting, workflow and approvals belong inside the toolchain, not beside it.
Static reports must give way to automated infrastructure: contracting, workflow management and legal approvals integrated directly into the digital engineering suite. Where a fixed record is legally required for archiving, push-button document generation produces it as a view-only output of the live model rather than a hand-built artefact. The waterfall alternative is rigid, document-heavy and slow. It destroys flexibility, yields outdated hardware and leaks IP; secure federated models, continuous configuration management and evidence-driven reviews are how buyers and suppliers build the next generation of systems together.
8. Limitations and open problems
The argument is structural, not yet empirical, and it has three dependencies.
It names the synchronisation tax and the cost drivers behind it, but does not measure them; quantifying that liability across real programmes is open work. Three dependencies also temper it:
Tooling (federated environments, clash detection and document generation are uneven in practice).
Governance (the legal standing of a model as the authoritative baseline, rather than the document drawn from it, remains unsettled).
Trust (governing against a black box means accepting outputs one cannot directly inspect).
That last problem, how a hidden model earns the authority to stand as a contract, is taken up in ‘Engineering the Decision Trail’; the supplier relationship it depends on is the subject of the next paper, ‘Securing the Supplier Ecosystem’.
References
DoDI 5000.97, “Digital Engineering” (2023).
Modular Open Systems Approach (MOSA), 10 U.S.C. § 4401.
DoDI 5010.44, “Intellectual Property (IP) Acquisition and Licensing” (2019).
On Digital Twins in Defence: Overview and Applications (2025), arXiv:2508.05717.
DoD Digital Engineering Fundamentals (2022).
Applying Digital Engineering to Defence Acquisitions … MBSE (AFIT Scholar).
Transforming Systems Engineering through Model-Centric Engineering (DTIC).
Wolstencroft, J. (unpublished at the time of writing). The Continuum.