Examples › data-ui › Analyses · reports that mix text with live views
Analyses · reports that mix text with live views
Three analyses, each one Markdown file: prose, ```base fences and ![[x.base]] embeds drawn as live views and dashboards, a decision callout, and a table of contents from the headings. The list is a data-ui view over their frontmatter; open one to read it. data-ui's third tier: views, then dashboards, then analyses.
The .base file and its data
Every tab above is one entry of this file; the views read these rows. ⋯ in the toolbar copies the current view as YAML.
# The analyses list (docs/peps/0007-analyses.md): one row per analysis, from its frontmatter (source/build.py writes
# analyses.json with data_ui_analysis.build_index). <data-analyses> draws these presets; a click opens the analysis.
data: analyses.json
facets:
- { as: current, label: Current filters }
- { property: status, as: values, label: Status }
- { property: tags, as: values, label: Tags }
views:
# WHY Table first: a card with no image puts its selection box over the title's first letters (a core cards
# issue, reported to the integrator); analyses have no picture of their own
- type: table
name: Table
order: [title, status, decision, parts, question, date, author]
rowHeight: short
- type: cards
name: Gallery
order: [title, question, status, decision, parts_count, date]
cardSize: 320
sort:
- { property: date, direction: DESC }
- { property: title, direction: ASC }
- type: kanban
name: Board by status
order: [title, decision, date]
groupBy: { property: status }
groupOrder: [draft, open, decided, superseded]
open: { mode: link, url: url }
// analyses.json: 3 rows, 3 KB; the first 3
{
"id": "data-ui-analyses",
"title": "Analyses",
"titleProperty": "title",
"linkProperty": "url",
"properties": {
"title": {
"type": "text",
"label": "Analysis"
},
"question": {
"type": "text",
"label": "Question"
},
"status": {
"type": "text",
"label": "Status"
},
"parts": {
"type": "list",
"label": "Parts considered"
},
"part_ids": {
"type": "list",
"hidden": true
},
"parts_count": {
"type": "number",
"label": "Parts"
},
"decision": {
"type": "text",
"label": "Decision"
},
"decision_id": {
"type": "text",
"hidden": true
},
"date": {
"type": "date",
"label": "Date"
},
"author": {
"type": "text",
"label": "Author"
},
"tags": {
"type": "list",
"label": "Tags"
},
"visibility": {
"type": "text",
"label": "Visibility"
},
"url": {
"type": "text",
"hidden": true
},
"path": {
"type": "text",
"label": "File"
}
},
"rows": [
{
"id": "pid-gains",
"title": "Analytic or tuned gains, robot by robot",
"question": "Does the tuning rung beat the analytic rung on every robot, or should some ship with analytic gains?",
"status": "decided",
"parts": [
"conveyor",
"five_bar",
"gantry",
"hand_2",
"hand_3",
"hand_6",
"hand_9",
"lever",
"ur5e"
],
"part_ids": [
"conveyor",
"five_bar",
"gantry",
"hand_2",
"hand_3",
"hand_6",
"hand_9",
"lever",
"ur5e"
],
"parts_count": 9,
"decision": null,
"decision_id": null,
"date": "2026-10-26",
"author": "pidtuna (example)",
"tags": [
"pid",
"tuning"
],
"visibility": "public",
"url": "pid-gains.html",
"path": "pid-gains.md"
},
{
"id": "shoulder-actuator",
"title": "Shoulder actuator for a 1-DOF arm",
"question": "Which actuator should drive the shoulder of a 1-DOF arm holding 0.3 kg at 0.25 m, under $150?",
"status": "decided",
"parts": [
"Steadywin GIM4305-10",
"Steadywin GIM6010-8",
"Damiao DM-J4310-2EC",
"JMC 60ASM400-5-1024C"
],
"part_ids": [
"aifitlab-8541438771336",
"aifitlab-8542347853960",
"aifitlab-8565793194120",
"jmc-60asm400-5-1024c"
],
"parts_count": 4,
"decision": "Steadywin GIM4305-10",
"decision_id": "aifitlab-8541438771336",
"date": "2026-10-26",
"author": "robotparts.dev (example)",
"tags": [
"actuator",
"arm"
],
"visibility": "public",
"url": "shoulder-actuator.html",
"path": "shoulder-actuator.md"
},
{
"id": "sim-to-real-twin",
"title": "Which motor's twin to tune controllers on",
"question": "Of the rack's eight motor twins, which is close enough to its real motor to tune a controller in simulation first?",
"status": "decided",
"parts": [
"CAN 14",
"CAN 15",
"CAN 4",
"CAN 1",
"CAN 13",
"CAN 12",
"CAN 21",
"CAN 11"
],
"part_ids": [
"CAN 14",
"CAN 15",
"CAN 4",
"CAN 1",
"CAN 13",
"CAN 12",
"CAN 21",
"CAN 11"
],
"parts_count": 8,
"decision": "CAN 14",
"decision_id": "CAN 14",
"date": "2026-10-26",
"author": "BAM rig (example)",
"tags": [
"sim-to-real",
"rack"
],
"visibility": "public",
"url": "sim-to-real-twin.html",
"path": "sim-to-real-twin.md"
}
]
}README.md
# Analyses · reports that mix text with live views
Three analyses, each one Markdown file: prose, ```base fences and ![[x.base]] embeds drawn as live views and
dashboards, a decision callout, and a table of contents from the headings. The list is a data-ui view over their
frontmatter; open one to read it. data-ui's third tier: views, then dashboards, then analyses.
- **App:** data-ui
- **Replaces:** robotparts.dev's own analysis renderer (its PEP 0002), now the kit's `<data-analysis>` and `<data-analyses>`
(docs/peps/0007-analyses.md); W&B reports, as a file format an agent writes.
- **Shows:** a list as Gallery, Table and Board by status; a report with a resizable contents column; ```base fences
filtered by `this.parts` (the note's frontmatter, as in Obsidian); a whole dashboard embedded with one line
(`![[../sim-to-real/views.base]]`); one view of another case's file (`![[../actuator-charts/views.base#Ashby · torque vs mass]]`);
[!decision], [!illustrative], [!example] and [!warning] callouts.
- **Data:** the sibling cases' data, read where it lies: robotparts' actuators (**real** catalog values), the rack's
sim-to-real twins (**real** hardware runs), pidtuna's robots (**simulated**, illustrative parameters, and said so).
Every number in the prose is copied from those files; the arm's load in the shoulder analysis is illustrative and
marked. `analyses.json` (the list's rows) is written by `source/build.py` with data_ui_analysis.py.
The original UI it replaces
robotparts.dev's own analysis renderer (its PEP 0002), now the kit's <data-analysis> and <data-analyses> (docs/peps/0007-analyses.md); W&B reports, as a file format an agent writes.
What it shows
a list as Gallery, Table and Board by status; a report with a resizable contents column; ``base fences filtered by this.parts (the note's frontmatter, as in Obsidian); a whole dashboard embedded with one line (![[../sim-to-real/views.base]]); one view of another case's file (![[../actuator-charts/views.base#Ashby · torque vs mass]]`); [!decision], [!illustrative], [!example] and [!warning] callouts.
Data
the sibling cases' data, read where it lies: robotparts' actuators (real catalog values), the rack's sim-to-real twins (real hardware runs), pidtuna's robots (simulated, illustrative parameters, and said so). Every number in the prose is copied from those files; the arm's load in the shoulder analysis is illustrative and marked. analyses.json (the list's rows) is written by source/build.py with data_ui_analysis.py.