Assurance Knowledge Platform

Ontology Architecture Specification

Version 1.0 (Conceptual Architecture)

Author's Vision

This specification defines an ontology-driven knowledge platform intended to support assurance, quality management, information management, asset management and digital thread traceability across regulated built environment and infrastructure projects.

The architecture is designed to support:

• ISO 9000 / 9001 Quality Management
• ISO 55000 / 55001 Asset Management
• ISO 19650 Information Management and BIM
• Building Safety Act Golden Thread principles
• GraphRAG and Knowledge Graph applications
• Human-in-the-loop assurance workflows
• AI-assisted reasoning with explainable traceability

---

1. Problem Statement

Many Knowledge Graph and GraphRAG implementations rely upon unconstrained extraction of triplets from documents:

Document
    ↓
Chunking
    ↓
LLM Extraction
    ↓
Triplets
    ↓
Graph

While suitable for general knowledge discovery, this approach often produces:

• Ambiguous terminology
• Inconsistent semantics
• Duplicate concepts
• Hallucinated relationships
• Weak traceability

The result is frequently a large, highly connected but poorly governed graph.

This document refers to such structures as:

Spaghetti Graphs

A Spaghetti Graph may contain many relationships but provides limited assurance value because the semantic meaning of nodes and relationships is inconsistent.

---

2. Design Objective

The objective is to create a graph structure that supports:

• Explicit semantics
• Controlled vocabulary
• Human-governed knowledge extraction
• Digital Thread traceability
• Explainable AI reasoning

The target architecture is referred to as a:

Flower Graph

Characteristics include:

• Strong ontology governance
• Consistent terminology
• Controlled relationship types
• Clear traversal paths
• Human review of extracted knowledge
• Lifecycle traceabilit

Example:

Requirement
    ↓
Design Output
    ↓
Verification Record
    ↓
Evidence
    ↓
Certification

Every path has assurance meaning.

---

3. Architectural Principles

Principle 1: Ontology Creates the Graph

Documents do not define graph structure.

Ontologies define graph structure.

Documents populate graph instances.

The extraction process must therefore answer:

Can this information instantiate an existing ontology definition?

rather than:

What new concepts can be invented?

Principle 2: Human-in-the-Loop Assurance

Knowledge extraction should support:

Document
    ↓
Candidate Objects
    ↓
Human Review
    ↓
Approved Graph

This significantly reduces semantic drift and hallucinations.

Principle 3: Traceability Before Discovery

The primary objective is not knowledge discovery.

The primary objective is:

Assurance Traceability

The platform shall support traversal across:

Requirements
Design
Construction
Verification
Validation
Certification
Operations
Maintenance
Renewal

Principle 4: Everything Must Be Explainable

Every graph relationship should be explainable through a governed ontology.

Questions such as:

Why is this requirement satisfied?

Why was access denied?

Why is this certificate valid?

must be answerable through graph traversal.

---

4. Multi-Layer Ontology Architecture

The platform consists of four logical layers.

Meta Ontology
        ↑

Assurance Ontology
        ↑

Access Control Ontology
        ↑

Project Data Layer

---

5. Meta Ontology

Purpose

The Meta Ontology defines the ontology construction language.

It describes how ontologies themselves are built.

Root Structure

Ontology
│
├── Ontology_Domain
├── Ontology_Concept
├── Ontology_Lifecycle_Stage
├── Ontology_Process
├── Ontology_Entity
├── Ontology_Relation
├── Ontology_Property
└── Ontology_Pattern

This Meta Ontology becomes a self-describing schema repository stored entirely inside a Graph Database.

---

6. Ontology Definitions

Ontology

Represents an ontology.

Examples:

Meta Ontology

Assurance Ontology

Access Control Ontology

Ontology_Domain

Represents a management discipline or capability area.

Examples:

Requirements Management

Asset Management

Information Management

Design Assurance

Risk Management

Configuration Management

Access Control

Questions answered:

Which business domain does this belong to?

Ontology_Concept

Represents abstract meaning.

Examples:

Requirement

Evidence

Conformance

Risk

Objective

Stakeholder

Competence

Information

Value

Questions answered:

What does this mean?

Ontology_Lifecycle_Stage

Represents a phase or state.

Examples:

Project Lifecycle

Concept

Definition

Design

Construction

Commissioning

Operations

Decommissioning

Asset Lifecycle

Planning

Acquisition

Operation

Maintenance

Renewal

Disposal

Questions answered:

When does something occur?

Ontology_Process

Represents activities or business processes.

Examples:

Verification

Validation

Design Review

Testing

Inspection

Audit

Commissioning

Condition Assessment

Change Control

Questions answered:

How is something performed?

Ontology_Entity

Represents things that may exist in data.

Examples:

Asset

Requirement

Certificate

Document

Verification_Record

Inspection_Record

Maintenance_Record

Organisation

Person

Questions answered:

What exists?

Ontology_Relation

Represents permitted relationship types.

Examples:

SATISFIES

VERIFIES

EVIDENCES

DERIVES_FROM

PART_OF

APPROVES

OPERATES

MAINTAINS

CERTIFIES

Questions answered:

How may things connect?

Ontology_Property

Represents reusable property class definitions.

Questions answered:

What attributes may be recorded?

Ontology_Pattern

Represents reusable graph structures.

Examples:

Requirement Verification Pattern

Certification Pattern

Maintenance Evidence Pattern

Questions answered:

What reusable structure exists?

---

7. Standard Property-Class Model

Ontology_Property nodes should represent property definitions rather than simple descriptions.

Recommended structure:

{
  "property_id": "PROP-0001",
  "name": "Requirement_ID",
  "display_name": "Requirement Identifier",
  "description": "Unique requirement reference",
  "data_type": "string",
  "mandatory": true,
  "unique": true,
  "indexed": true,
  "nullable": false,
  "default_value": null,
  "allowed_values": [],
  "validation_pattern": "^RQ-[0-9]+$",
  "unit": null,
  "minimum_value": null,
  "maximum_value": null,
  "version": "1.0",
  "status": "Approved"
}

This structure is:

• Graph friendly
• API friendly
• JSON serialisable
• GraphRAG friendly
• Validation friendly

---

8. Core Ontology Relationships

Meta Relationships

ONTOLOGY_CONTAINS

ONTOLOGY_RELATES_TO

ONTOLOGY_TYPE_OF

ONTOLOGY_PART_OF

ONTOLOGY_HAS_PROPERTY

ONTOLOGY_ALLOWS_RELATION

ONTOLOGY_HAS_PATTERN

ONTOLOGY_OCCURS_IN

Examples

Requirement
    HAS_PROPERTY
Requirement_ID

Verification_Record
    VERIFIES
Requirement

Inspection
    OCCURS_IN
Construction

---

9. Multiple Domain Membership

Ontology entities may belong to multiple domains.

Example:

Requirement

may belong to:

Requirements Management

Information Management

Configuration Management

Verification & Validation

This reflects the real-world nature of assurance information.

Ownership should not be restricted to a single domain.

---

10. Assurance Ontology

The Assurance Ontology is the primary business ontology.

Examples include:

Requirement

Asset

Verification_Record

Inspection_Record

Certificate

Maintenance_Activity

Information_Requirement

Design_Output

The Assurance Ontology shall be linked to the Meta Ontology through:

ONTOLOGY_TYPE_OF

---

11. Access Control Ontology

Access control is intentionally separate from assurance semantics.

The purpose of this ontology is to describe:

Identity

Role

Permission

Authority

Ownership

Classification

Policy

Examples:

Person

Role

Organisation

Permission

Security Classification

Example relationships:

HAS_ROLE

HAS_PERMISSION

OWNS

CAN_VIEW

CAN_EDIT

CAN_APPROVE

The Access Control Ontology shall also be linked to the Meta Ontology through:

ONTOLOGY_TYPE_OF

---

12. Project Data Layer

Project data contains actual records.

Examples:

RQ-001

AHU-101

VR-001

CERT-001

Inspection-824

The connection between project data and ontology elements is:

INSTANCE_OF

Example:

RQ-001
    INSTANCE_OF
Requirement

AHU-101
    INSTANCE_OF
Asset

---

13. Digital Thread Pattern

The core assurance pattern is traceability.

Example:

Requirement
    ↓ SATISFIED_BY

Design_Output
    ↓ VERIFIED_BY

Verification_Record
    ↓ SUPPORTED_BY

Evidence
    ↓ SUPPORTS

Certification

Equivalent chains exist for:

Asset Management

Operations

Maintenance

Information Management

Compliance

---

14. The Flower Graph Principle

The desired outcome is not maximum graph density.

The desired outcome is semantic clarity.

A Flower Graph exhibits:

Controlled vocabulary

Strong ontology governance

Clear traversal paths

Human-reviewed knowledge

Explainable relationships

Lifecycle traceability

The success criterion is not:

How many relationships exist?

The success criterion is:

Can the graph reliably answer:

"What evidence demonstrates that this
requirement has been satisfied throughout
the asset lifecycle?"

If that question can be answered transparently and consistently, the graph has achieved its assurance purpose.

---

15. Strategic Vision

The long-term vision is a self-describing knowledge platform in which:

• The Meta Ontology defines ontology construction rules.
• The Assurance Ontology defines assurance semantics.
• The Access Control Ontology defines platform governance.
• Project information populates the graph through governed instances.
• GraphRAG uses ontology-guided retrieval rather than unconstrained triplet extraction.
• Human experts remain accountable for assurance-critical knowledge.

The result is a trusted, explainable and traceable Digital Assurance Thread capable of supporting the complete lifecycle of regulated built assets and infrastructure.