Cross-platform CI verified on Ubuntu and Windows for the final interactive judge console commit
Interactive safety console — all four deterministic scenarios completed with RESULT: PASS (4/4)
Nexus Vector Evidence Guard — a fail-closed deployment and recovery layer for high-risk AI agents

Nexus Vector Evidence Guard

Inspiration

Autonomous agents are often evaluated by how well they make decisions at runtime. But a correct agent can still become unsafe during deployment.

A reviewed destination may drift before an update is applied. A file replacement may return an ambiguous result. An operator may retry an incomplete deployment or rollback and make the situation worse. Traditional logs may show that something happened without proving which source, backup, manifest, or deployment run the action belonged to.

For systems that manage real money or other high-risk operations, “probably deployed” is not an acceptable state.

Nexus Vector Evidence Guard was created to answer a practical question:

How can we update a high-risk autonomous agent while treating every uncertainty as a blocked, auditable state?

What it does

Nexus Vector Evidence Guard is a standalone, offline developer tool for fail-closed deployment and recovery.

It demonstrates a deterministic workflow:

Build a SHA-256 manifest for canonical source files and the reviewed destination baseline.
Verify the complete baseline before any mutation.
Create and verify a backup bound to the exact deployment run.
Recheck each file immediately before replacement.
Record durable, sanitized evidence around every mutation.
Verify canonical bytes after every copy.
Stop and require manual recovery when a mutation result is ambiguous.
Permit rollback only when the exact apply run, backup, manifest, and terminal evidence agree.

The tool never retries an ambiguous operation blindly.

When uncertainty is detected, it produces explicit safety states such as:

manual_recovery_required=true
safe_to_retry=false

Four deterministic demo scenarios

The offline judge demo runs four scenarios.

CLEAN_DEPLOYMENT_PASS

The source manifest, destination baseline, backup, apply operation, and post-copy hashes are all verified.

DESTINATION_DRIFT_BLOCKED_PRE_MUTATION

The destination differs from the reviewed baseline. The operation stops before the tool mutates any file.

AMBIGUOUS_MUTATION_REQUIRES_MANUAL_RECOVERY

A synthetic replacement returns an ambiguous result. Evidence is preserved, automatic retry is prohibited, and the system enters a manual-recovery state.

VERIFIED_ROLLBACK_PASS

Rollback is bound to the exact successful apply and backup. The original baseline is restored and verified, and a duplicate rollback is rejected.

Expected result:

PASS CLEAN_DEPLOYMENT_PASS
PASS DESTINATION_DRIFT_BLOCKED_PRE_MUTATION
PASS AMBIGUOUS_MUTATION_REQUIRES_MANUAL_RECOVERY
PASS VERIFIED_ROLLBACK_PASS
RESULT: PASS (4/4)

How we built it

The implementation uses:

Python 3.12;
the Python standard library only;
PowerShell for the Windows judge runner;
deterministic SHA-256 manifests;
append-only JSONL evidence journals;
create-once sanitized reports;
same-directory staging;
post-replacement hash verification;
GitHub Actions on Windows and Ubuntu;
unit tests and public-safety audits.

The demo uses only temporary directories and synthetic text files.

It requires:

no API keys;
no external account;
no exchange connection;
no messaging service;
no database;
no Docker;
no network access.

Run it on Windows:

powershell -ExecutionPolicy Bypass -File .\demo\run_demo.ps1

Run it cross-platform:

python demo/run_demo.py

The demo generates sanitized machine-readable evidence in demo/output/evidence.json and a static HTML summary in demo/output/index.html.

How we used Codex and GPT-5.6

The Build Week extension was developed in Codex using the verified effective model identifier gpt-5.6-sol with high reasoning effort.

Codex helped implement and harden:

deterministic source identity;
baseline drift prevention;
backup, apply, and rollback binding;
append-only evidence;
partial and ambiguous mutation states;
no-blind-retry semantics;
same-volume staging;
newline identity reconciliation;
dependency closure;
cross-platform tests and CI;
the sanitized offline judge package.

I made the key product and safety decisions: the tool must fail closed, never retry an ambiguous mutation automatically, preserve evidence before recovery, avoid production credentials and data, and clearly separate prior work from the Build Week extension.

Verified /feedback Codex Session ID:

019f7783-bcbc-7203-afb4-b4698642a2b6

Verified effective model:

gpt-5.6-sol

Challenges we faced

The hardest challenge was defining correct behavior when the operating system could not conclusively confirm whether a file replacement succeeded.

A naive implementation might retry the operation. In a high-risk environment, that can duplicate a mutation or destroy the evidence needed for recovery.

We instead designed ambiguity as a terminal blocked state:

no blind retry;
persistent mutation evidence;
explicit recovery requirement;
run-bound backup and rollback authorization.

Another challenge was cross-platform byte identity. Git working trees may use LF or CRLF line endings, while deployment safety still requires deterministic identity. The system accepts only explicitly authorized byte representations and rejects unknown newline or encoding states.

We also needed to ensure that evidence itself remained safe to publish. The public implementation rejects absolute paths and sensitive evidence keys and contains no production credentials, balances, order identifiers, databases, or proprietary trading strategy code.

Accomplishments

We are proud that the project:

fails closed before mutation when destination drift is detected;
preserves evidence around ambiguous operations;
prevents blind retries;
binds rollback to the exact apply run and backup;
blocks duplicate apply and rollback operations;
runs fully offline;
requires no external dependencies;
passes deterministic tests on Windows and Ubuntu;
provides a one-command judge demo;
produces both JSON evidence and an HTML summary.

Prior work vs. Build Week extension

The original private Nexus project already contained a trading runtime, lifecycle state machine, duplicate-order protections, restart recovery, and an OFF → CANARY → NORMAL production-promotion policy.

Those components are prior work. Codex did not build the entire trading bot during this Build Week session.

During OpenAI Build Week, GPT-5.6 through Codex implemented and hardened the fail-closed deployment and recovery subsystem around that existing runtime.

This public repository is a standalone, sanitized extraction of those general developer-tool concepts. It does not contain the private trading engine, live credentials, production databases, order data, or proprietary strategy implementation.

What we learned

Deployment safety is not only about copying the correct bytes.

A safe deployment system must also prove:

what was reviewed;
what existed before mutation;
which backup belongs to which run;
what changed;
whether the result was certain;
whether retry is authorized;
whether rollback is still valid.

We learned that uncertainty should not be represented as a warning. In high-risk systems, uncertainty must become a first-class state that blocks further automation.

What's next

The current project is an educational offline reference implementation.

Future development could add:

process-supervision integration;
signed manifests and evidence;
remote-host deployment adapters;
distributed deployment locks;
database migration rehearsal;
policy-based promotion from OFF to CANARY and then NORMAL;
independent evidence verification;
operator dashboards for manual-recovery workflows.

The long-term goal is to make fail-closed deployment and evidence-bound recovery a reusable safety layer for autonomous agents operating in finance, infrastructure, healthcare, and other high-risk environments.