Task: Port the market data cuts reference

A durable knowledge page defines a market data cut, its kinds and its lifecycle, connected to the snapshot notes and the backlog story.

• The external summary is ported in our voice and structure, with the source named.
• The page is registered, linked from the snapshot and pricing notes, and states what the system has and lacks.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

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.

A durable reference for cuts, as a structure note and four child pages. Cuts states the definition and the body, and beneath it sit Kinds of cut, Market data cut, Trade cut and The option-expiry cut code. The single page this task first produced was split into those pages at the product owner's direction, and its verified content moved with it. The kinds later moved out of the hub into a page of their own, since a classification is a subject in its own right.

• The cluster carries both senses of the word, what a cut is, the deal cut and the market data cut, the four kinds, the end of day process and its rate overrides, multiple centres, what a cut holds, profiles, one cut per book, option-expiry cut codes, audit and rerun, our position, a glossary and references. No notebook is referenced, and no vendor system appears in the conceptual pages. The prior-art survey in Naming the cut names systems, because the naming question requires it.
• Every non-repository claim rests on a public source fetched and read while writing: EBA RTS (EU) 2016/101 Art. 3 for independent price verification and its accepted sources; the ECB euro reference rates for an official daily rate; Fedwire operating hours for a centre's stated business day.
• Claims with no verifiable public source are marked as our working convention and listed under What the sources establish: the deal-cut then market-data-cut order, the flash and start-of-day runs, the six-step end of day sequence, one cut per book, the after-hours rule and the specific option cut times. The advisory sentence about inferring a cut from the volatility surface was dropped.
• Our own position is verified against the notes and the schema and linked: the as-of read and its lack of an as-of parameter; the resolution-side snapshot as a definition with no implementation; the cut time as a designed lookup with no table; the population as unmodelled; the report binding as unable to name the population.
• The hub is registered in the knowledge index as a hub, and linked from the two snapshot notes, the pricing configuration, the market data architecture hub, risk reporting, report processing, the reports index, the report-binding design and its journey, the market bindings prototype and the backlog story. Each child links the hub back, and the structure note check passes.
• The report binding's open question now points at the hub: a binding names a published set and cannot name the population, so the cut model is the binding's missing foundation.

Checks: compass lint valid; the org link check 0 unresolved; the structure note back-link check green across 25 notes; compass site page published the sixteen touched pages with no failures. Open on the pages: the option cut times, whether a book may hold more than one cut, and whether the story's cut time and a population cut are one entity.

The consequence for the report binding: binding a population needs a cut that does not exist yet, so the cut model is the binding's foundation.