See who changed a curve, and when prototype

The trail carries no state of its own: it is a reading of the versions the server keeps. The open question is how that reading is shown when its five kinds arrive from different entities, on different clocks, and several cannot be read yet. The journey records the defects already — an observation keeps no actor, no publish operation exists, no market-data approval kind is seeded — so the prototype asks what a screen honestly shows around those absences.

Switch with the Variant buttons in the bottom bar, or ?variant. The variant is how the five kinds are laid out, which is the screen's central design question.

The variants disagree about structure, not colour. A trades completeness for speed, B gives each kind its own panel and notice, and C answers the journey's last step and leaves the four other kinds off the page.

Switch with the Trail buttons, or ?state. The state is the mock trail the page reads.

The manual panel is the argument in one block. It says the writer is inferred, because the observation keeps no version and no actor, and it reads the writer from the write's change reason and the source string. The screen states the inference rather than claiming a version it cannot read.

The bottom bar switches variant and trail, and any combination is a URL: ?variant=b&state=manual opens that page, because every button rewrites the query string rather than hiding panels in place. One control is live: the series URI is a button that opens the oresmd URL editor in an overlay and takes back the URL the editor returns. A link to the journey sits at the top right, every actor name is drawn as a link that goes nowhere, and no other click writes.

Everything. The series, its subclass, its derivation, its config and its provenance; the three blueprint versions and their field differences; the four builds and their point counts; the two hand points, their values, reasons and writers; the lineage row; the approval and its decision; and the two publishes, with every actor and clock, are constants in the page. There is no server, no session and no build step, and nothing is written or stored.

doc/prototypes/market_data/see-who-changed-a-curve/. One file, index.html, holding its markup, styles and script, with no framework and no build step. The site copies the directory as it stands and adds nothing to it. The URI button opens ../oresmd-url-editor/index.html in an overlay, so the page borrows the editor prototype beside it and embeds no copy of its own.

The group accepted the argument rather than a layout: the trail of a curve is one reading, in one place, and each row names its actor and time where the server keeps one. A panel whose read does not exist says which subject is missing and stays empty, and a writer the server cannot name is marked inferred rather than presented as a version. The three variants proved the argument holds whether the kinds are merged, separated or reduced to a compare.

What stayed on the page as the record: the three variants; the three trails, because the empty and manual cases are what the missing reads produce; the per-point provenance panel, kept as the record that a lineage row is read by an id the screen does not hold; and the oresmd URL editor overlay on the series URI.

Which variant wins. The merged timeline, the per-kind tables and the compare are all drawn and none is chosen; the choice belongs to the reads the server will answer.

The publish and approval panels. No publish subject and no publish event exist, so the two publish rows are the design target, not a read. The inbox seeds one kind, iam.role_grant, and no kind names a curve publish or a hand adjustment, so the approvals panel holds a shape and is otherwise empty.

The actor, the manual marker and the lineage read. market_observation registers no history provider and keeps no version, so a build has no actor and a point's writer is inferred from the change reason and the source string; no column marks a point manual, so a source that names no producer channel is treated as one by convention; and the lineage read takes the row's id, not the observation, so the screen matches the rest by hand. No field separates a candidate from a published value, so the trail does not claim which points were published.