Epistemic Representation and Uncertainty Quantification in Autonomous Software Systems

The central challenge of probabilistic software systems—particularly those conceptualized for complex, high-stakes environments such as a fictional autonomous kill web—is the phenomenon of uncertainty multiplication. An uncertain observation feeds an uncertain state estimate; that state estimate feeds an uncertain interpretation; the interpretation feeds uncertain option generation. Finally, a polished human-machine interface (HMI) falsely presents the final result as precise, deterministic, or authoritative.
This dangerous pipeline performs “explanation laundering,” a process wherein fragile, deeply uncertain probabilistic guesses are progressively stripped of their caveats, edge-case warnings, and statistical variances. By the time the data reaches a human operator, the cascading uncertainties have been mathematically scrubbed, resulting in a system that output a seemingly authoritative directive. This dynamic induces automation bias—a severe cognitive failure where humans defer to machine outputs even in the presence of accessible, contradictory evidence, assuming the machine possesses a superior, infallible heuristic1.
Numerical confidence does not create authority or evidential sufficiency. A system that outputs a prediction with “95% confidence” has merely stated a statistical property of its own internal model architecture given a specific, finite dataset. It has not stated an objective truth about the physical world. Deep neural networks, in particular, are famously overconfident; they will happily output 99% confidence scores for static noise if the noise falls outside their training distribution4. When software conflates mathematical output logic with operational authority, it causes both errors of omission (failing to act because the machine did not alert) and errors of commission (acting incorrectly because the machine recommended it)1.
This research report outlines how a public software laboratory should rigorously represent uncertainty within a fictional autonomous framework. It strictly avoids the creation of target-confidence systems, target-selection thresholds, weapon-target assignments, or operational engagement recommendations. Instead, the focus remains exclusively on the epistemology of the software: how it models what it knows, how it mathematically bounds what it does not know, and how it communicates its own ignorance to prevent human overreliance.

1. A Conceptual Uncertainty Architecture

To prevent explanation laundering, the system architecture must mathematically isolate different sources of uncertainty rather than collapsing them into a single, deceptive “confidence” score. The architecture relies on three foundational pillars: the decomposition of variance, conformal prediction for distribution-free coverage guarantees, and conformal risk control.

1.1 Aleatoric and Epistemic Variance Decomposition

Predictive uncertainty must be decomposed into two distinct components: aleatoric uncertainty and epistemic uncertainty4.
Aleatoric uncertainty refers to the intrinsic, irreducible noise in the data-generating process. Examples include thermal sensor noise, atmospheric interference, or the inherently stochastic movement of a tracked entity. Aleatoric uncertainty cannot be reduced by gathering more training data or refining the model architecture7. Conversely, epistemic uncertainty represents model ignorance arising from a lack of knowledge, sparse training data, or out-of-distribution (OOD) observations. Epistemic uncertainty is theoretically reducible; gathering more data in the uncertain domain will decrease it7.
The architecture utilizes the Law of Total Variance (Eve’s Law) to perform this decomposition10. If is the target variable (e.g., a spatial coordinate) and is the input evidence, the total variance is:

The first term, , represents the expected value of the process variance (EVPV), which captures the aleatoric uncertainty. The second term, , is the variance of the hypothetical means (VHM), which captures the epistemic uncertainty8. By utilizing a heteroscedastic deep ensemble of lightweight forecast heads over a shared frozen trunk, the software can estimate these terms separately in real-time9. A high aleatoric score indicates that the environment is inherently unpredictable, whereas a high epistemic score indicates that the model is operating outside its training distribution and is essentially guessing. Conflating these two leads to catastrophic systemic failures, as the system might halt operations due to high total variance when the target is merely behaving stochastically (aleatoric), while failing to alert operators when the model is completely blind to a novel environment (epistemic)9.

1.2 Conformal Prediction and Open-Set Recognition

Traditional machine learning models output softmax probabilities that are often heavily miscalibrated and fail to handle out-of-distribution data4. The architecture replaces point predictions with Conformal Prediction (CP) sets. Conformal prediction is a model-agnostic, distribution-free framework that transforms heuristic non-conformity scores into rigorous prediction sets11.
Given a pre-specified error rate (e.g., 0.10), a conformal predictor generates a set that is mathematically guaranteed to contain the true label with probability at least , assuming the underlying data is exchangeable13:

However, in a dynamic autonomous environment, the closed-set assumption (that all possible classes were represented during the training phase) is consistently violated. Standard conformal prediction fails to provide adequate coverage when encountering new labels at test time, and becomes overly conservative when predicting previously seen labels15.
To handle Open-Set Recognition—where the system encounters entirely novel phenomena—the architecture integrates Conformal Good-Turing p-values15. By defining random hypotheses about the empirical frequency of labels, the system leverages the classical Good-Turing estimator (traditionally used in ecology to estimate the probability of discovering an unseen species) to calculate the probability mass of unrepresented classes16. The system tests the hypothesis , which is true if and only if the next observation belongs to a new, unseen class16. If the resulting conformal p-value falls below the threshold, the system expands the prediction set to include an explicit “unseen class” designation. This prevents the system from confidently misclassifying an unknown anomaly into a known category, thereby explicitly communicating its own ignorance16.

1.3 Conformal Risk Control and Distribution Drift

Because autonomous environments are non-stationary, the exchangeability assumption of standard conformal prediction is frequently violated by distribution drift. To maintain valid coverage without requiring continuous ground-truth labels, the architecture implements Adaptive Conformal Inference (ACI)21. ACI dynamically updates the threshold quantile based on an empirical coverage sequence. It uses a learning rate to increase the effective miscoverage level , and thereby the size of the prediction sets, when recent forecasts fail to cover the true outcomes, and shrinks them when coverage is restored22.
Furthermore, the architecture utilizes Conformal Risk Control (CRC) to bound the expected value of any monotone loss function, moving beyond simple miscoverage23. CRC allows the system to bound complex risks, such as the False Discovery Rate (FDR), graph distance, or the conditional value-at-risk (CVaR)25. For a loss function that is non-increasing with respect to a threshold parameter , CRC selects the optimal such that the expected loss on future data remains strictly below 25:

where is the empirical risk on the calibration set, is the sample size, and is the known upper bound of the loss function25. This guarantees that the system’s epistemic representations remain statistically bounded even as the operational environment shifts unpredictably.

2. Evidence-Quality Schema

To trace the provenance and degradation of information, every single observation ingested by the system must be governed by a strict, immutable evidence-quality schema. This schema prevents uncertain, stale, or highly correlated data from being treated as independent, authoritative ground truth by downstream modules.

Every time an observation passes from a sensor node to an estimation node, the transformation_hist array is appended. If a probabilistic output is thresholded or rounded (e.g., converting a 0.82 probability into a boolean TRUE), that transformation is permanently recorded. If downstream modules attempt to ingest this data without accounting for the information lost during the rounding process, the system triggers a type-safety violation.

3. Dependence and Correlation Model

When multiple reports share an underlying source, or when sensors are subject to correlated errors, traditional Bayesian updating (which assumes conditional independence) will artificially inflate the certainty of a state estimate. The system must manage competing hypotheses, contrary evidence, and echo-chamber effects using an advanced formulation of Dempster-Shafer Theory (DST) combined with covariance discounting28.

3.1 Belief, Plausibility, and Conflict in DST

In DST, a frame of discernment represents all mutually exclusive hypotheses. A basic probability assignment (BPA), or mass function , assigns evidence weights to the subsets of such that 30. The Belief () and Plausibility () functions create lower and upper bounds on certainty. The system explicitly represents uncertainty (pure ignorance) as the gap between these bounds: 28.
When combining evidence from two independent sources, Dempster’s rule of combination is traditionally used:

where represents the conflict coefficient between the two sources30.

3.2 Redistribution of Essential Conflict

A known, catastrophic vulnerability in standard DST is Zadeh’s paradox. In situations where there is highly conflicting evidence, combining that evidence via Dempster’s rule yields counterintuitive, highly confident results because the conflict mass is normalized away via the term32. In an autonomous environment with contradictory evidence, normalizing away conflict is a severe form of explanation laundering; the system hides the fact that its sensors are fundamentally disagreeing.
The software architecture must utilize modified conflict redistribution rules. The system calculates an essential conflict metric to distinguish between minor sensor noise and fundamental epistemic disagreement32. If the conflict is deemed essential, the conflict mass is not normalized. Instead, the architecture applies Yager’s rule, wherein the conflict mass is reassigned directly to the universal set . This explicitly increases the system’s quantified degree of total ignorance, representing that the system knows it is receiving contradictory data but does not know which is correct29. Alternatively, under Smets’ open-world assumption, conflict mass is assigned to the empty set , indicating that the true state of the world likely lies outside the current frame of discernment entirely, triggering an open-set anomaly alert34.

3.3 Covariance Discounting for Correlated Evidence

When evidence is highly correlated (e.g., three visual cameras looking through the same smoke plume, or three algorithmic models trained on the exact same dataset), applying standard evidence combination rules will double-count the evidence, leading to rapid, false convergence on a highly confident estimate.
The correlation model utilizes the correlation_group field from the evidence schema. Before combining evidence, the system calculates a correlation coefficient between the sources. If sources belong to the same correlation group, their combined mass is discounted by a factor proportional to their covariance28. This ensures that the sheer volume of highly correlated, redundant reports cannot statistically overcome a single, highly reliable independent report. The system enforces the principle that ten identical reports from a shared source equal the epistemic weight of one report, not ten independent reports.

4. Calibration-Dashboard Specification

A machine learning model is considered perfectly calibrated if, out of all instances where it predicts an outcome with a probability of , the true outcome occurs at exactly a frequency of . The calibration dashboard is the primary instrument for system auditors and developers to verify that the software’s epistemic representations align with empirical reality.

4.1 Murphy’s Brier Score Decomposition

The core metric of the dashboard is the Brier Score (BS), a strictly proper scoring rule that measures the mean squared difference between predicted probabilities and actual binary outcomes36. To provide actionable insights, the dashboard visualizes the Brier score using Murphy’s 1973 three-component decomposition36:


The dashboard must display all three components independently, as an aggregated score hides critical failure modes:

1. Reliability (Calibration): Measures how closely the forecasted probabilities match the observed conditional frequencies within a specific bin. A lower reliability score is better; a score of indicates perfect calibration36. The dashboard tracks the calibration gap to ensure models are not drifting into overconfidence.
2. Resolution (Discrimination): Measures the ability of the forecasts to distinguish situations with different outcome frequencies from the overall climatological base rate . A higher resolution score is better36. A system that simply predicts the base rate every time will have perfect reliability but zero resolution, rendering it operationally useless.
3. Uncertainty: Measures the inherent variance of the base rate, mathematically defined as . This is a property of the data, not the model, and reaches a maximum of when the base rate is 50%36.

4.2 Base Rates and Positive Predictive Value Collapse

The dashboard continuously monitors the underlying base rate of events. When predicting rare events, even a model with 99% accuracy will suffer from a catastrophic collapse in Positive Predictive Value (PPV) due to the base rate fallacy. If the prevalence of an event in the environment is 1 in 10,000, a 1% false positive rate will result in 100 false alarms for every 1 true positive.
The dashboard plots PPV as a continuous function of the shifting environmental base rate. It sets dynamic tripwires, triggering visual alarms if the base rate falls so low that the system’s false positive rate outstrips true positives, explicitly warning auditors that any positive prediction is mathematically likely to be noise.

4.3 Expected Calibration Error (ECE) and Post-Hoc Mitigation

Alongside the Brier score, the dashboard calculates the Expected Calibration Error (ECE). ECE partitions predictions into equally spaced bins and calculates the weighted average of the absolute difference between accuracy and confidence4:

To mitigate high ECE, the dashboard integrates monitoring for post-hoc calibration functions. It verifies the application of temperature scaling (for deep neural networks) or isotonic regression (for non-parametric models) to correct miscalibration without requiring full model retraining5.

5. Reliability-Diagram Specification

The Reliability Diagram (also known as a Calibration Curve) is the primary graphical tool for interpreting the Reliability component of the Brier score and visualizing ECE37. The specification requires the rendering of a specific plot where the x-axis represents the binned predicted probabilities and the y-axis represents the true observed empirical frequency.

• Perfect Calibration Line: A strict diagonal line originating at and ending at .
• Overconfidence Zone: Any plotted curve that falls below the diagonal indicates overconfidence (e.g., the system predicted an event with 90% confidence, but the event only occurred 60% of the time). This is the most dangerous failure mode in autonomous systems, directly inducing automation bias, and is strictly highlighted in deep red41.
• Underconfidence Zone: Any plotted curve that falls above the diagonal indicates underconfidence (e.g., the system predicted 30%, but the event occurred 50% of the time). This indicates untapped predictive power and overly conservative behavior, highlighted in yellow41.
• No-Skill Line: A line defined as , which separates regions of positive resolution from negative resolution37.
• Sharpness Histogram: Placed directly below the main curve, a histogram displays the frequency of predictions residing in each bin (sharpness). A highly calibrated model with all predictions clustered tightly around the ambient base rate lacks sharpness; the histogram ensures auditors can evaluate whether the model actually makes decisive, informative predictions or merely safely hedges its bets.

6. Synthetic Forecasting Tournament Design

To prevent algorithmic stagnation and to rigorously evaluate new uncertainty quantification methods, the software lab must continuously evaluate experimental updates against the incumbent system using a synthetic forecasting tournament, inspired by Philip Tetlock’s methodologies and utilizing the Brier Skill Score (BSS)36.
The tournament architecture feeds synthetic, highly stochastic simulated environments into competing algorithmic branches. Each branch is required to generate probabilistic forecasts for state estimations over a predefined temporal horizon.
The primary evaluation metric is the Brier Skill Score:

Where is the Brier score of a naive, low-effort baseline (e.g., historical climatology or a simple moving average)36. A BSS of 1 indicates perfect skill, 0 indicates no improvement over the baseline, and negative values indicate that the highly complex machine learning model performs worse than a naive guess.
The tournament specifically applies adversarial distribution shifts to the synthetic data streams to test how quickly the Adaptive Conformal Inference (ACI) routines adjust their prediction set sizes to maintain marginal coverage22. Models that fail to expand their uncertainty bounds during distribution drift, or models that normalize away essential conflict, are penalized logarithmically in the tournament rankings.

7. Immutable Fictional Forecast Records

To audit a probabilistic system’s true historical calibration, the system must retain an immutable ledger of all prior forecasts. If a system can quietly overwrite, update, or smooth its past predictions upon learning the ground truth, calculating a valid Brier score or ECE becomes mathematically impossible. This prevents hindsight bias at the architectural level.
The ledger is implemented as a cryptographically signed, append-only log using an event-sourcing architecture (e.g., via a Merkle tree structure). Each forecast entry must contain:

1. Forecast ID & Timestamp: The exact cryptographic moment the prediction was made.
2. Horizon Target Time: The specific future time the forecast applies to.
3. Evidence State Hash: A cryptographic hash of the exact state of the Evidence-Quality Schema at the time of the forecast, proving exactly what the model knew and when.
4. Epistemic Representation: The raw logits, the conformal prediction set output, the estimated aleatoric variance, and the estimated epistemic variance.
5. Resolution Timestamp & Value: An empty field to be appended only when the ground truth is later confirmed by an independent auditing module.

This strict immutability ensures that forensic audits can recreate the exact state of the machine’s knowledge at to determine if a failure at was due to an inherently unpredictable aleatoric event, or a systemic epistemic calibration failure that requires a software patch.

8. Algorithmic Behaviors and Stress Tests for Evidence Failures

The system must predictably degrade when encountering compromised evidence. The architecture mandates rigorous algorithmic responses to ten specific behavioral conditions, which are continually validated via automated stress tests:

9. Abstention and Hold Rules

A well-calibrated probabilistic system must possess the capacity to abstain. The “insufficient evidence” outcome is not a failure of the software; it is a successful manifestation of epistemic humility and statistical integrity.
The software triggers a mandatory Hold Rule (abstention) when any of the following boundary conditions are breached:

• Epistemic Variance Threshold: If the variance of the hypothetical means (VHM) exceeds a predefined safety parameter, indicating that the model is guessing entirely outside its training manifold.
• Open-Set Anomaly: If the Conformal Good-Turing estimator determines the probability of an unseen class exceeds the target error rate 16.
• Base Rate Collapse: If the ambient base rate of the phenomenon drops below the model’s known False Positive Rate.
• Essential Conflict: If the Dempster-Shafer conflict mass remains above 0.4 for multiple successive temporal frames despite the integration of new evidence.

When a Hold Rule is triggered, the system explicitly returns a NULL_EPISTEMIC_VIOLATION to all downstream modules. This aggressively blocks the generation of operational options, preventing a downstream system from taking a “best guess” based on critically flawed data.

10. Interface Requirements that Surface Uncertainty Before Recommendations

The human-machine interface (HMI) is the most critical vector for automation bias. Automation bias stems from a well-documented social psychology phenomenon where humans assign more positive evaluations to decisions made by automated systems than humans, leading to a heuristic replacement of vigilant information seeking1. Under time pressure, humans suffer from omission errors (failing to notice an environmental problem because the system did not alert them) and commission errors (actively following a flawed system directive despite having access to contrary evidence)1.
To combat explanation laundering and automation bias, the interface must be constructed around the following non-negotiable requirements:

1. Status Displays Over Command Displays: The interface must strictly operate as a “status display” (presenting the state of the world and its associated statistical uncertainties) rather than a “command display” (suggesting a specific course of action)42. Command displays induce a “moral buffer,” allowing humans to psychologically distance themselves from the consequences of the action, actively deteriorating their sense of accountability42.
2. Uncertainty Precedes Categorization: The interface must force the user to acknowledge the boundaries of the system’s ignorance before they can view the point-estimate state estimate. Conformal prediction sets must be rendered visually as overlapping, translucent bounding geometries or text lists. A user cannot simply read a tag stating “Object X”; the UI must enforce a layout reading “75% probability of Object X, 20% probability of Object Y, 5% probability of Unseen Class.”
3. Active Mitigation of Complacency: To mitigate automation-induced complacency (where users fail to monitor the system because it is highly reliable under normal conditions), the system must expose the raw unreliability of its sources1. If the system triggers a Dempster-Shafer essential conflict alert, the interface must visually fracture the display, forcing the human operator to manually interact with and resolve the divergent data streams before the system will resume automated tracking.

11. Accessibility and No-JavaScript Requirements

The representation of uncertainty must remain fully legible to all operators, including those using assistive technologies, and must function in austere computing environments where client-side scripting (JavaScript) may fail, be blocked for security reasons, or be unavailable due to bandwidth constraints.

11.1 ARIA Grids and Screen Reader Support

All tabular data, such as conformal prediction sets, reliability diagrams, and evidence schemas, must be structured using strict Web Content Accessibility Guidelines (WCAG) 2.1 and WAI-ARIA standards44. The interface must utilize the role=”grid” pattern46.
Because datasets in this domain are frequently massive and virtualized (where the Document Object Model (DOM) does not contain the whole grid to save memory), the software must explicitly declare:

• aria-rowcount and aria-colcount to define the total size of the matrix, even for unrendered cells.
• aria-rowindex and aria-colindex to define a cell’s position with respect to the total number of rows and columns, ensuring screen readers can announce spatial context46.
• aria-readonly=”true” to ensure screen readers announce the grid as an epistemic representation rather than an editable spreadsheet47.

11.2 Progressive Enhancement and No-JavaScript Fallbacks

The uncertainty architecture cannot rely on JavaScript-heavy canvas elements or client-side rendering frameworks for its core epistemic function. Applying the principle of progressive enhancement:

• The baseline representation must be delivered via standard semantic HTML forms and static SVG graphics rendered entirely on the server.
• If JavaScript is disabled, the user must still be able to read the conformal prediction sets, view the Brier score decompositions in standard HTML tables, and traverse the evidence schema via standard hypertext links.
• Data visualizations must rely on CSS patterns (e.g., cross-hatching, stippling) rather than color alone to differentiate data series. This ensures the visualizations remain understandable in high-contrast mode, monochrome environments, or for users with color vision deficiencies44.

12. Page/API Parity Requirements

A persistent vulnerability in modern software design is the divergence between what the graphical user interface (GUI) displays and what the application programming interface (API) provides. If the GUI carefully displays a conformal prediction set to a human, but the API endpoint allows a downstream client (or another autonomous subsystem) to request GET /api/v1/target/best_guess, the entire uncertainty architecture is bypassed, and explanation laundering occurs machine-to-machine.
The Page/API Parity Requirement mandates structural isomorphism between the frontend rendering and the backend data contract.

• The API must never return a point estimate or a singular confidence score. All endpoints querying state estimations must return an array of possibilities (the conformal prediction set) alongside the explicit value used to generate it.
• The API payload must explicitly include the freshness_score, aleatoric_variance, and epistemic_variance objects.
• If an external system queries an entity that has triggered an Abstention/Hold Rule, the API must not return an empty array or a best-effort guess. It must return an HTTP 409 Conflict or 422 Unprocessable Entity with a strictly typed error detailing the exact epistemic violation (e.g., OOD_DETECTED, BASE_RATE_COLLAPSE, ESSENTIAL_CONFLICT).

13. Test Plan

Validating the uncertainty architecture requires a massive, multi-tiered testing strategy encompassing statistical validation, adversarial algorithmic testing, and human-factors cognitive testing.

14. Prohibited Misleading Visualizations

To enforce strict epistemic hygiene, the design system explicitly prohibits the following UI/UX paradigms, as they are mathematically unsound and psychologically manipulative:

• The Single “Confidence” or “Threat” Score: Representing a complex, multi-dimensional probabilistic state as a single scalar percentage (e.g., “Threat Level: 87%”) is strictly banned. It collapses aleatoric variance, epistemic ignorance, and temporal staleness into a single deceptive number. A single numerical confidence implies authority and sufficiency, triggering immediate automation bias.
• Gauge Charts and Speedometers: These visualizations imply a fixed, deterministic boundary between “safe” and “dangerous.” They completely hide the distribution of the data, the size of the conformal prediction set, and the variance of the underlying evidence.
• Traffic Light Colors (Red/Yellow/Green) for Epistemic States: Using red for “danger” and green for “safe” conflates operational decision-making with statistical probability. Color coding should only represent data freshness or calibration error (e.g., highlighting overconfidence in red on a reliability diagram).
• Point-Estimate Trend Lines without Confidence Intervals: Any temporal graph plotting a state estimate over time must include shaded bands representing the conformal prediction intervals. A naked trend line implies a false deterministic trajectory and hides the exponential growth of uncertainty over time.

15. Developer Backlog

The following epics and user stories are prioritized for the engineering teams to implement this conceptual uncertainty architecture:
Epic 1: Statistical Foundations & Variance Decomposition

• Story 1.1: As an ML engineer, I need to implement heteroscedastic deep ensembles over a frozen trunk to output dual variances, so that the system can separate aleatoric from epistemic uncertainty9.
• Story 1.2: As an ML engineer, I need to develop the Conformal Prediction pipeline to accept ensemble outputs and generate marginal coverage prediction sets for a given .
• Story 1.3: As a data scientist, I need to implement the Conformal Good-Turing estimator, so the system can calculate the probability of open-set anomalies15.
• Story 1.4: As a data scientist, I need to implement Adaptive Conformal Inference (ACI) to recursively adjust the threshold dynamically when distribution drift is detected21.

Epic 2: Evidence Schema and Conflict Management

• Story 2.1: As a backend engineer, I need to implement the immutable Evidence-Quality Schema as a rigid PostgreSQL/JSONB schema with strict type-checking.
• Story 2.2: As an algorithm engineer, I need to build the Dempster-Shafer fusion engine to aggregate basic probability assignments.
• Story 2.3: As an algorithm engineer, I need to implement Yager’s and Smets’ rules for redistributing essential conflict mass to the universal set or empty set, bypassing Zadeh’s paradox29.
• Story 2.4: As a backend engineer, I need to build evidence time-decay functions tied to the collection_time and freshness_score to continuously inflate epistemic variance on stale data.

Epic 3: Calibration, Analytics, and Ledgers

• Story 3.1: As a data engineer, I need to build the backend chron-job to continually calculate the Brier Score and Murphy Decomposition (REL, RES, UNC) across all forecasting models36.
• Story 3.2: As a data engineer, I need to implement Expected Calibration Error (ECE) monitoring and trigger API alerts for severe overconfidence5.
• Story 3.3: As a systems architect, I need to build the cryptographic, event-sourced immutable ledger for all forecast records to prevent hindsight bias.
• Story 3.4: As an ML engineer, I need to build the synthetic forecasting tournament test-harness for CI/CD pipeline integration, utilizing the Brier Skill Score36.

Epic 4: Interface, Parity, and Accessibility

• Story 4.1: As a frontend developer, I need to design and develop the HTML/CSS Reliability Diagrams (Calibration Curves) to visualize over/underconfidence zones41.
• Story 4.2: As an accessibility specialist, I need to implement WAI-ARIA grid specifications (role=”grid”, aria-rowcount) for all data matrices to ensure screen-reader compatibility46.
• Story 4.3: As a full-stack developer, I need to create the “Abstention/Hold” UI state and HTTP 409/422 API responses that block all downstream data flow when epistemic limits are breached.
• Story 4.4: As a frontend developer, I need to conduct progressive enhancement audits, ensuring all uncertainty bounds and HTML tables render correctly with JavaScript forcibly disabled in the browser.

By strictly adhering to these epistemic and architectural boundaries, the software laboratory can build a system that accurately models and communicates its own uncertainty, mathematically precluding the false precision and explanation laundering that inevitably leads to catastrophic human overreliance.

Works cited

1. Automation bias - Wikipedia, https://en.wikipedia.org/wiki/Automation_bias
2. Automation bias: a systematic review of frequency, effect mediators, and mitigators - PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC3240751/
3. Complacency and bias in human use of automation: an attentional integration - PubMed, https://pubmed.ncbi.nlm.nih.gov/21077562/
4. Performance of Conformal Prediction in Capturing Aleatoric Uncertainty - CVF Open Access, https://openaccess.thecvf.com/content/WACV2026/papers/Hagos_Performance_of_Conformal_Prediction_in_Capturing_Aleatoric_Uncertainty_WACV_2026_paper.pdf
5. DELVING INTO TEMPERATURE SCALING FOR ADAP- TIVE CONFORMAL PREDICTION - OpenReview, https://openreview.net/pdf?id=qpI6GO80ri
6. Variational Uncertainty Decomposition for In-Context Learning - NIPS, https://papers.nips.cc/paper_files/paper/2025/file/0343104ddbfc48f35f06aaae88980e48-Paper-Conference.pdf
7. A Posterior-Predictive Variance Decomposition for Epistemic and Aleatoric Uncertainty in Wind Power Forecasting - arXiv, https://arxiv.org/html/2605.22390v1
8. Evidential Uncertainty Quantification: A Variance-Based Perspective - CVF Open Access, https://openaccess.thecvf.com/content/WACV2024/papers/Duan_Evidential_Uncertainty_Quantification_A_Variance-Based_Perspective_WACV_2024_paper.pdf
9. (PDF) Epistemic-Aleatoric Decomposition of Forecast Uncertainty for Deadline-Aware Horizon Truncation - ResearchGate, https://www.researchgate.net/publication/410923028_Epistemic-Aleatoric_Decomposition_of_Forecast_Uncertainty_for_Deadline-Aware_Horizon_Truncation
10. Law of total variance - Wikipedia, https://en.wikipedia.org/wiki/Law_of_total_variance
11. A Gentle Introduction to Conformal Prediction and Distribution-Free Uncertainty Quantification - arXiv, https://arxiv.org/html/2107.07511v6
12. valeman/awesome-conformal-prediction - GitHub, https://github.com/valeman/awesome-conformal-prediction
13. Elements of Conformal Prediction for Statisticians - arXiv, https://arxiv.org/pdf/2603.23923
14. Conformal Prediction Adaptive to Unknown Subpopulation Shifts - arXiv, https://arxiv.org/html/2506.05583v2
15. [2510.13037] Conformal Inference for Open-Set and Imbalanced Classification - arXiv, https://arxiv.org/abs/2510.13037
16. Conformal Inference for Open-Set and Imbalanced Classification - arXiv, https://arxiv.org/pdf/2510.13037
17. Conformal Inference for Open-Set and Imbalanced Classification - arXiv, https://arxiv.org/html/2510.13037v1
18. (PDF) Conformal Inference for Open-Set and Imbalanced Classification - ResearchGate, https://www.researchgate.net/publication/396517730_Conformal_Inference_for_Open-Set_and_Imbalanced_Classification
19. Estimating the size of a set using cascading exclusion - arXiv, https://arxiv.org/pdf/2508.05901
20. Elements of Conformal Prediction for Statisticians - arXiv, https://arxiv.org/html/2603.23923v1
21. Adaptive Conformal Predictions for Time Series - Proceedings of Machine Learning Research, https://proceedings.mlr.press/v162/zaffran22a/zaffran22a.pdf
22. Adaptive Conformal Inference Under Distribution Shift, https://papers.neurips.cc/paper/2021/file/0d441de75945e5acbc865406fc9a2559-Paper.pdf
23. Getting started with risk control : contents - MAPIE - Read the Docs, https://mapie.readthedocs.io/en/v1.3.0/theoretical_description_risk_control.html
24. Conformal Risk Control - arXiv, https://arxiv.org/html/2208.02814v4
25. Conformal Risk Control - arXiv, https://arxiv.org/pdf/2208.02814
26. End-to-End Optimization of Conformal Risk Control - NIPS, https://proceedings.neurips.cc/paper_files/paper/2025/file/6559542f75b4452ebaaf82094c7defb7-Paper-Conference.pdf
27. Conformal Risk Control | OpenReview, https://openreview.net/forum?id=33XGfHLtZg
28. Dempster-Shafer Argument Schemes - Brooklyn College, http://www.sci.brooklyn.cuny.edu/\~parsons/publications/conferences/argmas13b.pdf
29. Combination of Evidence in Dempster- Shafer Theory - Stat.berkeley.edu, https://www.stat.berkeley.edu/\~aldous/Real_World/dempster_shafer.pdf
30. Generalized Evidence Theory - arXiv, https://arxiv.org/pdf/1404.4801
31. lore/docs/logic.md at main · dmbch/lore · GitHub, https://github.com/dmbch/lore/blob/main/docs/logic.md
32. Essential Conflict Measurement in Dempster–Shafer Theory for Intelligent Information Fusion - MDPI, https://www.mdpi.com/2227-7390/14/1/97
33. An improved conflicting-evidence combination method based on the redistribution of the basic probability assignment, https://d-nb.info/1244129151/34
34. Generalized combination rule for evidential reasoning approach and Dempster–Shafer theory of evidence, https://fs.unm.edu/DSmT/GeneralizedCombinationRule.pdf
35. Conflict Management in Dempster-Shafer Theory by Sequential Discounting Using the Degree of Falsity, https://www.foi.se/download/18.7fd35d7f166c56ebe0bfff4/1542623724500/Conflict-management-in-Dempster-Shafer_FOI-S–2843–SE.pdf
36. Brier score - Wikipedia, https://en.wikipedia.org/wiki/Brier_score
37. A bias-corrected decomposition of the Brier score, https://empslocal.ex.ac.uk/people/staff/ferro/Publications/ferro-fricker2012copyright.pdf
38. Simplifying and generalising Murphy’s Brier score decomposition - University of Exeter research repository, https://ore.exeter.ac.uk/articles/journal_contribution/Simplifying_and_generalising_Murphy_s_Brier_score_decomposition/29748851/1/files/56771708.pdf
39. BrierScoreDecomposition: Brier Score Decomposition - RDocumentation, https://www.rdocumentation.org/packages/SpecsVerification/versions/0.3-0/topics/BrierScoreDecomposition
40. A New Spatial-Scale Decomposition of the Brier Score: Application to the Verification of Lightning Probability Forecasts in - AMS Journals, https://journals.ametsoc.org/view/journals/mwre/135/9/mwr3442.1.xml
41. Brier Score vs Log Loss vs Calibration - MetricGate, https://metricgate.com/blogs/brier-score-vs-log-loss-vs-calibration/
42. [PDF] Automation and Accountability in Decision Support System Interface Design, https://www.semanticscholar.org/paper/Automation-and-Accountability-in-Decision-Support-Cummings/aebf3ac74a325a99b2f2d68a8c115b5ecf7e82c8
43. Automation Bias in Intelligent Time Critical Decision Support Systems - ResearchGate, https://www.researchgate.net/publication/329727855_Automation_Bias_in_Intelligent_Time_Critical_Decision_Support_Systems
44. Data Visualization and WCAG 2.1 / Minnesota IT Services - MN.gov, https://mn.gov/mnit/about-mnit/accessibility/training/wcag2.1/data-viz.jsp
45. How accessible are JavaScript data grids? - Bryntum, https://bryntum.com/blog/accessibility-in-the-bryntum-grid/
46. Grid and Table Properties | APG | WAI - W3C, https://www.w3.org/WAI/ARIA/apg/practices/grid-and-table-properties/
47. Accessible Data Grid Guide (role=grid, gridcell & 2-D keyboard navigation) | Accessibility.build, https://accessibility.build/guides/accessible-data-grid
48. ARIA: grid role - MDN Web Docs - Mozilla, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/grid_role