PaperlayerView exact revision on arXiv

Source-linked AI summary

ClinGuard: a governance framework for reliable, transparent, and auditable clinical coordination

Kaiyuan Wu, Aditya Nagori, Nicoleta J. Economou, Robert M. Califf, Rishikesan Kamaleswaran

arXiv:2610.31354v1cs.CY

TL;DR

Clinical coordination often leaves referrals, follow-up, and discharge tasks open-loop, while generated text alone cannot verify that work was completed. ClinGuard wraps agent proposals in policy-bound transactions with independent validation, limited-privilege execution, and auditable monitoring; retrospective bench tests report increased throughput, but do not establish performance in live clinical use.

  • Problem

    Coordination workflows can leave referrals, results, and discharge steps unverified, while generated text may imply completion without a real state change.

    Source: §1 · p. 2

  • Method

    ClinGuard governs patient-scoped transactions by independently checking agent proposals against auditable data and versioned rules before limited-privilege execution and monitoring.

    Source: §1 · pp. 2–3, §3.2 · p. 4, §4.1.1 · p. 6

  • Results

    2.0 to 66.4 transactions per minute throughput was measured, with no failure or saturation through 32 clients and 23.6–27.6 seconds end-to-end median latency.

    Source: Load and latency · p. 15

  • Takeaways & Limitations

    The fixed supervisory layer is designed to let institutions evaluate agents through policy manifests, audit traces, and shadow-mode autonomy performance rather than unverified performance claims.

    Source: Procurement based on policy inspection · p. 16

    Bench measurements from one workstation, a hosted model interface, and retrospective corpora do not predict latency or reliability under sustained production load, live feeds, or concurrent clinical users.

    Source: §9 · p. 17

Abstract

from arXiv · show

ClinGuard is a model-agnostic governance framework that treats clinical coordination as patient-scoped, policy-bound transactions rather than free text. An independent sentinel layer validates and governs agent-proposed actions, escalates when needed, and executes approved actions through limited-privilege connectors. Each transaction is linked to a tamper-evident audit record, while an outcomes monitor informs future autonomy decisions. Using MIMIC-IV-FHIR and skilled-nursing-facility placement, we distinguish retrospective demonstration from proposed prospective evaluation in this work.

1 Introduction

Clinical coordination often fails through untracked handoffs and missing closure, not merely knowledge gaps. ClinGuard proposes a model-agnostic governance layer that validates agent proposals, governs transactions, and records and monitors their execution; the work distinguishes retrospective demonstration from prospective clinical evaluation.

1 Introduction

  • Open-loop referrals, follow-up, and discharge workflows leave tasks unverified, while generated text can mask hallucinations, omissions, or apparent completion without a state change.The paper frames these as failures of state tracking, verification, and closure, motivating a controllable system that treats actions as verifiable transitions.Source: §1 · p. 2, §3.2 · p. 4
  • ClinGuard makes coordination a governed, patient-scoped state transition, independently validating agent proposals against auditable data and versioned rules before limited-privilege execution.Its proposed transactions are monitored to closure, with escalation when delayed or uncertain; the sentinel remains fixed when the agent changes.Source: §1 · pp. 2–3

Scope of evidence.

  • The framework and proof of concept were exercised over MIMIC-IV-FHIR, not in live care; the paper makes no claim of prospective clinical efficacy, safety benefit, or workload reduction.The paper separates retrospectively demonstrated capabilities from items specified but not implemented and those reserved for prospective evaluation.Source: Scope of evidence · p. 3

2 Related work and positioning

  • Unlike tools limited to drafting, conversational monitoring, or post-deployment drift detection, ClinGuard evaluates each proposed action before execution and records its decision.The paper positions it as a clinical, FHIR-native instantiation of external model oversight; cited related work includes Sentinel Agents [30].Source: §2 · pp. 3–4

3.1 Put the language model inside a controllable system

  • Language models handle semantic extraction, drafting, and candidate generation, while deterministic ClinGuard components handle compliance, authorization, and execution.Transactions bind to versioned institution and payer constraints; execution uses privilege-scoped connectors, and each transaction produces an audit-grade record.Source: §3.1 · p. 4, §3.3 · p. 4, §3.4 · p. 5

3.6 Outcomes close the loop and govern autonomy

  • Time-stamped transaction events track latency, safety intercepts, and subgroup disparities, informing task-specific autonomy and circuit-breaker downgrades.Third-party vendor tools can be normalized into a common schema and checked against local policies before becoming pathway steps.Source: §3.6 · p. 5, §3.7 · p. 5

3.8 Four sentinel functions and risk-tier-aware design

  • ClinGuard organizes runtime oversight around monitor, validate, govern, and escalate, with thresholds adjusted to workflow risk.High-acuity workflows use tighter drift thresholds and stricter validation; low-acuity workflows favor automated revision over blocking.Source: §1 · p. 3, §3.8 · p. 5

4 Platform architecture: execution, accountability, outcomes

ClinGuard separates agent proposals from deterministic oversight through a modular architecture for execution, accountability, and outcome monitoring. Transactions pass policy and evidence checks before execution, leave tamper-evident records, and can trigger human escalation or reduced autonomy.

4.1 Overview: three supervisory modules plus an external-actor, internal-critic governance loop

  • Three supervisory modules provide execution, accountability, and measurement, while an external coordinating agent proposes actions and an internal sentinel checks them against fixed governance artifacts.The actor and critic remain outside one another’s optimization loop; model substitution changes the adapter, not the governance artifacts, ledger, or autonomy ladder.Source: §4.1 · p. 6, §4.1.1 · p. 6, What keeps the layer model-agnostic · p. 11

4.1.2 Cross-tier contracts and secure data flow

  • Typed contracts separate read-only, purpose-bound context, structured proposals, and signed authorization over compiled actions and policy versions.A transaction advances a pathway-defined state graph from trigger and time-stamped context through verdict, audit artifact, limited-privilege execution, and monitoring to closure.Source: §4.1.2 · p. 6, §4.2 · p. 7

4.2 Coordination transactions: explicit state transitions with closure

  • Before execution, the sentinel checks permissions, evidence provenance, pathway and policy mapping, completeness, risk tier, and human accountability; failures return revision, veto, or escalation directives.Uncertainty from low-confidence concept resolution triggers revision or escalation rather than autonomous approval.Source: §4.2 · p. 7, §4.3 · p. 7

4.3 Sentinel critic implementation: gates, predicates, and concept resolvers

  • The critic combines structured contract checks, versioned rule and ontology validation, and optional sandboxed concept resolvers; thresholds are pathway-level defaults calibrated by risk and unit context.Deployment-wide invariants require every state-changing action to pass the gate sequence, every claim to have a source pointer, and every verdict to be recorded.Source: §4.3 · pp. 7–8

4.4 Evidence abstraction: pluggable evidence sources via an evidence-adapter interface

  • Evidence adapters normalize heterogeneous sources for arbitration against local context, while Module A compiles pathway specifications into workflow-native actions.Module B binds claims to source pointers and versions, records the decision, and appends a cryptographically linked envelope; the ledger is tamper-evident, not absolutely immutable.Source: §4.4 · p. 8, §4.5 · p. 8, §4.6 · pp. 8–9

4.7 Module C: outcomes monitor

  • Module C monitors closure, safety, equity, drift, and alert fatigue, linking actions to downstream outcomes so routine operating data can change permitted autonomy without changing the model or guideline.Consensus entropy is treated as a deviation alarm against a unit-specific shadow-mode baseline, not an optimization target.Source: §4.7 · pp. 9–10

4.7.1 Event processing and circuit-breaker actuation

  • Per-transaction signals can lower autonomy within seconds and stop an action in flight, whereas rolling-window population signals can lower autonomy but cannot stop an action already in flight.CUSUM detects persistent departures from a shadow-mode baseline while limiting responses to isolated outliers; the baseline is reset after pathway, policy, or model changes.Source: §4.7.1 · p. 10

4.8 Silent-failure prevention: revise, veto, rollback, and escalation

  • Missing prerequisites trigger revision, prohibited transitions trigger veto and escalation, and reversible failures can be retried or rolled back; a kill switch supports pathway shutdown.Runtime requirements include deployment within the institution’s trust boundary, declarative pathway specifications, and recorded build provenance; configuration changes undergo regression testing and shadow-mode review.Source: §4.8 · p. 10, §4.9 · p. 10, Where the system runs · p. 10

5 Operationalization in clinics: integration, governance, and autonomy

ClinGuard operationalizes oversight through purpose-bound EHR integration, versioned governance artifacts, and tiered autonomy. Its design maps monitoring, traceability, access controls, and escalation to regulatory guidance while retaining human oversight for higher-risk actions.

5.1 Integration and knowledge grounding

  • SMART-on-FHIR integration logs purpose-bound reads, authorizes write-backs only after assurance-tier approval, and binds clinical claims to source pointers and a time-stamped snapshot.Unsupported claims are rejected to avoid moving-target ambiguity during review.Source: §5.1 · p. 11

5.2 Governance artifacts and ownership

  • Policies, pathway specifications, and monitoring definitions carry stable identifiers, versions, accountable owners, approvers, and testable acceptance criteria in a manifest registry.Updates require regression testing and shadow-mode promotion before higher autonomy is enabled.Source: §5.2 · pp. 11–12

5.3 Alignment with regulatory guidance for clinical artificial intelligence

  • The framework maps transaction-time authorization, reconstructable ledger traceability, limited-privilege access, and outcome and equity monitoring to health-system, regulatory, and standards guidance.The paper says ClinGuard supplies instrumentation for organizational responsibility rather than replacing that responsibility.Source: §5.3 · pp. 12–13

5.4 Supervised dynamic autonomy and circuit breaker

  • Autonomy is granted per task type, pathway version, and unit context: Level 0 drafts without execution, Level 1 requires human approval, and Level 2 is limited to defined low-risk administrative actions.Telemetry degradation can trigger an automatic downgrade and route remaining workflow tasks to human review.Source: §5.4 · p. 13

6 Pilot domain and broader application family

The paper uses skilled-nursing-facility placement as a measurable example of a broader family of coordination workflows. It proposes a prospective stepped-wedge trial to test clinical outcomes, distinguishing that plan from the retrospective demonstrations reported elsewhere.

6.1 Why the family of coordination workflows is the right wedge

  • Routing, acknowledgment, and closure challenges recur across six workflows, including discharge, hospital-to-home transitions, specialty referrals, prior authorization, medication refills, and rural handoffs.The paper presents skilled-nursing-facility placement as a stringent, high-volume, well-measured baseline and supplies a planned evaluation roadmap for the six scenarios.Source: §6.1 · p. 13

6.2 Worked example: skilled-nursing-facility placement

  • For skilled-nursing-facility placement, the coordinator drafts facility-specific referral packets, and ClinGuard checks completeness, payer constraints, and capability matches before authorized outreach.The episode tracks sent, received, reviewing, and accepted-or-declined states for deadline-aware escalation and closure.Source: §6.2 · pp. 13–14

6.3 Planned stepped-wedge trial (Duke Health)

  • The proposed Duke pragmatic stepped-wedge cluster-randomized trial would move inpatient discharge units from usual care through Level 0 shadow mode to Level 1 copilot mode with human sign-off.Primary outcomes are event-timestamped latency to placement closure and transaction rework; secondary outcomes include safety intercepts, near-misses, and equity-stratified performance.Source: §6.3 · p. 14

7 Bench-scale characterization of the governance plane

Bench characterization measures engineering performance rather than clinical benefit. The outlook frames multi-site, multi-domain coordination as the next step beyond a single-institution pilot.

Scope of inference.

  • The reference implementation was exercised retrospectively, and its bench-scale tests do not establish clinical benefit or production performance.The characterization used one workstation and a hosted model interface; no transaction reached approval.Source: §7 · p. 14, Scope of inference · p. 15, §9 · p. 17

Load and latency.

  • Throughput rose from 2.0 to 66.4 transactions per minute without failure or saturation through 32 clients.End-to-end median latency was 23.6–27.6 seconds; measured governance stages contributed 0.74–0.98% of transaction time.Source: Load and latency · p. 15

Interception of non-conforming transactions.

  • 91.1% of Synthea mutants and 87.4% of MIMIC-IV-FHIR mutants were intercepted across five injected fault classes.These tests verify injected mechanisms, not sensitivity to naturally occurring errors; the fault set was derived from the gate contract.Source: Interception of non-conforming… · p. 15

Audit and actuation cost.

  • A 100,000-entry ledger chain verified in 656 milliseconds with no integrity error.Median append time remained 0.032–0.039 milliseconds across 100 to 100,000 entries.Source: Audit and actuation cost · p. 15

Governance artifacts as durable infrastructure.

  • Governance artifacts are intended to outlast individual model backends, allowing the same versioned pathways and predicates to supervise replacement models.The paper presents this as a durable institutional asset over a multi-year horizon.Source: Governance artifacts as durable… · p. 16

Federation as a compliance commons.

  • Shared, versioned governance manifests could let smaller institutions adopt and inspect policies rather than authoring them from scratch.The proposed federation makes policies available for transparent inspection, contestation, and reuse across health systems.Source: Federation as a compliance commons · p. 16

Procurement based on policy inspection.

  • The proposed procurement model compares vendors through inspectable policy manifests, audit traces, and shadow-mode autonomy performance rather than unverified claims.Third-party verification under documented governance is proposed as a prerequisite for procurement and ongoing operation.Source: Procurement based on policy inspection · p. 16

9 Limitations

  • Deployment remains constrained by vendor write-back, site-specific validation, policy maintenance, residual data and human risks, and fail-closed availability dependence.The framework cannot overcome vendor-side write-back limitations natively; local environments require validation, while exceptions may increase escalation volume and alert fatigue.Source: §9 · pp. 16–17

Competing Interests

The authors disclose a pending provisional patent application covering the manuscript’s multi-agentic governance systems and methods. The figures depict ClinGuard’s architecture, risk-aware transaction and autonomy flows, and bench-scale characterization.

Competing Interests

  • Three authors are inventors on a pending U.S. provisional patent application covering the manuscript’s multi-agentic governance systems and methods.The other authors report no competing financial or non-financial interests.Source: Competing Interests · p. 18

Figures

  • Figures 1–5 depict ClinGuard’s modules, risk-tiered pillars, data-access tiers, transaction lifecycle, and sequential sentinel gates.Approved actions use limited-privilege execution; failed gates stop the sequence and can trigger revision or escalation.Source: Figure 1 · p. 23, Figure 2 · p. 24, Figure 3 · p. 25
  • Figures 6–7 connect monitored outcomes and dynamic autonomy with six workflows spanning acuity and latency targets.Monitoring can trigger autonomy downgrades and escalation.Source: Figure 6 · p. 28, Figure 7 · p. 29
  • Figure 8 characterizes per-gate latency across 674 transactions and interception rates across 1,000 mutants generated from 200 frozen proposals.The caption notes that the lower missing-prerequisite interval reflects policies firing on every unmutated control in this corpus.Source: Figure 8 · p. 30

Use of Generative AI Tools

Generative AI tools assisted with manuscript brainstorming and language polishing, not new scientific analyses, results, or conclusions. The supplementary materials provide implementation artifacts and worked examples grounded in MIMIC-IV FHIR, using skilled-nursing-facility placement as an example.

Use of Generative AI Tools

  • Generative AI tools were used for brainstorming and language polishing, not to generate scientific analyses, results, or conclusions.All authors reviewed and edited the manuscript and take responsibility for its final content.Source: Use of Generative AI Tools · p. 37

Supplementary information

  • The appendices provide implementation artifacts, worked examples, and supporting results, including contracts, ledger schemas, calibration materials, and validation steps for institutional porting.The appendix list also includes a worked timeline and candidate evaluation metrics.Source: Supplementary information · p. 37
  • The supplementary schemas, contracts, and worked examples use MIMIC-IV FHIR and skilled-nursing-facility placement, while the artifact contracts apply across six coordination workflows.The appendix narrative distinguishes plain-language terms from code and schema identifiers retained verbatim for implementers.Source: Supplementary information · p. 38

Appendix A. Evidence-adapter interface and evidence-item normalization

Appendix A describes adapters that normalize evidence from different sources into provenance-bearing EvidenceItem objects for local arbitration and logging. Its illustrative contract and example lead into Appendix B’s pathway specification, which defines episode states, transitions, prerequisites, exceptions, and closure.

Appendix A. Evidence-adapter interface and evidence-item normalization

  • Evidence adapters normalize source-specific evidence into a source-agnostic EvidenceItem with provenance, strength grade, and applicability.The platform locally arbitrates evidence, compiles validated recommendations into actions, and logs the action basis in the decision record.Source: Appendix A · p. 38

A1. Evidence-adapter interface (illustrative contract)

  • The illustrative adapter contract accepts a query and minimum-necessary local context, calls a source-specific system, and returns normalized evidence items.The interface is transport-agnostic, with required operations and request and response schemas defining the contract.Source: A1. Evidence-adapter interface… · p. 38

A2. Example evidence item (normalized object)

  • The example evidence item records source and version, applicability, contraindications, and a policy claim about PASRR before qualifying SNF placement.The example includes a Moderate, source-native strength grade and retrieval time.Source: A2. Example evidence item (normalized… · p. 40

Appendix B. Illustrative pathway specification (YAML)

  • A pathway specification defines episode states, allowed transitions, prerequisites, exceptions, and closure; the SNF example has analogous specifications across five other named pathways.The listed analogues are hospital-to-home, prior authorization, specialty referral, transitional heart-failure, and rural-health hand-off pathways.Source: Appendix B · p. 40

Appendix C. Example action (electronic health record objects)

The appendix illustrates how ClinGuard compiles recommendations into guarded, reviewable EHR actions and applies versioned predicates and calibrated thresholds to uncertain inputs.

C1. Example object

  • The action bundle turns validated recommendations into workflow-native orders, tasks, referrals, messages, and education, with guardrails and human sign-off for higher-risk actions.Its example includes a draft SNF referral, follow-up appointment request, patient education, and case-management tasks.Source: C1. Example object · pp. 41–43

C2. Policy-predicate definitions and uncertainty-aware concept resolvers

  • Policy predicates use deterministic, versioned rules over structured inputs when possible; unresolved or low-confidence values prompt revision or escalation rather than autonomous execution.When structured inputs are unavailable, a sandboxed concept resolver may propose a value with confidence.Source: C2. Policy-predicate definitions and… · p. 44

Threshold calibration mirrors main paper Section 4.3.

  • Thresholds are pathway-specific starting defaults, calibrated by risk tier and unit context rather than treated as universal constants.Higher thresholds are expected for irreversible or high-acuity actions; calibration tracks alert-fatigue and safety indicators.Source: Threshold calibration mirrors main… · p. 44

Appendix D. Decision-record example

The decision record captures the evidence, policies, alternatives, verdict, action, and timing for a transaction. A worked SNF placement example shows a missing PASRR document leading to revision and a completion task.

Appendix D. Decision-record example

  • A transaction’s audit-grade decision record captures the evidence consulted, policies applied, alternatives considered, verdict, action sent, and timestamps for clinical and governance review.The example binds the record to a context snapshot and FHIR pointers, including patient, medication, observation, and discharge-document references.Source: Appendix D · p. 45, Worked example:… · p. 46

Worked example: skilled-nursing-facility placement transaction

  • A missing PASRR document fails policy validation, blocks packet submission, and prompts revision to obtain and attach the form before creating a completion task.The transaction also records required sign-off and a pending execution status.Source: Worked example:… · pp. 46–47

Appendix E. Outcome specification: event-time-stamped metrics

The appendices specify event-based outcome measurement, monitoring and autonomy controls, console functions, surveillance reporting, and supporting audit schemas. Their SNF example defines both pathway events and metrics to monitor.

Appendix E. Outcome specification: event-time-stamped metrics

  • An outcome specification defines a pathway’s start and closure events, intercepts, latency targets, and equity stratifiers.For SNF placement, the example starts at the discharge-to-SNF order and closes at acceptance or documented alternate disposition.Source: Appendix E · p. 48, E1. Example event model and metrics · p. 48

E1. Example event model and metrics

  • SNF metrics include time to closure, rework, contraindication intercepts, subgroup completion gaps, avoidable delay, agreement patterns, edge-riding, drift, and safety events.Consensus entropy is treated as deviation from a unit-specific, pathway-versioned baseline, not as an absolute failure threshold.Source: E1. Example event model and metrics · pp. 48–49

E2. Outcome-driven autonomy governance

  • Autonomy is granted per task type, pathway version, and unit context, with monitoring and circuit-breaker downgrades tied to safety, latency, and subgroup indicators.The guidance also calls for stable safety-intercept rates and low rollback frequency before scaling autonomy.Source: E2. Outcome-driven autonomy governance · p. 49

Appendix F. Operator console (tasks, governance, auditability) of the demo

  • The operator console surfaces patient-scoped outputs, task queues, validation and escalation decisions, autonomy controls, emergency stop, and ledger-integrity checks.Its task-management view presents proposed actions as trackable, human-reviewable work items and flags episodes requiring escalation.Source: Appendix F · p. 50, Figure S1 · p. 51, Figure S2 · p. 51

Appendix G. Sentinel surveillance checklist for Responsible Use of AI in Healthcare

  • The surveillance checklist maps seven Responsible Use of AI in Healthcare elements to ClinGuard control points and artifacts.It frames operational surveillance around measuring deployment behavior, detecting drift and bias, capturing safety events, and triggering governance action.Source: Appendix G · p. 53, Table S1 · p. 54

G1. Safety-event reporting bundle

  • High-severity intercepts or circuit-breaker events can produce safety-event reports for incident review and optional de-identified external reporting, linked to immutable hashes and governance versions rather than raw patient narrative.This linkage is presented as the basis for audit-grade post-deployment surveillance.Source: G1. Safety-event reporting bundle · pp. 53–55

Appendix H. Full audit-ledger and decision-record schemas

  • The full schemas distinguish the ledger envelope, which establishes authenticity and ordering, from the payload, which records the context, proposal, critique, and resulting action.The field-level schemas are intended for downstream implementers and auditors.Source: Appendix H · p. 56

H1. Audit-ledger envelope schema (full)

These appendices detail the audit envelope and payload, a worked transaction timeline, evaluation targets across workflows, and governance procedures for calibration and predicate promotion.

H1. Audit-ledger envelope schema (full)

  • The ledger envelope groups fields that establish hash-chain position, bind entries to transactions and policy versions, and identify what produced each verdict.The schema also describes external chain-head witnesses and evaluator-image digests for detecting truncation and reconstructing decisions with the original evaluator.Source: H1. Audit-ledger envelope schema (full) · pp. 56–57, Table S2 · p. 56

H2. Decision-record payload schema (full)

Appendix I. Worked-example timeline (one skilled-nursing-facility transaction)

  • The worked timeline pairs workflow events at each waypoint with the corresponding immutable audit-ledger record; its timing is illustrative and based on MIMIC-IV-FHIR.The appendix says the same timeline structure applies to other coordination workflows with adjusted timing and acuity.Source: Figure S5 · p. 59, Appendix I · p. 59

Appendix J. Per-workflow evaluation metrics for the six coordination scenarios

  • The evaluation roadmap maps six coordination scenarios to failure modes, sentinel controls, candidate KPIs, risk tiers, and sentinel pillars; only SNF placement is implemented with MIMIC-IV-FHIR data.The other workflow rows are prospective extensions, not reported outcomes.Source: Appendix J · p. 60, Table S4 · p. 61

Appendix K. How thresholds, predicates, and escalation conditions are set and checked

  • Configurable quantities are either deployment-wide invariants or locally adjustable tunables constrained to declared, versioned ranges.The appendix specifies calibration, change authority, predicate tests, and audit records.Source: Appendix K · p. 63, Table S5 · p. 63

K2. Calibrating a threshold

  • Threshold calibration starts in shadow mode, records verdicts without execution, and uses a few hundred transactions per pathway and unit as a working minimum rather than a validated universal sample size.Independent clinicians adjudicate a stratified sample enriched near the cutoff; promotion and recalibration follow review and material changes.Source: K2. Calibrating a threshold · pp. 63–64

K3. What a policy predicate must pass before it can block anything

  • Predicates must pass must-fire, must-not-fire, and must-abstain tests before promotion; changes rerun these cases and a stored transaction corpus.Newly blocked transactions require review, while newly allowed transactions require named approval before promotion.Source: K3. What a policy predicate must pass… · p. 64

K4. Uncertainty and escalation

This appendix presents bench-scale measurements of uncertainty handling, transaction safeguards, ledger behavior, and model usage, then outlines how to adapt and validate ClinGuard at a new institution. The measurements do not establish live clinical performance, and portability requires local configuration and validation.

K4. Uncertainty and escalation

  • Unresolved resolver results route by risk tier to a navigator for administrative ambiguity or a credentialed clinician for high-risk clinical ambiguity.The ledger records both the resolver output and human decision, and adjudicated cases enter the calibration set.Source: K4. Uncertainty and escalation · p. 64

K5. What is recorded, and why it matters later

  • Each tunable’s recorded value, range, pathway, unit, adjudicated sample, rationale, approver, and recalibration date support reconstruction of its setting and justification.Source: K5. What is recorded, and why it… · p. 64

Appendix L. Supporting bench-scale results

  • The appendix reports supporting results for the evaluation design in the main text.Source: Appendix L · p. 64

L1. Per-gate latency decomposition

L2. Diurnal surge arm

  • The surge arm compressed 275 encounter starts into the bench window, applying a 1.8× multiplier at the 07:00, 15:00, and 23:00 nursing shift boundaries.The resulting profile peaks at those hours.Source: L2. Diurnal surge arm · p. 65, Table S7 · p. 65

L3. Ledger scaling, chain verification, and breaker actuation

  • Append latency remained stable with chain depth; the kill switch actuated in 0.131 ms and the veto-rate breaker in 0.472 ms after its triggering condition.The tail digest is held in memory and revalidated against file size; an externally altered file is reread before append.Source: L3. Ledger scaling, chain… · p. 66, Table S8 · p. 66

L4. Transaction-conformance fault suite

Related papers

Loading 2610.31354v1…