> ## Documentation Index
> Fetch the complete documentation index at: https://hubify.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Dynamic Surface Inference (DSI)

> Hubify's AI-native UI layer, agents render the Captain's view from a JSON spec, not a hardcoded layout. Coming soon.

# Dynamic Surface Inference (DSI)

<Note>
  **Status: in development (Phase 4 of the [phase plan](https://github.com/houstongolden/hubify/blob/main/project-context/SSOT/PHASE_PLAN.md)).** The minimal Captain shell + DSI render pipeline ships behind the `dsi` flag once the design-system unification (Track G in `project-context/POLISH_LOOP.md`) drains. Track progress in the [POLISH\_LOOP](https://github.com/houstongolden/hubify/blob/main/project-context/POLISH_LOOP.md).
</Note>

DSI is Hubify's answer to the question: "what does an AI-native research IDE actually look like?" The current web app has a fixed layout, sidebar, view tabs, chat dock, terminal. Useful, but rigid. DSI replaces the fixed layout with a **catalog of rendering primitives** plus an **AI view planner** that emits a JSON spec describing what the Captain should see right now.

## The shape of it

The Captain opens the lab. Instead of always seeing the same Captain view, the orchestrator agent looks at:

* What experiments are running (and which need attention).
* What the Captain was last working on (paper draft, knowledge note, GPU dispatch).
* Recent agentEvents (paper review just completed, pod failed, novelty score arrived).
* Time of day / Captain rhythm signals.

...and emits a layout spec like:

```json theme={null}
{
  "view": "captain",
  "blocks": [
    { "type": "StatCard", "label": "Active Experiments", "value": 3, "delta": "+1" },
    { "type": "StatCard", "label": "GPU Cost (mtd)", "value": "$847", "budget": "$2000" },
    { "type": "AlertBanner", "severity": "warn", "title": "paper-2 review stalled, round 3 of 5" },
    { "type": "ActivityFeed", "labId": "...", "limit": 8 },
    { "type": "Stepper", "title": "publish-loop:paper-2", "stepIndex": 2, "steps": [...] }
  ]
}
```

The renderer consumes the spec, instantiates each catalog block (`StatCard`, `AlertBanner`, `Stepper`, `ActivityFeed`, `EmptyState`, ...), and paints the view. The Captain can drag, save, share, or override layouts, they're just JSON.

## Why it matters

* **The view follows the work.** Today the Captain hunts through tabs to find what changed. DSI surfaces it.
* **Agents can render UI.** Skills like `/hubify-status` could push their output as a saved view, not just a terminal blob.
* **Forkable.** Lab teams build their own catalogs (a wet-lab Captain wants different blocks than an ML Captain).
* **AI-native by construction.** The system prompt knows the catalog; layout becomes generation, not configuration.

## Architecture (read the audit)

The full architectural spec lives in [`docs/DSI_AUDIT.md`](https://github.com/houstongolden/hubify/blob/main/docs/DSI_AUDIT.md) in the repo. Highlights:

* **Renderer:** [vercel-labs/json-render](https://github.com/vercel-labs/json-render) as the catalog-constrained AI UI generator (under audit; we may vendor + fork rather than depend).
* **Catalog:** \~12 primitives in PR1 (`StatCard`, `Card`, `Breadcrumb`, `Stepper`, `CodeBlock`, `EmptyState`, `AlertBanner`, `ActivityFeed`, `MetricChart`, `TableView`, `MarkdownBlock`, `ButtonRow`).
* **Storage:** new `savedViews` Convex table (`saveView` / `getLabViews` / `deleteView` mutations).
* **Planner:** Claude Haiku 4.5 returns JSON validated against the catalog schema; falls back to the current hardcoded Captain layout if the spec is invalid.
* **Gating:** `dsi` feature flag per-lab; opt-in for early Captains.

## Why we're waiting

DSI is gated on the design-system unification work landing first ([Track G in POLISH\_LOOP.md](https://github.com/houstongolden/hubify/blob/main/project-context/POLISH_LOOP.md)). Building the catalog primitives against a moving token set means rebuilding them once the tokens settle. Captain's call (2026-04-30):

> you need to be working on Slice D next as soon as we have the app, marketing pages, and docs all working under a cohesive single source of truth design system internally, from there we can tackle Slice D and the whole minimal Captain's shell and DSI etc properly

Right call. We'll ship DSI on a stable foundation.

## What you can do today

While DSI is in development, the same instinct (let the agent shape the surface) is partially available:

* **Saved layouts (manual).** Drag chat dock, sidebar width, terminal pane, the per-lab positions persist. Closest pre-DSI analogue.
* **Captain Recent Lab Events.** The activity heatmap + event feed already use the "show me what's changed since I was last here" pattern that DSI generalizes.
* **Skills + MCP.** `/hubify-status` already returns a contextual snapshot; today it renders to terminal. Post-DSI, the same skill outputs render to the Captain view as catalog blocks.

## Track progress

* Live tracker: [`project-context/POLISH_LOOP.md`](https://github.com/houstongolden/hubify/blob/main/project-context/POLISH_LOOP.md) Track G + Track C
* Design audit: [`docs/DSI_AUDIT.md`](https://github.com/houstongolden/hubify/blob/main/docs/DSI_AUDIT.md)
* Phase plan: [`project-context/SSOT/PHASE_PLAN.md`](https://github.com/houstongolden/hubify/blob/main/project-context/SSOT/PHASE_PLAN.md)

## See also

* [Captain View](/features/captain-view), what's there today
* [Skills Overview](/skills/overview), the recipe layer that will plug into DSI
* [MCP Server > Tools](/mcp/tools), the data layer DSI reads from