Review Reports

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The authors proposed a communication paper called “XAI-Compliance-by-Design” to integrate the GDPR requirements in explainability feature of AI systems. The proposed model consists of  two layers architecture and five functional layers, namely,  1) Data, 2) Model, 3) Explanation, 4) Audit, and5) Interface. The authors proposed utilizing a mini-case in network anomaly detection to show how decision provenance, model lineage, and human-in-the-loop mechanisms can be embedded within MLOps pipelines.

The paper's idea is technically sound.

 

Major issues:

 

1. The proposed system is theorical with no practical results such as quantitative metrics, or comparative analysis with SOTA methods which limits the evaluation of which limits assessment of the proposed method practical feasibility.
2. The paper does not distinguish the proposed work from existing MLOps practices, governance polices, or XAI integration approaches, nor does it provide a justification for ignoring such comparison.

 

Abstract:

=======

• The abstract includes various technical terms (dual-layer architecture, upstream/downstream flows, correspondence matrix) without sufficient details for a general readership, making it difficult to understand.
• Keywords are not ordered alphabetically.

 

Introduction (Section 1):

====================

• The manuscript claims that "a significant gap remains" without proper citation of recent work exposing the research gaps in XAI engineering practice.
• The citation to "ISO/IEC 42001 standard" is incomplete (marked with [?]) and it should be fixed.
• The description of the main contribution of this work: "formulation of a modular framework" and "correspondence matrix" is unclear and should be explained in light of the existing XAI integration methodologies SOTA.
• The phrase "fully aligned with emerging European best practices" is very generic and not supported by proper citation. The authors should list the practices or standards being covered in this work.
• The research question(s) and other hypothesis/assumptions should be highlighted in a better way in the introduction section.

Technical Background and Motivation (Section 2):

=========================================

• The authors claim that many AI systems lack "native mechanisms for decision provenance"; this contradicts the SOTA MLOps platforms (MLflow, Kubeflow, etc.) that provide these capabilities even partially. The authors should mention why these SOTA included in these sentences by defining what specific gaps the proposed framework bridges.
• The motivation of the paper does not clearly explain why SOTA (e.g., model cards, datasheets for datasets, MLOps audit trails) are insufficient.

 

Proposed Framework: XAI-Compliance-by-Design (Section 3):

==================================================

• Line 75: "sytematic" is misspelled; should be "systematic."
• Figure 1 provides insufficient details to grasp the interactions between figure’s components; the authors should add labels for data flows, list the protocols/interfaces, and clarify what "XAI metrics" and "compliance indicators" are being exchanged. For instance, the bottom yellow box includes text "Synchronization of XAI metrics...". But the arrows connecting to it are just lines. For the readership, it is not clear if it pulls data or if layer push data.
• Lines 109-128: The layers discussion is at a high-level requirement specification rather than a technical contribution. The authors should discuss layer’s implementation details or key differences of these proposed layers that are not found in the SOTA MLOps practices.
• Table 1: The correspondence matrix lacks a valid mapping methodology between the two columns. The authors should add justification for why these proposed mappings are valid and required by the AI system.

 

 

 

• Model Layer (lines 113-116): The authors should cite a paper to explain the difference between "intrinsic" and "induced" transparency.
• Explanation Layer (lines 117-120): The authors didn’t cite any work to show how fidelity and stability metrics are calculated or what thresholds trigger compliance violations.

 

Conceptual Mini-Case (Section 3.3):

=============================

• The proposed case study is only theoretical without any practical evidence ( such as quantitative results, comparative baselines, or performance metrics).
• The authors also ignores considering the computational overhead introduced by SHAP calculations and audit logging tasks of the real-time network monitoring.

Technical Discussion and Practical Implications (Section 4):

=================================================

• Lines 163-165: While the authors expose the computational overheads from SHAP/LIME, they didn’t propose any solutions to their proposed framework.
• Lines 166-170: Figure 1 has no mention to the security and privacy considerations for audit logs.
• Lines 180-184: The authors’ claims about "reducing compliance costs" and "enhancing institutional trust" are not supported without case studies, user evaluations, or cost-benefit analyses. The authors should address this critical point.

Conclusions and Future Perspectives (Section 5):

=========================================

• This section described the contributions by claiming "significant innovation" without and support of the practical part, i.e., implementation.

Minor Comments:

================

1. Line 75: "sytematic" should be "systematic"
2. Line 27: Incomplete citation marker [?] for ISO/IEC 42001 standard
3. Line 222: Inconsistent citation formatting; ensure all DOIs follow the same format

Table and Figure Captions:

Figure 1 caption is not self-contained. it should specify what each color represents, what the arrows represent (data flow, control flow, or both), and also the abbreviations should be defined.

Comments for author File: Comments.pdf

Author Response

For clarity, comments are numbered sequentially.

Comments (R1): The proposed system is theoretical and provides no practical results (e.g., quantitative metrics) and no comparative analysis with state-of-the-art (SOTA) methods, which limits assessment of practical feasibility.
Response (R1): Thank you for this major point. We agree that feasibility must be assessable even in a short communication without reported measurements. To address this without introducing unsupported numbers, we added an implementation-oriented “Evidence-by-Design Evaluation Protocol” that specifies (i) measurable indicators, (ii) baseline configurations for comparison, and (iii) the audit-ready artefacts that must be produced so the framework can be empirically validated in follow-up work in a reproducible way.
Changes made (R1): Added the “Evidence-by-Design Evaluation Protocol” (Section \ref{sec:eval_protocol}) and revised the Conclusions to avoid any phrasing that could be read as reporting measured improvements.

Comments (R2): The paper lacks a comparison with existing solutions, even qualitative. Please add a baseline comparison table.
Response (R2): We agree. Because the manuscript does not report measured results, we added a qualitative, capabilities-based comparison that clarifies (a) what common documentation and MLOps practices typically provide, (b) what governance-oriented frameworks specify at a high level, and (c) what our framework adds specifically in terms of evidence routing, governance triggers, and audit-ready bundling.
Changes made (R2): Added a capabilities-based, non-quantitative comparison table (Table \ref{tab:sota_caps}) and a short paragraph positioning the framework relative to mainstream MLOps toolchains.

Comments (R3): The abstract is too dense. It needs to be simplified and clearer about the contribution.
Response (R3): We agree and revised the abstract to reduce jargon and to state the contribution in simple operational terms: (i) a modular architecture that routes explainability outputs and technical traces into audit-ready evidence across the lifecycle, and (ii) a mapping matrix that links regulatory anchors to concrete evidence artefacts and triggers, plus (iii) an evaluation protocol appropriate for a paper without reported measurements.
Changes made (R3): Rewrote the abstract to emphasise the practical “evidence routing” contribution and the evaluation protocol, while avoiding claims of measured performance.

Comments (R4): Keywords should be in alphabetical order.
Response (R4): Agreed. We alphabetised the keywords to comply with the guideline.
Changes made (R4): Updated the keyword list to alphabetical order.

Comments (R5): The introduction needs stronger motivation and more recent references to show the gap between XAI and compliance/audit needs.
Response (R5): Thank you. We strengthened the motivation by explicitly framing the gap as an “evidence gap”: explainability outputs are often produced as isolated technical artefacts that do not become structured, queryable, audit-ready evidence linked to provenance, human oversight actions, and governance decisions. We also added/placed references to recent work and governance/risk frameworks to support this gap statement.
Changes made (R5): Expanded the Introduction and the Technical Background to explicitly state the evidence gap and to support it with governance and XAI survey references.

Comments (R6): There is a missing citation for ISO/IEC 42001 or an unresolved reference in the text.
Response (R6): Thank you for catching this. We corrected the ISO/IEC 42001 reference so that it compiles cleanly and points to the correct bibliographic entry.
Changes made (R6): Fixed the ISO/IEC 42001 citation key/entry and verified that the manuscript compiles without unresolved references.

Comments (R7): The description of the main contribution should be explained in light of existing SOTA XAI integration methodologies.
Response (R7): We agree and clarified the positioning. The manuscript does not propose a new explanation algorithm; instead, it addresses how explainability artefacts become governance-operational. Concretely, our novelty is the explicit routing and standardisation of evidence (logs, explanation summaries, drift reports, review actions) into decision records and audit-ready bundles, together with defined governance triggers and versioned compliance parameters that can reconfigure technical operation over time.
Changes made (R7): Clarified the contribution statement and strengthened the “governance integration” positioning in the Introduction/Background; emphasised evidence routing, decision records, and governance triggers as the key differentiator.

Comments (R8): The framework should describe how it supports continuous monitoring and periodic updates, especially for data drift and concept drift.
Response (R8): Thank you. We made continuous compliance explicit by treating drift monitoring (data drift / concept drift) and explanation stability as governance-relevant indicators that can trigger review, mitigation, and policy/threshold updates. This is reflected both in the framework description and in the Discussion (continuous compliance under drift).
Changes made (R8): Added/expanded the discussion of drift monitoring and explanation stability as lifecycle governance signals, including how these signals feed triggers and parameter updates.

Comments (R9): It would be helpful to include a brief illustrative example or mini case study showing how the framework works end-to-end.
Response (R9): Agreed. We added a concise conceptual mini-case (network anomaly detection) to illustrate how each layer emits evidence, how human oversight and audit actions are captured, and how governance feedback updates versioned parameters that constrain subsequent technical execution.
Changes made (R9): Added the “Conceptual Mini-Case” subsection illustrating end-to-end evidence routing and feedback closure.

Comments (R10): Section 2 lacks a clear problem statement and specific gaps that the proposed framework addresses.
Response (R10): We agree and made the problem statement more explicit by defining the “evidence gap” and by stating what is missing in typical deployments: compliance-oriented evidence schemas, governance triggers, and audit-ready bundling that links explanations, lineage, and human actions at the decision level.
Changes made (R10): Strengthened the problem framing in Section \ref{sec:tech_background} and aligned it with the capabilities-based comparison table.

Comments (R11): Some terminology is unclear or inconsistent (e.g., evidence, compliance artefacts, decision records). Please define terms.
Response (R11): Thank you. We added operational definitions to ensure consistent, implementation-oriented usage across the manuscript.
Changes made (R11): Added an “Operational definitions” block defining compliance evidence, decision records, upstream technical flow, downstream compliance flow, and the Compliance-by-Design Engine.

Comments (R12): Minor typo (e.g., “sytematic” should be “systematic”).
Response (R12): Corrected. Thank you.
Changes made (R12): Fixed the typo in the revised manuscript.

Comments (R13): Figure 1 and/or its description should make the loop closure explicit (how governance feedback actually reconfigures technical execution).
Response (R13): We agree. We clarified that governance feedback is materialised as versioned compliance parameters (policy-as-code rules, promotion gates, thresholds, retention controls) that are persisted by the Engine and then consumed by the upstream technical flow at explicit enforcement points (training/validation, deployment, inference-time checks, and post-deployment monitoring). This makes the compliance flow a closed loop rather than a one-way “backward arrow”.
Changes made (R13): Updated the framework text around Figure 1 to explicitly state how feedback becomes executable configuration consumed by the technical flow; ensured the figure/caption language reflects “evidence input” and “governance feedback” routing via the Engine.

Comments (R14): Table 1 is too general; please provide more concrete examples of evidence artefacts and governance triggers.
Response (R14): Thank you. We refined the matrix to include explicit “audit-ready” evidence artefacts (e.g., decision provenance record, signed artefact manifest, drift report) and concrete trigger examples (e.g., stability below monitoring criterion; schema completeness check failure; integrity verification mismatch; drift threshold exceedance). We keep thresholds configurable because they depend on domain and risk context.
Changes made (R14): Revised Table \ref{tab1} entries to be more concrete and added clearer trigger phrasing.

Comments (R15): The mapping methodology for the Technical–Regulatory Correspondence Matrix should be explained.
Response (R15): Agreed. We added a short “mapping methodology” paragraph that explains how anchors are selected and how each row is derived from (i) a verifiable duty, (ii) a minimal evidence artefact, (iii) a producing mechanism, and (iv) a trigger that prompts governance action.
Changes made (R15): Added the “Mapping methodology (how Table \ref{tab1} is constructed)” paragraph immediately before the matrix.

Comments (R16): Ensure references are up to date and that regulatory citations are properly anchored.
Response (R16): Thank you. We reviewed the regulatory and standards anchors used in the manuscript and ensured that the text consistently cites the intended sources for GDPR, the EU AI Act, and the referenced ISO/NIST governance frameworks.
Changes made (R16): Checked/adjusted placements of key regulatory/standards citations for consistency (no new empirical claims added).

Comments (R17): The architecture/figure may be read as duplicated layers; please clarify the representation.
Response (R17): We agree and added a clarification that the parallel layer depiction is role-specific (technical vs compliance responsibilities) and does not represent duplicated system components.
Changes made (R17): Added an explicit sentence clarifying that layers are displayed in parallel to avoid ambiguity and do not imply duplicated components.

Comments (R18): Since there are no results, the manuscript should be explicit about limitations and provide a clearer evaluation plan.
Response (R18): We agree. Beyond adding the evaluation protocol, we also revised the Discussion and Conclusions to clearly state the limitation (no reported measurements) and to position any potential benefits as evaluation targets rather than demonstrated outcomes.
Changes made (R18): Strengthened the limitation statements and added the Evidence-by-Design evaluation plan (Section \ref{sec:eval_protocol}); revised Conclusions accordingly.

Comments (R19): SHAP/LIME and other XAI techniques can add overhead; please discuss how to manage runtime/storage costs.
Response (R19): Thank you. We added a focused discussion of operational overhead and practical mitigation patterns compatible with MLOps, including tiered evidence generation, sampling/windowed computation, caching/deduplication, and asynchronous evidence emission to decouple inference latency from logging throughput.
Changes made (R19): Added the “Operational overhead” discussion and explicit mitigation patterns (Section “Overhead, log security, and regulatory evolution”).

Comments (R20): Figure 1 does not mention security and privacy considerations for audit logs.
Response (R20): We agree. We added a security/privacy treatment framing evidence stores as security-critical assets, including integrity protection, access control, encryption, and retention minimisation aligned with GDPR principles.
Changes made (R20): Added an “Audit log security and privacy” paragraph and ensured Figure 1’s caption reflects this framing.

Comments (R21): Please discuss audit scalability and how the approach supports reproducibility during audits.
Response (R21): Thank you. We added a paragraph explaining how automation via standardised evidence schemas, version control of artefacts/policies, and metadata tracking supports reproducibility and reduces manual reconstruction effort during audits (without claiming measured reductions).
Changes made (R21): Added an “Audit scalability and reproducibility” paragraph in the Discussion.

Comments (R22): Please avoid overstating benefits (e.g., “reduces audit effort”) without evidence.
Response (R22): Agreed. We revised wording to avoid implying demonstrated improvements. Where we mention potential operational benefits, we use cautious phrasing (e.g., “may”) and explicitly frame them as evaluation targets under the protocol rather than validated outcomes.
Changes made (R22): Softened benefit statements in the Discussion and Conclusions; aligned claims with the “no measured results” limitation.

Comments (R23): The Conclusions should not read as if compliance is achieved; please align with the conceptual nature of the work.
Response (R23): We agree and revised the Conclusions to emphasise that the paper provides an engineering blueprint and an evaluation protocol, not validated compliance or quantified improvements.
Changes made (R23): Revised Conclusions and Future Perspectives to foreground limitations and future empirical validation.

Comments (R24): Ensure consistent use of terms throughout (evidence, artefacts, triggers, parameters).
Response (R24): Thank you. We harmonised terminology using the operational definitions and ensured consistent phrasing across the framework description, the matrix, and the Discussion.
Changes made (R24): Standardised terminology and cross-checked usage against the operational definitions block.

Comments (R25): Clarify the meaning of upstream vs downstream flows and the Engine’s role.
Response (R25): We clarified that the upstream technical flow produces predictions/explanations and emits structured evidence, while the downstream compliance flow carries governance feedback (review outcomes, incident actions, policy/threshold updates). The Engine coordinates both by maintaining XAI metrics, decision records, and versioned compliance parameters that are consumed by technical enforcement points.
Changes made (R25): Clarified flow definitions and reinforced the Engine’s coordination role in the framework text and in Figure 1 caption language.

Comments (R26): Please ensure DOI formatting is consistent across references.
Response (R26): Thank you. We reviewed the bibliography to ensure DOI formatting is consistent and complete where applicable.
Changes made (R26): Normalised DOI formatting across the reference list (bibliography file).

Comments (R27): Figure caption should be self-contained and define acronyms.
Response (R27): Agreed. We expanded the caption to explain the meaning of solid vs dashed arrows, describe the Engine’s coordination role, and define acronyms used in the caption.
Changes made (R27): Updated Figure 1 caption to be self-contained and to define EU AI Act, GDPR, and XAI.

Reviewer 2 Report

Comments and Suggestions for Authors

A very interesting and promising short article. My comments are in the attached pdf.

Comments for author File: Comments.pdf

Author Response

For clarity, comments are numbered sequentially.

Comments (R2-1): The EU AI Act can still change substantially (e.g., simplification), so the paper should acknowledge regulatory evolution and how the proposal remains usable under change.
Response (R2-1): We agree and we now treat regulatory change as an explicit lifecycle condition. We added a dedicated paragraph explaining that governance obligations, triggers, and documentation duties may evolve, and that the framework therefore models policies/thresholds/documentation requirements as versioned configuration items rather than hard-coded assumptions.
Changes made (R2-1): Added the paragraph “Regulatory change as a lifecycle condition” in Section 4.1 (“Overhead, log security, and regulatory evolution”), including the Digital Omnibus reference, and clarified that governance parameters are versioned and auditable.

Comments (R2-2): Please clarify how the framework can be adjusted to new regulatory requirements in practice, and how governance outputs affect technical operation.
Response (R2-2): We agree and clarified that the compliance flow closes the loop by updating executable configuration that is then consumed by the technical flow at explicit enforcement points. Concretely, governance feedback is materialised as versioned compliance parameters (policy-as-code rules, promotion gates, monitoring thresholds, retention controls) persisted by the Engine and enforced during training/validation, deployment, inference-time checks, and post-deployment monitoring.
Changes made (R2-2): Expanded the “Compliance-by-Design Engine” paragraph in Section 3 to explicitly state loop closure via versioned compliance parameters consumed by the upstream technical flow.

Comments (R2-3): One reference is a 2017 preprint; please replace it with a peer-reviewed source and/or authoritative documentation.
Response (R2-3): We agree. We removed the 2017 preprint and replaced it with peer-reviewed and/or authoritative sources, updating the bibliography accordingly to avoid reliance on non-peer-reviewed material.
Changes made (R2-3): Updated the reference list by removing the 2017 preprint and revising citations where needed.

Comments (R2-4): Bias is increasingly important for AI regulation; please strengthen the paper with a clear treatment of bias/fairness in the governance discussion.
Response (R2-4): We agree and added an explicit treatment of bias and fairness as first-class governance risk signals. We clarify that bias/fairness checks are not optional diagnostics but governance indicators that must produce audit-ready evidence and support traceable escalation and human oversight.
Changes made (R2-4): Added “Bias and fairness as core risk signals” in Section 4.1 and incorporated the suggested bias/fairness reference.

Comments (R2-5): The discussion should better connect “continuous compliance” to operational monitoring (e.g., drift) and explainability stability over time.
Response (R2-5): We agree and strengthened the operational explanation of continuous compliance under drift. We now state that maintenance requires monitoring data drift and concept drift, and also “explainability regression” (stability of explanations/attributions over time), with governance triggers for review and recalibration when thresholds are exceeded.
Changes made (R2-5): Expanded the paragraph “Continuous compliance under drift” in Section 4.1 to explicitly include drift + explanation stability as governance-relevant indicators with actionable triggers.

Comments (R2-6): The paper is conceptual; please clarify what can be evaluated and how future work can validate the proposal without overstating claims.
Response (R2-6): We agree. Because the communication does not report measured results, we added a minimal, reproducible Evidence-by-Design Evaluation Protocol specifying baselines, indicators (performance, explainability quality, governance coverage, overhead, monitoring efficacy), and audit-ready artefacts that must be produced to enable empirical validation in follow-up work.
Changes made (R2-6): Added the “Evidence-by-Design Evaluation Protocol” (Section 3, label \ref{sec:eval_protocol}) and ensured that the Conclusions frame any benefits as evaluation targets rather than demonstrated outcomes.

Reviewer 3 Report

Comments and Suggestions for Authors

1. The architecture description (5 layers, two streams) should be expanded. The implementation details are missing, for example: - How exactly are upstream and downstream streams synchronized via the Compliance-by-Design Engine? - What specific APIs, protocols, or tools are offered? - How is compatibility with existing MLOps platforms (MLflow, Kubeflow, etc.) ensured?
2. It is necessary to add a section describing quantitative and qualitative metrics for evaluating the effectiveness of the framework (for example, reducing the risks of GDPR violations, improving auditability, reducing labor costs for compliance).
3. Performance issues (overhead from XAI methods), log security, and audit scalability are noted, but no specific solutions or architectural patterns are proposed to address them. 

Author Response

For clarity, comments are numbered sequentially.

Comments (R3-1): The architecture description (5 layers, two streams) should be expanded. The implementation details are missing, for example: (i) how exactly are upstream and downstream streams synchronized via the Compliance-by-Design Engine? (ii) what specific APIs, protocols, or tools are offered? (iii) how is compatibility with existing MLOps platforms (MLflow, Kubeflow, etc.) ensured?

Response (R3-1): Thank you. We agree and expanded the manuscript to make the synchronization and integration surfaces explicit, without claiming a full implementation. We now clarify that the two flows are closed via the Compliance-by-Design Engine through versioned compliance parameters (e.g., policy-as-code rules, monitoring thresholds, promotion gates, and retention controls) that are persisted and then enforced at explicit upstream checkpoints (training/validation, deployment, inference-time checks, and post-deployment monitoring). To address “how” this integrates in practice, we added an Implementation note (interfaces) stating that the Engine can be realised through standard MLOps integration surfaces—artifact registry / tracking APIs, evidence-store query interfaces, message buses (for asynchronous evidence emission), and policy-as-code repositories (for versioned governance parameters). Finally, we explicitly frame mainstream toolchains (e.g., MLflow/Kubeflow-style pipelines) as lifecycle substrates over which the proposed evidence-routing layer is added, preserving interoperability while making evidence schemas, triggers, and audit-ready bundling first-class requirements.

Changes Made (R3-1): Expanded the architecture description to clarify synchronization via versioned compliance parameters and explicit enforcement points; added an “Implementation note (interfaces)” adjacent to Figure 1; strengthened the “Relation to mainstream MLOps toolchains” explanation to state how evidence routing overlays MLflow/Kubeflow-style stacks.

Comments (R3-2): It is necessary to add a section describing quantitative and qualitative metrics for evaluating the effectiveness of the framework (e.g., reducing GDPR violation risks, improving auditability, reducing labour costs for compliance).

Response (R3-2): We agree. Because this communication does not report measured results, we addressed this request without inventing values by adding an Evidence-by-Design Evaluation Protocol. The protocol defines (i) baseline configurations for comparison (documentation-only MLOps controls vs. evidence-routing governance), (ii) quantitative and qualitative indicators (model performance, explainability stability/consistency, governance coverage via evidence-schema completeness, operational overhead, and monitoring/incident trace completeness), and (iii) the audit-ready artefacts that must be produced (versioned evidence bundles, governance-parameter change logs, and minimal report templates). In addition, we revised wording in the Discussion/Conclusions to avoid unsupported benefit claims, framing any potential reduction of manual audit effort as an evaluation target rather than a demonstrated outcome.

Changes Made (R3-2): Added the “Evidence-by-Design Evaluation Protocol” subsection (baselines, indicators, required artefacts); adjusted Discussion/Conclusions to keep benefits non-assertive and tied to future empirical validation under the protocol.

Comments (R3-3): Performance issues (overhead from XAI methods), log security, and audit scalability are noted, but no specific solutions or architectural patterns are proposed to address them. Also, regulation change can impact scalability.

Response (R3-3): Thank you. We agree and expanded the manuscript with framework-compatible, implementable patterns. We now (i) identify the main overhead sources (explanation computation and evidence logging), and propose mitigations such as tiered evidence generation (minimal provenance per decision, higher-fidelity artefacts in audit/sampling modes), asynchronous evidence emission (message queues), sampling/windowed computation for monitoring, and caching/deduplication of explanation summaries and baselines. We also (ii) treat evidence stores as security-critical assets, detailing integrity protection (e.g., hash chaining / signed manifests), role-based access control, encryption in transit/at rest, and retention minimisation aligned with GDPR proportionality. For (iii) audit scalability and reproducibility, we emphasise automation via standardised evidence schemas, version control of artefacts/policies, and audit-ready bundling to support consistent reconstruction of decision provenance and oversight context. Finally, for (iv) regulatory evolution, we clarify that governance requirements (policies, triggers, thresholds, documentation duties) are handled as versioned configuration items, enabling controlled updates without rewriting technical modules while preserving traceability.

Changes Made (R3-3): Expanded the “Overhead, log security, and regulatory evolution” discussion; added/strengthened explicit design patterns (tiered evidence, asynchronous emission, sampling/windowing, caching/deduplication, secure evidence stores); clarified “regulatory change” handling via versioned governance parameters; linked overhead/security/scalability aspects to the evaluation indicators in the protocol.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

The authors addressed all of the reviewer's concerns. The paper is ready for publication in its current form.

Reviewer 3 Report

Comments and Suggestions for Authors

The authors have taken into account all the comments, no additional corrections are required.