Product · audits
Autonomous Host Readiness Audit
Nine readiness domains, one weighted verdict, every gap named.
Inputs and outputs
You supply
- An evidence bundle collected from the host, in the published schema
- Nothing else — the audit never connects to the host
You receive
- Weighted readiness score with the published weights shown alongside it
- Findings with severity, evidence, remediation, and source provenance
- Deterministic rule identifiers stable across hosts and across runs
- Prioritized remediation ledger grouped by shared cause
- Explicit list of evidence that was not read and score withheld for it
- Per-domain statement of what was checked and what was not
Phase A evaluates a sealed evidence bundle you already hold. There is no remote connection to the host, no collector sold here yet, no checkout, and no price. The specification and the scanner are public so the product can be judged before anyone is asked to pay for it.
What this is
A deterministic, offline evaluation of a single host against a published readiness specification. You supply an evidence bundle collected from the host in the published schema. The scanner never connects to the machine, never authenticates, and never changes anything. It answers one question: is this host ready to be migrated, or left to run unattended — and if not, what exactly is in the way?
Nine domains are examined. Every finding carries severity, evidence references, remediation, and source provenance. A domain whose evidence is missing is withheld from the score rather than counted as passing. A domain the evidence proves does not apply is excluded, which is a different statement and is labelled as one.
What you get back
Two files produced offline from the bundle you keep: a self-contained HTML report that opens without network access, and a versioned JSON document with the same content in machine-readable form. Both carry the ruleset version and the specification version that produced them.
Phase A honesty
Phase A ships the engine, the fixtures, the tests, and this specification. It does not ship a host collector, a checkout, a price, or a claim that any of this can be bought. The collector that would produce a live bundle from a real host is deliberately outside Phase A so the sold product never has to hold credentials or reach into someone else’s machine.
The fail-closed rule
An unread check is not a passed check.
If a source in a domain could not be read, that domain does not quietly pass. Its weight leaves both sides of the score and the run is reported incomplete. The best an incomplete run can be is ready with conditions. That rule is enforced in the loader, the rules, the scorer, the verdict, and the report — not only in this paragraph.
Why there is still no buy button
Checkout is not open. No price is published. The public product page exists so the scope, weights, and limits can be read before any of that changes. When the collector path and the shipping gates close, this page will say so in the same plain language it uses today.
9 readiness domains · spec v0.1.0
Every check, every artifact, every limit
Expand a domain to read exactly what is examined, what is kept as proof, and what the domain does not cover.
Identity and access weight 14 · 6 checks
Whether a person or a process can still reach this host after the migration, and whether anyone who should not reach it can.
Checked
- Interactive accounts that carry neither a password nor a key
- Accounts other than root holding uid 0
- Remote root login permitted by the SSH server configuration
- Password authentication accepted by the SSH server
- Sudo rules that escalate without re-authentication
- Whether any named administrative account exists besides root
Evidence sources
- identity.accounts
- identity.sudoers
- identity.ssh_server
Not covered
- Directory services, single sign-on, and federated identity are not examined
- Key material is never read, so key strength and age are not assessed
- Group membership is inventoried, not evaluated against a policy
- Nothing is authenticated against; every statement comes from configuration
Storage and capacity weight 12 · 5 checks
Whether the data this host holds will survive the move, and whether it has room to keep running until someone looks at it again.
Checked
- Filesystem utilisation against the near-capacity and critical thresholds
- Data paths that live on volatile or non-persistent filesystems
- Data paths that share the root filesystem instead of a separate volume
- Device health as reported by the device's own self-assessment
- Data volumes carrying no encryption at rest
Evidence sources
- storage.filesystems
- storage.block_devices
Not covered
- No filesystem is mounted, read, walked, or repaired
- Growth rate is not projected; only the recorded utilisation is judged
- RAID and volume-manager topology is inventoried, not verified
- Backup coverage of a data path is decided in the backups domain, not here
Secrets and operating modes weight 12 · 5 checks
Whether the host's secrets are held in a way that survives a migration without being copied around, and whether it is actually in the operating mode its owner believes it is in.
Checked
- Secret stores readable by users other than their owner
- Secrets held in plaintext rather than through a sealed backend
- Secret stores committed to version control
- Development, debug, or trace modes left enabled
- Whether unattended operation is declared rather than assumed
Evidence sources
- secrets.material
- secrets.modes
Not covered
- No secret value is ever read; only location, mode, owner, and backend
- Secret rotation age and strength are not assessed
- Application-level secret handling is invisible to a host audit
- A sealed backend is recorded as sealed, not verified cryptographically
Services and boot survival weight 12 · 5 checks
Whether the work this host does comes back by itself after a reboot, a crash, or a migration, without anyone logging in.
Checked
- Units in a failed state at collection time
- Units the host depends on that are not enabled to start at boot
- Long-running units with no restart policy
- Units running as root that declare they do not require it
- Timers that do not catch up after downtime
Evidence sources
- services.units
- services.timers
Not covered
- No unit is started, stopped, restarted, or reloaded
- Unit dependency ordering and cycles are not analysed
- Application health behind a running unit is not probed
- Resource limits and cgroup accounting are not evaluated
Networking and exposure weight 14 · 5 checks
What this host answers to, from where, and whether anything is listening that should never have been reachable.
Checked
- Whether a host firewall is present and enabled
- Default inbound policy
- Data-tier and administrative services bound to a public interface
- Plaintext administrative protocols accepting connections
- Whether outbound traffic is filtered at all
Evidence sources
- networking.listeners
- networking.firewall
Not covered
- Nothing is scanned, probed, or connected to; listeners are read from the host's own tables
- Upstream network controls are invisible; only host-level filtering is judged
- Reachability from the internet is inferred from binding and policy, not tested
- TLS configuration and certificate validity are not assessed
Container runtime and workloads weight 12 · 6 checks
Whether the containerised work on this host can be reproduced somewhere else, and whether any of it has quietly been given the host itself.
Checked
- Containers running with full privileges
- Images pinned by tag alone rather than by digest
- Containers running as the root user inside the container
- Sensitive host paths and runtime sockets mounted writable
- Runtime sockets writable by every user on the host
- Workloads with no restart policy
Evidence sources
- containers.runtime
- containers.workloads
Not covered
- No image is pulled, inspected, scanned, or run
- Image contents, layers, and provenance are not assessed
- Orchestrator state beyond this host is out of scope
- Network policy between containers is not evaluated
Accelerator readiness weight 8 · 5 checks
Whether the accelerators this host is supposed to have are present, driven by a matching stack, and healthy enough to be worth migrating.
Checked
- Devices declared present with no kernel driver loaded
- Driver version disagreeing with the version the devices report
- Container toolkit absent on a host that runs both containers and accelerators
- Persistence mode left disabled
- Hardware errors recorded by the device itself
Evidence sources
- gpu.devices
Not covered
- No workload, benchmark, or diagnostic is run against a device
- Thermal and power headroom are recorded, not judged against a duty cycle
- Multi-instance partitioning and scheduling policy are not evaluated
- A host with no accelerator is excluded from the score rather than penalised
Backups and rollback weight 10 · 6 checks
Whether this host can be put back the way it was, by someone who was not there when it broke.
Checked
- Data paths with no backup job covering them
- Backup jobs whose most recent run failed
- Restores that have never been tested, or not tested recently
- Backups held only on the host they protect
- Backups written without encryption
- Whether a rollback procedure exists and has been exercised
Evidence sources
- backups.jobs
- backups.rollback
- storage.filesystems
Not covered
- No backup is read, restored, or verified; job records are read as reported
- Recovery time and recovery point objectives are not measured
- Off-host copies are recorded as declared, not confirmed at the destination
- Staleness is measured against the collection time in the bundle, never a live clock
Operator tooling weight 6 · 6 checks
Whether the person who inherits this host at three in the morning has what they need to understand it and get back into it.
Checked
- Whether a runbook exists for the host
- Whether a monitoring agent is installed and has somewhere to alert
- Whether logs leave the host that produces them
- Whether time is synchronised
- Whether break-glass access is documented
- Tools the host declares it needs and does not have
Evidence sources
- tooling.operator
Not covered
- Runbook quality and accuracy are not assessed, only its existence
- Alert routing is recorded as configured, not tested end to end
- On-call arrangements and escalation policy are outside a host audit
- Nothing is executed; tool presence is read from the inventory
Not buyable yet
Checkout is not open, there is no waitlist form, and no price is published. The launch page lists the gates that have to close first, and the launch feed records each one as it does.