Influences

The design choices in Daslab aren't original. Most of them are stolen from people who thought harder about specific problems than we have time to. This page is the running citation list — what we took from where, what we deliberately rejected, and what we still want to figure out.

It's also an argument: most of the things we picked are the same things. Pre-attentive design at small sizes serves human glance and AI agent context budgets. Tufte's data-ink ratio is LLM token economy. Patterns at appropriate scale are Apple WidgetKit tiers and Engelbart outline views. The same discipline serves both audiences.

The size system

Our five-tier widget system (icon / small / medium / large / xlarge) is modeled on Apple WidgetKit. The vocabulary, the cell math, and the iPad-only xlarge are all directly taken from systemSmall / systemMedium / systemLarge / systemExtraLarge. We added icon (1×1) for the "asset launcher" position — the home-screen app icon equivalent — because it pre-fetches no data and lets users put a connected asset in a scene without paying enrichment cost.

What we keep going back to:

• Apple WidgetKit — the discrete-tier system itself. Most apps use fluid resize; Apple's bet that users want a pick list not a slider won. We agree.
• watchOS complications — the proof that each tier should answer a different question, not just show "more or less of the same content." A weather Circular complication shows just 72°. A Graphic Bezel shows the 24-hour curve wrapped around the dial. Same data, different render decision per tier. We aspire to this; we're not there yet — most of our widgets currently truncate, not curate.

The same principle, applied to Daslab — one list of PRs rendered across all five tiers below, live. Each tier is the same WidgetData; only the size parameter differs. Resize your window — the rendering scales accordingly.

• Edward Tufte, Envisioning Information (1990) and Beautiful Evidence (2006) — small multiples and sparklines. The data-ink ratio. Pre-attentive design. The reason metric at small should be a sparkline by default, not a number-with-arrow.

• Christopher Alexander, A Pattern Language (1977) — patterns live at specific scales. You don't apply a regional pattern at room scale. Each of our tiers corresponds to a user intent, not just an information amount. icon = "exists, don't fetch." small = "answer one question." large = "this is the focus."

The render protocol

Every value in Daslab — a cell, a tool call's output, a message — knows how to render itself at any of the five tiers. Same protocol everywhere: scene grid widgets, trace timeline tool-call cards, bottom-sheet detail views.

What we keep going back to:

• Alan Kay, Personal Dynamic Media (1977), and Self / Morphic. The principle: the object owns its presentation. A morph in Self can resize and recompose fluidly because it carries its own rendering. Daslab's long-term move is to push toward this — every cell type owning its render(size) rather than going through a central dispatcher. We're not there yet; today our WidgetRenderer is a switch on data.type, which is the un-Kay way.

• Smalltalk-80 (Goldberg & Robson, 1983) — every object had inspectors at every level. Click on anything, see itself. Daslab's "tap any widget → opens detail view" is a degenerate version of this; the deeper version would be every value at every level being interactive in itself.

Tracing and replay

Every job is an OpenTelemetry trace. Every workflow is a frozen trace. Same format you store, export, paste between tools, replay.

What we keep going back to:

• OpenTelemetry / OpenInference — directly. We don't invent a workflow format; OTLP is the workflow format.
• Doug Engelbart, Augmenting Human Intellect (1962). NLS had outline view + structured editing — different views of the same content. The "five-tier rendering of a single value" is a discrete version of his fluid expand/collapse.
• Git — content-addressed commit chains. Our scene state is hash-linked the same way; the engine internally is closer to git's commit graph than to a relational store.

Context-driven information

Widgets, in their best form, show what's relevant now — not all the data the underlying cell has.

What we keep going back to:

• Bret Victor, Magic Ink (2006). Context-driven design. The thesis: most software should infer what info you need from your current activity. Our scenes are a step in that direction — what's in scope is what's relevant. The deeper Victor move (auto-sizing widgets by recency, by focus, by what the agent just touched) is something we'd like but haven't built.
• Bret Victor, Up and Down the Ladder of Abstraction (2011). Sliding fluidly between concrete examples and abstract patterns. Our discrete five tiers are a coarse version of this.

Two consumers, one protocol

The deeper claim worth making explicit: the same rendering work that's good for human attention is also good for AI agent context. Not by accident — both are bandwidth-constrained intelligences asking "what should I notice?"

A human glancing at a watch face has ~300ms and ~20 visible characters before they look away. An agent inspecting a prior call in a 50-step trace has ~80 tokens of context per row before the window crowds out fresh thinking. Same resource problem, different units. A sparkline at small reads pre-attentively to a human and tokens-efficiently to an agent. Tufte's data-ink ratio is also LLM token economy. Christopher Alexander's patterns-at-appropriate-scale is also "the right level of detail at the right step in the trace."

Investing in design quality at the small tiers compounds twice. Once a third party builds a beautiful gmail/message widget for the small tier, both the human user and every AI agent in the system benefits. One design effort, two consumers, both better off. This is why we think a renderer ecosystem built on Daslab will outperform ones built on workflow tools that don't think this way.

What we deliberately don't follow

A short list of things we've explicitly rejected and why:

• Notion / Coda fluid blocks. Beautiful for documents; we want consistency across scenes, not freeform layout. Discrete tiers compose better.
• Tableau / Grafana free-form panels. Power users love them; everyone else gets confused. Apple's pick-list works for a reason.
• Material Design density tokens. A user-level density setting that applies uniformly. We want per-cell density (different widgets care about different sizes), not per-app density.
• Microsoft Live Tile flipping animations. The information was good but the constant motion was tiring. We use animations to indicate state changes, not to perform.
• n8n / Zapier visual graph editors. Workflows-as-graph is a great UI for authoring; it's a poor UI for understanding what happened. Our trace timeline is structured for replay, not authoring; you'd never want it the other way.

What we're still figuring out

Honest list of where we want to be smarter:

• Pre-attentive design at small. Most of our small renders today are still text-truncation. Should be glyph + value + status dot, watchOS complication-style. Real work, hasn't shipped.
• Per-tier content curation, not truncation. Each tier should answer a different question. Today most tiers just show "more or less of the same data." This is the next big rendering investment.
• Cell-owned rendering (the Kay move). Today rendering goes through a central WidgetRenderer; it should eventually be each cell type owning its own. Refactor target.
• Fluid resize. Today users tap from a discrete pick list. Bret Victor would have them slide. We don't yet have a model for this that doesn't break the agent's mental model of "size = render mode."
• Animation discipline. No house style yet. Should be: animations indicate state change, never decorate.

How we describe what good looks like

The visual references above shape what a single widget should be. There's a separate question — how do we tell partners, advanced users, and our own agent what makes a scene good — that has its own lineage.

What we keep going back to:

• Gojko Adzic, Specification by Example (2011). The thesis: requirements documented as concrete, illustrative examples are better specifications than abstract rules. The examples are the spec, the test, and the documentation. They survive because they can be disagreed with — abstract principles drift; concrete examples either work or they don't. We aspire to write Daslab patterns this way; we're not consistently there yet.
• Anthony Ulwick, Outcome-Driven Innovation (1990s onward, codified in What Customers Want, 2005, and Jobs to be Done: Theory to Practice, 2016). Ulwick coined "Jobs To Be Done." His operational version is the one worth stealing from: jobs decompose into measurable desired outcomes — typically framed as "minimize the time it takes to..." or "increase the likelihood of..." — and a product wins by getting those outcomes faster or more reliably than alternatives. Useful framing for what a scene is for.
• Clay Christensen, Competing Against Luck (2016). Christensen learned the JTBD frame from Ulwick and made it famous with the milkshake example. The narrative gloss ("the milkshake is hired to make a long commute less boring") is more memorable than Ulwick's outcome lists, and both are worth knowing — Christensen to introduce the idea, Ulwick to do work with it.

The pairing is the point. SBE gives us a format that scales (one pattern per job, written as an example). JTBD gives us a unit (the user's job) that holds the pattern accountable to a real human goal, not a designer's preference. Same as the Tufte / Alexander / Apple pairing above — visual references and process references both compress to "answer the question, omit everything else."

Where this sits in the world-model lineage

The phrase "world model" has become 2026's hottest framing — LeCun's AMI Labs at $1.03B, Fei-Fei Li's World Labs, DeepMind Genie 3, NVIDIA Cosmos, and a flood of robotics papers (Dreamer 4, V-JEPA 2, WorldGym, DreamDojo). The honest framing is the one Yann LeCun keeps repeating: "world model" is a problem statement, not an architecture. Multiple solutions, each with different stances on what to compress, what to predict, and whether to render pixels.

Daslab is in this family — not the humanoid-locomotion / grasping branch, but the agentic instrumentation and self-driving-lab branch. Scoped to physical workflows, lab automation, and hardware-in-the-loop agents rather than motor-control policies.

What we keep going back to:

• Yann LeCun, A Path Towards Autonomous Machine Intelligence (2022) — the JEPA position paper. The bet: encode the world into an abstract state, predict forward in that state, and make rendering decoder-optional. That's exactly the move scenecast and scene-otel make: typed canonical shapes are the canonical state; HTML / Markdown / Text / native renderers are decoder-side downstream choices. The "no pixel reconstruction" stance is why scene-otel ships predictions in widget-data space, not video frames.
• Richard Sutton, Dyna, an Integrated Architecture for Learning, Planning, and Reacting (1991) — the iterative-world-model loop. Real-world deployment produces trajectories that improve the model that powers the next round of training. Modern robotics rediscovered this 35 years later (DreamerV3, World-Gymnast). For us: agent-otel traces + scenebench fixtures instantiate the same loop for agentic tools — every evaluation run is also a data collection run for the substrate.
• V-JEPA 2 (Meta, 2025) — concrete proof of the JEPA philosophy at scale. A 1.2B-parameter model planning manipulation tasks zero-shot on Franka arms entirely in latent space, no pixel generation, no task-specific training. Confirms the architectural bet we're making at our scope.
• HuggingFace LeRobot — the open-robotics ecosystem center of gravity. scenebench adapters explicitly target LeRobot fixtures because that's where the reproducible robotics benchmarks already live.
• OpenUSD / Pixar / NVIDIA Isaac Sim — the universal scene description format that's become robotics simulation's lingua franca. openusd-mcp and makeusd connect the 3D-representation half of the world-model story to agent-callable surfaces.

What's pointedly not here: Sora, Genie 3, generative video models, World-Action Models. That's the pixel-generation branch — different paradigm, different bet. Our agents reason over typed structured state; we don't try to predict pixel-perfect video frames as a training objective.

Read these directly

If any of the above resonates, read the source — these are short and worth the time:

• Tufte, The Visual Display of Quantitative Information (1983) and Envisioning Information (1990).
• Alexander, A Pattern Language (1977) — at least the introduction.
• Victor, Magic Ink (2006) and Inventing on Principle (2012, talk).
• Kay, Personal Dynamic Media (1977) and the Self papers.
• Engelbart, Augmenting Human Intellect (1962, paper) and the Mother of All Demos (1968, talk).
• Apple's Human Interface Guidelines on widgets and complications.
• LeCun, A Path Towards Autonomous Machine Intelligence (2022) — the JEPA position paper.
• Sutton, Dyna, an Integrated Architecture for Learning, Planning, and Reacting (1991) — the iterative-world-model loop, foundational.

Updated 2026-05-02