nordisk/nornir

Nornir Warehouse — Authoritative Schema Reference

Epic A of THE_BIG_PLAN. Derived by a deep read of src/warehouse/* plus an exhaustive grep of every Iceberg table name's write- and read-sites across src/. Section 2 documents only tables that exist in code today; Section 4 ("What should be added") is explicitly a proposal set.

0. How the warehouse is wired

The warehouse is an append-only columnar store. The canonical backend is IcebergWarehouse — Apache Iceberg via iceberg-rust over a single-file skade-katalog redb catalogue. Every derived fact is an Iceberg row; each append produces a fresh Iceberg snapshot, so the table "as of snapshot T" is the state at time T (true time-travel for free).

Key plumbing facts (from src/warehouse/mod.rs, iceberg.rs):

• Trait surface: Warehouse (mod.rs) has 9 methods — the generic Arrow rail (append_arrow, scan_arrow, scan_filtered, scan_limited), schema plumbing (ensure_table, ensure_columns, table_names), and the two bench convenience methods (append_bench_run, query_bench_runs). Everything else is concrete methods / free functions on IcebergWarehouse. A future RemoteWarehouse (Arrow Flight → nornir-server, Phase 5) will reuse the trait.
• Open paths: open() (mutating) vs open_read_only() (copies a read-only snapshot aside if the live server holds the redb lock — so a CLI read can never be wedged).
• Table registration: IcebergWarehouse::open calls an ensure_layout routine (iceberg.rs) that creates the namespace if missing, then idempotently create_table_if_missing / create_partitioned_table_if_missing for every table below. New fields append with a fresh, unused field ID — never reuse, never renumber (iceberg_schema.rs header rule).
• Partitioning: artifact *_snapshots partition by repo (lookup latest per repo); artifact *_blobs partition by snapshot_id (fetch one snapshot's bytes); knowledge-map + sbom_components + knowledge_scans partition by repo. All others are unpartitioned (scan + filter / row-group pruning).
• Generic readers: table_names() and scan_preview(table, limit) back the viz Warehouse introspection tab and the server's wh.table_names / scan_preview RPCs — so every table is browsable generically even when it has no bespoke reader.

Type legend

Iceberg primitive types as they appear in iceberg_schema.rs. Timestamptz columns are stored as Arrow timestamp[µs, +00:00] (the ts_micros convention). req = required (non-null), opt = optional (nullable). "PK"/"FK" are logical — Iceberg has no enforced keys; they are the join columns the code actually uses.

1. Table inventory (72 tables)

Numbered 1..72 in ensure_layout (iceberg.rs) registration order — the row number is the physical table ordinal, so the last row is the total. Groups follow the create-order blocks.

Complete physical inventory: 72 tables (every create_*_table_if_missing in ensure_layout, cross-checked against sql.rs's "71-table catalog" — that prose count predates feature_dep_edges). Of these, the five artifact pairs = 10 tables share just two schemas (artifact_snapshots() / artifact_blobs(), each reused by 5 tables); the remaining 62 tables each have their own schema fn. So the 72 tables resolve to 64 distinct schema functions — the artifact pair is the only schema reuse; all other rows map 1:1 to a fn. (This supersedes the earlier stale "47 tables / ~35 schemas" count, which predated the build-provenance, op/populate-event, coverage, UI-oracle, binary-analysis, bake-off, viz-trail, saga and yggdrasil-infra table families.)

§2 caveat: the per-table documentation in §2 below is not yet exhaustive — it predates several of the families added here (binary-analysis, coverage, yggdrasil, etc.). §1 is the authoritative physical roster; §2 is a being-caught-up prose subset. Every table is browsable generically via scan_preview / table_names regardless of whether §2 documents it yet.

2. Per-table documentation

Group: bench / test history

bench_runs

One row per bench invocation (IcebergWarehouse::append_bench_run).

• Writes: append_bench_run_async (iceberg.rs), invoked from bin/nornir.rs (nornir bench …). Co-writes bench_results + test_outcomes under the same run_id.
• Reads: query_bench_runs_async (filter by repo/machine/limit); viz viz/model.rs timeline; viz/timetravel.rs.
• Relations: run_id → bench_results.run_id, test_outcomes.run_id.

bench_results

Long/narrow metric rows for a run.

• Writes: co-written by append_bench_run_async. Reads: viz/timeline, generic scan_preview.

test_outcomes

One row per test case in a run; also the substrate for flake/quarantine windows.

• Writes: co-written by append_bench_run_async.
• Reads: window queries feed test_quarantines decisions; viz.
• Relations: run_id/retry_of_run_id → bench_runs; test_name+repo → test_quarantines.

Group: dependency graph

dep_graph_edges

Long format: one row per (snapshot, edge, via-crate). The whole cross-repo graph at a point in time. src/warehouse/dep_graph.rs.

• Writes: dep_graph::record_dep_graph (one row per via-crate; empty-graph marker row if no edges).
• Reads: dep_graph::query_dep_graph_snapshots (pushes workspace_name filter + column projection, rolls long rows back into DepGraphSnapshot); release::regression::trace ranks suspects off a snapshot; viz Timeline RPC.
• Relations: snapshot_id is the join target for release_lineage, yank_events, semver_diffs, links_declarations, resolved_features, test_impacted_selections, version_bump_plans (all carry dep_graph_snapshot_id).

Group: release provenance

release_lineage

One row per (release, repo) — full provenance of a release op. Per-repo gate_status makes partial releases reconstructable. src/release/pipeline.rs (persist_lineage).

• Writes: release::pipeline::persist_lineage, invoked from bin/nornir.rs (nornir release). Reads: docs/release_book.rs (renders the per-repo lineage table), viz viz/model.rs + viz/timetravel.rs (release timeline, artifact pins for time-travel), release::regression.
• Relations: dep_graph_snapshot_id, the four *_snapshot_id artifact pins; release_id is FK target for the cargo-pipeline release-scoped tables.

release_events

The row-level DAG of a release run — one row per component × op × phase boundary as the pipeline walks the build order. Where release_lineage is the outcome, this is the shape. The structural twin of funnel_events. src/warehouse/release_events.rs (schema release_events()). Full design: release-events.md.

• Writes: release_events::ReleaseEventEmitter (best-effort + non-fatal), driven by BOTH release::pipeline::run_pipeline (library/server path) and run_release_run in bin/nornir.rs (fat-CLI nornir release run). The fat-CLI path keys run_id to its ndjson progress run_id so the live file and the warehouse DAG share an id.
• Reads: release_events::query_release_events(EventSelector::{Run|Repo|All}) (sorted by (run_id, seq)); the nornir release events <repo|run_id> CLI (render_topo / rows_to_json); the future viz "Release Ops" tab (B3/B4).
• Relations: run_id loosely ↔ release_lineage.release_id; depends_on entries + repo share repo identity with dep_graph_edges and release_lineage.repo.

Group: idea-intake funnel DAG

funnel_events

Append-only event log of the idea→plan→run DAG. Wide/typed (one optional column per variant field) so SQL readers query the DAG directly. src/warehouse/funnel.rs.

Envelope: event_id (string req, PK), ts_micros (timestamptz req), kind (string req — the variant tag).

Common id refs (subset per kind): idea_id, plan_id, node_id, run_id, from_node, to_node (all string opt).

Variant payload columns (all opt): source, text, refs (list<string>), decision, node_status, plan_status, why, summary, planner, node_kind, targets (list<string>), prompt_excerpt, params_json (string — open-ended JSON), ran_by, outcome, log_ref, produced_commits (list<struct{repo,sha}>), produced_test_runs (list<string>).

• Writes: funnel::append_event (each mutation = one row = one Iceberg snapshot), driven by src/funnel/store.rs and the CLI funnel commands.
• Reads: funnel::load_all_events replays the whole log into the in-memory DAG; viz Funnel tab; MCP funnel tools (bin/nornir-mcp.rs).
• Relations: run_id loosely co-references bench run_id; produced_commits references repo SHAs (same identity as release_lineage.git_sha, release_commits.git_sha).

Group: artifact time-machine (snapshot + blob pairs)

Five logical artifact kinds, each a (<kind>_snapshots, <kind>_blobs) pair sharing the generic artifact_snapshots() / artifact_blobs() schemas. Restore = SELECT blobs WHERE snapshot_id=X → write each (filename, bytes) to a tmpdir → mmap with the native loader (no re-tokenize/rebuild). Blob writes are content- deduped by sha256 (src/warehouse/blob_store.rs).

Kinds: tantivy_index_* (code search index — live), rustdoc_json_* (semver diff source — live, feature 7), docs_index_* (rendered-docs search index — live), dwarf_* + gimli_* (debuginfo / unwind — registered stubs, no capture logic ships yet).

<kind>_snapshots (schema artifact_snapshots, partition repo)

<kind>_blobs (schema artifact_blobs, partition snapshot_id)

• Writes: snapshot rows by the capture path (index/docs build, rustdoc-json capture); blob rows via blob_store::put_blobs_dedup. Idempotency: artifact_snapshot_id_for(repo, git_sha) skips re-capturing an existing SHA.
• Reads: index_snapshot_id_for / dwarf_snapshot_id_for lookups; restore paths in index/docs/semver; viz time-travel resolves the pins on release_lineage.
• Relations: snapshot_id is FK target from the matching release_lineage pin column; rustdoc_json_snapshots.snapshot_id is referenced by semver_diffs.from_snapshot_id/to_snapshot_id.

Group: rendered docs

doc_exports

Historized rendered-doc exports (inline bytes), one row per distinct (repo, doc_name, version, format, sha256). src/docs/warehouse.rs.

• Writes: docs::warehouse export path (nornir docs export).
• Reads: list_doc_exports, doc fetch-by-version; the file directory under docs/ only holds the current copy, past versions come from here.

Group: vector / semantic search

embeddings

Content-addressed, deduped vector store. src/vector/store.rs.

embedding_snapshots

Identity of one index build (makes re-index idempotent).

embedding_manifest

Per-occurrence rows for a snapshot (no vector, no source text).

• Writes: vector::store index path (append_embeddings + snapshot + manifest). Reads: time-travel semantic search filters manifest by snapshot_id, JOINs embeddings, builds the in-memory VectorIndex.
• Relations: (content_hash, model_profile) join embedding_manifest ↔ embeddings; snapshot_id join embedding_manifest ↔ embedding_snapshots.

Group: cargo-pipeline fact tables (features 1–15)

Status note (load-bearing for the gap analysis): these 16 tables are all registered at warehouse open and have full schemas + helper structs/prose, but only a subset are wired to a live write path today. The bespoke append code for publish_attempts and crate_tarball_stats now lives with the release ENGINE in dwarves::release_doctor::publish (moved out of nornir under doctrine L5a — dwarves/crates/dwarves/src/release_doctor/publish.rs); nornir writes links_declarations (from bin/nornir.rs) and reads all of these back through the Mimir warehouse for its lineage verbs. The rest are forward-compatible schema stubs awaiting their producer. All are browsable via scan_preview.

• Relations: release-scoped tables FK release_id → release_lineage; graph-scoped tables FK dep_graph_snapshot_id → dep_graph_edges; semver_diffs FKs into rustdoc_json_snapshots; version_bump_targets FK plan_id → version_bump_plans and applied_release_id → release_lineage.

Group: knowledge map (syn + gix producers)

One snapshot_id per nornir knowledge scan <repo>. Partitioned by repo.

symbol_facts

One row per public item found by the syn walker.

call_edges

Call edges from syn ItemFn bodies (callee unresolved).

snapshot_id(req), ts_micros, repo(part), crate_name, caller_path, callee_ident, call_kind, file, line(int) — all req.

feature_gate_facts

One row per #[cfg(...)] on a discovered item.

snapshot_id, ts_micros, repo(part), crate_name, module_path, item_name, cfg_expr(raw text), file, line — all req.

feature_dep_edges

One row per edge of the FEATURE ACTIVATION graph parsed out of Cargo.toml — which feature enables which dependency / other feature. The manifest side of the feature story (feature_gate_facts is the source side). Exists because cargo metadata cannot supply it: its features map is already flattened and resolved, so the conditional structure — above all the weak pkg?/feat form — is gone before cargo hands the data over.

snapshot_id, ts_micros, repo(part), crate_name, feature, enables, kind, optional(bool), dep_kind — req; target_cfg — opt.

• feature — "" means UNCONDITIONAL (not behind any feature), i.e. the ⊥ "cannot be removed by any feature toggle" case. Not a missing value.
• kind — dep | feature | dep-feature | weak-dep-feature | implicit-dep. weak-dep-feature is pkg?/feat, the ONLY form that creates an AND-group (fires only if pkg is enabled by another route) — the reason the table exists.
• target_cfg — the [target.'cfg(...)'] predicate; NULL ⇒ unconditional across targets (never the empty string).
• dep_kind — normal | build | dev, so a consumer can drop dev-deps the way cargo tree -e no-dev does.
• Sort key (repo, enables, crate_name, feature) — enables leads so the reverse point lookup "which features pull dep X" prunes files.
• Writes: warehouse::feature_dep_edges::append_feature_dep_edges, driven by populate step 7d (monitor::republish_with → compute_feature_graph), which parses every present member's manifests through the nornir-feature-graph edda leaf. Compute fans out over members on gatling; the append is serial and writes one snapshot id for the whole run (the writer groups by repo internally, because the table is partitioned and skade allows one partition per append — a per-member id would make the reader return only the last member). Reads: query_feature_dep_edges — which errors (never returns an empty Vec) when the scope was never populated, because "no rows" here would read as the meaningful answer "nothing pulls this dependency". It also errors on a kind/dep_kind string it cannot classify rather than defaulting one.
• One row type (L5): the row struct + the EnableKind/DepKind codecs come from the parser leaf (nornir_feature_graph, re-exported as nornir::feature_graph), so writer, reader and the in-memory graph cannot disagree about the shape.
• Measured 2026-08-01 over the real nornir + edda + dwarves trees: 1078 edges / 86 packages, of which 8 are weak-dep-feature and 661 unconditional.

git_heat_facts

Per-file git activity heat at scan time.

snapshot_id, ts_micros, repo(part), file, commits_total(long), commits_30d(long), commits_90d(long), authors_total(long), last_commit_ts_micros(timestamptz) — all req.

• Writes: append_symbol_scan (symbol+call+feature-gate in one scan), append_git_heat_scan; driven by bin/nornir.rs (nornir knowledge scan) via src/mimir.rs.
• Reads: knowledge::query::load_latest(repo) (latest scan per repo, partition-pruned); viz callgraph.rs, ops_tabs.rs, remote.rs.
• Relations: snapshot_id ties the four tables of one scan together; recorded in the knowledge_scans ledger keyed by (repo, git_sha).

Group: telemetry / security / ledger

mcp_requests

MCP tool-call telemetry (metrics only — no payloads).

ts_micros(timestamptz req), tool(string req), status(string req), latency_ms(long req).

• Writes: append_mcp_calls (from the MCP server bin/nornir-mcp.rs).
• Reads: query_mcp_stats (McpToolStat aggregation); viz mcp_tab.rs.

vuln_findings

Cached OSV/RUSTSEC findings keyed by immutable crate@version.

crate(req), version(req), ids(req — comma-joined advisory ids; empty = checked-clean), summary(req), checked_at_micros(timestamptz req).

• Writes: append_vuln_findings (src/security.rs after an OSV/advisory-db lookup). Reads: query_vuln_findings (warehouse-first; only un-cached crate@versions hit OSV); viz security_tab.rs; server RPC.

sbom_components

One row per resolved dep in a repo's closure, per capture snapshot_id. Partition repo.

snapshot_id(req), ts_micros(timestamptz req), repo(req, part), name(req), version(req), license(req).

• Writes: append_sbom_components (src/security.rs, from a deep-scan / cargo metadata sweep). Reads: query_sbom_components(repo) assembles the CycloneDX SBOM from the latest snapshot per repo (no server-side cargo metadata); viz security_tab.rs.

knowledge_scans

Ledger: one row per (repo, git_sha) knowledge-scanned. Partition repo.

repo(req), git_sha(req), snapshot_id(req), scanned_at_micros(timestamptz req).

• Writes: record_knowledge_scan. Reads: knowledge_scan_exists(repo, git_sha) makes re-scanning an unchanged SHA a no-op (idempotency on the republish path).
• Relations: snapshot_id → the knowledge-map tables produced by that scan.

warehouse_access_edges

The fn → warehouse-table access fact (AUT7 / EPIC ARCH n-002): the ONE wiring edge no call graph yields — which function reads/writes which warehouse table. Code-derived by a static syn pass (src/warehouse/access_scan.rs), not a manual grep. Grounded in the layer-boundary-discoverability LAW: warehouse access goes through canonical accessors (query_<table> / append_<table> / the generic scan_preview), so the access sites are enumerable by callee name. One row per (caller_fn, table, access) site; one scan = one snapshot_id.

snapshot_id(req, PK with caller_fn+table+access), ts_micros(timestamptz req), caller_fn(req — crate::module::Type::fn), crate_name(req), table(req — the warehouse table, or the <dynamic> sentinel for a generic scan_preview(var, …) whose table is a runtime value), access(req — read|write), file(req), line(int req).

• Writes: warehouse_access::append_warehouse_access_edges (one Iceberg snapshot per scan), fed by access_scan::scan_repo / scan_source.
• Reads: warehouse_access::query_warehouse_access_edges(AccessSelector:: {All|Snapshot|Table|Crate}), sorted by AccessEdge::key(); generic scan_preview for the browser. This is the feeder the ARCH auto-generator (n-006) consumes for its core-fn → table edges (§5 of architecture-wiring.md).
• Accessor → table map (what's covered): the named per-table readers/writers (query_test_results→test_results read, append_release_events→release_events write, record_dep_graph→dep_graph_edges write, append_bench_run→ bench_runs+bench_results+test_outcomes write, append_symbol_scan→ symbol_facts+call_edges+feature_gate_facts write, append_event→funnel_events write, persist_lineage→release_lineage write, load_all_events→funnel_events read, query_{mcp_stats,sbom_components,vuln_findings,viz_actions, agent_model_runs,bench_telemetry,dep_graph_snapshots}, the matching append_*, record_knowledge_scan/knowledge_scan_exists→knowledge_scans, load_latest→the four knowledge-map tables) plus the generic scan_preview/table_names with a literal table argument.
• Not statically knowable (limits): a scan_preview(var, …) with a runtime table → <dynamic> (the viz Warehouse browser + MCP RPC iterate table_names()); accessor indirection through a fn pointer/closure; trait dispatch (TestSink::append) — matched by concrete fn/method name only.

3. ER diagram

Plain-text relationship list. Cardinality notation: 1──* = one-to-many, *──1 = many-to-one (required parent), *──o1 = many-to-optional-one. The joining key is in parentheses.

bench_runs           1──*  bench_results              (run_id)
bench_runs           1──*  test_outcomes             (run_id)
test_outcomes        1──*  test_quarantines          (test_name+repo)

dep_graph_edges      1──*  release_lineage           (dep_graph_snapshot_id)
dep_graph_edges      1──*  yank_events               (dep_graph_snapshot_id)
dep_graph_edges      1──*  links_declarations        (dep_graph_snapshot_id)
dep_graph_edges      1──*  resolved_features         (dep_graph_snapshot_id)
dep_graph_edges      1──*  test_impacted_selections  (dep_graph_snapshot_id)
dep_graph_edges      1──*  version_bump_plans        (dep_graph_snapshot_id)

release_lineage      1──*  path_dep_audits           (release_id)
release_lineage      1──*  patch_strip_events        (release_id)
release_lineage      1──*  publish_attempts          (release_id)
release_lineage      1──*  crate_metadata_checks     (release_id)
release_lineage      1──*  crate_tarball_stats       (release_id)
release_lineage      1──*  release_commits           (release_id)
release_lineage      1──*  registry_mirrors          (release_id)

release_lineage      1──*  release_events            (release_id≈run_id, loose)

release_lineage      *──1  tantivy_index_snapshots   (tantivy_snapshot_id)
release_lineage      *──1  dwarf_snapshots           (dwarf_snapshot_id)
release_lineage      *──1  gimli_snapshots           (gimli_snapshot_id)
release_lineage      *──1  rustdoc_json_snapshots    (rustdoc_json_snapshot_id)

tantivy_index_snapshots  1──*  tantivy_index_blobs   (snapshot_id)
dwarf_snapshots          1──*  dwarf_blobs           (snapshot_id)
gimli_snapshots          1──*  gimli_blobs           (snapshot_id)
rustdoc_json_snapshots   1──*  rustdoc_json_blobs    (snapshot_id)
docs_index_snapshots     1──*  docs_index_blobs      (snapshot_id)

rustdoc_json_snapshots   1──*  semver_diffs          (from/to_snapshot_id)

embedding_snapshots  1──*  embedding_manifest        (snapshot_id)
embeddings           1──*  embedding_manifest        (content_hash+model_profile)

version_bump_plans   1──*  version_bump_targets      (plan_id)
version_bump_targets *──o1 release_lineage           (applied_release_id)

knowledge_scans      1──*  symbol_facts              (snapshot_id)
knowledge_scans      1──*  call_edges                (snapshot_id)
knowledge_scans      1──*  feature_gate_facts        (snapshot_id)
knowledge_scans      1──*  feature_dep_edges         (snapshot_id)
knowledge_scans      1──*  git_heat_facts            (snapshot_id)

feature_dep_edges    *──*  feature_gate_facts        (repo+crate_name+feature≈cfg_expr, loose)

funnel_events        1──*  bench_runs                (run_id, loose)

4. What should be added (proposals — NOT in code today)

These are roadmap proposals. None of the tables/columns below exist in iceberg_schema.rs yet; each entry states why, the columns, and the write/read path it would plug into.

4.1 release_events — a clean release-op DAG ✅ IMPLEMENTED

Status: shipped (Epic B / B1+B2). Moved out of the proposal set — see the per-table entry in §2 (group "release provenance") and the design doc release-events.md. The shipped schema refined the proposal below: the PK is (run_id, seq) (a per-run monotonic seq is the durable ordering key instead of a bare event_id, since Iceberg gives no scan order); repo is a first-class column alongside component; detail is required ("" = none); elapsed_ms was added (nullable, end rows only); and depends_on carries component names (the dep-graph producers a repo waited on), not event ids — that's what the viz draws edges from.

Write path: release_events::ReleaseEventEmitter, driven by both release::pipeline::run_pipeline (server) and run_release_run (fat CLI), best-effort + non-fatal. Read path: nornir release events <repo|run_id> (CLI parity ✓) + query_release_events; the viz "Release Ops" tab (B3/B4) is the remaining consumer.

The original proposal (kept for the record):

4.2 test_results — first-class suite/case results ✅ IMPLEMENTED (C6b)

Status: shipped (Epic C / C6b). test_outcomes is bench-shaped (keyed to a bench_runs.run_id, co-written with a bench); this is the standalone green/red board the C6 test-matrix writes. Moved out of the proposal set — see the schema fn iceberg_schema::test_results(), write/read in src/warehouse/test_results.rs, and the design doc test-matrix.md. The shipped schema refined the proposal: the case column is named test_name; duration_ms is required (0.0 when the runner gives none); message is required ("" = none); status ∈ pass | fail | ignored | stalled (the stall watchdog records stalled + red); partitioned by repo so per-repo reads prune. There is no release_id pin yet (release-coupling is a follow-up; the matrix is deliberately bench/release-free).

• Write path: nornir test run/test all → append_test_results (fat-CLI today, like bench run; a Test.Submit RPC is a follow-up). One Iceberg snapshot per run; repo-partitioned so a batch is one repo.
• Read path: the viz 🧪 Test pane (src/viz/test_tab.rs); the nornir test history <repo> CLI (render_matrix / rows_to_json); query_test_results(TestSelector::{Run|Repo|All}).

4.3 Bench CPU / telemetry — bench_telemetry (IMPLEMENTED, P1.2)

Why. bench_runs had cores but no runtime telemetry, so a slow run couldn't be correlated with machine load. Telemetry is captured per bench unit, not per run, so it lands in a sibling table keyed by (run_id, bench) rather than as columns on the one-row-per-run bench_runs. (This supersedes the earlier "columns on bench_runs" sketch; per-bench grain is the right shape and it keeps the load profile out of bench_results so it never competes in the docs metric-comparison renderer.)

bench_telemetry (schema fn bench_telemetry(), partition repo):

• Sampler: src/bench/telemetry.rs — a 1 Hz background thread reading /proc/stat + /proc/self/status + /proc/meminfo (no perf/ptrace/crate); non-perturbing. Folds min/avg/max; publishes live cores-busy for the progress line. See .nornir/bencher.md § Live CPU/mem telemetry.
• Write path: run_pass injects the summary into each BenchResult.metrics under reserved telem_* keys (so it survives the stdout-JSON hop); append_bench_run_async lifts those keys into bench_telemetry and excludes them from bench_results.
• Read path: IcebergWarehouse::query_bench_telemetry(Some(repo)) → Vec<BenchTelemetryRow>; generic scan_preview for the viz browser.

4.4 work_log — op / work-log table

Why. There is no durable, queryable record of who ran what nornir command when, and with what result across the whole tool. mcp_requests covers MCP tool calls only. An op-log gives provenance for every CLI/RPC mutation.

• Write path: a thin wrapper around CLI command dispatch in bin/nornir.rs (and the server RPC layer) appends one row per mutating op.
• Read path: viz "Activity" tab; nornir log CLI; audit/forensics.

4.5 robot_test_results — UI/robot-test outcomes

Why. The Njord/UI robot-test goal (per memory) needs a place to land automated UI/robot test outcomes with screenshots/diffs, distinct from unit tests.

• Write path: the robot-test harness appends per step; screenshots stored via the existing blob_store dedup path into a new robot_blobs artifact pair.
• Read path: viz "Robot Tests" tab with pass/fail + screenshot preview; CLI nornir robot status.

4.6 funnel_demo_provenance — funnel-demo provenance

Why. Funnel-demo / seeded-DAG runs currently leave no marker distinguishing demo events from real intake in funnel_events, so a demo can pollute the real DAG view. A provenance side-table (or a provenance column on funnel_events) lets the viz filter demo vs real.

• Write path: the funnel-demo seeder tags every event it emits; real intake defaults to real.
• Read path: viz Funnel tab gains a "hide demo" toggle; queries can WHERE provenance='real'. (Cheaper alternative: add one optional provenance column to funnel_events — field ID 28 — and skip the side-table.)

5. Verification notes

• Markdown is plain CommonMark; tables are GitHub-flavored.
• The entity/relationship diagram is a plain text block (ASCII tree, bare identifiers, relationships noted inline) — no mermaid, per the NUKE-MERMAID standard; it renders verbatim everywhere with no JS and no diagram engine.
• This doc lives under .nornir/ and is intentionally not in the docs-export render set, so nornir docs check does not gate on it; it stays hand-maintained.

Migrations — use Iceberg schema evolution (LAW)

When a warehouse table's schema changes, use Iceberg's native schema evolution as much as possible instead of rewriting/repartitioning data:

• Add columns (new fields default to null on old rows), rename, reorder, widen types (int→long, float→double) — all are metadata-only operations in Iceberg; existing data files are untouched and stay readable.
• A reader written for the new schema reads old files transparently (missing columns → null); a reader for the old schema ignores new columns.
• Avoid full table rewrites, drop-and-recreate, or repartition-rewrite unless a change genuinely can't be expressed as evolution (e.g. a type narrowing or an incompatible partition-spec change) — and when unavoidable, do it as an explicit, logged migration, never silently.
• New tables/columns ship additively so a server running the old binary keeps reading the warehouse a newer binary wrote, and vice-versa.

On-append auto-evolution (ensure_table_schema)

create_table_if_missing is create-only — it never touches an existing table. So a table created by an older binary keeps that binary's (narrower) schema forever, even after the canonical schema fn grows new columns. A writer that builds the full canonical Arrow batch then fails with number of columns(N) must match number of fields(M).

The fix (shipped 0.4.24): [warehouse::iceberg::ensure_table_schema] is called on the write path right after load_table. It diffs the table's current top-level column names against the canonical schema; if any are missing it commits an Iceberg add-column migration (the missing fields added as OPTIONAL, keeping their canonical field-ids) via skade's RedbCatalog::commit_table raw primitive (AddSchema + SetCurrentSchema). iceberg-rust 0.9.1 exposes no public schema-mutation Transaction action, so this raw-commit path is the only public route until 0.10.

• Wired on: agent_model_runs (append_agent_model_runs, 13→16) and test_results (append_test_results, 8→10) — the two tables whose canonical schemas grew columns after live servers had already created them. The migration is logged to stderr and is a no-op fast path once the table is current.
• Safe by construction: old data files are untouched (add-column is metadata-only; old rows read those columns back as null) and every read path already defaults the optional columns, so a mixed-version warehouse stays readable both ways.

Binary-analysis fact tables (task #65, slice 1)

The binary-analysis subsystem (the compiled-artifact twin of Mimir's source intelligence — .nornir/binary-analysis-design.md) adds 3 new Iceberg tables in slice 1, all keyed by content_sha256 — the build_info.content_id / build_provenance.digest join key every binary fact hangs off, so no new identity is invented. Written by nornir::binscan::persist_report (from nornir-introspect's size + hardening pure-Rust producers); registered + partitioned by content_sha256 in create_all_tables; read back by query_binary_facts / query_section_sizes / query_symbol_sizes.

• binary_facts — one header row per analysed artifact: format / arch / class / total_bytes + the checksec verdict (stripped / has_debug_info / pie / relro / nx / stack_canary / fortify / rpath / runpath / build_id_note) + the section/symbol/dep counts, plus the repo / git_sha / build_id build context. Partition + sort key: content_sha256.
• section_sizes — one row per (artifact, section): size_bytes / vaddr / alloc·exec·write flags / file_offset / kind — the Bloaty section view. Sort key: content_sha256, section_name.
• symbol_sizes — one row per (artifact, symbol): mangled + demangled (± generics) names, crate_name (GROUP BY → per-crate roll-up), section, size_bytes, kind, binding, is_monomorphization (twiggy monos), and the DWARF-joined source_file / source_line. Sort key: content_sha256, crate_name, symbol_mangled.

Binary-analysis diff table (task #65, slice 2)

Slice 2 adds the 4th binary-analysis table, artifact_diff — the artifact-to-artifact diff, the binary twin of the source-side semver_diffs. One narrow row per change between a (base, new) artifact pair, keyed on the pair (from_content_sha256, to_content_sha256). Written by nornir::binscan::persist_diff (from nornir-introspect's diff pure-Rust producer — gatling-parallel over the union of both symbol tables, ROOT-LAW #0); partitioned by to_content_sha256 in create_all_tables; read back by query_artifact_diff(from, to).

• artifact_diff — one row per change: kind ∈ size_delta / section_delta / crate_delta / symbol_added / symbol_removed / symbol_grew / symbol_shrunk / abi_added / abi_removed; name (the changed symbol / section / crate, or total_bytes), crate_name attribution, before / after / delta_bytes (the size waterfall), and severity (info / warn / high — a removed export is high, the gate hint). Plus the repo + optional release_id lineage anchor. Partition key: to_content_sha256; sort key: to_content_sha256, from_content_sha256, kind.

Deferred to later slices (do NOT exist yet): the sbom_components.derived_from column (slice 4). With artifact_diff, the live Mimir table count lands the design's 67→71 target (67→70 at slice 1; artifact_diff closes it at 71).