Engineering the Decision Trail

The Continuum as the Engine of Accountable Change and Trust Adjudication

James Wolstencroft · June 2026

The Tekmerium · Paper IV of VI

Abstract

A connected substrate preserves a system’s relationships; it does not, by itself, decide anything or remember why. This paper specifies the apparatus that does. The Continuum is the engine that computes the consequences of change across a model-centric system and preserves an unbroken, accountable record of every decision that change provokes. Building on the connective substrate of its companion paper, it sets out how the Digital Backbone adjudicates trust across federated evidence; how a black-box or learning model gains authority through provenance and probabilistic proof, maintaining it only when monitored for drift; and why the operation-to-design feedback path should be a capture gate instead of a pipe, to ensure the audit trail remains visible where an autonomous system changes most rapidly. It closes by engaging the unsolved problem of mapping these mechanisms onto a recognised verification, validation and accreditation regime.

1. Accountability when the system writes itself

A connected graph is inert until something decides and records why.

Architecting the Connective Substrate’ establishes the fabric and treats it as given here. But connection is only half the problem: something must decide whether a component may be cleared and capture the reason for it. As systems acquire learning components that retrain and drift in the field, that task sharpens, behaviour can change with no human hand on the decision, and an unrecorded change is an unaccountable one. This paper owns what acts on the connections: computation, adjudication, and an audit trail that survives autonomy.

2. The Continuum that computes change

Treat the decision trail not as a record of what was decided but as a machine that computes what a change now implies.

Continuity is the property the substrate delivers; the Continuum is the engine that sustains it, propagating a moved requirement or tightened constraint through to every decision it touches rather than waiting for an engineer to notice (The Continuum, Ch. 5). Its primitive is the Decision Object, a design decision elevated from an undocumented event in someone’s memory to a first-class, addressable object carrying its rationale, alternatives and evidence. Because each decision is linked to the same graph as the requirements it depends on, an upstream change can make every dependent decision potentially stale and surface the consequences for adjudication.

3. How the Digital Backbone brokers trust

The Digital Backbone acts as a trust broker, weighing federated evidence against rules and wrapping probabilistic components in deterministic guardrails.

Rather than a passive store, the Digital Backbone aggregates evidence from independently owned sources and resolves a single answer: a controller is cleared only once it assembles the sensor supplier’s calibration logs, the software house’s unit tests and the lab’s integration results and judges them against the safety requirement (Ch. 22). It also determines how a black-box element behaves by enforcing strict rules (Ch. 17):

  1. A Simplex channel where a high-assurance path can override the AI.

  2. Fallback modes activated when confidence is low.

  3. A sandbox restricting actions to a predefined scope.

A probabilistic output is information to be verified, never a command to be obeyed; the judgement lives in the architecture itself, not in an operator’s unblinking attention.

4. Earning authority

A model gains trust via provenance and probabilistic proof.

Provenance extends the configuration baseline to encompass the entire AI system, including:

  1. The inference engine.

  2. The specific trained-model version.

  3. The training dataset and its lineage.

  4. The data pipelines.

This allows users to trace the reason behind the system’s behaviour back to a particular model version and the influencing data (Ch. 17). Probabilistic verification replaces exhaustive testing with statistical methods based on large-scale simulations. For example, targets like a “99.99% obstacle-detection” rate are set, while a “15% efficiency gain” serves as an illustrative goal rather than an actual result. The principle underneath is simple: every verification result attaches to the Decision Object it supports, so authority always traces to proof.

5. Keeping authority

Authority is transient: a model keeps it only while the monitoring says it may. Trust is a dial, not a certificate.

Performance declines as the environment shifts away from the training data, prompting observers to compare new inputs to the original distribution and monitor error rates continuously; when live data falls outside known parameters, an alert triggers (Ch. 17). The system has two main responses: either retrain the model with new data or automatically reduce trust, using conservative logic or backup sensors until the model is validated again. This is where the engine interacts with the asset: each deployed component maintains a live Decision Object, which the Digital Backbone re-evaluates as new data arrives over the twin coupling. The model stays trustworthy the same way it earned trust in the first place, continuously, or not at all.

6. The capture gate

View the operation-to-design feedback path as a gate, not a pipe; this prevents the audit trail from becoming obscured during rapid system progress.

A learning system self-modifies in the field without human intervention. The risk is not the change itself but the change happening out of the Continuum’s sight, so that the recorded rationale quietly stops describing the thing in the field (Ch. 17). The rule is that every self-initiated change must be recorded as a decision within the Continuum, justified before it is trusted. This rule applies whether the change results from retraining, drift, or bias checks. It mirrors the design-side review in §3: both are driven by the same process, and the capture gate is what transforms a self-modifying, autonomous system from being unaccountable to being auditable.

7. Towards accreditation

Accrediting an evolving model after approval is challenging, but not impossible.

The framework is general across domains and provides no accreditation regime of its own; regulated industries have verification, validation, and accreditation (VV&A)1. A constructive mapping is available: the provenance baseline supplies the pedigree record, probabilistic evidence fits a graded credibility scale, and captured Decision Objects could be the living accreditation record. The obstacle is conceptual: VV&A accredits a fixed artefact for a fixed use, but a model that rewrites itself violates that premise, because the thing accredited on Monday is not the thing operating on Friday. The capture gate is the most promising bridge, accrediting the model together with its gate rather than a frozen model alone; no standard yet recognises the construct. This paper proposes the bridge; it does not claim to have crossed it.

8. Limitations and open problems

The bridge to accreditation is built in principle, not yet in practice.

No existing VV&A regime certifies a constantly evolving model together with its gate, which leaves the capture gate an honest audit instrument with no formal accreditation standing. The verification figures are illustrative (the 99.99% standard is an aspirational goal, and the 15% improvement is hypothetical), and the accreditation should not rely on them as definitive metrics. The gate’s assurance is only valid with complete instrumentation: any unnoticed on-field adjustments inherently compromise it. Additionally, “reduce trust” is mentioned as a response, not a measure; it remains undefined how trust levels are quantified, decreased, or regained. The related paper, ‘Governing the Model Vault’, explores that aspect: how a validated model tracks its trustworthiness, enabling reuse to advance the Continuum without compromising accountability.

References

  • DoD Instruction 5000.61, DoD Modelling and Simulation (M&S) (VV&A).

  • MIL-STD-3022, Documentation of (VV&A) for Models and Simulations.

  • NASA-STD-7009A, Standard for Models and Simulations.