README

Dataview & Obsidian Setup — Usage Guide

Notes for the user and the Docs agent on the Obsidian/Dataview setup of this wiki. Broader
“how to use the wiki” rule: USAGE.md. Schema law: CLAUDE.md.

Plugins installed (vault = wiki/)

• Dataview — live tables/lists from page frontmatter. Powers the dashboards/ views.
• Templater — page templates in _templates (result/topic).
  Setup: Settings → Templater → Template folder location = _templates. Use via
  ⌘P → "Templater: Create new note from template". (The core “Templates” plugin will NOT render the
  <% … %> syntax — it needs Templater.)
• Tasks — checkbox queries (powers dashboards/open_questions.md).
• Kanban — board view (dashboards/verify_board.md: draft → reviewing → verified).
• Core Bases is also enabled (native DB views) — an optional future alternative to Dataview.

Naming: dashboards vs reports

• dashboards/ — important, human-facing live views. No underscore prefix (house rule:
  important files don’t take a leading underscore; the folder does the grouping).
• _reference/_*.md — transient, machine-generated reports (underscore = scratch). Regenerated by
  scripts; safe to delete. These are: _lint_report.md, _classification_report.md,
  _classification_review.md, _review_needed.md, _topic_merge_candidates.md.

The dashboards (dashboards/, Obsidian-only)

• overview.md — drafts-by-type, results (with proof status), topics
  missing kind/related, recently-updated, and the inconsistency roll-up.
• inconsistencies.md — every page carrying an inconsistencies: flag.
• equations.md — result pages with proof status (proven vs stub →
  Phase-D checklist) and the singularity/Γ cluster.
• clusters.md — counts and page lists by topical tag and by the
  regime / layer axes (incl. the free-floating re-derivation watch-list).
• verify_board.md — Kanban verify board, seeded from review
  (run scripts/seed_kanban.py to re-seed; folder-qualified [[…]] links).
• open_questions.md — Tasks roundup of every unresolved
  - [ ] item inside an ”## Open Questions” section.

These render only in Obsidian (Dataview / Tasks / Kanban). On GitHub they appear as raw code
blocks — which is why the canonical catalog index.md is kept static
(centrally-assembled) and GitHub-readable.

Frontmatter fields the queries depend on

Dataview reads YAML frontmatter; the schema keeps it consistent:

Field	Values	Used for
type	source / topic / result	group & filter by kind
review	draft / verified	the verify workflow
status	stub / developing / evergreen	maturity views
kind	phenomenon / technique (topics)	topic filtering
regime	free_flying / free_floating / fixed_base / general	the dynamics-assumption axis
layer	nominal / risk_aware	nominal-vs-risk research-phase axis
proof_status	proven / stub (results)	Phase-D proof checklist
tags	closed vocab (YAML list)	tag clusters / #tag queries
related	list of page stems	graph / “missing related” view
bibkey	matches ../raw/references.bib (sources/results)	citation join
inconsistencies	list of one-line notes	the inconsistency dashboard
created / updated	YYYY-MM-DD	recency views

Writing / extending queries (examples)

```dataview
TABLE status, bibkey FROM "results" WHERE review = "draft"
```

• Topics still missing kind: LIST FROM "topics" WHERE !kind
• Everything tagged singularity: TABLE type FROM #singularity (tags become #tags in Dataview)
• Free-floating re-derivation watch-list: TABLE tags FROM "sources" OR "results" WHERE regime = "free_floating"

Dataview reference: https://blacksmithgu.github.io/obsidian-dataview/

Conventions that keep it healthy

• Relative-markdown links only ([x](../topics/x.md)), never [[wikilinks]] — GitHub
  compatibility; .obsidian/app.json locks useMarkdownLinks: true, newLinkFormat: relative.
  (Exception: the Kanban verify_board.md uses [[…]] — that is the Kanban file format.)
• One canonical static index.md (no Dataview), assembled centrally; dynamic views live in
  dashboards/.
• Important files take no underscore prefix; underscore is reserved for transient reports +
  quarantine/staging dirs.
• Add any new frontmatter field centrally and document it here, so queries stay consistent.