Skip to content
Hozu
Menu

Understand the design. Try the decisions.

An idea goes in. A checked app comes out.

Follow a feature through Hozu. Break a contract. Change the data rules. See what the framework can make explicit.

Try the pipelineRead the design

Explore the pipeline

Make it. Check it. Then ship it.

A preset walkthrough, powered by a real Hozu machine. It illustrates the design; it does not compile source in your browser.

feature.tsA small toggle
const Toggle = event({ payload: z.object({}) })

const m = machine({
  context: z.object({}),
  initialContext: {},
  initial: 'off',
  states: () => ({
    off: { on: [on(Toggle, { target: 'on' })] },
    on: { on: [on(Toggle, { target: 'off' })] },
  }),
})
contracts.tsThe off → on transition
contract(m, {
  given: { state: 'off' },
  when: [{ send: Toggle, payload: {} }],
  expect: { state: 'on' },
})

Excerpts: imports, feature registration and the reverse-transition contract are omitted.

  1. 1
    SourceTyped declarations
    ●
  2. 2
    Feature IROne shared representation
  3. 3
    ValidatorRules and contracts
  4. 4
    CompilerDerived rendering
  5. 5
    RuntimeHTML and islands

Your feature is ready.

Run the valid example first. Then remove its contract and find out where Hozu stops.

Explore the render plan

You describe the data. Hozu places the boundaries.

Change these declarations and watch the diagram respond. Caching and interactivity are separate decisions.

Read about derived rendering
Data scope
Freshness
Machine binding
Your pageRender-plan illustration
Static shellNavigation, headings, article
Query region

Static HTML

Public, static data can be rendered ahead of time.

Plain HTML

No machine binding. This node does not hydrate.

Data: static export possibleInteraction: no hydration

This models one query in a static shell. Dependencies can make a region more dynamic. The controls update a local illustration; they do not fetch private or live data.

Go a little deeper

The reasoning behind the rules.

Six chapters, from the first design decision to the costs that remain.

  1. 1

    Why AI-first?

    Hozu makes application behavior visible to tools, so an agent can check more than whether its code compiles.

  2. 2

    From source to a running application

    Follow one feature through recording, validation, render planning and execution.

  3. 3

    Machines and contracts

    Make a feature’s allowed transitions explicit, then check them against its intended behaviour.

  4. 4

    Rendering follows the data

    Declare ownership and freshness; let the compiler derive caching, streaming and islands.

  5. 5

    Framework-owned data

    Declare reads, writes and invalidation together, so refresh behaviour is not scattered across handlers.

  6. 6

    Trade-offs, measured honestly

    Hozu buys explicit structure and checks with authoring cost, constraints and a different ecosystem fit.

Build your first featureExamine the measured results