Candidate Ambiguous Commit State Machine

Candidate Ambiguous-Commit State Machine

The operator selected host-storage rollback as an in-scope fault. This contract does not select an authority, prove protection against authority compromise or rollback, or authorize a TPM operation or external service. Unverifiable authority continuity remains UNKNOWN. The required independence, custody, and concurrency guarantees are implementation and live-proof gates, not assumptions that the local model establishes.

A versioned request must bind the authority identity and epoch, verified VM UUID, unique transaction ID, operation and target obligation, expected generation and complete head digest, complete proposed state, any terminal receipt, and the applicable authorization or fencing context. Its exact canonical encoding, digest, and authority protocol remain to be specified. No credential, recovery material, or raw guest evidence may enter the request or its history.

State	Required behavior
Not dispatched	A verified pre-dispatch failure makes no authority transition and authorizes no dependent mutation. If dispatch cannot be excluded, use UNKNOWN instead.
Intent established	Before sending the transition, prove that its exact identity and contents remain discoverable if host storage rolls back. Independently durable intent is one candidate; complete authority enumeration plus fencing is another. A lost or ambiguous preparation response must itself be reconciled before dispatch.
In flight or response uncertain	Treat the affected obligation as blocking and do not release success or overwrite the authority with a cached earlier state. A timeout, malformed response, lost reply, or unverified TPM response is UNKNOWN.
Committed	Verify the exact ID and contents against a fresh authenticated current state or sufficiently retained authenticated history. A committed result establishes history, not present readiness; re-read current state under the UUID lock and independently satisfy all phase, authorization, and VM-state gates before any dependent action.
Conflict	A verified conflict proves only that the particular invocation did not change state. After any earlier ambiguous invocation, do not infer its outcome from a later conflict without independently proving the earlier transaction was closed without commit.
Unknown	Retain the effective block and preserve the intent, relevant baselines, and receipt evidence. Missing local intent, missing current state, or an unverifiable authority is neither failure proof nor baseline-free genesis.

Deduplication must check the transaction ID and exact bound contents before reapplying a compare-and-commit. The ID is unique within the authority identity, epoch, and VM UUID. An exact committed retry returns the original result without advancing the state; the same ID with different contents is rejected. Retain the binding or a sufficient tombstone until old requests cannot reappear, including after host rollback. A backend that cannot prove this behavior, including a bare non-idempotent TPM increment, is not safe to retry blindly.

A missing transaction in a current read does not prove that an earlier request failed: the request may still be in flight and commit after that read. A definite no-commit conclusion requires complete authenticated history and a proven authority-side closure or equivalent fencing that prevents that request from committing later. Fencing a request or client must itself be durable and its result verified. If an intent registration, authority write, or fence has an ambiguous result, reconciliation must cover that operation too; local absence is not a substitute.

One candidate for lost local intent is an authority-enforced per-VM writer fence. An authenticated new session conditionally advances a monotonic writer generation against the verified current head; every authority transition atomically checks that generation and its owner. If an old transaction commits first, the fence conflicts and the current state and history must be re-read. If the fence commits first, the old writer's later transition is rejected. A fence whose reply is lost remains uncertain; a freshly verified state and a new conditional claim may recover only if the authority proves atomicity, unique session identities, complete history, and rollback resistance. These semantics are not equivalent to blindly repeating a TPM increment.

The fence is only an authority-side candidate. It does not stop a VM command already delivered to VirtualBox, prevent third-party snapshot operations, or provide a resource-side interlock. A separate proven quiescence or enforceable VM-control boundary remains necessary before a dependent mutation; a token that VirtualBox never validates is not such proof. Cross-host ownership, stale clients, authority recovery, and fence-counter limits remain unproven.

The authority may already have committed a valid resolution and removed an obligation before its response is lost. During uncertainty the client treats that obligation as blocking, but must not overwrite the committed state with its old local copy or claim the authority retained it. Once the exact committed transition is proven, its stored receipt may be returned only as historical. It cannot establish current readiness, and other unresolved obligations and their baselines remain in force.

An authority's independently verified current head and the necessary transaction history must survive the specified host-storage rollback. If the authority and its purported anti-rollback proof are restored together, or their epoch, freshness, custody, or complete history is unverifiable, the client remains UNKNOWN. The project-local UUID lock alone does not fence another host, an old in-flight authority operation, or a third-party VirtualBox snapshot.

Under the verified VM's lock, persist and anchor an obligation before starting a managed operation that could require reboot proof. For an unexpected reboot, compare the current boot with the retained baseline and durably record the obligation before authorizing continuation. If the process crashes before that observation is recorded, a later attempt must compare the then-current boot with the retained baseline again; inability to do so is UNKNOWN. This relies on the separate replay and boot-ID provenance gates, not on the host lock excluding third-party VM actions.

Persist a validated terminal receipt and its state transition together, then verify the durable journal and anchor before releasing a success receipt. A crash after commit but before delivery may replay the exact committed receipt as a historical result; it is not fresh current-readiness evidence. A crash before commit cannot clear the obligation. A missing, torn, unanchored, ahead-of-anchor, behind-anchor, or mismatched journal is UNKNOWN; recovery must not silently choose an older valid generation. How to make the journal and anchor transition crash-safe on each supported host remains an implementation and live-test gate.

An absent file is not proof of an empty history. Baseline-free fresh-start requires independently established, protected genesis for that VM, proving that there is no earlier accepted baseline or pending obligation in the trusted continuity domain. If that distinction cannot be established, report UNKNOWN, even after observing off/on. Initializing or adopting a VM without trustworthy prior continuity requires a separate recovery design and authorization; it must not silently erase history.

Treat snapshot or saved-state restoration as capable of replaying guest-local metadata and boot identity. A fresh attempt ID and serial boundary alone do not rule out such a replay. Oracle documents that a running snapshot can retain guest memory and resume execution at the snapshot point when restored; see Snapshot Contents. Detecting or excluding a restore, and binding any accepted evidence to the current VM state, is a feasibility gate; unresolved replay makes the affected proof UNKNOWN.

A changed volatile boot ID alone is insufficient to prove a guest-only reboot: the volatile key might have disappeared without an OS restart. An additional independently established boot observation is required, but its source, comparison rules, failure modes, and receipt representation remain a feasibility decision. Microsoft describes System-log event ID 12 from Kernel-General as an OS-start event in its reboot-history guidance. It is a candidate, not an approved or proven source: availability, provider identity, log continuity and clearing behavior, and correlation with the current boot require proof. Windows Event Log strict subscriptions can reject a missing bookmark and report missing records, but do not by themselves establish current-boot identity or exclude snapshot replay. A partially accepted query cannot establish complete evidence. Until a suitable source is specified and validated, a guest-only reboot outcome is UNKNOWN and cannot satisfy TEST-061.

The candidate observation must be independent of the volatile key, usable with the verified VM and current boot, and comparable with the retained pre-reboot baseline. Missing, stale, or inconsistent source data, and resets or interruptions without independently established cause and continuity, are UNKNOWN. Microsoft documents GetTickCount64 as elapsed milliseconds since startup, with typical 10-16 ms resolution. Its behavior across suspension, VM restore, and a delayed post-reboot sample requires proof; a new uptime greater than the baseline cannot by itself rule out a reboot. A boot time calculated from wall-clock time minus uptime can change when the wall clock changes and is not sufficient on its own.