Appendix A — Assurance Knowledge Platform: Governance, Change and Evidence Principles
Appendix A — Assurance Knowledge Platform: Governance, Change and Evidence Principles
A.1 Purpose
This Appendix provides additional context for the Ontology Architecture Specification.
The specification intentionally remains concise and focuses on the structure and semantics of the Assurance Knowledge Platform. This Appendix explains how that architecture is intended to operate within the quality assurance environment of major infrastructure and other regulated projects.
It addresses several issues that are fundamental to practical implementation but which would unnecessarily complicate the core ontology specification, including:
- the relationship between the Knowledge Layer and existing authoritative systems;
- authority and provenance;
- document and information maturity;
- change control;
- semantic continuity between revisions;
- impact analysis;
- ontology and metadata evolution;
- evidence and assurance claims; and
- the role and limitations of AI.
The Appendix describes architectural principles rather than prescribing a particular software implementation.
A.2 Role of the Assurance Knowledge Platform
The Assurance Knowledge Platform is not intended to become a replacement system of record.
Major infrastructure projects already rely upon specialised systems for managing authoritative information, including:
- Engineering Document Management Systems (EDMS);
- Common Data Environments (CDE);
- Enterprise Resource Planning (ERP) systems;
- project controls systems;
- design and engineering applications;
- BIM and Digital Twin platforms;
- asset management systems; and
- other discipline-specific systems.
The Knowledge Platform should not attempt to replicate these systems.
Instead, its purpose is to provide a governed semantic layer across authoritative information, allowing relationships between requirements, processes, deliverables, evidence and assurance outcomes to be represented and traversed.
The distinction can be expressed simply:
Systems of record manage authoritative information. The Knowledge Platform manages the meaning and relationships between that information for assurance purposes.
The Knowledge Platform therefore consumes information that has already passed through the appropriate organisational controls and uses that information as the basis for knowledge and assurance relationships.
A.3 Information Authority and Maturity
The Knowledge Platform should distinguish between information that is merely available and information that is sufficiently mature to support assurance.
For example, a project may contain several versions of a design calculation:
- working draft;
- submitted;
- returned with comments;
- revised;
- approved;
- superseded.
The Knowledge Platform should not treat all such information as equivalent evidence.
Where assurance conclusions are being generated, the relevant information should normally be sourced from the project's established information-management processes and should carry the appropriate status, revision and approval information.
The Knowledge Platform therefore relies upon the following principle:
The Knowledge Platform does not independently establish the authority of information that belongs to another system; it consumes and represents the authority established by the responsible system and process.
This allows authority to remain with the organisation, process or system that is responsible for it.
For example:
Calculation ABC Rev 3
may be authoritative because the project information-management process has established that it is the approved revision.
The Knowledge Platform represents this state and uses it when establishing assurance relationships.
A.4 Provenance
Provenance provides the basis for understanding how a knowledge statement or assurance relationship was established.
Provenance should be considered at several levels:
Source provenance
Where did the information originate?
Semantic provenance
How was the information interpreted and mapped to the ontology?
Process provenance
Through which controlled project process was the information produced or approved?
Authority provenance
Which organisation, role or system established its authoritative status?
Temporal provenance
During which period was the information valid?
Version provenance
Against which document, ontology, process or information revision was the relationship established?
The Knowledge Platform should preserve sufficient provenance to allow an assurance statement to be traced back to its authoritative source.
The objective is not to reproduce the complete audit trail of every source system.
Rather:
The Knowledge Platform should provide a navigable assurance trail back to the authoritative evidence and its governing process.
A.5 Change Control
Change is an inherent characteristic of major infrastructure projects.
Requirements, legislation, guidance, processes, designs, deliverables and evidence are continuously revised.
A change in one part of the information environment may therefore affect relationships elsewhere in the Knowledge Platform.
Change control should consequently be treated as a semantic impact-analysis problem, rather than merely a graph update operation.
The fundamental sequence is:
Compare → Determine semantic continuity → Identify impact → Propagate, terminate or review relationships → Approve the resulting state
The Knowledge Platform should preserve the historical state of the graph rather than simply overwriting previous relationships.
A.5.1 Semantic Continuity
A revision does not necessarily represent a new semantic entity.
For example:
Document Rev 1 → HAS_REQUIREMENT → Requirement R1
may become:
Document Rev 2 → HAS_REQUIREMENT → Requirement R1
where the requirement remains substantively unchanged.
The requirement may therefore retain its semantic identity while its relationship to the current document revision changes.
Conversely, apparently similar text may represent a materially different requirement.
Semantic continuity should therefore not be determined solely by:
- database identifier;
- document identifier;
- textual similarity; or
- revision number.
It should be determined by the semantic meaning of the requirement and, where necessary, by controlled human review.
A.5.2 Requirement Change Scenarios
When a revised document is introduced, the relationships associated with its requirements can generally fall into three categories.
Scenario 1 — Requirement unchanged
The requirement remains semantically equivalent.
Example:
Document Rev 1 → HAS_REQUIREMENT → R1
becomes:
Document Rev 2 → HAS_REQUIREMENT → R1
Where the downstream meaning of R1 has not changed, existing relationships may be transferred to the new document revision.
For example:
R1 → REQUIRES → Design Assessment A
remains valid.
The important point is that the relationship is transferred because semantic continuity has been established, not simply because the text appears similar.
Scenario 2 — Requirement withdrawn
A requirement present in the previous revision no longer exists in the new revision.
In this case, its downstream relationships should not automatically be transferred.
The previous requirement and its associated assurance relationships remain part of the historical state, but the current graph should reflect that the requirement is no longer active.
This distinction is important because removal of a requirement is itself an auditable change.
Scenario 3 — Requirement changed
The requirement remains related to the same general subject but its meaning, applicability or conditions have changed.
For example:
Revision 1
The design shall assess earthquake loading.
Revision 2
The design shall assess earthquake loading for structures located within the defined seismic zones.
The requirement may retain some semantic continuity while changing the conditions under which it applies.
Existing downstream relationships must therefore be individually assessed.
Some may remain valid, some may require modification, and others may no longer provide sufficient evidence.
This is expected to be the most complex change-control scenario.
A.6 Relationship Impact Analysis
The principal purpose of semantic change control is not merely to identify changed nodes.
It is to determine which dependent knowledge and assurance relationships are affected.
A requirement may have relationships to:
- processes;
- design activities;
- specifications;
- deliverables;
- verification activities;
- validation activities;
- evidence;
- approvals;
- assurance claims.
A change to the requirement should therefore trigger an impact analysis across its dependent relationships.
Conceptually:
Changed Requirement
↓
Dependent Relationships
↓
Affected Processes / Outputs
↓
Affected Evidence
↓
Affected Assurance Claims
The extent of propagation should depend upon the semantics of the changed relationship.
This means that change propagation should not be implemented as a simple rule such as:
“If a node changes, delete all downstream relationships.”
Nor should it automatically preserve every relationship.
Instead:
Each affected relationship should be classified as transferable, invalidated, modified or requiring review.
A.7 Change Control Across Knowledge Layers
The same principle applies across the Data, Meta and Ontology layers.
Data Layer
A change to a controlled project requirement, deliverable or evidence item may affect downstream knowledge and assurance relationships.
Meta Layer
A change to status, validity, applicability, ownership, provenance or other metadata may alter whether an existing relationship remains valid.
For example, a previously approved document becoming superseded may invalidate its use as current evidence without changing the underlying document content.
Ontology Layer
A change to a class, relationship, constraint or semantic definition may affect the interpretation of existing knowledge.
Ontology changes therefore require impact analysis against existing instances and relationships.
A change to the ontology should be treated as potentially affecting the meaning of previously created knowledge.
The same fundamental principle applies at all levels:
Changes should be evaluated according to their semantic impact, not merely their technical representation.
A.8 Historical State and Versioning
Assurance requires the ability to answer not only:
“What is true now?”
but also:
“What was considered true at the time?”
The Knowledge Platform should therefore preserve historical states sufficiently to reconstruct previous assurance positions.
For example, if Requirement R1 was withdrawn in Revision 4, the historical relationship between R1 and Calculation ABC should not simply disappear.
It should remain available as part of the historical state, while the current state records that R1 is no longer an active requirement.
This allows the platform to support questions such as:
- What requirements applied at the time of design?
- What evidence was accepted at the time?
- Which revision of the requirement was used?
- When did the requirement change?
- Which assurance conclusions were affected?
- What changed following the revision?
Historical state is therefore a fundamental property of an assurance knowledge platform.
A.9 Assurance Claims
The ultimate purpose of the Knowledge Platform is not to produce graphs.
It is to support assurance claims.
An assurance claim is a governed statement that a particular requirement, obligation or condition has been addressed and is supported by appropriate evidence.
For example:
Claim: Earthquake loading has been assessed for the proposed design.
The graph may establish the following chain:
Legislation
↓
Guidance
↓
Project / Organisation Process
↓
Design Requirement
↓
Required Assessment
↓
Approved Calculation ABC Rev 3
↓
Assurance Claim
The Knowledge Platform does not perform the engineering calculation.
Nor does it independently certify the result.
Instead, it identifies:
- that the assessment is required;
- the process or requirement from which that obligation arises;
- the expected output or evidence;
- the authoritative evidence that exists;
- the status of that evidence; and
- the relationship between the evidence and the assurance claim.
The resulting output might therefore be expressed as:
Earthquake condition assessment is required. The requirement is evidenced by approved Calculation ABC Rev 3.
This is fundamentally different from asking an AI system to determine whether the design is structurally adequate.
The Knowledge Platform provides the assurance trail, while technical judgement remains with the responsible discipline and governed project process.
A.10 Evidence Does Not Equal Compliance
The existence of evidence should not automatically be interpreted as proof of technical compliance.
For example:
Requirement → SUPPORTED_BY → Calculation ABC
does not necessarily mean:
Requirement → COMPLIANT_WITH → Calculation ABC
The first relationship indicates that the calculation is recognised as evidence relevant to the requirement.
The second would constitute a much stronger engineering or assurance conclusion.
The Knowledge Platform should therefore distinguish between:
- requirement;
- expected evidence;
- available evidence;
- approved evidence;
- verification;
- validation;
- assurance claim; and
- compliance conclusion.
This distinction prevents the Knowledge Platform from unintentionally becoming an automated certification system.
A.11 Role of AI
AI may assist in the creation, maintenance and use of the Knowledge Platform, but should not be confused with the authority of the underlying information.
AI may be used to:
- identify candidate entities and relationships;
- compare revisions;
- propose semantic equivalence;
- identify potential changes;
- identify potentially affected relationships;
- suggest ontology mappings;
- detect missing evidence;
- generate assurance queries;
- summarise evidence chains; and
- assist users in navigating the knowledge graph.
Where an AI system proposes a semantic interpretation that affects governed knowledge, the proposal should be subject to the appropriate validation and approval process.
The distinction is therefore:
AI may propose knowledge; governance establishes knowledge.
This principle is particularly important where the resulting knowledge may support regulated-project assurance.
A.12 AI Confidence and Assurance Status
AI confidence and assurance status should not be treated as equivalent concepts.
For example:
AI semantic-mapping confidence: 95%
does not mean:
Assurance confidence: 95%.
The first describes the AI system's confidence in its interpretation.
The second would imply an engineering or governance judgement.
A candidate relationship may therefore have high AI confidence but remain unapproved.
Conversely, once a relationship has passed the appropriate controlled review, its assurance status derives from that governance process rather than from the AI model's confidence score.
This separation helps prevent probabilistic AI output from being mistaken for authoritative engineering knowledge.
A.13 Missing Evidence and Gap Analysis
One of the principal benefits of the Knowledge Platform is the ability to identify what should exist but does not currently have sufficient evidence.
For example:
Approved Design Brief
+
Project Location
↓
Applicable Requirement
↓
Required Assessment
↓
Expected Evidence
↓
No approved evidence found
The platform can therefore report:
Earthquake assessment is required for this design, but no approved evidence has been identified.
This is more valuable for assurance than simply searching existing documents.
The platform is able to reason from requirements toward expected evidence, rather than only from evidence toward known requirements.
This creates a basis for proactive assurance and gap analysis.
A.14 The Assurance Knowledge Platform as a Controlled View
The Knowledge Platform should therefore be understood as a controlled semantic view over authoritative project information, rather than as an alternative source of truth.
Its value comes from connecting information that is otherwise distributed across organisational systems.
The platform should make it possible to traverse relationships such as:
Legislation
→ Guidance
→ Organisation / Project Process
→ Requirement
→ Design / Construction / Operational Obligation
→ Required Output
→ Approved Evidence
→ Assurance Claim
This traversal represents the Digital Assurance Thread.
It provides a structured explanation of:
What is required, why it is required, what was expected to demonstrate it, what evidence exists, and whether that evidence has reached the required governed state.
A.15 Design Principles
The following principles summarise the intended interpretation of the Ontology Architecture Specification.
Principle 1 — Do not replace systems of record
The Knowledge Platform should connect authoritative information rather than attempt to own all information.
Principle 2 — Meaning is governed
Ontology defines the semantics through which information is interpreted and connected.
Principle 3 — Evidence remains authoritative at source
The Knowledge Platform should reference and connect approved evidence rather than recreate the authority of the source system.
Principle 4 — Change is semantic
A revision should be evaluated according to its effect on meaning and relationships, not merely its technical revision identifier.
Principle 5 — Relationships are governed objects
Relationships may require their own provenance, status, validity and change history.
Principle 6 — Historical states matter
Previous assurance positions must remain reconstructable.
Principle 7 — AI proposes; governance approves
AI can accelerate knowledge creation and analysis but should not become the source of authority.
Principle 8 — Evidence is not automatically compliance
The presence of evidence does not by itself constitute a technical or regulatory conclusion.
Principle 9 — The platform should identify gaps
The system should be capable of determining where required evidence is missing, obsolete or insufficiently governed.
Principle 10 — Assurance is the objective
The purpose of the graph is not graph completeness.
The objective is to provide a reliable, navigable and explainable connection between obligation, requirement, process, evidence and assurance.
A.16 Implementation Considerations
The principles described above do not prescribe a single technical implementation.
Several implementation questions remain open and should be evaluated against the requirements of individual projects and platforms, including:
- methods for identifying semantic continuity between revisions;
- graph versioning strategies;
- relationship-level versioning;
- ontology version management;
- automated change-impact analysis;
- provenance representation;
- integration with authoritative source systems;
- approval workflows;
- handling of conflicting evidence;
- treatment of incomplete information;
- ontology evolution and extension;
- AI-assisted semantic mapping; and
- performance and scalability.
These are implementation decisions rather than fundamental principles of the architecture.
The specification should therefore remain technology-neutral wherever the underlying assurance requirement can be expressed independently of a particular implementation.
A.17 Concluding Perspective
The Assurance Knowledge Platform is intended to make existing controlled information meaningfully connected for assurance.
It does not attempt to become the source of every piece of project information, perform every engineering calculation, or replace professional judgement.
Its purpose is narrower and more practical:
To establish a governed semantic connection between what a regulated project is required to achieve and the approved evidence demonstrating how that requirement has been addressed.
When combined with controlled change management, provenance, versioning and appropriate human governance, the resulting Knowledge Graph can provide an auditable Digital Assurance Thread across the project lifecycle.
The fundamental question the platform should help answer is therefore:
Given the applicable requirements and the current approved state of the project, what must be demonstrated, what evidence demonstrates it, and how can the complete assurance path be traced?