# Observability and verification The decision journal, the health contract, degradation monitoring, and how the platform's accuracy claims can be checked by a third party. A system that produces probabilities has to be auditable after the fact, otherwise its numbers are decoration. The platform's observability layer exists so that any published figure can be traced back to the rows that produced it. ## The decision journal Every signal of every core in every cycle is written to a journal, including suppressed signals and errors. Each row carries the state, the confidence, the value, the explanation payload, the suppression reason, the regime context, the horizon and the schema version, keyed on cycle timestamp, cycle type, core, asset and signal kind. The journal has one invariant that is enforced rather than intended: it is diagnostic-only. The live path never reads it. There is no feedback loop from the record of past decisions into the making of new ones, so no self-confirmation can develop. A journal write failure raises an alert and does not stop the cycle. The journal is the dataset the platform trusts most, because it was written before the outcome was known. It currently holds 264 723 decisions. ## The health contract Every snapshot carries a health block: the cycle type, the data lag, the state of every core, a line-by-line report of which resolve rule fired and why, feature-store hit and miss counts, and three deterministic aggregates. Those aggregates are computed, not generated. There is no language model anywhere in the live decision path. - A one-sentence narrative of the cycle. - An agreement score describing whether the overall picture is coherent or self-contradictory. - A single structured situation object combining cross-asset regime coherence, data health across the source families, a deterministic consistency check between the expansion probability and the volatility forecast band, ranked factors for and against with their impact, recent changes and a stability measure. The consistency check deserves a note: it compares two independently trained models that should agree, and reports contradiction explicitly. A platform that only shows agreement is not measuring anything. ## Degradation monitoring A daily pass produces a degradation report served through the health endpoint. It covers calibration drift over a rolling window of about thirty thousand rows, the state of the kill engine, and a shadow-null placebo in which outcomes are shifted by one so that the hit rate must sit at chance. A placebo that starts winning indicates leakage and is treated as an incident rather than as good news. Alerts fire on state change only, with a cooldown per key and state that survives a restart, so that a persistent condition does not generate a stream of identical messages. Every action of the kill engine – a freeze, a fallback, a pending confirmation – raises its own notification. Metrics are stored as a narrow time series in the dashboard store rather than exported to a general-purpose metrics stack. That was a deliberate choice for a single-node deployment: fewer moving parts, and the metric history lives beside the data it describes. ## Accuracy accounting The platform reports its own hit rates, and how those rates are computed is itself a documented decision. - Directional accuracy and forecaster accuracy are computed over the full history – the live database together with all monthly snapshot archives – rather than over a rolling recent window. An earlier implementation capped the window at two weeks for direction and at a fixed row count for the forecasters, which on production cadence amounted to about three and a half days. Both caps are gone from the reporting path, and the labels state the sample explicitly. - Effective sample size is used instead of nominal count. With a horizon of several hours at a five-minute cadence across three assets, nominal counts overstate independence by roughly an order of magnitude. - Base rates are always shown next to hit rates. A hit rate of 0.69 against a base rate of 0.48 is a result; the same hit rate against a base rate of 0.70 is not. Current live figures, over the full journal: volatility expansion at 0.692, 0.708 and 0.695 across the three assets against a base rate of 0.48, and regime change at 0.643, 0.652 and 0.654 against a base rate of 0.52, on an effective sample of 1 918. Directional win rates across the same base sit between 0.497 and 0.582 across six asset-horizon cells, which is the same story the research told. ## Third-party verification Because internal consistency is not evidence, the platform produces a diagnostic export designed to be handed to an outside reviewer: the methodology stated in words and in the formulas taken from the code, the summary computed by the same functions that feed the panel, every permitted forecast as an individual row, every matured decision as a table, monthly aggregates, and self-checks that recompute the summary from the rows so that a discrepancy between the two is visible rather than assumed away. The export is read-only and reproducible. The point of it is that someone who does not trust the platform can recompute its headline numbers from the underlying rows without asking the platform for anything. ## Interfaces The live surfaces are private. A terminal presents the engine state per asset – regime, volatility band, risk context, order-flow state, forecaster consistency, core disagreement and data-source health – and a control panel presents telemetry, the security journal, the desk state and the accuracy block. Both sit behind authentication. The dashboard has been through several generations, and the current one carries a mode selector rather than a single fixed layout, because a volatility workflow and a short-horizon workflow need different blocks in front of the operator. Colour semantics are unified across modes: one palette for entry direction, one for no entry, one reserved for the risk layer, with brightness carrying confidence.