Shipped vs proposed

Documentation says what is true today. Direction lives in the product statement, and it is not presented as a capability.

This page is the reconciliation. Three states:

State	Means
Shipped	The current binary does this.
Schema only	The loader validates it and it is in the published JSON Schema, so your editor completes it — but the behaviour is an open proposal. Declaring it changes nothing on the server.
Intent only	Validated and carried into plans, but the local engine runs nothing continuous for it.

Shipped

• A stable, explicit onebox.run/v1 project schema. Future v1 evolution is additive.
• Compose generation and validation, SSH transport with known-host checking, state-bound plans, image pinning, rendered diffs.
• Health-gated rolling or recreate deployments, traffic drain, verification, versioned releases, retention, rollback.
• Locks, fencing, append-only journals, resume, abort, migration gates, status, audit, SOPS secrets, supporting services, proxy operations, notifications.
• A canonical, versioned operation graph and one shared Go service for proposals, execution, structured events and operational memory. The CLI is an adapter over it. Observation is the engine’s status snapshot, not a method on that service.
• Eleven supporting-service drivers, each running with a durable volume, a server-generated credential, and projected connection details. All but nats also run a health check; that image has no shell to probe with, so condition: healthy against it is refused at load.
• One application owner per host, recorded on the box at bootstrap and checked before every mutation, so a second application cannot converge over the first.
• Typed release manifests, durable activation and secret-rotation checkpoints, opaque secret generations, and retention that fails closed when the evidence it prunes against cannot be read.
• A closed CLI contract: a versioned envelope, an NDJSON event stream with one terminal record, three families of typed error code, and the 0/1/2 exit mapping. See Policies and Error codes.
• Plan/status drift observation and plan-bound migration backup reports validation.

Distribution, published by tag

Configured and verified in CI on every pull request, and published by pushing a vYYYY.M.REVISION tag. What is installable at any moment is what the releases page lists; the install commands work from the first published tag onward.

• Tag-gated GitHub Releases with checksum-covered Linux, macOS and Windows archives for amd64 and arm64, plus Debian and RPM packages for both Linux architectures.
• A Scoop bucket manifest for Windows amd64 and arm64, published only after the same release verification gate succeeds.
• A Homebrew Cask for macOS amd64 and arm64. Both macOS binaries are signed with LabStack’s Developer ID and accepted by Apple’s notarization service before publication.

Distribution not shipped

WinGet, hosted APT and RPM repositories, non-macOS artifact signatures, SBOMs and provenance attestations are not configured. The first release channels are GitHub Releases, Homebrew and Scoop. Checksums detect corruption; macOS also has Developer ID publisher identity and Apple notarization.

Schema only

Your editor is ahead of the engine here

These three blocks are published in the JSON Schema and accepted by ob validate. Nothing behind them executes.

Block	Reality today
backup_targets	Declaring a target creates no repository and no schedule.
services.<name>.protection	Declaring recovery intent establishes no protection. No backup is taken, no drill is run, and no service reports Managed.
external_services	Connections are projected into the generated runtime, and two refusals are wired: an unknown needs.env part, and condition: healthy against a service with no probe. Health probes do not execute, and the remaining lifecycle refusals are not wired.

The lifecycle failure codes are defined and drift-tested in the binary, but most of the operations that raise them are not yet executable.

Intent only

observability — logs, metrics and alerts declare desired capability. ob validate reads the block. Nothing else does: the local engine runs no collectors and no alert managers, and ob status does not report the block at all — not even as declared.

Not owned at all

Backups. Onebox does not take them. ob doctor reports the absence for every workload and service holding durable data, because silence there would read as approval.

Restore proof. No drill is run, and no service can currently prove a backup would restore.

Log rotation. Container logs are not bounded by Onebox today.

High availability. Rolling deployment can avoid interruption while the host is healthy; it cannot make a failed host available. Recovery onto another host is a distinct, evidence-backed workflow, not failover.

Why the distinction is published

A product direction that reads as a capability list is how an operator ends up believing their database is backed up by something that has never taken a backup.

A capability ships only when its design is agreed, its tests pass, and the generated reference and this page are updated from proposed to implemented. Until then it appears here, in this column, and not in the other one.