stevens 
A portfolio can contain a long list of different names and still depend on a small number of shared assumptions. A holdings table tells us what we own. It does not, by itself, explain which positions would matter most under a particular market scenario.
Mahanth Chintha, an analyst on our Risk team, approached that question by building a scenario explorer with a deliberately simple starting point: every portfolio result should be explainable as a set of position-level contributions. I worked with Mahanth on the scope, while he owned the calculation workflow and the report that makes those contributions visible.
Begin with an explainable scenario
We started with a small collection of explicitly defined shocks rather than a single score intended to summarize every possible risk. Each scenario records its assumptions, the affected inputs, and the valuation date. Running a scenario means applying the same recorded assumptions to a fixed portfolio snapshot.
That separation makes the output easier to discuss. An analyst can ask whether a scenario is useful without confusing that question with whether its calculations are consistent. The report describes what happens under the specified assumptions, rather than attaching a probability to them.
Mahanth also kept the baseline alongside the stressed result. Without a clear starting point, even a carefully calculated change can be difficult to interpret.
Make the contributions reconcile
The central engineering task was making the portfolio summary and the position table agree. Mahanth built the aggregation from the individual contributions, so the total shown at the top of the report comes from the same values shown below it.
He made units explicit at each boundary. A return, a percentage-point change, and a dollar change are different quantities; the report should never require the reader to infer which one a column represents. Position weights and valuation inputs are recorded with the run so that the same scenario can be reproduced later.
The drilldown then sorts positions by their contribution to the selected scenario. This turns an abstract portfolio result into a concrete review question: which assumptions or holdings deserve a closer look?
Treat missing information as a result
A position with incomplete inputs cannot simply disappear from the calculation. Mahanth added a coverage summary that distinguishes positions evaluated successfully from positions requiring attention.
We chose to show incomplete coverage prominently instead of filling missing contributions with zero. Zero would look like a measured absence of sensitivity, which is a stronger statement than the available information supports.
The same rule applies to stale snapshots and inconsistent identifiers. The explorer reports those conditions before presenting a portfolio total as complete. Handling those cases clearly took as much care as the main calculation.
Build tests that explain the model
Mahanth used small synthetic portfolios to make the expected behavior easy to inspect. A one-position portfolio should reproduce that position's contribution. Splitting an otherwise identical position into two entries should preserve the total when their weights add to the original weight.
He also checked that the aggregation is independent of row order and that an unchanged scenario produces an unchanged result. Each test isolates an assumption that would be harder to spot inside a large portfolio.
What Mahanth owned
Mahanth owned the scenario input format, contribution calculations, coverage checks, and report drilldown. His strongest design choice was keeping the path from assumptions to results visible throughout the workflow.
The next step is to compare scenarios side by side without losing that explanation. For the Risk team, the value of the tool is the discussion it enables: a reviewer can trace a number back to the positions, inputs, and assumptions that produced it.