SD06 risk dashboard renderer¶


ID	`MOD-177`
System	SD08
Repo	`bank-app`
Build status	Not started
Deployed	No

The SD06 risk dashboard renderer is the back-office TypeScript/Vite interface for SD06 regulatory and risk intelligence dashboards. It renders Recharts-based visualisations for capital adequacy, liquidity, model risk, and operational risk data sourced exclusively from the Snowflake semantic layer via MOD-176.

Rendering approach¶

React/Recharts components are authored using a Claude Code session that reads the SD06 module's semantic view definitions, dbt column descriptions, and wiki module spec as context. The session produces typed TypeScript components that the developer reviews and commits. Generated components are ordinary source code — version-controlled, editable, and treated identically to hand-written code. There is no runtime code generation and no metadata layer.

New or updated dashboard components for a module are produced by opening a Claude Code session pointing at: - The module's CREATE SEMANTIC VIEW DDL (bank-risk-platform migrations) - The module's dbt schema.yml column descriptions - The module's wiki page (requirements, capability list, data model section)

Data access¶

All data queries are structured metric requests sent to MOD-176 POST /v1/snowflake/metrics. The renderer holds no SQL, no Snowflake credentials, and no direct Snowflake connection. A component binds to a metric name, a set of dimensions, and optional filters — the query shape is declared in the component, resolved by Cortex Analyst at request time.

Write-backs¶

Back-office actions that change state (model parameter overrides, validation approvals, alert threshold changes) are submitted as maker-checker proposals to MOD-168, not written directly. The actor identity is taken from the Cognito JWT claim (ADR-065). Classification:

Action	Tier	Time-lock
Model parameter override	TIER-3	15 min
Change control approval (MOD-175)	TIER-3	15 min
Alert threshold change	TIER-2	None

The SiS (Streamlit in Snowflake) renderer maintained per SD06 module is independent of this module. Divergence between the two renderers is accepted — they serve different audiences and are not coordinated.

Incremental delivery¶

MOD-171 and MOD-172 are deployed and provide the first dashboard panels at launch. MOD-173, MOD-174, and MOD-175 panels are added as each module reaches Built status — the renderer degrades gracefully without them (routes return a "not yet available" state rather than failing).

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-068	Authentication & session management	Required	—	Dashboard routes are protected by Cognito JWT authentication via MOD-068; party_id and RBAC role are resolved from JWT claims for all metric queries and write-back requests.
MOD-075	Internal API gateway	Required	—	Metric queries to MOD-176 and write-back proposals to MOD-168 are routed through the internal API gateway.
MOD-168	Maker-checker enforcement engine	Required	—	TIER-2 and TIER-3 write-back actions from the dashboard are submitted as maker-checker proposals via MOD-168; the renderer holds no direct write path to any data store.
MOD-176	Snowflake read API service	Required	—	All Snowflake metric queries for dashboard rendering are served through the MOD-176 Tier 3b endpoint; the renderer references metric names only and holds no SQL or Snowflake credentials.
MOD-171	Risk Intelligence Dashboard	Required	—	Risk Intelligence Dashboard semantic views provide the first set of SD06 metrics rendered on launch.
MOD-172	Operations & Model Intelligence Dashboard	Required	—	Operations and Model Intelligence Dashboard semantic views provide the second set of metrics rendered on launch.
MOD-173	Model risk register & inventory	Optional	—	Model Risk Register dashboard panel added when MOD-173 semantic views are deployed; module degrades gracefully without it.
MOD-174	Model performance monitoring & drift detection	Optional	—	Model performance monitoring charts added when MOD-174 semantic views are deployed; module degrades gracefully without it.
MOD-175	Model change control & re-approval workflow	Optional	—	Model change control workflow and TIER-3 write-back actions added when MOD-175 is deployed; this is the primary write-back use case for this module.

Required by¶

(No modules in this wiki currently declare a dependency on this module.)

Policies satisfied¶

Policy	Title	Mode	How
DT-001	Information Security Policy	`GATE`	All Snowflake metric queries and write-back requests pass through authenticated, TLS-terminated internal API calls — no Snowflake credentials or database credentials exist in the browser.
GOV-003	Three Lines of Defence Policy	`CHECKER`	Consequential back-office actions (model parameter overrides, change control approvals) are submitted as MOD-168 proposals requiring a second authorised reviewer before execution — self-approval blocked at the database layer.

Capabilities satisfied¶

(No capabilities mapped)

Part of SD08 — Customer App & Back Office Platform Compiled 2026-05-22 from source/entities/modules/MOD-177.yaml