Generative UI Mini-App Factory

Generative UI Mini-App Factory

This document defines the architecture for the Mini-App Factory, which generates focused health experiences ("Editions") on the fly based on user intent. It leverages a Generative UI approach where an LLM orchestrates pre-built modular components to create a custom application interface.

1. The 'Mini-App Factory' Pattern

We move away from static application development toward a Generative Configuration model.

1.1 Config vs. Code

The system does not write new React code at runtime. Instead, it assembles pre-vetted modular widgets (Lego bricks) into a layout. This ensures:

  • Safety: No unvetted code execution.
  • Stability: Components are tested and performant.
  • Speed: UI assembly happens in milliseconds.

1.2 The Component Registry

The core of the factory is a Registry Pattern:

  • A searchable manifest of all available React widgets.
  • Each entry includes: id, description (for LLM indexing), required_props, and theme_compatibility.

2. Generative UI Workflow (The StreamUI Architecture)

We utilize an agentic workflow to transform conversational intent into a functional interface.

flowchart TD
    subgraph backend ["Backend (Agentic Orchestrator)"]
        Intent["User Intent (e.g., 'I want to do HIIT')"] --> Parser["Intent Parser"]
        Parser --> Registry["Registry Search"]
        Registry --> Config["Layout Configuration (JSON)"]
    end

    subgraph frontend ["Frontend (Generative UI)"]
        Config --> RSC["React Server Components (RSC)"]
        RSC --> UI["Rendered Mini-App / Widget"]
    end

    HS["Health State vN"] --> RSC

Step 1: Intent Parsing

The Orchestrator Agent identifies the requested "Edition" type and the primary objective.

Step 2: Component Selection

The agent queries the Component Registry for widgets that match the objective (e.g., "HIIT" -> TimerWidget, HRZoneChart, BodyweightExerciseList).

Step 3: Configuration Generation

The LLM outputs a structured JSON layout schema:

{
  "edition_name": "Hotel HIIT",
  "layout": "dashboard",
  "widgets": [
    { "id": "timer_v1", "props": { "duration": 1200, "intervals": 8 } },
    { "id": "hr_chart_v2", "props": { "realtime": true } }
  ]
}

Step 4: Server-Side Rendering

The frontend uses React Server Components (RSC) to map the JSON IDs to actual React components and stream them to the user.

3. Persistence & Instant Loading

To ensure the app is fast and reliable, generated mini-apps are cached locally on the user's device.

3.1 Local Configuration Storage

When a mini-app is generated, the JSON configuration is saved to a local mobile database (e.g., SQLite or WatermelonDB).

3.2 Zero-Wait Reload

Subsequent loads of the same mini-app read directly from the local disk.

  • Speed: Loading a local JSON file happens in milliseconds, bypassing the 1-2s "AI thinking" delay.
  • Offline Support: Users can launch their custom HIIT timer or Diabetes log even without an internet connection.

3.3 Background Updates

While the local UI renders instantly, the system performs a Background Sync:

  1. The app renders the cached JSON version.
  2. An agentic process checks the server for layout updates (e.g., a new widget added by the team).
  3. If an update exists, the UI is updated gracefully in the background.

4. Proactive Evolution (The Injection Loop)

The architecture allows the engineering team to improve the app by giving users features they didn't explicitly request but would find attractive.

4.1 Registry Injection

When the engineering team builds a new high-value widget (e.g., "AI Form Coach" or "Recovery Nutrition"), they add it to the Component Registry with a descriptive prompt.

4.2 Proactive Agent Pattern

The Orchestrator Agent monitors the HealthState_vN for specific triggers to "inject" new widgets into existing Editions:

  • Scenario: User finishes a HIIT session with high heart rate variability (HRV) drop.
  • Trigger: The agent sees high fatigue in the Health State.
  • Injection: The agent automatically adds a RecoveryNutrition widget to the user's HIIT app. "I've added a recovery plan because your intensity was high today."

4.3 A/B Testing at the Edge

The team can test new widgets by configuring the agent to only "suggest" them to a subset of users. The agent then reports back on engagement metrics, allowing for automated feature promotion.

5. Integration with Health State

Generative UI is useless without data. We use a Data-Binding model.

  • Widgets as Lenses: Every generated widget is a specific "lens" on the HealthState_vN.
  • Prop Injection: The RSC layer automatically injects the relevant slice of the Health State into the widget's props.
    • Example: A GlucoseLens widget automatically receives healthState.biomarkers.glucose as its data source.

6. Layout & Stability Guardrails

To prevent the "Messy AI UI" problem, we enforce strict constraints.

6.1 Layout Templates

The LLM cannot place widgets anywhere. it must choose from a set of Stable Layout Templates:

  • The Dashboard: 2x2 or 3x3 grid for dense monitoring.
  • The Protocol List: Linear sequence for workout or habit tracking.
  • The Deep Dive: Single large widget with supporting metadata.

6.2 Visual Fallbacks

If a generated configuration fails validation (e.g., a required prop is missing), the system defaults to a Standard Chat Artifact or a Generic Log Input, ensuring the user is never stuck with a broken screen.

7. North Star

"A living application that evolves as fast as the user's needs—often providing the solution before the user knows they have a problem."

The Mini-App Factory converts the app from a fixed tool into a Dynamic Health Interface that is persistent, proactive, and personalized.

Back to Epistemology All Documents