Candidate Negative Test Matrix

Candidate Negative-Test Matrix

These are planned expectations, not evidence that the candidate works on Windows or VirtualBox. A synthetic conditional match never constitutes a production PASS.

Stimulus	Required result
Changed boot ID after key deletion in the same boot, with equal or increasing counter	Guest-only proof is UNKNOWN; retain the prior baseline.
A real reboot followed by an equal or higher sampled counter	Guest-only proof is UNKNOWN, not proof that no reboot occurred.
Lower counter with unproven key lifetime, source behavior, non-reboot reset, wrap, or restore exclusion	Guest-only proof is UNKNOWN, regardless of the changed boot ID.
Wrong VM, stale attempt, old serial boundary, failed query, mismatched boot-ID brackets, or malformed unsigned counter	Reject the observation and retain the prior baseline and pending obligations.
Observed off/on with unchanged or unverifiable boot ID	Managed-restart proof is UNKNOWN; do not infer a full kernel restart.
Missing or corrupt continuity, journal and anchor mismatch, or both restored in the same rollback domain	Continuity is UNKNOWN; a missing file cannot establish fresh-start genesis.
Pending obligation followed by same-boot readiness recheck	Current readiness may pass in that limited phase, but the obligation persists and dependent continuation is blocked.
Crash before or during pending-state commit	Do not start a managed mutation without the durable obligation; ambiguous recovery is UNKNOWN.
Crash after a committed terminal decision but before delivery	Replay only the exact committed receipt as historical, not as current readiness.
Two unresolved obligations, with proof satisfying only one	Resolve only the proven obligation; retain the other and its referenced baseline.
Windows replacement partially fails, TPM submission returns a TPM error, or an authority-write response is lost	Report UNKNOWN; do not assume the previous pathname survived or repeat a non-idempotent increment blindly.
A delete marker hides a retained object version, or a restored authority advertises a bumped revision	Do not infer empty genesis or current continuity; require independently verified state.
Intent preparation is lost or ambiguous before dispatch	Do not send the transition until exact recoverable intent or an equivalent proven enumeration and fence is established.
A pending-obligation commit succeeds but its reply is lost	Block mutation while uncertain; after exact reconciliation, recheck the current obligation and all mutation gates.
A resolution commit succeeds but its reply is lost	Treat the obligation as blocking while uncertain; recover the committed state and exact receipt as historical, not fresh readiness.
The exact same committed transaction is submitted again	Return the original committed result without a second state change or increment.
A transaction ID is reused with different contents or expected head	Reject the reuse and change no state; do not infer the result of a different ambiguous request.
A current read has no matching transaction while a prior request may still be in flight	Remain UNKNOWN; a later commit must not invalidate an assumed no-commit conclusion.
A later invocation conflicts after an earlier response was lost	Reconcile the earlier exact transaction; the later conflict alone proves nothing about its result.
A host-local journal and request cache roll back while the independent authority remains current	Do not accept the old cache; independently recover and verify the current state and exact intent or remain UNKNOWN.
An authority and its anti-rollback proof roll back together	Do not accept their mutual agreement as current continuity; remain UNKNOWN.
Two coordinators submit different transactions against the same head	At most one transition commits; the other cannot overwrite it and remains blocked until its own outcome is established.
Committed history, transaction binding, epoch, custody, or a required fence is missing or unverifiable	Remain UNKNOWN; neither a cached receipt nor a larger generation proves safe recovery.
An authority-side fence commits before an old in-flight transaction	The old writer's transaction is rejected; verify complete current state before any new action.
The old transaction commits before a competing fence	The stale fence conflicts; a fresh fence and read must retain the committed transaction and any obligation.
A fence response is lost and the old session identity is unavailable	A new conditional claim may proceed only with independently verified current state and proven authority fencing; never blindly increment a counter.
Authority fencing succeeds while a VirtualBox command is already in flight	Do not infer VM quiescence or snapshot exclusion; require a separate proven resource-side boundary.
Another control session attaches while a VM session holds a write lock	Do not infer third-party exclusion from the VirtualBox lock; without a separately proven boundary, remain UNKNOWN.
A snapshot wait times out, cancellation is unavailable, or cancellation has no confirmed terminal result	Do not infer quiescence or interrupt a healthy snapshot; block dependent mutation.
A command may have been accepted but its progress ID is lost, lookup fails, or enumeration is unproven	Do not infer that the command failed or stopped; retain the obligation and remain UNKNOWN.
A snapshot UUID or numbered inventory entry appears while completion is unconfirmed or the current snapshot name and UUID do not match	The reserved entry alone is not proof of commitment or quiescence. Keep mutation blocked unless separately proven completion or quiescence and the required current-snapshot checks establish safety; do not interrupt serialization.
A completed snapshot and current-snapshot check are followed by an unexcluded competing client	A past completion and point-in-time read do not establish an interlock for the next mutation.
A second control process shares the broker's OS identity but bypasses its protocol	Do not infer its exclusion from owner-only DAC; require a proven boundary for that actor or remain UNKNOWN.
An alternate VBOX_USER_HOME is selected	Configuration selection alone does not establish exclusive control of the VM.
The web service is disabled while local COM/XPCOM control remains available	Do not treat web-service isolation as a complete VM-control boundary.
Pathname permissions are restricted but an abstract endpoint or a principal with DAC-bypass capability can reach an in-scope path	Do not infer exclusion from the pathname mode; require proof for the actual endpoint and actor.
A Linux flock candidate has an inherited or duplicated descriptor when the coordinator exits	Do not assume the lock was released; account for all retained descriptors and fail closed if ownership is uncertain.
The last engine-lock descriptor closes while a VirtualBox operation may still be active	Lock release or later reacquisition does not prove the earlier VM operation is terminal.
A Windows COM registry ACL exists but effective process-wide security or alternate control routes are unverified	Do not infer that competing clients are excluded.

Each producer serializes access to COM1 with a guest-local named mutex restricted to the launcher, installer, and witness identities. It writes one complete UTF-8 JSON line and flushes before releasing the mutex; the producer closes its COM handle after each record. An unavailable mutex or serial I/O is a local producer failure; missing channel evidence is UNKNOWN to the host. This design must be proven with the actual guest and VirtualBox; the serial stream is not cryptographically authenticated and is never a substitute for the separate WinRM and host-identity checks.