Analyses

Analyses

An analysis is a page that answers one question, like a Weights & Biases report: markdown prose, with views and dashboards embedded wherever the argument needs them, a contents list that stays in view as you scroll, and callouts that record what was decided and why. It is one Markdown file an agent can write.

On main now: <data-analysis> and <data-analyses> (dist/analysis.js, CONTRACT §19). The blocks below are the analyses example's own files, live.

Three tiers: Views → Dashboards → Analyses

  1. ViewsLiveOne dataset, many ways to see it: a table, a chart, a board, a map, all from one .base file.
  2. DashboardsLiveMany views laid out on a grid over linked datasets: one rail filters them all, a click in one narrows the rest.
  3. AnalysesLiveA report page that answers one question: prose with views and dashboards embedded, a sticky contents list and decision callouts.

How it builds on the other two

An analysis page

An analysis, live <data-analysis src>

Live

robotparts' shoulder-actuator analysis, one Markdown file. On the left, the contents (sticky as you scroll; drag its edge). Then the header: status, question, the parts considered, the decision, Copy as Markdown and Download. Then the prose: an [!illustrative] load, a ```base fence drawn as a table and a compare view, one embedded chart from another example, and the [!decision] callout.

The live analysis starts when it scrolls into sight.

index.html
<script type="module" src="/vendor/data-ui/data-ui.js"></script>
<script type="module" src="/vendor/data-ui/analysis.js"></script>

<data-analysis src="shoulder-actuator.md"></data-analysis>

From the example Analyses · reports that mix text with live views · its own page · analysis.js fetches dashboard.js only for the first dashboard it meets

Embedding views and dashboards

Two ways in, both drawn live where they stand in the prose. A .base with layout: is drawn as <data-dashboard>; any other as a <data-views> (no URL state, the compact toolbar).

  • A ```base fence is an inline .base: its data: is a path beside the analysis (or from /, a URL).
  • ![[name.base]] on its own line embeds a file, looked for beside the analysis and then in each embeds= folder; ![[name.base#View]] embeds one of its views.
  • this.<key> in any filter is the analysis' frontmatter, as Obsidian binds this in an embedded base: this.parts.contains(id) keeps the parts the note names.
  • Callouts: > [!decision] Title is the verdict box, [!illustrative] marks what is assumed, [!ai] sets a judgement apart from the numbers; any other type is a plain callout.
  • data-ui check x.md checks the frontmatter, then every fence and embed against the data each names, with each problem at its line.
```base
data: ../robotparts-actuators/actuators.json
filters: 'this.parts.contains(id)'
views:
  - type: table
    name: Candidates
    order: [name, price, rated_torque, peak_torque, torque_density, mass]
    sort:
      - { property: price, direction: ASC }
  - type: compare
    name: Side by side
    order: [price, rated_torque, peak_torque, torque_density, mass]
    compare:
      better: { price: lower, mass: lower, peak_torque: higher, rated_torque: higher, torque_density: higher }
```
one view of another example, and a whole dashboard
![[../actuator-charts/views.base#Ashby · torque vs mass]]
![[../pid-tuning/views.base]]

The second line is from Analytic or tuned gains, robot by robot, which embeds the pid-tuning dashboard whole.

The list of analyses

Every analysis, as a table, a gallery or a board <data-analyses base>

Live

One row per analysis, from its frontmatter: the question, the status, the decision, the parts, when it was written. The tabs switch to a gallery of cards and a board by status; a click opens the analysis.

The live list starts when it scrolls into sight.

From the example Analyses · reports that mix text with live views · the rows are analyses.json, written by source/build.py with data_ui_analysis.build_index