Status and limits

Runs today

Demonstrated end to end and replayed by the test suite on every change.

• Live delivery path. Product, architect, implementation and verifier personas, run by live models, take a stated intent through requirements, design, code and independent verification. The recorded runs are replayed on every change.
• Certification. The platform seals a release and certifies it in a fresh test environment on a versioned dataset, with a signed certification bound to the release digest.
• Production delivery. A certified release is promoted only after a signed approval by a second person, rolled out without downtime, verified in place and rolled back automatically if verification fails. An upgrade follows the same path, including additive database migrations.
• Evidence. Build, test, contract, image and deployment receipts are signed and verified by issuer and signature; images are signed and admitted to the cluster by registry and digest.
• Isolation. Row-level security per tenant and project, deterministic authorization over platform-owned grants, and builds in containers with no network.
• Usage ledger. Every meter is recorded once per tenant and project, with budgets that hold work before it overspends.
• Web components. A project can declare a web application; pages are edited through a bounded tool and gated by an automated check for broken links, external requests and accessibility basics. This site is delivered as such a component.
• Designer persona and the operator console. Live models, as product, architect, designer and verifier personas, built a read-only operator console from a one-paragraph request; the platform certified it and delivered it to production on the local test cluster after an operator's approval, in about eight minutes. That delivery did not run on the hosted cluster. The page declares its views; the platform's own tested script signs the operator in with a pasted token and renders them. The run is recorded and replayed.
• Stricter policy for the platform's own project. Operator approval, sandbox evidence and a canary before rollout; the kernel is outside anything the platform builds.

In first runs

Built and tested with scripted agents; not yet exercised by a live delivery.

• Remediation round. When the independent verifier fails a change, the author gets one bounded round to answer the findings before a fresh verification. Enabled for web delivery only.
• Findings about the requirements. When the verifier's finding is about the requirements and not the work, the delivery waits for a person, who can have the requirements amended and approved or reject the change; a blocking finding cannot simply be accepted on the platform's own project. Enabled for web delivery only.

Planned

Designed or decided, not built.

• More personas in deliveries. Integration, visual review, security and operations exist as written personas and do not yet take part in deliveries.
• Offerings and tenant publishers. Subscriptions, publishing by tenants, trust levels, per-publisher pricing and billing are accepted directions without an implementation.
• Pages. A website from a one-sentence intent as a subscribed offering.
• Data in depth. Typed columns, column migrations, backup and restore, a managed database binding, and object storage for files. Today each entity is one generic table, only added tables are migrated, and production data has no backup.
• Standard libraries and conventions. A backend library, a browser library, typed clients generated from each project's pinned contracts, and conventions with a check for every rule. Today conventions are carried by the generated skeleton and short instructions, and each change reinvents common code.
• Tenant theme. A design built with the designer and shared by an organisation's projects. Today each site is styled from scratch.
• Domains and routing. First a generated address for every public endpoint on a separate domain for tenant sites, with automatic HTTPS; then custom domains with ownership verification and automatic certificates.
• Onboarding. Invitation-only registration, sign-in by email link or Google, a personal organisation with trial credit for each tester and paid business organisations, and two stages when credit runs out: probation, where applications keep running, then suspension. Today organisations exist only as test fixtures.
• Self-deployment of the core. The platform deploying and upgrading its own hand-built core.
• Workflows beyond software. Sales and marketing are vision only; nothing is designed.

Known limits

• Where it runs. Since October 7, 2026 the platform's control plane runs on a hosted Kubernetes cluster in a non-production environment. There is no public signup, price list or availability date.
• Domains and certificates. TLS is a pre-provisioned secret by reference; there is no domain verification or certificate issuance.
• Sign-in. There is no browser login flow; the API authenticates bearer tokens, and the local server uses a development identity.
• Evidence is not certification. Signed receipts substantiate defined checks. They are not a proof of correctness, a security guarantee or a compliance determination.
• Checks have gaps. The web check reads pages statically. It does not run scripts, does not analyse vector images and performs no visual review. A check in a real headless browser is planned.
• No measured outcomes. No cost, speed or staffing figures have been measured, and none are claimed.
• Build isolation is a container, not a micro-VM. Builds run with no network, no credentials and a read-only filesystem. On the first hosting provider no sandboxed runtime is available, so a build is separated from other builds by a container on dedicated nodes. That does not protect against a kernel exploit from inside a build.
• The kernel is hand-built. Authorization, lifecycle and evidence verification are written and reviewed by people and are outside what the platform may change.