Set 12 Market Dashboard Read-Model Bundle

The dashboard read model is exercised as copied code

A dashboard read model turns a market graph into screen shapes, and it is the easiest place for a stale feed or overclaim to slip in. A market dashboard is a presentation layer. It takes a generated graph of market situations and turns it into the shapes a screen consumes: a trust strip, a ranked queue, a detail index, a graph slice, facets, and drilldowns. That read model is also the easiest place for an overclaim to slip in. A stale feed can render green. An auto_apply_allowed flag can stay true. A copied label can read "strong buy" without anyone deciding it should.

Three checks bind rows, filters, and claim limits

It imports the copied, read-model source as runnable code and drives its checks over small synthetic fixtures. The question it answers is narrow: when the read model is handed a planted overclaim, does the source flag it, or does the surface stay quiet? A pass is fixture evidence that the copied checks behave. It is not market-level conclusions, investment-related actions, or a live feed.

Dashboard evidence remains metadata-only and non-live

Three copied checks run, and every result is metadata-only: refs, digests, counts, and verdicts only, never the source text. The component runs three copied checks and records what each one did. Every result is metadata-only: refs, digests, counts, and verdicts only, never the copied source text or any model-output data.

Purpose

The failure mode worth catching

A loose harness that runs the copied source once on clean input proves nothing; the real risk is a read model silent on a planted overclaim. The copied source is system/lib/market_dashboard_read_model.py. It carries three functions this component cares about: validate_market_dashboard_read_model, _runtime_feed_freshness_overlay, and _related_situations, plus the constant TRADING_CLAIM_PATTERN. A loose harness would import that source, run it once on a clean input, watch it pass, and call it validated. That proves nothing about the boundary. The failure mode worth catching is a read model that passes its own structure checks and then stays silent on a planted overclaim.

A missing rejection is the finding

Each check is fed one input per failure shape, and a missing rejection, not a passing run, is what gets recorded as blocked. So this component feeds the checks inputs designed to trip them, one input per failure shape, and treats a missing rejection as the finding. If the validator does not emit the expected error for a dangling edge or an auto-apply overclaim, that is what gets recorded as blocked. The interesting evidence is what the checks refuse.

How it works

One sandboxed import feeds three checks

The component imports the copied source in a sandbox, runs all three checks over fixture cases, and collects their findings. The component imports the copied source in a sandbox, then drives the three checks over fixture cases and collects findings.

Stubbed sandbox import in _load_source_module

The copied file is executed under throwaway system stubs in sys.modules, so it imports without pulling in any private host dependency. _load_source_module resolves the copied file through the exported bundle manifest with _source_target and executes it under _market_dashboard_import_stubs. The stub context registers throwaway system, system.lib, and system.lib.market_situation_graph modules in sys.modules so the copied source imports without pulling in any private dependency, then restores the previous module table on exit. Nothing from the host system is loaded; the graph module is a stand-in with fixed filename and schema constants.

Structure and overclaim gate over five negatives

validate_market_dashboard_read_model first checks the read model is well formed, then enforces the claim boundary, and must emit the matching error for five negatives. _compute_validator_cases drives validate_market_dashboard_read_model. That copied check is the structural and overclaim gate. It first checks the read model is well formed: the schema version matches, every queued situation resolves to a detail entry, every graph-slice edge points at a node that exists, and each drilldown route returns metadata only with no .. traversal. It then enforces the claim boundary: auto_apply_allowed must be false, review_gated must be true, no_advice_mode must be on, the silent-omission count must be zero, and copied text is scanned against TRADING_CLAIM_PATTERN for trading and action language. The component runs it against five negative fixtures and confirms the source emits the matching error fragment for each one.

Three freshness states, no green from stale

The overlay classifies each synthetic run as fresh, stale, or blocked, and a stale or absent run never reports green. _compute_freshness_cases drives _runtime_feed_freshness_overlay. For each case it writes a synthetic readiness file with _write_readiness, then asks the overlay to classify the run into one of three states. fresh_green_feed needs the run ready, all targets met, no blockers, and same-day generation. stale_green_feed is artifact-backed but no longer same-day; the fixture ages one case 14 days. blocked_missing_artifact covers a run with no readiness file, a success shortfall, or a blocker present. A stale or absent run never reports green. Historical proof does not stand in for a live feed.

No-overlap cohort stays empty

_related_situations builds a capped see-also cohort from shared entities or type, and a situation with no overlap returns empty, not an invented link. _compute_related_cases drives _related_situations, the "see also" cohort builder. It collects situations that share an entity or match the situation type, excludes the focus situation, and caps the list. The component checks one boundary in particular: a situation with no entity overlap and a different type returns an empty cohort, not an invented link.

Clean payload, case sets, and the result card

_evaluate runs a clean payload and the three case sets, emits one row per check, and result_card projects the counts and floors into a card. _evaluate runs a clean payload first (a clean fixture that produces validator errors is itself a finding), then runs the three case sets, folds their findings together, and emits one mechanism row per check with a pass or blocked status and its negative-case rows. evaluate_negative_case is the per-case entry the runner uses for the ten declared negative cases; it re-derives the source result and matches it against the expected fragment or state. run and run_batch12_market_dashboard_read_model_bundle wrap _evaluate through run_crown_jewel_organ for fixture and exported-bundle inputs, and result_card projects the result into a compact card carrying the mechanism count, the computed negative-case count, and the authority and body floors.

flowchart TD A["Synthetic dashboard, freshness, related fixtures"] --> B["_load_source_module (stubbed import of market_dashboard_read_model.py)"] B --> C["validate_market_dashboard_read_model"] C --> C1["Structure: schema, queue-to-detail, graph edges, drilldown route safety"] C --> C2["Ceiling: no auto-apply, review-gated, no-advice, no trading language, zero silent omissions"] B --> D["_runtime_feed_freshness_overlay"] D --> D1["fresh_green_feed"] D --> D2["stale_green_feed"] D --> D3["blocked_missing_artifact"] B --> E["_related_situations"] E --> E1["Entity or type match; self-excluded, capped; no overlap means empty"] C1 --> F["metadata-only result record (refs, digests, counts, verdicts)"] C2 --> F D1 --> F D2 --> F D3 --> F E1 --> F

Negative cases

Ten declared negative cases

Ten cases live in EXPECTED_NEGATIVE_CASES, and five of them drive the validator, each expecting a specific error fragment. The component declares ten negative cases in EXPECTED_NEGATIVE_CASES. Five drive the validator and expect a specific error fragment:

• dangling_graph_edge expects $.graph_slice.edges[edge1].target is dangling.
• traversal_route_ref expects route_ref contains traversal.
• oracle_auto_apply_overclaim expects auto_apply_allowed must be false.
• strict_trading_claim_language expects contains trading/action claim language.
• silent_omission_count expects silent_omission_count must be 0.

Freshness and related cases expect states

Four freshness cases expect a blocked or stale state and the last expects an empty cohort, and a missing rejection is recorded as not observed. Four drive the freshness overlay and expect a state rather than a green pass: freshness_missing_readiness_artifact and freshness_success_shortfall and freshness_blocker_list each expect blocked_missing_artifact, and freshness_stale_not_fresh expects stale_green_feed with a non-zero staleness count. The last, related_no_overlap_different_type, expects an empty cohort. When the source does not produce the expected rejection, the case is recorded as not observed, which blocks that mechanism.

Prior Art Grounding

CQRS and dashboard-observability practice

The shape comes from CQRS read models and dashboard observability, with an added overclaim gate and a freshness state that refuses green from stale evidence. The read-model shape comes from CQRS and dashboard-observability practice: derive presentation-ready projections from source data, make feed freshness visible, and keep the read surface separate from any mutation authority. Two public anchors are relevant. Microsoft's CQRS pattern describes read models optimized for queries rather than command handling. Grafana dashboards query and transform data sources into operational panels. This component borrows the shape and adds an explicit overclaim gate and a freshness state that refuses to report green from stale evidence.

Validation Result record Path

Reader-verifiable commands, run from the microcosm-substrate/ public root:

What the two commands write and prove

The fixture and bundle commands validate the copied source, digests, and freshness rows, and a pass means every check behaved with a metadata-only result record. The fixture command writes the read-model result and sign-off JSON. The bundle command validates the copied source, its manifest digests, the freshness rows, the related-situation cohorts, and the metadata-only posture. A pass means the three checks behaved as declared over the synthetic fixtures: the clean payload validated, each negative fragment or state appeared, and the result record stayed metadata-only. These are validation result records for the fixtures, nothing more.