assure-os.demo.scaleright.ai

Release status

What is proven, what is partial, and what has not been run at all.

This is a lab record, not a release claim. Nothing on this page should be read as a support commitment. Where evidence does not exist, the status is NOT_RUN rather than an optimistic estimate — that distinction is the whole point of publishing it.

Gates

Gate	State	Meaning
G3	NOT_MET	Release gate not passed.
Lab qualified	false	Full lab qualification not achieved.
Pilot accepted	false	No customer has accepted a pilot.
Released	false	Not released.
Signing	unsigned-lab	Internal development builds only; not a signed customer artefact.
Support owner	mock	Placeholder for continuous lab work; a real named owner is required before customer acceptance.
Live cloud	NOT_RUN	AWS is the assumed provider; no live qualification has been performed.

Validation suites

Twenty suites (V01–V20): 4 fixture-tested, 13 partial, 3 not run. Per-suite notes live in the validation manifest at products/serviceassure/validation/r1/manifest.json, which is the source of truth for this page.

Suite	State	Note
V04	fixture_tested	Incident dependency chains.
V05	fixture_tested	Approvals, replay refusal, hash integrity.
V06	fixture_tested	Dispatch leases and unknown-effect handling; partition matrix incomplete.
V07	fixture_tested	F01–F06 independent verification.
V14	NOT_RUN	Local retrieval plus cloud inference journey not qualified; advanced hybrid scope disabled.
V16	NOT_RUN	Isolated export, build, install and restore closure not established by host-package smoke alone.
V18	NOT_RUN	Silence, memory and ticket-continuity suite not implemented or qualified.
V01–V03, V08–V13, V15, V17, V19–V20	PARTIAL	Evidence exists but the suite is incomplete — see the manifest for each.

Fault scenarios

Six named fault scenarios (F01–F06) are fixture-tested against the independent verifier. The 30-trial measurement protocol is NOT_RUN — the scenarios have been exercised, but no statistical reliability claim is backed by evidence.

Supported scope today

Category	Entries
Runtimes	`linux-systemd-user-bus-fixtures`, `docker-engine`, `kubernetes-kind-single-node`
Typed actions	`start_service`, `restart_container`, `replace_pod`
Explicitly disabled	`cloud-write-adapters`, `fleet-ha`, `bounded-autonomy`, `gitops-privileged-mutation`, `windows-host-qualification`

Note the runtime list carefully: Kubernetes support is qualified against a single-node kind cluster, and systemd against user-bus fixtures. Neither is a claim about production clusters or system-bus units on real hosts.

Work package status

41 work packages across three streams (AO portfolio imports, SA product, DX delivery): 29 fixture-tested, 12 implemented, 0 planned. Live AWS account qualification remains NOT_RUN (mock EC2 observer is fixture-tested only).

Status vocabulary is ordered and deliberately conservative: planned → implemented → fixture_tested → lab_qualified → pilot_accepted → released. Nothing in this repository is beyond fixture_tested.

Recent lab tooling (still not lab_qualified)

assurectl doctor — strict-local / HA / Windows refuse-closed preflight.
assurectl uninstall plan and assureosctl profile render — plan-only, execute: false.
R1 disabled list enforced in CLI, API (/api/disabled), UI banner, autonomy/cloud-write/GitOps gates.
On-call and strict-local runbooks under products/serviceassure/ops/runbooks/.
Poisoned-memory refusals for grounded plans (V08 partial; Ollama→propose E2E still NOT_RUN).
ops/fixtures/aws-mock-collect.sh — SA-12 mock EC2 observe journeys (aws.mock only).

Known open findings

These were raised in review and are tracked as acceptance gaps against existing tasks — none of them promoted a task's status:

Effect-boundary authority checks.
Enforced restore epochs.
Kubernetes UID and disruption boundary safety.
Verifier provenance, freshness and attribution.
Verifier destination controls.
CI full-push coverage and release provenance.
Live AWS SDK/account qualification (mock EC2 observer is fixture-tested only).

Outstanding owner inputs

Work that cannot proceed on engineering effort alone:

A real named support owner (currently a mock placeholder).
Signing keys and a signed release path (currently unsigned-lab).
A live AWS account for cloud qualification.
An HA lab for multi-node fleet testing.
Push and CI credentials for full-coverage runs.

Every figure here is read from products/serviceassure/validation/r1/manifest.json and docs/assureos/backlog.json. If the two disagree with this page, the JSON is right and this page is stale.