One sheet of everything that runs

What we built on August 16, 2026: a registry of every process that runs in the ShurIQ operation, and fifteen working dashboard panels inside Obsidian that read live vault data. Written for Alex, Diana, KG, Limore, and Nuri. It explains what exists, why we built it this way, and how the pieces are meant to be stitched together from here.

What shipped

A twelve-agent build ran overnight on August 16, 2026: four recon sweeps over the vault, one design pass, four builders, and two auditors. It produced four things, all committed to the vault under projects/shur/intent-registry/.

The intent registry. One spreadsheet, intent-registry.csv, with 62 rows and 40 columns. One row per thing that runs: 21 processes, 18 standing queries, 8 dashboard panels, and 15 registries and stores. Each row records what the thing reads and from which store, what it writes, how stale its inputs may get before the output stops being trustworthy, who reads the output, which gate its output must pass, and its honest build status. The status column tells the truth: 29 running, 12 partial, 9 not built, 8 specified only, 3 stalled, 1 dormant. The registry is now also a Google Sheet, linked at the end of this post.

A design document that treats the dashboard as a narrative problem before a layout problem. It fixes a reading order, defines what a single panel is allowed to say, names five view archetypes and five feedback loops, and catalogs seven ways a view fails, each drawn from an incident that actually happened in this vault.

Four recon documents. An inventory of all 36 in-scope Bases and the weekly questions none of them answer. A map of the processes and the live state each one needs. The ontology and its join keys. And a read of the product intent in KG's Command Center wireframes, row by row against what the vault can feed today.

Fifteen working panels. Three Bases carrying 23 views, five Dataview notes, and seven Charts View notes. Every one reads real vault data today.

Terms, defined once. Bases is Obsidian's built-in database view: it reads note frontmatter (the structured fields at the top of a note) and gives grouping, sorting, and boards without code. Dataview is a community plugin that queries the same notes with more power, including its DataviewJS mode, which runs JavaScript against the vault. Charts View is the charting plugin; our proven pattern feeds it from a DataviewJS block, so charts render live from the same notes.

Why a registry of intent

The goal is a shared mental model. Six to twelve sessions run against this vault at once, five people ship from it, and the question "what feeds this number, and is that feed alive" had no single place to get answered. Each of us carried a partial map in our head, and the maps disagreed.

The registry is that answer, written down. It matters for a reason we learned the hard way: a dead job reads green. The scheduler shows a job active, the result file is months old, and cleanly formatted cards keep appearing. It happened to the semantic store, which froze at week 16 while its nightly cards kept generating. So the registry refuses to trust configuration. A row earns running only when its result file carries a row count on two consecutive runs. A loaded schedule is not evidence. This one rule is why the sheet is worth keeping.

The registry also prices every panel we might build. A panel is a claim about state, and the row tells you whether the state it needs exists, where it lives, and how fresh it is. Ten of the forty-plus panels in KG's wireframes cannot name a data channel today. That is the build list for the sprint, and it takes nothing away from the wireframes.

The dashboard is a story with a fixed reading order

The design document opens with a rule: a reader opens the dashboard with one question and closes it with one decision. Thomas Olmsted, the one registered reader, has two recorded modes: ten minutes on Monday before the first call, and quarterly in a board room. Both read in the same order.

1. What changed since the last pass. One number per tracked entity, with the change against the prior recorded value and the date of that prior value.
2. What requires a decision. Items with a person's name, a severity, and a due condition. Second, because a decision list read cold is unreadable; a reader who has just seen what moved can weigh a decision in two seconds.
3. What produced the number. Thomas is on record that he will not act on a number without seeing what produced it. Evidence sits one click from every figure. Never zero clicks, never two.
4. What is being done, and by whom. Last, because it answers the question a reader asks after deciding.

Fifteen panels, and why each mechanism was chosen

The interesting part is the split. Which tool renders a panel is a function of the shape of the data, and the registry records that shape per row in one column, state_shape. The selection rule is mechanical:

• The value sits at the top level of frontmatter and the view needs grouping or a board: Bases.
• The value sits nested inside a list of objects, or in a JSON file: DataviewJS, because Bases structurally cannot reach it.
• The output is a chart: Charts View fed by DataviewJS.
• The nested value must ship to a client through Bases anyway: generate a derived top-level field with a drift check, the pattern watch_template_flatten.py already proves.

So the three Bases carry the plain grouped views: the queue of 76 nightly connection briefs in projects/dkr-agency/briefs, every one of which still carries status draft, the register of which builds carry a fact-check ledger and which shipped without one, and the per-brand coverage grid whose headline number is thirteen unproduced weeks. The five Dataview notes prove what Bases cannot do: reading key_numbers[].last_value inside a watch template, and joining watch templates to source-registry rows across folders on a shared key. The seven Charts View notes render the ranking, the radar, the trajectory lines, and the cadence views from live data.

From here, the path is stitching

Here is the underlying intent, stated plainly. The team gets a working intelligence environment today, before the BI terminal exists. Obsidian, the vault, and these fifteen panels are that environment, and the sprint that builds the terminal replaces panels one at a time while the registry keeps score of which claims moved from partial to running.

Each prototype is deliberately three things at once.

A working view. It answers a real weekly question against live data now.

An intervention point. Every panel is a row in the registry, and the row names its known defect and its single next step. When a panel misleads, the fix is legible: the row tells you whether the defect is in the source, the query, or the claim. The seven failure modes in the design document are the checklist.

A kit of configurable parts. The panels are not bespoke code. They are compositions of parts the system already defines: frontmatter schemas from SCHEMA-REFERENCE, controlled vocabularies from the registry, Bases templates, DataviewJS query modules, the knowledge graph sources (InfraNodus graphs, the Oxigraph store, the JSON state files), the 18 standing queries, and the conditional rules, meaning the watch-template thresholds that fire when a tracked number crosses a line, with the Conditional Mesh spec as the drafted generalization. Building the next view means stitching those parts, and the registry is the parts catalog: pick the rows, read their state_shape, and the mechanism follows.

That is what "capabilities as a function of design" means for us in practice. Nobody should have to remember what the system can do. The registry states it, per row, with the evidence file that proves it.

Where the discourse grammar lives in this

The same registry is how we encode how we talk, and it gives the team one place to configure it.

Every document in the vault now names its reader and its style guide in frontmatter, and reader: internal is banned because "internal" is not a person. The report grammar, the voice canon, and the Elements of Style spec are enforced by gates: grammar-gate.py for banned terms, consistency-gate.py for the rule that one fact gets one phrasing. The delivery grammar types every route to a reader as channel, form, reader, and action. These were already our rules. What the registry adds is the connection: the gates are rows. Each gate appears in the registry with what it reads, what it blocks, and its build status, and every producing row names the gates its output must pass in a gate column. The discourse rules stopped being lore distributed across memory files and became configuration the whole team can read, question, and change by editing a row and its controlled vocabulary.

This is the same general mental model applied to language that the panels apply to data. One fact, one phrasing, stated once, with its source one click down.

The kit

Everything below exists now.

The vault paths. Registry and README: projects/shur/intent-registry/. Panels: the bases/, dataview/, and chartsview/ folders under it. Design and recon: design/.

Open decisions, named

Three things need a person, and they are recorded as proposals rather than done work. Five artifact types that real files already use, including fact_check_ledger with 72 instances, have no schema entry and need registration. Brand-to-score joins still run on display names and need a slug field, which touches the schema and so needs sign-off. And the reader registry has one entry; naming the second reader is an open call for Jonny.

Every one of the 62 rows carries a next_step, and 33 of them sit short of running. That column is the build queue for the sprint. Pick a row.