Module cashflows 

Cashflows: what a trade pays, and when.

The layer’s whole discipline is in one sentence: the market is active, the trade is data. A coupon’s notional, its fixed rate, its gearing and spread, its dates and conventions are contract terms — they are f64, they are never registered as derivative inputs, and no sensitivity is ever taken with respect to them. What is active is the curve a floating coupon projects off, and that enters at valuation time through the mode.

That is not a simplification: every tape-input registration site is a market object, and no trade term is ever registered. Making a coupon’s notional and rate active scalars would only carry a permanently invalid slot, paying the cost of differentiability for a derivative nobody takes.

Consequences worth stating, because they are what this buys:

• Legs, coupons and cashflow types take no scalar type parameter. A book of trades is one type, not one per pricing mode.
• A schedule is compiled once, when the leg is built, and a valuation walks dates rather than calendars.
• The mode appears only where a curve is read, and leaves through the Cashflow a projection produces.

Modules

adjustments

Date adjustments threaded through leg resolution.

coupons

Coupon types. Every field here is passive contract data.

legs

Legs: a compiled list of coupons, and how to value one.

primitives

A dated payment, and the discounting kernel every leg folds through.

records

An instrument’s cashflow schedule as column-oriented records.