Relevant Operating Picture (ROP) + user stories (Stac Manager Nextgen)

**Note** from Bead: Stac Manager Nextgen · [canonical source](https://redfish.acequia.io/guerin/.agents/b73189b7-e605-4473-9789-20bcff57ba35/2026-06-21/notes/02-relevant-operating-picture-and-user-stories.md) · session 2026-06-21 · discussion: Talk: Stac Manager Nextgen

> Reframing from Stephen, 2026-06-21, after seeing the [interface sketches](https://redfish.acequia.io/guerin/apps/stac-manager/sketches.html): > *"the asset manager we need in this moment is to collect items for the purpose of a **relevant operating > picture**. this relates to user stories."*

## The reframe The next-gen app is not "a STAC browser." Its job is to **assemble a relevant operating picture (ROP)** — pull together exactly the asset-catalog items (camera frames, aircraft tracks, perimeters, FMV, model outputs) that answer a specific operational question, for a specific user, right now. "Relevant" is the load-bearing word: the picture is scoped to a task, not the whole catalog. Consequences for the design: - **Drive from user stories, not features.** Each story = a user, a question, the minimum set of catalog items that answers it, and how they're rendered/tracked together. The Catalog Shelf + storage locations (notes 00/01) are the *substrate*; a ROP is a *selection + composition* over that substrate, bounded in **time and space** (which is exactly the "incident STACs reference a subset" idea from the camera-STAC work). - **Sketch each story before building** (per the Buxton read in bead [`174efbfc`](https://redfish.acequia.io/guerin/.agents/174efbfc-d73f-4754-b138-d2cdbbefed6d/2026-06-21/notes/00-buxton-sketching-the-ux-designers-read.md)): act out the story, storyboard the arrows, ~5 disposable diverse frames, enumerate then refine, *then* build the smallest demonstrable slice. - This also reframes the open fork (note 00): catalog-first vs item-on-shared-surface is really **"how do you assemble and read a ROP?"** — the answer may differ per story.

## User Story 1 — render & track the plume for a given fire > *As an incident analyst, I want to see and track a fire's smoke plume over time, so I know where the > column is and which way it's carrying.* > **Worked instance: the Sandy Fire.** Inputs: **AlertWildfire cameras** + **v1 fire progression**. ### Assets this story composes (already in the ecology) - **v1 fire progression** — [`182bd1a7` fire-progression](https://redfish.acequia.io/guerin/.agents/182bd1a7-a376-4dd0-b445-578adc6635b9/): `progression-maker.mjs` interpolates timestamped perimeters into a **time-of-arrival raster**; the **Sandy Fire** is its worked example (AEVEX/NIFC perimeters re-anchored to ignition). This gives the **ground footprint over time** — the base the plume rises from. - **AlertWildfire / AlertCalifornia cameras** — [`65783732` firewatch-camera-grid](https://redfish.acequia.io/guerin/.agents/65783732-7907-4a36-983a-3b015e75e80b/) (AlertWildfire PTZ management) + today's grabber [`b3461c66`](https://redfish.acequia.io/guerin/.agents/b3461c66-1a49-4f62-8920-d6dcc9838942/) `grab-alertcalifornia-stac.mjs` (per-frame **pose**: lat/lon + azimuth/elevation/zoom/hfov). Cameras that saw the Sandy plume, with pose, are what let us locate the column. - **Sandy Fire STAC** already mapped in [`90f902e0` catalog](https://redfish.acequia.io/guerin/.agents/90f902e0-2e45-4aa1-b998-918ca3688e94/) / [`cbf8b027` incident-viewer-app](https://redfish.acequia.io/guerin/.agents/cbf8b027-e80c-4b9f-8eb3-91d40af072d5/). - **MISB FMV (aircraft cameras)** — posed full-motion video with **KLV telemetry** (sensor lat/lon/alt + relative az/el + hfov per frame): [`35e928bc` egp-missions](https://redfish.acequia.io/guerin/.agents/35e928bc-200c-4eb7-8248-e7bca9b07859/) (mission-browser pulls EGP FMV+KLV), [`97559992` cataloging-incident](https://redfish.acequia.io/guerin/.agents/97559992-a73c-47f6-89a6-6565e0c164f3/) (`catalog-incident.mjs` normalizes the KLV), rendered by [`c66cbd1d` taos-engine](https://redfish.acequia.io/guerin/.agents/c66cbd1d-453c-41f8-8440-179502f25de4/) (MISB FMV → terrain). This is an **aerial, well-posed** view — rays from above/oblique that see the column's *top and lean*, not just its base. - **News-helicopter footage** — oblique aerial views of the plume: [`58c0a5e0` media-forager](https://redfish.acequia.io/guerin/.agents/58c0a5e0-c64e-426e-8da2-ac7f5495d18a/) (foraged heli feeds → STAC) with camera-ship **pose recovered from ADS-B** by [`2986ff41` adsb-for-heli-videos](https://redfish.acequia.io/guerin/.agents/2986ff41-41ea-4629-bc6b-3ce22f55e628/) (orbit-centroid prior; today's `grab-adsb-live.mjs` does the live version). Pose is **coarser** (no gimbal/KLV — position only, look-direction inferred), so these are corroborating obliques rather than survey rays. - **Through-the-lens / panosphere** geometry — [`9943ac1c` astronomical-pano](https://redfish.acequia.io/guerin/.agents/9943ac1c-caa1-479d-b17e-89ef7ca326b6/) + [`74c30681` image-pose-uxui](https://redfish.acequia.io/guerin/.agents/74c30681/): a camera's pose turns a pixel into a ray. Two or more posed views seeing the same plume → **triangulate the column** (ray intersection); anchor its base to the progressing perimeter. > **Multi-modal now.** The plume is seen by **four view classes** with very different pose quality: > ground PTZ (AlertWildfire — good fixed pose), aerial FMV (MISB/KLV — best, 6-DOF per frame), > news-heli (ADS-B — position-only, coarse), and the model footprint (v1 progression — no view, the base > truth). This is exactly the **heterogeneity** Buxton's read flags (note 00 §3) and what UX Sketch ④ > (three-pane compare, per-source renderer) was for: each source needs its own renderer but feeds **one** > column estimate weighted by pose confidence (feedback_every-constraint-is-soft — each view is a soft ray). ### The shape of "render & track the plume" (to be sketched, not yet decided) 1. **Locate the base:** the plume rises from the active fire edge → take it from the v1 fire-progression TOA raster at time T. 2. **Find the column:** from ≥2 posed views (ground PTZ, MISB FMV, and/or heli obliques), each view contributes a ray toward the visible column; intersect the rays — weighted by each view's pose confidence — → ground point + lean + height. MISB FMV rays (best pose, aerial) anchor it; heli rays corroborate; with one view, fall back to azimuth + assumed base from (1). 3. **Render:** draw the plume on the operating picture (a billboard/volume from base, leaning downwind), with the source frames (PTZ stills, FMV clips, heli video) as evidence and the fire footprint beneath — each source rendered in its own idiom. 4. **Track:** step T over the fire's lifetime (master clock) → the base marches along the TOA raster, the column updates from frame-synced camera poses → the plume animates. This is the "scrub" gesture as the spine. ### Smallest demonstrable slice (first prototype, per Buxton hand-off) One Sandy-Fire time window · 2–3 posed AlertWildfire/AlertCalifornia cameras · the v1 progression footprint · a naïve azimuth-intersection for the column · one renderer (drape on the existing map/engine). Answers *"does the geometry close — do the camera rays agree on where the column is?"* before any polished UI.

### Open questions (to resolve by sketching the story) 1. **Who is the user?** Incident commander at a post, a field phone, or an analyst at a desk? (The Buxton read flags we never sketched the command-post/phone axis — do it here.) 2. **Plume representation:** triangulated volume, simple leaning billboard, or just a heading arrow + cone of uncertainty? Confidence-as-opacity (faint = unsure). 3. **Which cameras saw the Sandy plume**, and is their pose good enough (the treehouse mount-cant problem from `9943ac1c`)? 4. **Track vs re-derive per frame:** carry a tracked plume object over time, or re-solve each timestep? 5. **Where does the ROP live** relative to the Catalog Shelf — a "story" you open that pre-selects the camera + FMV + heli + progression catalogs scoped to the Sandy Fire bbox + window? 6. **Fusing heterogeneous pose quality:** how do we weight a 6-DOF MISB ray vs a position-only heli ray vs a fixed PTZ ray into one column estimate (the soft-ray/bundle-adjustment framing)? And does the Sandy Fire actually have MISB FMV + heli footage in our catalogs, or only ground cameras? > Next step (Buxton method): act out this story + ~5 rough disposable frames of the plume ROP *before* > any build. Do not git-deploy a plume app until the organizing metaphor is chosen.

## References (bead cross-links) - Bead: Bill Buxton Sketching · [canonical](https://redfish.acequia.io/guerin/.agents/174efbfc-d73f-4754-b138-d2cdbbefed6d/) - Bead: Fire Progression · [canonical](https://redfish.acequia.io/guerin/.agents/182bd1a7-a376-4dd0-b445-578adc6635b9/) - Bead: Firewatch Camera Grid · [canonical](https://redfish.acequia.io/guerin/.agents/65783732-7907-4a36-983a-3b015e75e80b/) - Bead: Wildfire Imagery Acquisition & Catalog Ops · [canonical](https://redfish.acequia.io/guerin/.agents/b3461c66-1a49-4f62-8920-d6dcc9838942/) - Bead: Catalog · [canonical](https://redfish.acequia.io/guerin/.agents/90f902e0-2e45-4aa1-b998-918ca3688e94/) - Bead: Incident Viewer Taos Engine App · [canonical](https://redfish.acequia.io/guerin/.agents/cbf8b027-e80c-4b9f-8eb3-91d40af072d5/) - Bead: Egp Missions · [canonical](https://redfish.acequia.io/guerin/.agents/35e928bc-200c-4eb7-8248-e7bca9b07859/) - Bead: Cataloging Incident · [canonical](https://redfish.acequia.io/guerin/.agents/97559992-a73c-47f6-89a6-6565e0c164f3/) - Bead: Taos Engine · [canonical](https://redfish.acequia.io/guerin/.agents/c66cbd1d-453c-41f8-8440-179502f25de4/) - Bead: Media Forager · [canonical](https://redfish.acequia.io/guerin/.agents/58c0a5e0-c64e-426e-8da2-ac7f5495d18a/) - Bead: Bead · [canonical](https://redfish.acequia.io/guerin/.agents/2986ff41-41ea-4629-bc6b-3ce22f55e628/) - Bead: Astronomical Pano · [canonical](https://redfish.acequia.io/guerin/.agents/9943ac1c-caa1-479d-b17e-89ef7ca326b6/)