Ontological Knowledge Blocks: Executable Compliance and Profile-Based Validation for Trustworthy AI Systems Aasish Kumar Sharma
and Julian M. Kunkel
arXiv:2605.23297v1 [cs.AI] 22 May 2026
Institute of Computer Science, Georg-August-Universität Göttingen / GWDG, Germany {aasish.sharma, julian.kunkel}@uni-goettingen.de Abstract—AI-enabled services deployed in critical digital infrastructure are subject to governance obligations spanning transparency, accountability, fairness, and traceability. Compliance today remains documentation-centric: obligations are described in prose, audits rely on static checklists, and verification depends on manual review. Such approaches do not scale to automated AI systems. This paper introduces Ontological Knowledge Blocks (OKBs), a programmable governance infrastructure that compiles regulatory obligations into machine-checkable constraints over structured evidence graphs. We formalize an OKB as a 5-tuple ⟨O, C, V, E, P ⟩ that binds normative obligations to an RDF/OWL concept schema, executable SHACL validation rules, explicit evidence requirements, and PROV-O provenance links. A deterministic regulatory compiler translates structured Intermediate Representation (IR) records into composable KB modules, enabling profile-based governance reconfiguration without modifying service code. We implement two prototypes and evaluate them in an AI-assisted HPC resource allocation scenario across 24 validation runs and four governance profiles. Results demonstrate profile-sensitive validation, strictly additive violation accumulation (Accountability: 1, Fairness: 2, Combined: 3 violations across failure cases), SHACL validation latency between 12.6 ms and 100.3 ms, and profile equivalence testing confirming Combined as the strictly most comprehensive profile, subsuming both Accountability and Fairness with no equivalence pairs. All artefacts are released as open source. Index Terms—Responsible AI, AI governance, policy-as-code, semantic web, RDF, SHACL, provenance, PROV-O, compliance automation, programmable governance
I. I NTRODUCTION Responsible AI governance is crossing a threshold. What was once a field of voluntary guidelines [3], [4] is becoming a landscape of enforceable, operational obligations. The EU AI Act requires high-risk systems to maintain technical documentation, record decisions with timestamps, provide transparency notices, and implement human oversight mechanisms [1]. The NIST AI Risk Management Framework (RMF) structures these concerns across the full AI lifecycle [2]. The practical question is, not whether governance obligations exist, they do, but whether they can be checked automatically against the evidence an AI system actually produces? The honest answer, today, is “no”. Compliance practice still relies on narrative documentation compiled for periodic audits. That approach has a structural flaw: it records claims rather than verifying evidence. A document asserting that “logging is in place” cannot confirm that individual decisions carry
correctly typed timestamps, that provenance links reach the model artifact that generated the decision, or that resource allocations satisfy a declared fairness threshold. Problem: To our knowledge, no widely adopted, standardsaligned, composable mechanism currently (a) makes governance obligations explicit and human-reviewable, (b) compiles them deterministically into executable checks, and (c) validates those checks continuously over evidence emitted by AI services. While individual components exist (ontologybased compliance models [11], [13], SHACL-based compliance checking [14], and policy-as-code engines [10]), no existing system, to our knowledge, integrates semantic evidence representation, deterministic obligation compilation, and executable profile-based validation into a single pipeline. Approach: We propose Ontological Knowledge Blocks (OKBs), a programmable compliance substrate built on W3C standards. Each OKB encodes governance obligations as an RDF/OWL concept schema paired with SHACL constraint shapes that execute over an evidence graph. A regulatory compiler translates human-reviewed IR records into Knowledge Block (KB) modules deterministically. Governance profiles select and compose KBs without touching service code. Contributions: (i) Formalization: an OKB model KB = ⟨O, C, V, E, P ⟩ with a compliance decision procedure and profile composition algebra. (ii) Compiler: a deterministic IRto-SHACL compiler. (iii) Prototype: open-source reference implementations covering logging, transparency, fairness, and provenance. (iv) Evaluation: validation of profile sensitivity, refinement relations, and sub-100 ms latency; Combined confirmed as strictly the most comprehensive profile. Scope: This work does not automate legal interpretation. Normative decisions remain with human governance owners. Once an obligation is captured in IR and reviewed, compilation and checking are deterministic and repeatable. II. BACKGROUND RDF and OWL: The Resource Description Framework (RDF) [7] defines a graph data model for representing entities and relationships as subject–predicate–object triples. The Web Ontology Language (OWL) extends RDF with formal class hierarchies. Together they provide a standards-based substrate for structured evidence representation.
SHACL: The Shapes Constraint Language (SHACL) [8] provides machine-checkable constraint shapes over RDF graphs. SHACL Core supports structural and datatype validation; SHACL-SPARQL extends this with query-based constraints enabling quantitative checks such as threshold comparisons. PROV-O: The PROV Ontology (PROV-O) [9] expresses provenance relationships between entities, activities, and agents. In this work, PROV-O links AI decisions to the model artifacts and activities that generated them, enabling traceability audits required by the EU AI Act and NIST AI RMF. III. R ELATED W ORK A. Governance Frameworks and Documentation Artefacts The NIST AI RMF [2] structures governance across the AI lifecycle. Model Cards [5] and Datasheets for Datasets [6] standardise how AI systems are described. These artefacts support human inspection but contain nothing executable and carry no mechanism for profile-based governance variation.
TABLE I C OMPARISON OF COMPLIANCE APPROACHES . ✓ = Y ES ; × = N O ; ∼ = PARTIAL . Approach
Exec.
Compos.
Crossprofile
Evidence grounded
NIST AI RMF Model Cards Policy-as-code (OPA) Compl. ontologies [11], [14] This work (OKBs)
× × ✓ ∼ ✓
× × ∼ × ✓
× × × × ✓
× × ∼ × ✓
Layer 1 - Obligation Representation: Obligations are captured as structured Regulatory IR records in YAML, specifying target concept, required relation/attribute, constraint type (structural, datatype, or quantitative threshold), parameters, and severity. IR records are authored and approved by human compliance engineers before compilation, preserving normative authority. Layer 2 - Deterministic Compilation: A compiler C maps each IR record to a SHACL node shape within a KB module: C : IR 7→ KB = ⟨O, C, V, E, P ⟩.
(1)
B. Policy-as-Code and Automated Enforcement Policy-as-code systems such as OPA [10] enforce declarative rules at infrastructure boundaries. They are effective for access control but operate over syntactic system state rather than semantically linked evidence graphs. Provenance-aware claims about AI decisions fall outside their native data model. C. Ontology-Based Compliance Automation Recent work applies ontological methods to regulatory compliance. Gallina et al. [11] propose an ontology for process compliance with machinery legislation; subsequent work extends this to compliance-aware system change management [12] and ontology-based product evolution in regulated industries [13]. Anim et al. [14] demonstrate SHACL-based automated compliance checking over RDF data, confirming that SHACL-SPARQL constraints are necessary for temporal and aggregate legal requirements. These contributions advance compliance modelling but do not address composing executable governance profiles over runtime AI evidence graphs, nor provide a deterministic compilation pipeline from humanreviewed obligations to SHACL shapes. D. Positioning
O is the obligation set; C the RDF/OWL concept schema; V the SHACL shape set; E the required evidence artifacts; P the PROV-O provenance links. The mapping is deterministic: the same IR always produces the same shapes. Layer 3 - Evidence Graph Construction: Each AI service decision is accompanied by an RDF evidence graph linking the decision to provenance artifacts, usage logs, explanation references, and quantitative measurements. The evidence graph is emitted by the service itself, making compliance checking concurrent with operation. Layer 4 - Profile Composition and Validation: A governance profile selects KB modules. Composition is defined by set union: KBa ⊕KBb := ⟨Oa ∪Ob , Ca ∪Cb , Va ∪Vb , Ea ∪Eb , Pa ∪Pb ⟩. (2) The SHACL engine evaluates all shapes over the evidence graph GS : validate(GS , KBa ⊕ KBb ) → ⟨conforms, violations, Greport ⟩,
(3)
Table I characterises OKBs against prior approaches. OKBs integrate executable validation, composable modularity, crossprofile governance variation, and evidence grounding: a combination that, to our knowledge, has not been previously demonstrated.
where Greport is a machine-readable SHACL report. Profile P1 refines P2 (P1 ⊑ P2 ) if every violation detected by P2 is also detected by P1 ; equivalence holds when both directions hold. When validation fails, the report identifies which shape fired, on which node, with what message, closing the feedback loop for remediation or audit.
IV. M ETHODOLOGY
V. F RAMEWORK A RCHITECTURE
The methodology translates governance obligations into machine-checkable infrastructure through four layers, separating normative interpretation (human responsibility) from constraint execution (deterministic machine process).
Figure 1 shows the governance pipeline. Figure 2 shows the system architecture, and Figure 3 shows the operational flow from evidence capture through profile selection to validation and reporting.
Start: User Request
Regulatory Text PHASE 1: REQUEST PROCESSING
Structured Regulatory IR (Human-approved)
Receive & Parse User Request
Extract Intent & Context PHASE 2: KNOWLEDGE BLOCK RETRIEVAL
Identify Relevant OKB Types
Deterministic IR → SHACL Compiler OKB Repository
Retrieve Knowledge Blocks from Repository
Compose Semantic Context Graph
Knowledge Blocks (Schema + SHACL Shapes)
PHASE 3: RESPONSIBLE AI VALIDATION
AI Service Evidence Graph (RDF + PROV-O)
Real-time Validation
Ethical Constraint Validation
Regulatory Compliance Check
Fairness & Bias Assessment
Feedback Loop (Updates OKB) All Checks Passed?
SHACL Validation Engine
NO
Machine-Readable Compliance Report
PHASE 4: AI INFERENCE & GENERATION
YES Contextualize Request with OKB
Execute AI Model Inference
Fig. 1. Executable governance pipeline: obligations are compiled into KB modules and validated against evidence graphs emitted per AI decision.
Apply OKB Constraints to Output PHASE 5: OUTPUT VALIDATION & AUDIT
Layer 1: Data & Knowledge Sources Domain Ontologies
Ethical Frameworks
Regulatory Rules
Fairness Metrics
Training Data
Generate Provenance Trail
Log Violation & Reasoning
Generate User Explanation
Return Safe Response
Validate Output Against OKB
Log to Audit System
Capture Feedback Signals
Continuous Learning
Return Response to User
Layer 2: Knowledge Block Construction Ontology Parser
Semantic Validator
Block Composer
Knowledge Block Repository
Layer 3: Core AI Service with OKB Integration AI Inference Engine
OKB Runtime Processor
Context Manager
Layer 4: Responsible AI Controls & Governance Bias Monitor
Explainability Engine
Compliance Checker
Audit Logger
Feedback Loop
Layer 5: User Interface & API
Fig. 2. OKB system architecture: obligations represented in IR, compiled into KB modules, executed over RDF evidence graphs at runtime.
VI. P ROTOTYPE : S CENARIO , B LOCKS , AND C ASES A. The HPC Resource Allocation Scenario We instantiate the framework on an AI-assisted GPU-hour scheduler distributing resources across research groups. HPC schedulers make high-throughput decisions affecting measurable quantities, operate across regulatory boundaries, and their fairness properties can be quantified precisely. B. Knowledge Blocks The Accountability block (A) comprises five SHACL shapes (A1–A5) enforcing logging, provenance linkage, and model traceability. The Fairness/Transparency block (B) comprises five shapes (B1–B5) enforcing explanation presence, fairness
Fig. 3. Operational process: the AI service emits an evidence graph per decision; the governance engine selects the active profile, merges SHACL shapes, and validates. The report feeds the audit trail.
threshold declaration, per-group allocations, and the quantitative disparity check shown in Listing 1: ex:B5Shape a sh:NodeShape ; sh:message "Fairness disparity exceeds threshold." ; sh:targetClass ex:Decision ; sh:sparql [ a sh:SPARQLConstraint ; sh:select """SELECT $this WHERE { $this ex:allocatedGPUHoursGroupA ?a ; ex:allocatedGPUHoursGroupB ?b ; ex:fairnessThreshold ?t . BIND(IF(?a > ?b, ?a, ?b) AS ?mx) BIND(IF(?mx = 0, 0, (ABS(?a - ?b) / ?mx)) AS ?ratio) FILTER(?ratio > ?t) }""" ] .
Listing 1. B5Shape: SPARQL constraint for quantitative fairness.
The Combined block is the set union of A and B (all ten shapes). C. Profiles and Evidence Cases The OKB prototype uses four jurisdiction-oriented profiles: EU, US, China, and EU+Fairness. The compiler prototype uses three capability-oriented profiles: Accountability, Fairness, and Combined. Evidence cases isolate specific governance failures (details in Appendix A).
TABLE II OKB PROTOTYPE : CONFORMANCE (✓/×) AND VIOLATION COUNTS . Evidence case
EU
US
China
EU+Fairness
Case Conform Case Profile Case Violate
✓ (0) × (1) × (2)
✓ (0) ✓ (0) × (1)
✓ (0) ✓ (0) × (1)
✓ (0) × (1) × (3)
TABLE III C OMPILER PROTOTYPE : CONFORMANCE (✓/×) AND VIOLATION COUNTS . Evidence case
Acct
Fairness
Combined
Case Conform Case Missing Explanation Case Disparity Exceeds Case Missing Model Artifact
✓ (0) ✓ (0) ✓ (0) × (1)
✓ (0) × (1) × (1) ✓ (0)
✓ (0) × (1) × (1) × (1)
D. Implementation Both prototypes use Python with rdflib 7.6.0 and pyshacl 0.31.0 with RDFS inference enabled and advanced SPARQL constraint evaluation. All policy artefacts (IR obligation records, SHACL shapes, validation profiles, and evidence graphs) are version-controlled with DVC [17] alongside Git. DVC checksums detect any modification to policy files, providing a tamper-evident audit trail as part of the compliance security framework. VII. E VALUATION A. Experimental Setup Experiment 1: 3 cases × 4 profiles = 12 runs (OKB prototype). Experiment 2: 4 cases × 3 profiles = 12 runs (compiler prototype). Total: 24 validation runs. B. Profile Sensitivity Table II: Case Conform passes all profiles. Case Profile passes US and China but fails EU and EU+Fairness with exactly one violation (missing explanation), demonstrating that the same evidence produces different verdicts via profile selection. Case Violate accumulates violations monotonically (1, 1, 2, 3). Table III: Atomic failure cases are detected precisely by the profiles encoding the corresponding obligations. Case C (Missing Model Artifact) fails Accountability and Combined, as expected: A5Shape correctly targets provenance activity nodes co-typed as ex:Activity. Violation accumulation is strictly additive: Accountability detects 1 failure case, Fairness detects 2, Combined detects all 3. C. Profile Refinement and Design Insight Table IV shows Combined is strictly the most comprehensive profile: it subsumes both Accountability and Fairness but is subsumed by neither. No two profiles are equivalent; each encodes a distinct obligation scope. Profile equivalence testing is a precise structural diagnostic: two profiles are equivalent if and only if they fire on exactly the same evidence graphs, which the refinement algebra detects without manual inspection.
TABLE IV P ROFILE REFINEMENT RELATIONS . ✓ = H OLDS ; × = D OES NOT HOLD . Relation
Holds?
Fairness ⊑ Accountability Combined ⊑ Accountability Combined ⊑ Fairness Fairness ⊑ Combined Accountability ⊑ Fairness Accountability ⊑ Combined
× ✓ ✓ × × ×
Implication Fairness misses provenance (A5) Combined detects all Acct. violations Combined detects all Fairness violations Combined additionally detects Case C Misses explanation/disparity Misses fairness obligations
Combined is strictly the most comprehensive profile
TABLE V VALIDATION LATENCY ( MS ) ACROSS EVIDENCE CASES PER PROFILE . Profile
Min
Median
Max
Compiler prototype Accountability Fairness Combined
12.6 55.3 59.5
14.6 58.7 61.1
33.0 270.4 100.3
OKB prototype EU (3 blocks) US (2 blocks) China (2 blocks) EU+Fairness (4 blocks)
15.1 13.7 13.5 61.6
15.4 14.9 14.9 61.6
31.7 19.0 19.2 248.1
D. Validation Performance Table V: All median latencies are within decision-time feasibility for second-scale allocation workloads. The Fairness maximum (270.4 ms) exceeding Combined (100.3 ms) reflects single-run variance in a small sample: medians (58.7 vs 61.1 ms) are nearly identical, confirming B5Shape dominates both profiles with no systematic architectural difference. VIII. D ISCUSSION The central result is that governance reconfiguration is achieved entirely through profile selection, with no change to service code, evidence schema, or validation engine. Profile equivalence testing confirms Combined is strictly the most comprehensive profile: it subsumes both Accountability and Fairness, detecting all failure cases across both constituent profiles, with no equivalence pairs between any two profiles. Compiler specification: Each IR record specifies: obligation_id, target_class, constraint_type (structural | sparql), relation, optional threshold_ref, severity, and message. The compiler maps each record to a SHACL NodeShape deterministically: structural constraints become sh:property paths; SPARQL constraints become sh:SPARQLConstraint. Duplicate obligation IDs are rejected; severity merging follows Violation > Warning > Info. Full schema and worked examples are in the repository. Scope: The B5 fairness constraint is illustrative: a two-group disparity proxy demonstrating the SHACL-SPARQL mechanism. Richer multi-group or temporal metrics are expressible within the same framework; selecting which to encode is a governance decision. Governance coverage claims should be understood accordingly. Companion works address collective
governance evaluation [15] and comparative regulatory analysis across the EU, US, and China [16]. Threats to validity: Internal: Evidence cases are handcrafted; they may not cover all failure modes. An automated schema validation step would prevent silent target-class mismatches before deployment. External: Evaluation uses a single domain (HPC scheduling); generalization to domains such as credit scoring or clinical AI requires further validation. Construct: The fairness metric is a simplified proxy; the mechanism generalises, but metric selection is domain-specific. IX. C ONCLUSION Ontological Knowledge Blocks provide a four-layer pipeline: human-reviewed Regulatory IR, deterministic compilation into RDF/OWL schema and SHACL shapes, evidence graph emission by AI services, and profile-based validation. Three findings are central: (1) profile sensitivity confirms identical evidence yields verdicts aligned with active obligations; (2) profile equivalence testing confirms Combined is strictly the most comprehensive profile, subsuming both Accountability and Fairness with no equivalence pairs; (3) violation accumulation is strictly additive across all cases. The illustrative B5 fairness constraint demonstrates the SHACL-SPARQL mechanism; richer multi-group metrics are expressible within the same framework. Validation latency of 12.6–100.3 ms (median) demonstrates decision-time feasibility for secondscale allocation workloads. Future work targets automated schema validation to prevent silent constraint failures, highthroughput evaluation at 103 –104 decision scale, cross-domain validation (e.g., credit scoring, clinical AI), and richer multigroup fairness metrics. ACKNOWLEDGMENTS © 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses. Accepted at the Security, Trust and Privacy for Software and Applications (STPSA) Workshop, IEEE COMPSAC 2026, Madrid, Spain, July 7–10, 2026.
This work was supported by NHR at GWDG and conducted within the KISSKI project (BMBF grant no. 01 IS 22 093 A-E) at the University of Göttingen. All artefacts (SHACL shapes, IR records, evidence graphs, evaluation scripts) are released as open source at https://github.com/AasishKumarSharma/ open-knowledge-blocks. R EFERENCES [1] European Union, “Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act),” Official Journal of the European Union, 2024. [Online]. Available: https://eur-lex.europa.eu/eli/reg/ 2024/1689/oj [2] National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, Jan. 2023, doi: 10.6028/NIST.AI.100-1. [Online]. Available: https://nvlpubs.nist. gov/nistpubs/ai/NIST.AI.100-1.pdf [3] A. Jobin, M. Ienca, and E. Vayena, “The global landscape of AI ethics guidelines,” Nature Machine Intelligence, vol. 1, pp. 389–399, 2019, doi: 10.1038/s42256-019-0088-2. [4] T. Hagendorff, “The Ethics of AI Ethics: An Evaluation of Guidelines,” Minds and Machines, vol. 30, pp. 99–120, 2020, doi: 10.1007/s11023020-09517-8.
[5] M. Mitchell et al., “Model Cards for Model Reporting,” in Proc. ACM FAT*, 2019, doi: 10.1145/3287560.3287596. [6] T. Gebru et al., “Datasheets for Datasets,” Communications of the ACM, vol. 64, no. 12, pp. 86–92, 2021, doi: 10.1145/3458723. [7] W3C, “RDF 1.1 Concepts and Abstract Syntax,” W3C Recommendation, Feb. 2014. [Online]. Available: https://www.w3.org/TR/ rdf11-concepts/ [8] W3C, “Shapes Constraint Language (SHACL),” W3C Recommendation, Jul. 2017. [Online]. Available: https://www.w3.org/TR/shacl/ [9] W3C, “PROV-O: The PROV Ontology,” W3C Recommendation, Apr. 2013. [Online]. Available: https://www.w3.org/TR/prov-o/ [10] Open Policy Agent, “Open Policy Agent (OPA) Documentation,” accessed Feb. 2026. [Online]. Available: https://www.openpolicyagent.org/ docs/latest/ [11] B. Gallina, G. L. Steierhoffer, T. Young Olesen, E. Parajdi, and M. Aarup, “Towards an ontology for process compliance with the (machinery) legislations,” J. Software: Evolution and Process, vol. 37, no. 1, Art. e2728, Jan. 2025, doi: 10.1002/smr.2728. [12] B. Gallina, M. Schweizer, and H. Dibowski, “Regulatory Complianceaware System Change Management via an Ontology-based Approach,” in Proc. 32nd EuroSPI, CCIS, vol. 2657, Springer, pp. 245–259, 2025, doi: 10.1007/978-3-032-04288-0 15. [13] B. Gallina, H. Dibowski, and M. Schweizer, “An Ontology-based Representation for Shaping Product Evolution in Regulated Industries,” in Proc. 21st ICSR, LNCS, vol. 14614, Springer, 2024, doi: 10.1007/9783-031-66459-5 6. [14] K. Anim, L. Robaldo, and A. Z. Wyner, “A SHACL-Based Approach for Enhancing Automated Compliance Checking with RDF Data,” Information, vol. 15, no. 12, Art. 759, 2024, doi: 10.3390/info15120759. [15] A. K. Sharma, D. Kyosev, and J. M. Kunkel, “Ethical AI: Towards Defining a Collective Evaluation Framework,” in Proc. IEEE COMPSAC 2025, pp. 1665–1670, 2025, doi: 10.1109/COMPSAC65507.2025.00344. [16] A. K. Sharma, D. Kyosev, C. Anich, R. K. Ojha, and J. M. Kunkel, “Global AI Regulations for FAIR and Ethics in High-Risk Use Cases: A Comparative Review,” in Proc. IEEE COMPSAC 2026 (STPSA Workshop), IEEE, 2026. [17] Iterative, “Data Version Control (DVC),” accessed May 2026. [Online]. Available: https://doc.dvc.org/user-guide
A PPENDIX A E VIDENCE G RAPH C ASES FOR P ROFILE -BASED VALIDATION This appendix provides the concrete RDF evidence graphs used in the evaluation. Each case is an evidence graph describing one scheduling decision and its associated artefacts. The profiles in Section VI validate these graphs using SHACL: the Accountability profile targets provenance completeness (usage log and model artifact linkage); the Fairness/Transparency profile targets explanation presence and quantitative disparity; the Combined profile enforces both. A. Case A: Conformant Evidence Case A (case_conform.ttl) includes a usage log with timestamp and CPU time, a resolvable explanation URI, and a provenance chain in which the generating activity prov:used both a model artifact and a log artifact. Allocations of 120.0 and 110.0 GPU-hours yield a disparity of 0.083, within the 0.20 threshold. This case should conform under all profiles. @prefix ex: <http://example.org/okb#> . @prefix prov: <http://www.w3.org/ns/prov#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . ex:svc1 a ex:AIService ; ex:hasDecision ex:dec1 . ex:dec1 a ex:Decision ;
ex:hasUsageLog ex:log1 ; ex:hasExplanation ex:exp1 ; ex:allocatedGPUHoursGroupA "120.0"ˆˆxsd:decimal ; ex:allocatedGPUHoursGroupB "110.0"ˆˆxsd:decimal ; ex:fairnessThreshold "0.20"ˆˆxsd:decimal ; prov:wasGeneratedBy ex:act1 . ex:log1 a ex:UsageLog ; ex:cpuTimeSeconds "3600.0"ˆˆxsd:decimal ; ex:energyKWh "2.3"ˆˆxsd:decimal ; ex:timestamp "2026-02-01T10:00:00Z"ˆˆxsd:dateTime . ex:exp1 a ex:Explanation ; ex:explanationURI "http://example.org/evidence/ explanations/dec1"ˆˆxsd:anyURI .
ex:fairnessThreshold "0.20"ˆˆxsd:decimal ; prov:wasGeneratedBy ex:act3 . ex:log3 a ex:UsageLog ; ex:cpuTimeSeconds "3600.0"ˆˆxsd:decimal ; ex:timestamp "2026-02-01T10:10:00Z"ˆˆxsd:dateTime . ex:exp3 a ex:Explanation ; ex:explanationURI "http://example.org/evidence/ explanations/dec3"ˆˆxsd:anyURI . ex:act3 a prov:Activity, ex:Activity ; prov:used ex:log_art3 . ex:log_art3 a ex:LogArtifact .
ex:act1 a prov:Activity, ex:Activity ; prov:used ex:model_v1, ex:log_art1 .
Listing 4. Case C (case_missing_model_artifact.ttl): provenance incomplete (model artefact not referenced).
ex:model_v1 a ex:ModelArtifact . ex:log_art1 a ex:LogArtifact .
D. Case D: Disparity Exceeds Threshold
Listing 2. Case A (case_conform.ttl): conformant evidence graph satisfying all obligation types.
B. Case B: Missing Explanation Case B (case_missing_explanation.ttl) contains full logging and provenance but omits the explanation artefact. It should fail profiles that enforce transparency (Fairness, Combined) and pass Accountability. @prefix ex: <http://example.org/okb#> . @prefix prov: <http://www.w3.org/ns/prov#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . ex:svc1 a ex:AIService ; ex:hasDecision ex:dec2 . ex:dec2 a ex:Decision ; ex:hasUsageLog ex:log2 ; ex:allocatedGPUHoursGroupA "120.0"ˆˆxsd:decimal ; ex:allocatedGPUHoursGroupB "110.0"ˆˆxsd:decimal ; ex:fairnessThreshold "0.20"ˆˆxsd:decimal ; prov:wasGeneratedBy ex:act2 . ex:log2 a ex:UsageLog ; ex:cpuTimeSeconds "3600.0"ˆˆxsd:decimal ; ex:timestamp "2026-02-01T10:05:00Z"ˆˆxsd:dateTime . ex:act2 a prov:Activity, ex:Activity ; prov:used ex:model_v1 . ex:model_v1 a ex:ModelArtifact .
Listing 3. Case B (case_missing_explanation.ttl): missing explanation evidence.
Case D (case_disparity_exceeds.ttl) includes full logging, an explanation, and a correct provenance chain, but reports group allocations whose normalised disparity exceeds the declared threshold. It should fail Fairness and Combined profiles. @prefix ex: <http://example.org/okb#> . @prefix prov: <http://www.w3.org/ns/prov#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . ex:svc1 a ex:AIService ; ex:hasDecision ex:dec4 . ex:dec4 a ex:Decision ; ex:hasUsageLog ex:log4 ; ex:hasExplanation ex:exp4 ; ex:allocatedGPUHoursGroupA "200.0"ˆˆxsd:decimal ; ex:allocatedGPUHoursGroupB "50.0"ˆˆxsd:decimal ; ex:fairnessThreshold "0.20"ˆˆxsd:decimal ; prov:wasGeneratedBy ex:act4 . ex:log4 a ex:UsageLog ; ex:cpuTimeSeconds "3600.0"ˆˆxsd:decimal ; ex:timestamp "2026-02-01T10:15:00Z"ˆˆxsd:dateTime . ex:exp4 a ex:Explanation ; ex:explanationURI "http://example.org/evidence/ explanations/dec4"ˆˆxsd:anyURI . ex:act4 a prov:Activity, ex:Activity ; prov:used ex:model_v1 . ex:model_v1 a ex:ModelArtifact .
Listing 5. Case D (case_disparity_exceeds.ttl): quantitative fairness violation.
C. Case C: Missing Model Artifact
E. Expected Outcomes by Profile
Case C (case_missing_model_artifact.ttl) provides a provenance activity but does not link it to a model artefact via prov:used. It correctly fails under Accountability and Combined profiles: A5Shape targets ex:Activity, which is co-typed on all activity nodes alongside prov:Activity.
Table VI summarises intended and observed conformance behaviour. All outcomes match expected behaviour.
@prefix ex: <http://example.org/okb#> . @prefix prov: <http://www.w3.org/ns/prov#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . ex:svc1 a ex:AIService ; ex:hasDecision ex:dec3 . ex:dec3 a ex:Decision ; ex:hasUsageLog ex:log3 ; ex:hasExplanation ex:exp3 ; ex:allocatedGPUHoursGroupA "120.0"ˆˆxsd:decimal ; ex:allocatedGPUHoursGroupB "110.0"ˆˆxsd:decimal ;
TABLE VI E XPECTED CONFORMANCE OUTCOME BY PROFILE AND CASE . ✓ = PASS ; × = FAIL . Case
Acct.
Fair.
Combined
A: Conformant B: Missing explanation C: Missing model artefact D: Disparity exceeds
✓ ✓ × ✓
✓ × ✓ ×
✓ × × ×