Why Governance Resets
Digital health programmes routinely rebuild governance capabilities that already exist elsewhere. Identity verification, consent management, clinical safety cases, data provenance. Each programme addresses these needs within its own scope.
This is not inefficiency. It is a natural consequence of how programmes are funded and governed. Programme boundaries create governance boundaries. What one programme builds belongs to that programme. When the programme ends or changes scope, its governance artifacts may not transfer.
The result is accumulation without compounding. Organisations gain governance implementations but not governance infrastructure. Each new initiative starts closer to zero than it should, given what has been built before.
Signal: When governance capabilities are rebuilt repeatedly, the architecture is optimising for programme autonomy rather than system efficiency.
Local Optimisation, System Drag
Each programme optimises governance for its own context. This is rational behaviour. The collective effect is irrational outcomes.
When Programme A builds identity verification for its user population, it makes choices suited to its scope: authentication methods, identity assurance levels, user experience trade-offs. Programme B, serving a different population, makes different choices. Both are locally optimal.
Problems emerge at boundaries. When Programme A needs to trust identities from Programme B, the optimisation choices diverge. Integration requires translation, mapping, or re-verification. The friction is proportional to the divergence between local optimisations.
Multiply this across consent, safety, and provenance. Multiply again across dozens of programmes. The system accumulates boundary friction that no single programme created and no single programme can resolve.
Where Friction Accumulates
Identity: Different verification standards, incompatible assurance levels, no trust framework for cross-system recognition.
Consent: Captured in different formats, stored in different systems, not portable across organisational boundaries.
Clinical safety: Cases built for standalone deployment, assumptions that do not survive integration, evidence that cannot be composed.
Provenance: Lineage maintained within systems but lost at handover, trust assertions that do not transfer.
Signal: System-wide friction is the aggregate cost of local optimisation. No single programme is at fault, but the system pays.
What Must Be Shared
Not everything needs to be shared. Some governance decisions are legitimately local. The question is which capabilities create compounding value when shared and which create unnecessary constraint.
Four capabilities consistently emerge as candidates for shared infrastructure. Each addresses a governance need that recurs across programmes, creates friction at boundaries when implemented differently, and compounds in value when implemented consistently.
Identity Infrastructure
Verification of patients, practitioners, organisations, and systems. Assurance levels that transfer across boundaries. Trust frameworks that allow systems to recognise each other's identity assertions.
When shared: Identity verified once can be trusted everywhere. New systems inherit identity infrastructure rather than rebuilding it.
Consent Infrastructure
Patient preferences captured in portable formats. Dynamic evaluation at point of action. Consent that travels with data rather than sitting in registration systems.
When shared: Consent decisions propagate across boundaries. Patients gain meaningful control over their data regardless of which system holds it.
Safety Infrastructure
Clinical safety evidence structured for composition. Hazard libraries that accumulate rather than reset. Assurance patterns that can be inherited by new implementations.
When shared: Safety cases build on prior work. CSO effort compounds rather than repeats. New integrations start with established safety foundations.
Provenance Infrastructure
Data lineage maintained through transformation. Trust assertions that survive handover. Audit trails that span organisational boundaries.
When shared: Data trustworthiness can be verified regardless of where data originated. Clinical decisions can be traced to authoritative sources.
These four are not exhaustive, but they are foundational. Other governance capabilities often depend on them. Accountability requires identity. Data rights require consent. Quality assurance requires provenance. Clinical safety requires all four.
Project-Scoped vs Persistent Governance
The distinction between governance that compounds and governance that resets is primarily about persistence: does the capability outlive the programme that created it?
| Dimension | Project-Scoped | Persistent |
|---|---|---|
| Funding | Programme budget, ends with programme | Infrastructure budget, continuous |
| Ownership | Programme team | Shared service or platform team |
| Scope | Optimised for programme needs | Designed for cross-programme use |
| Evolution | Changes with programme requirements | Evolves based on ecosystem needs |
| Handover | May not survive programme end | Outlives individual programmes |
This is not primarily a technical distinction. The same capability can be built either way. The difference is in how it is funded, governed, and maintained over time.
Persistent governance requires deliberate investment. It requires governance capabilities to be treated as infrastructure rather than programme deliverables. It requires funding models that survive programme boundaries and ownership structures that span organisational silos.
Signal: Governance compounds when it is funded as infrastructure. It resets when it is funded as programme overhead.
Reusable Assurance Artifacts
For governance to compound, the artifacts it produces must be reusable. Safety cases, consent records, identity assurances, provenance chains. Each must be structured for composition rather than standalone use.
Most governance artifacts today are documents: PDFs, Word files, spreadsheets. They capture what was decided and why. They do not easily compose with other artifacts or integrate into automated systems.
Reusable artifacts require different characteristics:
Structured formats
Machine-readable representations that can be consumed by other systems and assurance tools.
Clear boundaries
Explicit definition of what the artifact guarantees and what assumptions it requires from its environment.
Maintained provenance
Traceable chain from original assurance through all uses and compositions.
Version alignment
Clear indication of which component version an artifact applies to and when revalidation is required.
Compositional logic
Rules for how artifacts combine, what properties are inherited, what new assessment is required.
Trust anchors
Mechanisms for verifying artifact authenticity and the authority of the issuing party.
Building artifacts this way requires more upfront investment than document-centric approaches. The return is downstream: new programmes can inherit existing assurance rather than rebuilding it. Integration accelerates. Governance load shifts from repetitive assessment to compositional verification.
What This Means for Different Actors
For System Leaders
Shared foundations require deliberate investment in capabilities that no single programme will fund. This is infrastructure thinking applied to governance. The return is not visible in any single programme but in the cumulative reduction of governance friction across all programmes.
For Programme Leads
Programmes that build on shared foundations move faster than programmes that rebuild from scratch. The trade-off is constraint: shared infrastructure may not perfectly match programme-specific needs. The question is whether local optimisation is worth the boundary friction it creates.
For Architects
Designing for shared foundations requires different patterns than designing for programme scope. Interfaces must be stable. Boundaries must be explicit. Evolution must be coordinated. The architectural discipline is higher, but the system benefits compound.
For Governance Leads
Shared foundations change the governance role from repeated first-principles assessment to validation of composition. This requires new skills: understanding how assurance composes, how to evaluate inherited properties, how to maintain oversight of automated verification.
For Regulators
Shared foundations provide richer evidence than programme-scoped governance. Assurance artifacts are structured, traceable, and maintained. The regulatory question evolves from "was this assessed?" to "is this operating within assured parameters?"
How This Connects
Shared foundations are the architectural answer to governance patterns described elsewhere. They connect to questions about how assurance scales and why innovation struggles at boundaries.
These pages describe governance as infrastructure: capabilities that compound when shared, and reset when rebuilt.
Frequently Asked Questions
What are shared governance foundations?
Shared governance foundations are capabilities that persist beyond individual programmes and can be inherited by new systems without being rebuilt. These include identity verification, consent management, clinical safety assurance, and data provenance. When these capabilities are shared, governance compounds. When they are rebuilt per programme, governance resets.
Why does local optimisation create system-wide drag?
When each programme optimises governance for its own scope, the result is multiple incompatible implementations of the same underlying capabilities. Identity verification works differently across systems. Consent is captured in incompatible formats. Safety cases cannot reference each other. The system accumulates governance implementations rather than governance infrastructure, creating friction at every boundary.
What is the difference between project-scoped and persistent governance?
Project-scoped governance is funded, built, and retired with the programme that created it. Persistent governance outlives individual programmes and becomes available to subsequent initiatives. The distinction is primarily about how governance capabilities are funded and maintained, not about the capabilities themselves.
How can assurance artifacts be reused?
Assurance artifacts can be reused when they are structured for composition rather than standalone use. This requires clear boundary definitions, machine-readable formats, explicit assumptions, and maintained provenance. A safety case built on composable foundations allows new integrations to inherit existing assurance rather than rebuilding it.
Building Shared Foundations?
We work with system leaders, architects, and governance teams on infrastructure that compounds rather than resets.
Book a discovery call