Review the architecture skeleton before further buildout

[SimonHeybrock]

The skeleton under packages/essapps (branch architecture-sketch) has outrun review. This issue lists what to review, ordered by leverage, so that review time goes where a wrong choice costs the most. Each item names the files and the question the review should answer. Notes and outcomes go into the handoff document at docs/developer/plans/review-handoff-2026-09-17.md, which is also what a fresh session gets together with the findings.

• The LoKI session notebook as a user story, packages/essapps/notebooks/loki-session.ipynb. Read as a user: submit, chain by reference, rerun with a slider, publish. Does any step feel wrong? A wrong step there is a design problem, not a code problem.
• The callable contract, packages/essapps/src/ess/apps/binding.py, warm.py, loki.py, and aggregation.py. This is what every workflow author writes against. Is resolve per parameter and stage_inputs how you would bind DREAM or BIFROST? Do contribute, combine, and finalize fit a combine you have written? Where should this contract live once it settles, essreduce next to the spec or essapps? Instrument packages cannot ship bindings until that is decided.
• Records and references, docs/developer/architecture.md, the section of that name plus "Changes needed in the workflow spec" (D13) and choice 3 (D8). Everything rests on it and the team stumbled on it once. Today's decision that a dataset reference is one identity string, encoded by the framework as pid:, run:, or path:, is new and in it.
• Rules, batches, and the trigger loop (D14), packages/essapps/src/ess/apps/rules.py and batch.py, and the "Rules" section of the sketch. Written from reading Mantid and FIA, not from running anything, so the highest chance of being wrong in a way tests cannot catch. Check the lookup and selector against how ISIS interfaces are used in practice, and whether apply, backlog, reprocess, and rerun are the operations a scientist would ask for.
• Combining (D15), the "Combining" section of the sketch and examples.py NORMALIZE. Is "contribution at the accumulation keys, normalisation after" right for powder and BIFROST, not only SANS?

Not worth review time now: the record store, data store, and launchers; they are mechanical and tested.

Decisions taken so far in this round: pandas stays a hard dependency; a dataset reference is a single string in the spec (scipp/ess#690) and the framework encodes its identities.

Work proceeding in parallel without review: the branch's edges vocabulary for the LoKI bins, serialize() carrying the D15 fields, the review deck refreshed to the current sketch, and an Amor reflectometry binding as a probe of collection outputs and a non-additive combine.

[SimonHeybrock]

Work done alongside the review items, all on architecture-sketch:

• LoKI bins use the branch's QEdges and WavelengthEdges; the Q edges are the one stage input.
• WorkflowSpec.serialize() carries contribution and finalize_params.
• The review deck matches the current sketch.
• Amor reflectometry is bound as a probe (ess.apps.amor: one rotation against the supermirror reference as a warm stage, and a stitch over a collection of curves as a plain callable). Findings are in docs/developer/plans/amor-probe-2026-09-17.md and listed per review item in the handoff document. The ones that change the sketch: an opaque combine gets none of D15's member-consistency check; collection keys are never validated, and a reference into a pending collection output is not checked for its key; chaining compares format only, so a declared ArraySpec is never read; a stage input is also how a session shares work across the members of a series, which D8 does not say; an output that needs its own serializer has no place to declare one; every scalar parameter costs a NewType and a provider in the binding.

Nothing in the sketch is changed by these; they wait for the review.