Task: Design the .1 and greek ladder reports

A design for the .1 and greek ladder reports, grounded in ORE, with the tasks to build them.

• ORE's approach to .1 and greek ladders is researched and cited.
• The full ladder family (all greeks, not only vol) and what each needs are set out.
• The design note, the journey if needed, the tasks and the open questions are recorded.

Read the engine first and the store second, because the .1 family is a name for something the engine already does. Read the whole sensitivity schema rather than the example that looks closest, because the family is as wide as the schema and only the vocabulary comes from the example. Then measure what the Delta column actually holds before designing anything that divides by a shift size, since a Greek written as a quotient and a Greek written as a value change lead to different reports.

The work is docs and tasks only: no code, no seeds, no definitions. The build is sequenced so that each unit ends in a state a reviewer can check, and so that the plumbing lands before the reports that depend on it:

1. Bind a sensitivity configuration to a report definition — without this, every later run shifts nothing.
2. Seed the sensitivity shift families — the content the binding carries.
3. Build the rates delta and gamma ladders — the first ladder, over data the store already holds.
4. Build the par-rate DV01 and theta ladders — the two one-figure ladders off that same run.
5. Build the .1 ATM and surface vol ladders — the vol pair, waiting on market data.
6. Derive the risk reversal and strangle ladders — derived from unit 5, not asked of the engine.
7. Build the cross-gamma ladder — last, because it is the widest and the least load-bearing.

Units 1 to 4 need no new market data. Units 5 to 7 wait on Support volatility surfaces. The wider risk classes are captured separately in Extend the greek ladders to every risk class.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The design note is Greek ladder reports. It states what a .1 report is in the engine's terms, the full ladder family across every risk class and order, what each ladder needs, what the store holds and lacks, the ordered report list, six decisions and five open questions.

Six findings decide the design, and each is cited on the note:

• The engine has no .1. It has a shift type, a shift size, a shift scheme and a bucket list, and a .1 report is a report bound to one of those sizes.
• The Delta column is the value change for the configured shift, not a derivative, and it is not divided by the shift size. This was measured rather than assumed.
• The risk reversal and the strangle are not engine factors. ORE shifts an ATM-only grid or a strike-by-strike surface, so the two ladders are a change of basis over the surface points.
• crossgamma.csv has no writer at 1.8.17.0, though the cross gammas are present in sensitivity.csv and scenario.csv.
• Theta is a risk factor key of its own, not a mode of a rates run.
• The store names the sensitivity document and switches the analytic on in nine risk report configurations, and no configuration binds a document, so a sensitivity run today shifts nothing.

Seven tasks are scoped and sequenced in * Plan. Two captures wait beside them: Settle the .1 family with the product owner and Extend the greek ladders to every risk class.