How it works

A high-level view of the PhiWebs pipeline — enough to understand what happens when you build and publish a surface, without the internals.

The building blocks

Everything you build is a Surface — a composable page or view. Surfaces are assembled from Blocks: typed, self-describing units (text, layout, media, data, forms, navigation). A surface never invents a block; it picks from a real catalog, and every block carries a manifest describing its props, intent, and edge cases.

• Surfaces
• Blocks
• Composition model

From intent to a published surface

1. Compose. You describe what you want — in the PhiCo web composer, in PhiCo Code from your terminal, or directly through the SDK. The composer selects blocks from the catalog and wires their props, data bindings, and capabilities.
2. Receipt. The proposal is emitted as a Receipt — a signed, line-numbered recipe of every block, binding, and capability. Nothing publishes until the Receipt is accepted. The same Receipt always produces the same surface.
3. Publish. On accept, the Receipt is materialised into a Surface and published to your World. Each publish is a versioned deployment with rollback to any prior accepted Receipt.

• Receipts
• PhiCo — the composer

Rendering and delivery

Published surfaces run on the hosted runtime — you do not provision or operate any infrastructure. The runtime renders each surface from its definition and the blocks installed in the World, and serves it from a global edge for low latency. Self-hosting is not supported today.

• Capabilities

Next steps

• Quickstart — install the SDK and ship a surface.
• SDK reference — defineBlock, defineFactory, the client.
• API reference — the REST surface.