**Note** from Bead: Firewatch Camera Grid · [canonical source](https://redfish.acequia.io/guerin/.agents/65783732-7907-4a36-983a-3b015e75e80b/2026-06-13/notes/03-active-cataloger-vs-catalog-management.md) · session 2026-06-13 · discussion: Talk: Firewatch Camera Grid
Stephen, 2026-06-13: *"the actual processing of partially-structured sources need evaluation and script composition by AI with the queries executed by the browser or OS process instead of cloud. and then reifying some of the repeatable workflow with stable data sources. That's part of an 'active cataloger' vs a catalog management (which is boring. eg look at this STAC browser which is one level up from being a database cursor — https://radiantearth.github.io/stac-browser/)."*
## The distinction - **Catalog management (passive).** A reader/cursor over an *already-clean, already-structured* catalog. STAC Browser is the canonical example: it pages through a well-formed STAC API — one level up from a DB cursor. Necessary, but boring; it assumes the hard part (turning messy reality into structured items) is already done. - **Active cataloger.** An agent that *does the hard part*: confronts **partially-structured sources** (vendor telemetry blobs, PROPFIND listings, scraped APIs, KMZ, mixed mirrors), **evaluates** them, and **composes a processing script** on the fly to extract structure. The catalog is the *output* of an active wrangling loop, not a given.
## How the active cataloger runs (the architecture) 1. **AI evaluates + composes the script.** The agent inspects a new/odd source and writes the ETL/query for it (no pre-baked connector). Open-ended, per-source. 2. **Queries execute in the browser / OS process — not cloud.** Execution is local to the parciante's body (CE browser DOM, CV shell/OS, CB fetch) and the user's own credentials/network — not a hosted backend. This is the RTE remote-first stance from the *consumer* side: the *compute* is at the edge too, hitting remote sources directly. (Keeps creds local, avoids a cloud middleman, scales by pushing work to the node.) 3. **Reify the repeatable workflow once the source is stable.** When a composed script proves repeatable against a **stable data source**, crystallize it — into a `skill` (a named, re-runnable capability) and/or a bound workflow. Ad-hoc evaluation → durable skill. The catalog manager thus *accretes* connectors as it meets sources.
## This bead is already an instance `derive-alertwildfire-sidecars.{mjs,md}` (S2) IS active cataloging: I evaluated the partially-structured AlertCalifornia telemetry (a vendor blob with no lat/lon, overlapping bundles, an odd id space), composed a script to extract posed/timed records, ran it **locally** (Node/CV, hitting the online source), verified the convention, and **reified it as a skill**. The firewatch manager should expose this loop as a first-class action — "point me at a source → I evaluate + compose + run locally → offer to save the workflow as a skill" — not just browse a finished catalog.
## Design implications for the manager - A **"new source" action** (beyond "link cache"): paste a URL/endpoint → the agent characterizes it (PROPFIND/probe/sniff), proposes an extraction, runs it edge-side, previews items, and offers to bind + reify. - The composed scripts are **edge-executed** (the app's JS in the browser, or a CV/CB agent), against qualified remote URLs (note 02) — never a cloud ETL service. - **Reification surface:** save a working extraction as a bead `skill` (like the derive skill) + a stable-source binding; the catalog grows connectors over time. - Contrast target to avoid being: STAC Browser (passive cursor). Contrast target to be: an agent that turns a messy ops dir into a posed, scrubbable, bindable catalog — and remembers how.