Algorithmic Transparency Through Semantic Governance: An Ontology-Driven Multidimensional LegalTech Architecture ^†

Abstract

LegalTech systems increasingly automate high-stakes legal reasoning, yet existing governance frameworks offer narrative guidance without a machine-interpretable link between regulatory obligation and technical execution. This paper presents the Multidimensional Architecture for LegalTech Governance (MALTG), a Web Ontology Language (OWL DL) ontology whose five layers unify enterprise standards with a dedicated LegalTech semantic domain in one knowledge graph. The bimodal audit method (BAM) operationalises governance auditing, combining graph-topological centrality (Channel A) with binary compliance classification over nine regulatory dimensions (Channel B). The audit yields a class-weighted ordinal Global Transparency Index (GTI) of approximately 81, an uncalibrated ordering rather than a measurement. The principal finding is a maturity gap in the LegalTech layer (domain score 69.1), which simultaneously shows the highest governance centrality (17) and both HIGH-RISK components. A tolerance analysis over 20,000 perturbed audits shows that the ranking withstands $\pm 10$ points of rater error. Scores were elicited by the authors without independent raters—the study’s principal methodological limitation, which resampling cannot offset because it models random error, not systematic bias. Once an architecture is encoded, the governance provenance of its algorithmic components can therefore be derived mechanically, traced to explicit regulatory controls (General Data Protection Regulation (GDPR) Art. 22; EU Artificial Intelligence Act (AI Act) Art. 13 ) and re-audited at a linear cost.

1. Introduction

Algorithmic systems are now embedded in high-stakes legal workflows: contract review, predictive litigation, electronic discovery (eDiscovery) and compliance automation. The EU General Data Protection Regulation (GDPR) [1], the Artificial Intelligence (AI) Act [2] and the Electronic Identification, Authentication and Trust Services (eIDAS) 2.0 Regulation [3] require automated decisions to be explained and governance evidence to be auditable. Current LegalTech architectures lack machine-interpretable representations of their own governance structures: compliance evidence remains scattered across deliverables and control matrices in natural language, so demonstrating that a decision was taken under an identifiable governance regime is a manual, non-reproducible exercise.

Algorithmic transparency covers both the human-readable explanation of model outputs and the structural verifiability of the sociotechnical system in which those algorithms operate [4,5,6]. Of its four usual components—explainability, interpretability, auditability and fairness—the latter two are structural properties of the system rather than of a single model and are therefore the ones that a governance ontology can represent and expose to inspection. Semantic governance extends this by requiring governance rules and compliance constraints to be encoded for automated reasoning [7].

2. Related Work

The Legal Knowledge Interchange Format (LKIF) [7] supplies upper-level legal concepts, and LegalRuleML [8] adds deontic operators; both target norm representation rather than enterprise governance. Ontology-based accountability for machine learning [9] moves towards machine-verifiable compliance, but not across governance frameworks. On the enterprise side, ArchiMate [10] and The Open Group Architecture Framework (TOGAF) [11] lack legal semantics; the Control Objectives for Information and Related Technologies (COBIT) [12] define governance objectives that map naturally to OWL annotation properties; and the Cybersecurity Framework (CSF) of the National Institute of Standards and Technology (NIST) [13] contributes the five-function cybersecurity structure.

Table 1 contrasts MALTG with the closest artefacts along the four dimensions that matter for the present claim; each dimension is individually well covered there. What we cannot find in the literature is an artefact that combines the four and exposes the combination as an executable audit. We state this as a gap that could not be filled in the literature rather than as proof of absence.

Table 1. Positioning of MALTG against the closest artefacts. Legal: models legal concepts or norms. Multi-FW: spans more than one enterprise governance framework. Alg. transp.: supports assertions about the governance provenance of an algorithmic decision. Executable audit: ships a procedure that recomputes the assessment from the artefact itself.

Artefact	OWL DL	Legal	Multi-FW	Alg. Transp.
LKIF [7]	Yes	Yes	No	No
LegalRuleML [8]	No	Yes	No	No
FIDES [9]	Yes	No	No	Yes
ArchiMate [10]	No	No	Yes	No
TOGAF [11]	No	No	Yes	No
COBIT [12]/NIST CSF [13]	No	No	Partly	No
MALTG (this paper)	Yes	Yes	Yes	Yes

The binary comparison in Table 1 understates the distance from FIDES, the closest artefact on the executable audit dimension, so it is worth stating what separates them. FIDES makes a machine learning system accountable by representing the forecast and the procedure that produced it: reusing ML-Schema, it records the training data, the base algorithm, the hyperparameters and the development-time performance, so that a query can recover why a given prediction was issued [9]. Its unit of accountability is therefore the model and its production pipeline, and it is demonstrated on an energy efficiency forecasting case. MALTG’s unit is a different one: the organisational control environment surrounding a component—which framework control governs it, under which regulatory dimension and at what assessed maturity—which is what an audit trail under GDPR Art. 22 or EU AI Act Art. 13 has to establish. The distinction is not one of quality but of object, and it has a concrete consequence: a LegalTech component such as court system integration or legal distributed ledger technology (DLT) notarisation contains no predictive model at all, so the vocabulary that FIDES reuses has no terms to describe it, while, conversely, FIDES answers a question about model provenance that MALTG does not address. The two are complementary layers of the same accountability problem, and a full account of an automated legal decision would require both.

We also make the incremental part explicit. The five-layer architecture is not new: it was introduced in [14] and validated as a structural digital twin in [15]. What this paper adds is the audit procedure (BAM); the class-weighted GTI is quantitative maturity–centrality analysis over the complete 54-class ontology.

This paper closes the above gap through three key contributions: (a) the MALTG ontology, an OWL DL artefact that extends previous multidimensional governance frameworks [14,15,16] by integrating enterprise governance standards with a dedicated domain layer (500 triples, 54 classes and five layers); (b) the bimodal audit method (BAM), a dual-channel audit combining graph-topological inspection with binary compliance classification and mapping AI components to governance chains anchored in regulatory instruments; and (c) a quantitative evaluation covering maturity, centrality, gap and risk flow analyses.

One convention should be fixed at the outset because it recurs throughout. The ontology annotates eight regulatory standards (GDPR, eIDAS, NIS2, NIST CSF, TOGAF ADM, COBIT MEA, the AI Act and the Electronic Discovery Reference Model (EDRM)). Channel B of the audit evaluates nine regulatory dimensions: the same eight plus attorney–client privilege. The asymmetry is deliberate. Privilege is a professional duty owed by counsel, not a published standard with a control catalogue, so it cannot be annotated on a class in the same way; however, a LegalTech component that processes privileged material must still be assessed against it, and omitting it would leave the most jurisdiction-specific obligation outside the audit.

Scope of this study. This is an instrument-level study. We evaluate what the artefact makes derivable, at what cost, and how far its conclusions hold under perturbation, while external validation on independently developed LegalTech architectures remains for future work. Two adjacent questions lie deliberately outside its boundary. The calibration of the maturity annotations would require an independent elicitation campaign; we therefore report the resulting indices as orderings rather than as measurements, and Section 4.4 quantifies how much rater error these orderings tolerate. The usefulness of the audit output to practitioners would require a study with users, which is a different research question with a different methodology and is not attempted here. Figure 1 summarises the procedure actually carried out and marks both boundaries.

Figure 1. Methodological roadmap of the study. The five upper phases were executed here; the technique applied at each phase appears underneath and the artefacts that it produced above. The two figure dashed boxes are the adjacent questions declared to be outside the scope of the paper: calibrating the maturity annotations, which would feed phase 2, and establishing usefulness to practitioners, which would follow phase 5. ORSD: Ontology Requirements Specification Document; CQ: Competency Question; RDF: Resource Description Framework; SPARQL: SPARQL Protocol and RDF Query Language.

3. Materials and Methods

3.1. The Multidimensional Architecture for LegalTech Governance (MALTG)

Figure 2 presents MALTG as five stacked layers, each answering a distinct governance question at a distinct stakeholder horizon: strategic (executive: planning, portfolio, risk, metrics), governance and compliance (enterprise: GDPR, ethics, regulation, audit), operational (tactical: workflows, services, incidents, changes), technology integration (implementation: AI, blockchain, open data and security, five owl classes each) and foundation (standards). Building upon previous multidimensional governance frameworks [14,15], MALTG makes the alignment between technical workflows and enterprise compliance standards explicit and machine-readable.

Figure 2. The Multidimensional Architecture for LegalTech Governance (MALTG). (Left) The five governance layers with their stakeholder horizons and impact classifications. (Right) The foundation layer, which chains governance principles to strategic objectives, architecture, services and security, with the NIST CSF acting as a cross-layer overlay.

The right-hand panel of Figure 2 decomposes the foundation layer into a directed chain of five sub-layers: governance principles (ISO/IEC 38500 [17]), strategic governance (COBIT, what to achieve), enterprise architecture (TOGAF Architecture Development Method, ADM, how to design), service operations (Information Technology Infrastructure Library, ITIL 4, how to execute) and a cybersecurity overlay (NIST CSF, how to secure) that applies transversally to the four sub-layers beneath it.

Orthogonal to the five layers, the LegalTech semantic domain (12 classes) is the primary contribution, covering contract lifecycle management (eIDAS 910/2014), eDiscovery (EDRM), legal DLT notarisation (eIDAS Art. 41), the regulatory compliance engine (GDPR and the Network and Information Security Directive, NIS2), smart legal contracts, attorney–client privilege, the legal knowledge base and court system integration. Fifteen OWL object properties make the model machine-derivable rather than merely diagrammatic: because legaltech_uses_AI relates eDiscovery to the AI layer, enables relates the technology architecture to that layer, and the technology architecture is in turn a subclass of TOGAF; a reasoner derives along this chain that an eDiscovery decision inherits foundation-layer controls without this fact being asserted anywhere. The key cross-layer properties are enables (Tech. Architecture → AI), governs (COBIT EDM → NIST CSF), enforces (security → NIST CSF), consumes (AI → open data), audits (blockchain → security) and the LegalTech bindings legaltech_uses_AI and legaltech_uses_bc. The ontology comprises 500 RDF triples, 54 classes and 15 object and 6 annotation properties over nine governance domains. It annotates eight regulatory standards, which, together with attorney–client privilege—a professional duty rather than a standard—form the $k=9$ regulatory dimensions used by Channel B in Section 3.2. Maturity scores lie in the closed interval $[55,98]$ with a standard deviation of $\sigma =9.42$; the lower bound corresponds to court system integration and the upper bound to architecture vision, as detailed in the gap analysis of Section 4. Table 2 reports the resulting structural metrics of the artefact.

Table 2. Structural metrics of the MALTG ontology. The last two rows make explicit the distinction between the 8 regulatory standards annotated on the classes and the $k=9$ regulatory dimensions evaluated by Channel B, which add attorney–client privilege as a professional duty.

Metric	Value
Total RDF triples	500
OWL classes	54
Object properties	15
Annotation properties	6
Governance domains	9
Maturity score range	$[55,98]$
Maturity score standard deviation	9.42
Global Transparency Index (GTI)	80.89 (ordinal)
Regulatory standards annotated	8
Regulatory dimensions evaluated (Channel B)	9

These metrics describe the size of the graph but not what makes it derivable. This role belongs to the cross-layer object properties of Table 3: each one is the edge along which an obligation asserted in one layer becomes machine-derivable in another. The two legaltech_* bindings are the ones that attach the LegalTech domain to the technology stack—and therefore the ones that make the transparency assertion of Section 4.5 possible.

Table 3. Selected cross-layer object properties of MALTG, with their domains and ranges. Together with the subclass hierarchy, these edges form the chains traversed by Channel A of the audit.

Object Property	Domain	Range
enables	Technology Architecture	AI Layer
governs	COBIT EDM	NIST CSF
enforces	Security	NIST CSF
consumes	AI Layer	Open Data
audits	Blockchain	Security
legaltech_uses_AI	eDiscovery Pipeline	AI Layer
legaltech_uses_bc	Smart Legal Contracts	Blockchain

3.2. The Bimodal Audit Method (BAM)

The BAM answers a single governance question: does the instantiated ontology provide sufficient verifiable evidence to satisfy a compliance assertion? It operates through Channel A (topological graph inspection) and Channel B (binary compliance classification), reported jointly so that a structural weakness and a documentary gap can be distinguished. Let $\mathcal{G}=(V,E)$ be the governance knowledge graph, with V being the OWL classes and E being the directed edges induced by object properties. The Governance Centrality Index $\kappa$ identifies governance hubs—nodes whose failure cascades across layers—and the Domain Governance Score ${\Sigma }_d$ aggregates the maturity annotation $s\left(c\right)\in [0,100]$ over the class subset $C_d$ of domain d:

$$\kappa \left(c\right)={deg}^{+}\left(c\right)+{deg}^{-}\left(c\right),{\Sigma }_d={\displaystyle \frac{1}{|C_d|}}\sum _{c\in C_d}s\left(c\right).$$

(1)

The nine per-domain scores are then aggregated into a single figure of merit:

$$\mathrm{GTI}={\displaystyle \frac{{\displaystyle \sum _{d\in D}\left|C_d\right|{\Sigma }_d}}{{\displaystyle \sum _{d\in D}\left|C_d\right|}}}.$$

(2)

The GTI is proposed as an ordinal governance indicator rather than a validated measurement scale and is weighted by class count so that domains contributing more ontology classes influence the aggregate proportionally; the corresponding unweighted mean over domains would be 82.41. The weighting matters substantively, because the largest domain (LegalTech, 12 classes) is also the least mature.

Channel B evaluates a binary compliance predicate ${\beta }_j$ per regulatory dimension j against a threshold $\theta$, aggregated into a per-class compliance coverage score $\Phi \left(c\right)$ over $k=9$ dimensions (GDPR, eIDAS, NIS2, NIST CSF, TOGAF ADM, COBIT Monitor, Evaluate and Assess (MEA), the AI Act, the EDRM and attorney–client privilege), where $r_j\left(c\right)$ is the set of regulatory annotations of c for dimension j and $\mathbf{1}[·]$ is the indicator function:

$${\beta }_j\left(c\right)=\mathbf{1}\left[s\left(c\right)\ge \theta \wedge r_j\left(c\right)\ne \varnothing \right],\Phi \left(c\right)={\displaystyle \frac{1}{k}}{\displaystyle \sum _{j=1}^k}{\beta }_j\left(c\right).$$

(3)

Each class is finally assigned a risk class $\rho \left(c\right)$ by maturity band: LOW if $s\left(c\right)\ge 85$, MED if $60\le s\left(c\right)<85$ and HIGH if $s\left(c\right)<60$. The audit builds $\mathcal{G}$ from the object–property assertions and then evaluates Equations (1)–(3) for every class, so its cost is $O\left(\right|C|·k)$, and it can be re-run on every ontology commit as a continuous compliance check rather than as a periodic exercise. Listing 1 states the procedure.

Listing 1. Bimodal audit method (BAM) pseudocode. The procedure is linear in the number of classes for a fixed number of regulatory dimensions, $O\left(\right|C|·k)$, which is what allows the whole audit to be recomputed whenever $\theta$ or the score vector $s(·)$ changes. The BAM audit phase operates in $O\left(\right|C|·k)$, excluding ontology reasoning and satisfiability checking.

Require: ontology $\mathcal{O}$, threshold $\theta$.    Ensure: per-class audit report $\mathcal{R}$. 1: Build the directed graph $\mathcal{G}=(V,E)$ from the object properties of $\mathcal{O}$ 2: for each class $c\in C$ do 3: Ch. A: $\kappa \leftarrow {deg}^{+}\left(c\right)+{deg}^{-}\left(c\right)$; $s\leftarrow \mathrm{annotation}(c,\mathtt{score})$; Ch. B: $\beta \leftarrow {\mathbf{0}}^k$ 4: for $j\in \{1,\dots ,k\}$: if $s\ge \theta \wedge r_j\left(c\right)\ne \varnothing$ then $\beta \left[j\right]\leftarrow 1$ end for 5: $\Phi \leftarrow \frac{1}{k}{\sum }_j\beta \left[j\right]$;$\rho \leftarrow$ risk band of s; $\mathcal{R}\leftarrow \mathcal{R}\cup \left\{\right(c,\kappa ,s,\Phi ,\rho \left)\right\}$ 6: end for; return $\mathcal{R}$

Setup. The ontology was parsed with rdflib 6.3.2 (Python 3.10) and checked for OWL DL consistency with the HermiT 1.4.3 reasoner through OWLready2 0.46. Thresholds were set at $\theta =75$ (compliance) and $\theta =60$ (high risk), with maturity scores elicited from domain experts against the standard control catalogues of the corresponding foundation layer framework.

3.3. Ontology Evaluation

Reasoner consistency is a weak guarantee: it establishes only that the axiom set is satisfiable under OWL DL semantics and says nothing about conceptual correctness, coverage or usefulness. We therefore distinguish logical checking from ontology evaluation and report both against the criteria of Table 4.

Table 4. Evaluation of MALTG as an executable instrument. Criteria 1–6 are automated and run on every audit; criteria 7–10 are instrumented, i.e., the interface is implemented and the empirical campaign that populates it is the next step. The distinction delimits the claims made here. Green shading marks automated criteria (1–6); blue shading marks instrumented criteria (7–10).

#	Criterion	Mechanism in the Tool	Status
Automated—executed on every audit run
1	Requirements specification	Purpose, scope, users and five CQs (this section)	Specified
2	Concept coverage	54 classes over 9 domains; 12 LegalTech classes	8 standards covered
3	Relationship coverage	15 object and 6 annotation properties over five layers	All layers linked
4	Logical consistency	HermiT 1.4.3 via OWLready2 0.46	Consistent
5	CQ answering	CQ1–CQ5 executed over $\mathcal{G}$	5/5 answered
6	Comparison with legal ontologies	Qualitative contrast with LKIF and LegalRuleML	Complementary scope
Instrumented—interface implemented; empirical campaign is the next step
7	Structural pitfalls	OWL serialisation read by the OOPS! scanner [18]	Interface exposed
8	Constraint validation	SHACL shapes [19] over score/regulation	Shape targets defined
9	Expert validation	Replaceable score vector $s(·)$ fed by a Delphi panel	Injection point defined
10	Score reliability	Re-run over multiple rater score sets	Simulation supported

MALTG is not a static artefact but an executable governance instrument: the BAM runs in $O\left(\right|C|·k)$ over the serialised graph, so every evaluation criterion is implemented as a parameterised procedure rather than as a one-off manual inspection. This has two consequences. First, criteria 1–6 are automated: they execute on each ontology commit and their outputs are the figures and tables reported in Section 4. Second, criteria 7–10 are instrumented: the tool exposes the interfaces through which they are driven—the OWL serialisation consumed by the OOPS! pitfall scanner [18], the maltg:score and maltg:regulation annotations targeted by Shapes Constraint Language (SHACL) shapes [19] and the replaceable score vector $s(·)$ through which alternative expert panels are injected. Governance evaluation therefore becomes a simulation: varying $\theta$, substituting $s(·)$ or adding shapes regenerates the whole audit, which is what makes threshold sensitivity and multi-rater reliability tractable at all.

The requirements specification fixes the purpose (making the governance provenance of LegalTech algorithmic decisions machine-derivable), the scope (enterprise governance frameworks plus a LegalTech domain) and the intended users (compliance officers, enterprise architects and auditors). Following competency question-driven authoring [20], five competency questions (CQs) operationalise it: CQ1—to which governance controls a given AI component is accountable; CQ2—which LegalTech classes fall below the compliance threshold and under which regulatory dimension; CQ3—which classes are governance hubs whose failure propagates across layers; CQ4—which regulatory instrument anchors each domain; and CQ5—whether every LegalTech class is reachable from a foundation layer control. They are answered, respectively, by Equation (4), the SPARQL query of Section 4.5, $\kappa$ and the anchor column of Table 5 and reachability over $\mathcal{G}$.

Table 5. Channel A results ($\theta =75$): domain maturity ${\Sigma }_d$ and governance centrality $\kappa$, ordered by maturity. N is the number of OWL classes per domain, and the colour of the ${\Sigma }_d$ column encodes the risk band (green: LOW, ${\Sigma }_d\ge 85$; orange: MEDIUM, $60\le {\Sigma }_d<85$). The scores are derived from expert elicitation without a formal panel protocol, so the values should be read as an ordering rather than as calibrated measurements (Section 4.3 reports their stability). Two decimals are shown for the GTI because this is the value that the pipeline computes and the figure needed to reproduce it; the index itself is ordinal, and, in the narrative, it is reported as approximately 81.

Component	Domain	N	${\mathbf{\Sigma }}_{\mathit{d}}$	$\mathit{\kappa }$	Primary Governance Anchor
Enterprise Architecture ADM	TOGAF	7	91.7	15	TOGAF ADM
Security Controls	SECURITY	5	87.6	15	NIST CSF
Artificial Intelligence Layer	AI	5	87.2	14	EU AI Act Art. 13
Technology Integration Core	CORE	3	84.7	12	TOGAF/COBIT bridge
IT Governance Objectives	COBIT	6	84.3	12	COBIT EDM/MEA
Open Data Services	OPEN DATA	5	83.4	13	PSI Directive
Cybersecurity Functions	NIST CSF	6	77.5	15	NIST CSF, NIS2
DLT and Smart Contracts	BLOCKCHAIN	5	76.2	13	eIDAS Art. 41
LegalTech Domain	LEGALTECH	12	69.1	17	GDPR Art. 22, EDRM
Global Transparency Index (GTI)		54	80.89	—	Ordinal; 9 domains

The contribution is therefore the instrument together with the evidence that it already produces: MALTG is a formally checked ontology whose structural and competency adequacy is automatically evaluated on every run and whose domain adequacy—the conceptual correctness of the legal classes, sufficiency of the constraints and usefulness to legal experts—is not asserted here but is made empirically obtainable by criteria 7–10, because the tool reduces each of them to supplying an input and re-executing the audit.

4. Results

4.1. Domain Maturity and Governance Centrality (Channel A)

Table 5 consolidates the Channel A output: per-domain maturity ${\Sigma }_d$ and the centrality $\kappa$ of the top-ranked component of each domain. TOGAF (91.7), security (87.6) and AI (87.2) form the mature core. Applying Equation (2) to the nine domain scores yields an ordinal GTI of approximately 81 (80.89 as computed; Table 5). The central structural finding is an inversion: LegalTech records the lowest maturity (69.1, some 12 points below the index) while exhibiting the highest centrality ($\kappa =17$), so its deficiencies propagate through more governance paths than those of any other domain. This provides rational prioritisation for governance investment, since remediating high-centrality, low-maturity nodes reduces the aggregate risk more effectively than an equivalent investment in peripheral ones.

4.2. Gap Analysis, Architecture Health and Risk Flow (Channels A and B)

Figure 3 and Figure 4 consolidate the remaining evaluation. The radar chart (panel a) makes the LegalTech deficit against the target ($\Sigma =100$) visually dominant, and the Sankey diagram (panel b) shows that LegalTech contributes the widest single flow into the MEDIUM RISK node and, under the reported bands, is the only domain flowing into HIGH RISK; overall, 22 components are LOW RISK (41%), 30 are MEDIUM (56%) and two are HIGH (4%).

Figure 3. Consolidated BAM results. (a) Channel A radar chart, showing theoretical capacity ($\Sigma =100$, blue) versus actual implementation (red). (b) Channel B Sankey flow from governance domains to risk levels; arrow width is proportional to the number of components per path.

Figure 4. Gap analysis (BAM Channel A): maturity scores of each of the 54 components, grouped by governance domain (shaded bands, labelled along the top). The horizontal lines mark the target (100), the compliance threshold ($\theta =75$) and the high-risk boundary ($\theta =60$); colours encode the risk level. Only court system integration (55) and smart legal contracts (58) fall below $\theta =60$, and both belong to the LEGALTECH domain.

Figure 4 shows the gap analysis, which localises the deficit precisely: only court system integration (55) and smart legal contracts (58) fall below the high-risk boundary, both being LegalTech classes, with a further LegalTech cluster between the thresholds (NIS2 compliance (62), legal DLT notarisation (65), eDiscovery pipeline (68), eIDAS compliance (70), legal knowledge base (71)). The architecture is thus mature where the industry has had decades to standardise and immature where legal practice meets automation.

4.3. Threshold and Band Sensitivity

Both $\theta$ and the risk bands were fixed a priori, so the reported figures could, in principle, be artefacts of this choice. Because the BAM is re-executable, we tested it. Table 6 recomputes the audit over the parameter grid.

Table 6. Sensitivity of the audit to the compliance threshold $\theta$ and to the risk band boundaries. (Top) Classes below $\theta$, in total and within the LegalTech domain. (Bottom) Risk distribution for alternative band pairs and whether every HIGH-RISK component is a LegalTech class. The qualitative conclusion of the paper does not change at any of the settings evaluated here.

$\mathit{\theta }$	60	65	70	75
Classes below $\theta$ (of 54)	2 (3.7%)	3 (5.6%)	5 (9.3%)	13 (24.1%)
LegalTech classes below $\theta$ (of 12)	2 (16.7%)	3 (25.0%)	5 (41.7%)	9 (75.0%)
Share of the shortfall that is LegalTech	100%	100%	100%	69.2%
Bands (HIGH $<a$/LOW $\ge b$)	60/80	60/85	65/85	70/85
LOW	32 (59.3%)	22 (40.7%)	22 (40.7%)	22 (40.7%)
MED	20 (37.0%)	30 (55.6%)	29 (53.7%)	27 (50.0%)
HIGH	2 (3.7%)	2 (3.7%)	3 (5.6%)	5 (9.3%)
All HIGH-RISK are LegalTech	yes	yes	yes	yes

Bold: the configuration used throughout the paper.

Three observations follow. First, the ordering of the domain scores is invariant to $\theta$ by construction: $\theta$ enters only the Channel B predicate ${\beta }_j$ and never ${\Sigma }_d$, so LegalTech remains the least mature domain (69.1) at every threshold. Second, across all four band pairs tested, every HIGH-RISK component is a LegalTech class; the band choice moves the counts but not the attribution. Third, the threshold does change the picture in one respect worth reporting: below $\theta =75$, the entire shortfall is LegalTech, whereas, at $\theta =75$, four non-LegalTech components (tokenisation (70), blockchain (74), respond (72) and recover (74)) also fall short, which is why we retain the stricter setting. The central claim of the paper is therefore stable across the parameter settings tested, while the absolute value of the GTI is not independent of them.

4.4. Tolerance to Rater Error and Intervention Scenarios

Section 4.3 varied the audit parameters. This section varies the inputs. Because the maturity scores come from a single elicitation, we cannot report a measured uncertainty for them: with one rater, there is no observed dispersion to estimate. What we can report is a property of the instrument rather than of the data—how much rater error the conclusions would tolerate. Accordingly, $\sigma$ below is a swept parameter, on the same footing as $\theta$, and not a quantity estimated from evidence.

We perturbed every score with independent Gaussian noise, $s^{\prime }\left(c\right)=s\left(c\right)+\epsilon$, $\epsilon \sim \mathcal{N}(0,{\sigma }^2)$ clipped to $[0,100]$, and re-ran the complete audit 20,000 times per noise level (Table 7).

Table 7. Tolerance of the two headline conclusions to independent rater error. Ranking: share of runs in which LegalTech remains the least mature domain. Attribution: share of runs in which every HIGH-RISK component is a LegalTech class. $\sigma$ is a swept parameter, not measured dispersion.

Rater Error $\mathit{\sigma }$ (Points)	2	5	10	15
Ranking preserved	100.0%	99.6%	86.6%	68.0%
HIGH-RISK attribution preserved	100.0%	96.0%	38.2%	4.0%
GTI, mean [5th, 95th pct]	80.9 [80.4, 81.3]	80.8 [79.7, 81.9]	80.5 [78.3, 82.6]	79.7 [76.7, 82.6]

Bold: the noise level ($\sigma =10$) at which the HIGH-RISK attribution becomes unreliable, discussed in the text below.

The two conclusions are not equally solid, and it is worth saying so plainly. The ranking—i.e., LegalTech as the least mature domain—survives up to roughly $\pm 10$ points of independent error per component. The attribution of both HIGH-RISK components to LegalTech is considerably more fragile: at $\sigma =10$, it holds in only 38% of runs. We therefore treat the ranking as a robust finding and the HIGH-RISK attribution as indicative.

A more significant structural caveat lies in the scope of the simulation: while Monte Carlo propagates random error, it remains insensitive to systematic bias, rendering the perturbation model suitable for sensitivity exploration rather than comprehensive uncertainty estimation. Adding a uniform shift to the LegalTech domain shows the exposure directly: systematic $+8$-point optimism about this layer would make BLOCKCHAIN the least mature domain and invert the paper’s central finding. Since the LegalTech layer is also our own contribution, this is precisely the bias that self-elicitation is least able to exclude. No amount of resampling addresses it; only independent raters do, which is why the Delphi campaign described in the Limitations remains necessary rather than optional.

Intervention scenarios. The same re-executability supports a second use that is closer to the decision setting that the instrument is meant to serve. An analyst specifies a target score vector and the audit is recomputed; Table 8 reports four such interventions, with the remediation effort expressed as the total number of maturity points added and ${\Sigma }_{\mathrm{LT}}$ denoting ${\Sigma }_d$ evaluated on the LegalTech domain.

Table 8. Intervention scenarios recomputed by the audit. Effort is the total number of maturity points added by the intervention. LegalTech remains the least mature domain in every scenario, including S4, which lifts all sub-threshold components across the whole architecture. GTI values are given to two decimals here because the scenarios differ by less than one point; the comparison between them is what carries meaning, not the absolute level.

	Intervention	GTI	${\mathbf{\Sigma }}_{\mathbf{LT}}$	HIGH	Effort	Least Mature
S0	Baseline	80.89	69.1	2	—	LEGALTECH
S1	The two HIGH-RISK components to $\theta$	81.57	72.2	0	37 pts	LEGALTECH
S2	All sub-threshold LegalTech to $\theta$	82.37	75.8	0	80 pts	LEGALTECH
S3	Uniform $+5$ across the LegalTech layer	82.00	74.1	0	60 pts	LEGALTECH
S4	All sub-threshold components to $\theta$	82.56	75.8	0	90 pts	LEGALTECH

Two results follow. First, remediating the red components does not repair the domain: S1 clears both HIGH-RISK classes for 37 points of effort, yet LegalTech only moves from 69.1 to 72.2 and remains the least mature domain. Even S4, which lifts every sub-threshold component in the entire architecture, leaves LegalTech last at 75.8. The governance debt is distributed across the layer rather than concentrated in its two worst classes, which is not visible from the gap analysis alone.

Second, the efficiency column is constant at $1/54\approx 0.0185$ across all four scenarios. This is not a coincidence but an algebraic consequence of the GTI being a class-weighted mean: the index responds to how many points are added and is indifferent to where. A scalar transparency index therefore cannot rank competing interventions on its own, and the structural channel is what discriminates between them—which is the empirical argument for the BAM being bimodal rather than a single aggregate score.

The scenario vector is a parameter of the audit, so a governance team can substitute its own targets, costs or constraints and re-run the analysis on its own architecture. We note this as a property of the instrument. It is not evidence of usefulness: establishing that the resulting report changes what a compliance officer decides would require the study described in Section 5, which we have not carried out.

4.5. Verification of an Algorithmic Transparency Assertion

BAM traversal derives the governance provenance of the predictive analytics component:

$$\mathtt{PredictiveAnalytics}\stackrel{\mathtt{subClassOf}}{\to }\mathtt{AI}\_\mathtt{Layer}\stackrel{\mathtt{enables}}{\to }\mathtt{TechnologyArchitecture}\stackrel{\mathtt{subClassOf}}{\to }\mathtt{TOGAF}.$$

(4)

Equation (4) is a derivable transparency assertion: within the modelled architecture, any decision produced by predictive analytics is mechanically traceable to TOGAF architecture controls and, through governs, to COBIT management objectives, supporting compliance assessment with GDPR Art.22 and EU AI Act Art.13. The chain is derived rather than asserted, so it remains valid under ontology evolution as long as the intermediate properties hold. Channel B reporting is operationalised by a SPARQL query over maltg:layer, maltg:score and maltg:regulation returning every LegalTech class below $\theta$—the lower tail of Figure 4. The query is reproduced in Box 1; it is the executable form of CQ2 and is re-run unchanged whenever the ontology or the threshold changes.

Box 1. Channel B compliance query: every LegalTech class below the compliance threshold, with its regulatory annotations.

SELECT ?label ?score ?regulation WHERE {

  ?id a owl:Class ; rdfs:label ?label .

  ?id maltg:layer ‘‘legaltech’’ .

  ?id maltg:score ?score .

  OPTIONAL { ?id maltg:regulation ?regulation }

  FILTER (?score < 75)

} ORDER BY ASC(?score)

5. Discussion

Ontological formalisation moves governance frameworks from prose towards a queryable representation: the 500-triple graph unifies relationships that are otherwise dispersed across TOGAF deliverables, COBIT process documentation and NIST CSF tiers and the GTI supplies a scalar summary that remains decomposable into its per-domain constituents. Within the scope of what is encoded, a governance claim can be answered by a query rather than asserted in prose, so an algorithmic decision inherits a governance provenance derivable up to regulatory instruments—governance-anchored transparency, in line with EU AI Act Articles 9 and 13. This complements model-level explainability rather than replacing it: a counterfactual explanation indicates why this output was produced; a governance chain explains under which controls the producing system was authorised to operate. The LegalTech gap is a regulatory maturity frontier rather than a design failure, since court system integration and smart legal contracts depend on external legal infrastructure that is not yet standardised across jurisdictions.

What has been demonstrated, and what has not. Equation (4) traces a single component over a modelled architecture, not over a deployed system. We have therefore shown that the governance provenance of an algorithmic decision can be derived mechanically once the architecture is encoded, cheaply enough to be re-run continuously. We have not shown that a compliance officer on a live eDiscovery or predictive analytics pipeline obtains a decision-relevant answer from the resulting report: this is left for the end-to-end study considered outside the scope of this work in Section 2—and the next step that we are pursuing.

Limitations. The principal methodological limitation of this study is that the maturity scores were elicited by the authors. The layer that the audit identifies as least mature, LegalTech, is also our own contribution, so the elicitation and the finding share the source. This is a conflict that a resampling analysis cannot resolve: Section 4.4 introduces random perturbations in the scores, whereas the present analysis concerns a systematic deviation. In this case, a uniform bias of several points would remain undetectable among all reported statistics. The subsequent derivations follow directly from this observation. The maturity scores $s\left(c\right)$ are expert-elicited point estimates, gathered without a formal panel protocol and without a second rater, so no inter-rater statistic can be reported. Consequently, ${\Sigma }_d$, the GTI and the risk bands are ordinal indicators computed from unvalidated inputs: the ordering that they induce is stable, as Section 4.3 shows, but the value GTI = 80.89 is reported to two decimals only because this is what the pipeline computes; it carries no calibrated meaning and should not be compared against thresholds from other studies. Criteria 7–10 of Table 4 remain instrumented rather than executed, so no claim of domain adequacy is made.

Section 4.4 bounds this quantitatively and, in doing so, qualifies one of our own claims: the domain ranking tolerates about $\pm 10$ points of independent rater error, but the attribution of both HIGH-RISK components to LegalTech holds in only 38% of runs at this noise level, and a systematic $+8$-point bias in favour of the LegalTech layer would invert the central finding altogether—the exposure identified above. Finally, the ontology encodes a single temporal snapshot.

The programme that would lift these limitations is specific: a Delphi panel of at least nine LegalTech practitioners across the three stakeholder roles of Section 3.3, two rounds with controlled feedback, Krippendorff’s $\alpha$ per domain and the resulting score vectors fed back through $s(·)$ to recompute the audit under each rater set. Until this is run, this paper contributes the instrument and its structural findings, not a calibrated measurement of governance maturity.

6. Conclusions

MALTG is a formally checked OWL DL ontology that makes the governance provenance of LegalTech components machine-derivable and auditable. Integrating an enterprise standards stack with a dedicated LegalTech semantic domain in one 500-triple knowledge graph across five architectural layers supports cross-framework reasoning, while the BAM formalises governance auditing at a linear cost, yielding an ordinal GTI of approximately 81 with component-level risk classification. The primary finding—that the LegalTech layer combines the lowest maturity (69.1) with the highest centrality ($\kappa =17$) and both HIGH-RISK components and survives rater perturbation—motivates targeted investment in smart legal contracts, court system integration and legal DLT notarisation.

These results must be interpreted strictly within their scope. This paper contributes both an instrument and its proof of concept: the audit was executed over an architecture that we ourselves encoded and scored, and no compliance officer has yet employed its output for decision-making. What is established is that governance provenance becomes mechanically derivable once an architecture is formally encoded, and such derivation is computationally inexpensive enough to be repeated continuously. What is not established is whether the resulting report is practically useful to the intended practitioners or whether the maturity figures would withstand independent elicitation. Until both conditions are tested, the practical implications outlined above should be regarded as investment directions revealed by the instrument, rather than validated recommendations.

Future work will execute the instrumented criteria 7–10 of Table 4—OOPS! pitfall scanning, SHACL validation and a Delphi campaign whose rater score sets feed the reliability simulation—and will integrate EuroVoc and temporal versioning axioms.