Demonstrable
Governance

The starting point is that modern information systems must simultaneously satisfy business, security, data-governance, compliance, resilience, operational and sovereignty requirements. These requirements are generally defined by different stakeholders, on distinct life cycles, and are then translated in more or less application-specific ways. The result is fragmented responsibility, a strong dependency on development teams, and a persistent difficulty in demonstrating that the organisation’s policies have actually been applied.

The white paper proposes moving from primarily declarative governance to Demonstrable Governance. The principle is to progressively transform organisational policies into executable technical actions and controls. Those actions and controls produce verifiable evidence; evidence establishes guarantees; and the accumulation of guarantees ultimately builds trust. Trust is therefore not treated as a property granted in advance to an application, infrastructure component or identity, but as the consequence of properties that can be demonstrated when they matter.

Business logic deliberately remains separate from governance mechanisms. A business processing component focuses on its functional purpose — obtaining data, transforming it and publishing a result — while specialised mechanisms perform the controls and actions required by governance. This separation allows security, data, operational and strategic policies to evolve independently of business code and its development life cycle.

A first family of guarantees concerns data. The white paper proposes verifying integrity and, where possible, authenticity through digital signatures; formalising structure through Data Contracts; validating compliance before processing; and separating logical representation from physical representation. Business processing therefore manipulates standardised abstractions rather than directly handling files, SQL tables, JSON documents or other storage formats. This normalisation, together with the corresponding denormalisation, reduces coupling with storage and transport technologies and contributes to portability and information-system sovereignty.

This notion of trust in data is extended across the data life cycle. A control performed when data is consumed does not protect it while it remains stored. The approach therefore distinguishes execution-related checks from custodial integrity controls, which can be performed periodically to verify the integrity of data stored on mutable media. Their frequency can be adapted to the nature of the data and the immutability properties of the storage used.

A second family of guarantees concerns trust in execution. The objective is not to claim that software is free from defects, but to verify that the component being executed is the one that was approved and that its technical capabilities are compatible with the applicable policies. To support this, the white paper introduces the Behaviour Manifest, generated from an analysis of the component and describing, among other things, referenced libraries, namespaces, file-system or network access, reflection, P/Invoke, process creation and any other technical capabilities deemed relevant. Once signed, this manifest becomes the authoritative description of approved behaviour and can be regenerated and compared before the processing component is loaded.

Execution is coordinated by a Guarantee Orchestrator. It does not control business logic itself; it coordinates the construction of the trust required for that logic to run. Guarantee Controllers verify specific properties and produce the corresponding evidence; Resource Managers handle interactions with external resources; and recorded state changes and evidence provide traceability and, where possible, allow a transaction to resume after interruption.

The business processing component is therefore executed only when the guarantees required at that point have been established. This leads to the principle of “service denial over uncontrolled execution”: when a mandatory guarantee cannot be demonstrated, execution may be stopped rather than continued under unknown trust conditions. This remains a governance decision and may vary according to organisational policy.

The approach also relies on independent declarative descriptions. The Business Process Definition describes what the processing must do and the resources it uses, while the Guarantee Pipeline Definition describes the actions, controls, resources and evidence required to govern its execution. Data Contracts, Behaviour Manifests and other artefacts also have their own independent life cycles. A transaction therefore represents the convergence of several independently versioned artefacts, with the exact versions recorded in its Execution Context.

This separation means the execution engine is not the implementation of a particular policy, but rather an interpreter of declarative policies. A policy can evolve without changing business logic; conversely, a functional change does not necessarily require a change to the governance policy. The model therefore seeks to reduce coupling between responsibilities while preserving the autonomy of the teams involved.

The white paper also introduces the concept of Execution Quality Assurance. Unlike traditional quality assurance, which is primarily performed before deployment, Execution Quality Assurance verifies the real conditions of each individual transaction: the version of the processing component executed, the availability of applicable contracts, the application of the governance pipeline, the success of mandatory controls, and the production of expected evidence. Its purpose is not to establish that a business decision is correct, but to demonstrate that it was produced under the declared and approved conditions.

The evidence produced is not only useful for audit. Because it links each transaction to the exact versions of processing components, contracts, policies, controls and other governing artefacts, it progressively becomes a source of knowledge about the information system.

Declarative descriptions consequently become knowledge assets. They can be used to analyse dependencies, assess the impact of change, compare policies, verify applicable controls or identify the elements affected by a modification. The information system can therefore contribute to producing its own documentation from artefacts that are necessary for operation, rather than relying exclusively on documentation maintained separately.

The accumulation of these relationships between processing components, data, policies, controls, artefacts and executions can give rise to an Enterprise Knowledge Graph. It can be used, for example, to query dependencies between processes and Data Contracts, identify the policies that governed a transaction, or assess the impact of a proposed change. This knowledge is an emergent property of the declarative descriptions and the evidence that connects them.

This capability also contributes to Cyber Resilience. An organisation must not only be able to restore technical components; it must also understand its critical functions, their dependencies and the conditions required to restore them into a trustworthy state. Automatically produced knowledge about functions, dependencies and guarantees can therefore support impact analysis and reconstruction after an incident.

Sovereignty is addressed more broadly than through infrastructure or data location alone. The objective is to preserve the organisation’s ability to control and evolve its business logic, data, policies, evidence and the knowledge describing its information system. The approach does not remove technological dependencies, but seeks to identify and isolate them and reduce their impact on business functions so that they can be replaced more easily.

Finally, Demonstrable Governance is not presented as a product or an all-or-nothing transformation. The white paper proposes progressive adoption: begin by formalising processing and contracts, make critical artefacts verifiable through digital signatures, characterise software behaviour, progressively introduce execution controls and produce evidence. Each additional guarantee is intended to reduce uncertainty, and each additional item of evidence to increase the level of trust available to the organisation.

In summary, the white paper proposes an architecture in which trust is neither assumed nor provided by a single component. It results from the assembly of independently governed commitments, their verification during execution, and the preservation of evidence demonstrating that those commitments were fulfilled. Business execution therefore becomes both a functional transformation process and a process for producing governance evidence.