Project Plans¶
This section contains project planning documents and phase tracking for the RWA Calculator.
Overview¶
The project follows a phased, test-first approach prioritising CRR (Basel 3.0) implementation before extending to Basel 3.1.
Documents¶
- Implementation Plan - Detailed acceptance test scenarios, contract definitions, and regulatory parameters
- Target Architecture & Migration Plan - Architecture review findings, the rulepack target architecture, and the phased (0-8) strangler migration plan
- Engine Defensiveness — Boundary Hardening - Producer-enforced stage-contract investigation; folded into migration Phase 3 (includes the binding KEEP-guard triage)
- Single-Lazy-Plan Refactor - SUPERSEDED by migration Phase 1; preserves the Polars plan-depth SIGSEGV evidence and the irreducible-barrier finding
- UI Output Folder - Let a UI user write calculation outputs to a chosen local folder (server-side write, run-stamped subfolder, network guard); phased TDD plan
- Return Reconciliation - Proposed: compare a generated template (e.g. C 08.03) against the firm's current return cell by cell, and decompose each delta into population / row placement / sheet placement / measurement
- Independent Validation System - Why a green suite keeps shipping template defects, and the six-component plan (impact report, property suite, shadow calculator, cell re-derivation, coverage ratchets, defect-injection scorecard) to fix it
- Architecture Review — structure, efficiency, parallelism (2026-08-29) - Measured review of
engine/stages/layout, reporting-vs-calculation cost, and thread scaling; a sequenced proposal (proposal only, nothing implemented) - Facility Share — Riskiest Member by Applied Approach - Proposal: allocate a shared facility's undrawn to the member with the highest RWA under its own approach (candidate fan-out, resolved before the output floor), and the two-assignment rule that makes "riskiest" well-defined under the Basel 3.1 floor (approved and implemented 2026-09-05; methodology in Specifications → Facility Share Allocation)
- Test-Suite Runtime (proposed) - Measured: the dev loop's 6m47s is ~1,300 tests that each run a pipeline or a COREP generation, not per-test overhead; five ranked levers (memoise repeat runs, cut the per-run fixed cost, compile COREP cells once, tail, collection) to ~4m15s with identical tests (proposal only, nothing implemented)
Development Philosophy¶
The project adheres to these core principles:
- Test-Driven Development (TDD) - Tests are written before implementation
- Phased Delivery - Features are delivered incrementally with clear milestones
- Regulatory Accuracy - All calculations are validated against regulatory specifications
- Performance First - LazyFrame operations and vectorized calculations throughout