STATIC_EXPORT product benchmark

Web Product Factory

A controlled production system for moving from a brief to a validated, deployment-ready independent web product.

See the production pathReview the controls

What it solves

Small input should not mean loose execution.

Web Product Factory is built for the gap between a lightweight product brief and a real, inspectable web product. It turns the brief into a structured production contract, selects only the capability level the product honestly needs, and keeps generation inside explicit ownership boundaries.

It is not:

  • a template library
  • a multi-framework site generator
  • an AI that freely edits everything
  • an automatic deployment platform

Brief to product

A production loop with gates, not guesswork.

  1. 01

    Ingest the brief

    The user can start with a compact idea, real facts, optional assets, and explicit constraints.

  2. 02

    Gate the requirements

    Requirements are classified as included, deferred, human-needed, or rejected before implementation begins.

  3. 03

    Lock the plan

    The run plan freezes scope, ownership, capabilities, acceptance checks, and the exact output path.

  4. 04

    Materialize the kernel

    A product-owned copy of the Universal Next Product Kernel becomes the independent product foundation.

  5. 05

    Compose the product

    Codex creates product-specific content, layout, behavior, and polish within the locked boundaries.

  6. 06

    Verify and repair

    Machine checks verify the contract, and deterministic repair is bounded instead of open-ended.

  7. 07

    Human QA

    A person owns visual judgment, copy judgment, product feel, interaction feel, and fact correctness.

Shared work

The user brings truth. The system brings structure.

The user provides

  • Idea or brief
  • Real facts
  • Optional assets
  • Answers to true blockers
  • Human QA
  • Deployment ownership

Factory and Codex provide

  • Structured planning
  • Product generation
  • Deterministic validation
  • Bounded repair
  • Packaging evidence after QA
  • Independent product output

Capability first

The runtime follows the product, not convenience.

Product types in V0Product / Service and Personal / Project
This benchmark profileSTATIC_EXPORT to STATIC_HOSTING
Why the profile fitsNo authentication, persistent data, server secrets, payments, realtime, or backend computation.

Capability selection keeps unsupported needs visible. A static product should not pretend to have accounts, payments, backend forms, realtime coordination, AI API access, or cross-device state.

Controls

AI composition stays inside a governed production system.

  • One write owner per task keeps Factory assets, product source, and run state separate.
  • The Factory repository stays read-only during normal product generation.
  • Generated products own their copied source, assets, configuration, and deployment handoff material.
  • Unsupported facts and forbidden claims are omitted, deferred, or marked human-needed.
  • Deployment remains user-owned in V0.

Human QA boundary

Machine verification can check contracts, routes, links, assets, builds, and obvious residue. Human QA still decides whether the product is clear, credible, visually sound, and factually right.

Controlled output

The result is a standalone web product, not a Factory mutation.

The Factory supplies the contracts, kernel, boundaries, and checks. The generated product owns its source and can move toward deployment only after Human QA and the later package and handoff phases.

Revisit the path