Where this is going

Rescue of machines with no BMC GOAL

• The idea. NAS boxes, mini PCs, kiosks and ARM boards often have no console path when the operating system is down. Bootscry would give an agent one.
• What we have today. A NAS boot-loop recovery, told by the operator (NAS recovery record); an unattended install and a rescue card boot (install and rescue record); and two ARM boards brought up (board bring-up record). The usage page lists twenty-four recorded uses in all.
• What is missing. Twenty-four recorded uses in one lab is a start, not a pattern. Several needed a person to power-cycle a machine. No one outside the lab has used it.
• The gate that must pass. Twenty or more usage rows of class rescue or setup, on at least five different machines including two with no BMC, each with its human steps recorded, plus one design partner outside the lab.

Governed recovery for operators GOAL

• The idea. An agent that reads the screen and acts only under audited, ticket-gated rules, for on-premises operators first.
• What we have today. Capability tiers, dry run, a hash-chained audit log, a kill switch, rate limits and a stale-frame gate. All are mock-tested. Only the read tier has run on real hardware (see safety).
• What is missing. A real-client demonstration of the approval step: it is built and tested on a mock, but we have not shown that any client displays it to a person, and an agent with a shell could still approve its own call. Approval for typed keyboard input. Approval tied to a change ticket. Audit export. Input, media and power tiers run on hardware.
• The gate that must pass. Roadmap milestones M1 and M6 pass, plus two paid or formal pilots.

High-assurance control GOAL

• The idea. Regulated settings may prefer an out-of-band loop with no credentials on the target to an agent running inside the operating system.
• What we have today. The design, written up on the threat model page. We can say the loop needs no credentials or software on the target and that every action is meant to be gated and logged.
• What is missing. The KVM is itself an attack surface, and its maker published vulnerabilities in March 2026. The held-back claims on the threat model page each have a gate that has not passed.
• The gate that must pass. A published threat model, an independent penetration test of the server and the KVM path, a control mapping reviewed by someone outside the project, and an answer on whether our unit checks firmware signatures.

Not now: Common Criteria and FedRAMP. We have no basis to attempt them.

OS and firmware test automation GOAL

• The idea. Firmware screens differ by vendor and are the part most tools avoid. A rig that drives them could test installs and updates on real machines.
• What we have today. One unattended install on real hardware (install record), a boot-phase classifier checked on a small set of real frames, virtual media, and a session recorder. Boot-menu catching is measured on one machine (boot-menu record).
• What is missing. More machines, repeatability numbers, continuous-integration output and a way to pick between targets.
• The gate that must pass. The staged benchmark at milestone M3. Stage one needs ten machines across at least four firmware families plus two ARM boards, twenty runs per task per machine, a pooled Wilson ninety-five percent lower bound of at least ninety-five percent, no machine under eighty percent, failures split into rig faults and decision faults, and the cost per run published.

Maker partnerships GOAL

• The idea. Hardware makers list Bootscry as a tested integration, lend units, or later license it.
• What we have today. We wrote to makers in September 2026. We have no partner. See for hardware makers and supported KVMs.
• What is missing. One fully published, Certified record for the Comet. No hardware is Certified yet.
• The gate that must pass. A first maker publishes or links a tested-with record.