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

• An explicit onebox.run/v1alpha1 Application schema. Future contract evolution is additive.
• Compose generation and validation, SSH transport with known-host checking, state-bound plans, image pinning, rendered diffs.
• Scheduled jobs as host timers with exact cron translation, bounded retry inside one firing, one run record per activation in the host journal (ob job history, ob job logs, ob status), per-outcome notifications, and declared inputs for operator-initiated runs (ob job run).
• Opt-in durable job executions with named linear steps, declared string outputs, per-step retries, and host-local checkpoints. ob execution list, inspect, resume, and abandon expose recovery state. Resume requires the original current release and unchanged observed compatibility evidence; applications own idempotency and out-of-band schema compatibility. Requires Python 3.8+ only for durable jobs; no database or resident orchestration service. See durable executions.
• Per-workload reconciliation that retains proven-unchanged healthy workloads, health-gated rolling or recreate replacement for changed or uncertain ones, 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
backupTargets	Declaring a target creates no repository and no schedule.

| externalServices | 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. |

Every lifecycle failure code is raised by a path in the shipped binary, checked against the source in both directions.

Not owned at all

Workload volumes. A workload’s own durable data is not copied anywhere. ob doctor reports it for every workload holding some, because silence there would read as approval. Managed services are different: one declaring backup is backed up continuously and recoverable to a point in time — see the backup reference. Only the postgres driver has an executable contract today; every other driver declares policy_qualified: false and its backup policy is refused rather than accepted and ignored.

For PostgreSQL, the digest-pinned Onebox image carries the compatible WAL-G executable. The host receives generated configuration only; no backup binary is installed by Onebox.

Restore proof. ob backup drill proves it on demand: it recovers the repository into a throwaway volume, waits for the cluster to promote, and makes it answer a query — the same code a real restore runs, stopped before the last step. What is not run is an unattended drill. Onebox puts no agent on the host, so the timer from drill.schedule runs the archive-continuity check instead, and the full proof is yours to run from CI on the cadence your policy declares. No proof age is recorded, so nothing tells you the last drill has gone stale.

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.