# How OneDroid Argus Works — Holdout, Load and Continuous Verification > The scenario set is sealed and hash-anchored before the build, run against a pinned artefact the coding agent never tested it on, revealed in full after the verdict, and replayable by an open-source runner you control. Canonical: https://onedroid.ai/argus OneDroid OneDroid Argus # How Argus verifies what your agent built. Argus is the verifier your coding agent cannot pass by guessing, because it never sees the test. Ask us for early access The evidence contract The runner is open source, Apache-2.0, and runs inside your environment. The evidence contract ## Sealed before the build. You give the control plane the intent — the ticket, the acceptance criteria, the interface diff, the shape of your system. It produces a scenario set (happy path, repeat, wrong actor, wrong state, every external call's failure, the race at the shared resource, the load profile) and seals it. The hash goes on a cryptographic ledger before the first line of code, so anyone can check that the scenarios existed first and never changed. The hash proves priority. Keeping them unseen is a separate mechanism — the builder holds a runner-scoped token that cannot read expectations, and the scenario folder is never inside its working directory — and leakage is detected over time by decoy probes. Both halves matter; we say both. The run ## Run unseen, then adjudicated. The runner sits next to the system under test, inside your environment, driving HTTP, the message broker, the database, external webhooks, permissions and rate limits, and gathering evidence by correlation id. During the build it reports only what happened — failing ids and observed reality, so your agent can fix things — never what was expected. The final run happens once, against a pinned artefact, and the control plane adjudicates it. ### The reveal Every scenario is published with its trigger, expectation, observed evidence and verdict. The verdict binds to a specific build, so it cannot be re-pointed at a later one. Any scenario can be replayed by the open-source runner against the same artefact — by you, by your auditor, by anyone. Then the scenarios go on a schedule as regression guards. Every scenario ends in one of three states — passed, failed, or harness error — and a harness error is never a pass. A broken driver, a missing fixture or an unreachable layer is reported as exactly that, so a run cannot go green because nothing ran. The verdict is a decision about one build, with the evidence attached. It is not a score: there is no number to optimise for and no “safe” label. Mode two ## Under load. The load profile is part of the sealed criteria, not an afterthought: ramp, soak, spike, concurrency at the shared resource. Back comes what a single pass cannot show — latency percentiles, error rates by layer, saga completion rate and time, queue depth at the end of the soak, the refund count at a 200-way race on one order, and the order in which the system degraded. Under load, expectations are tolerances, and the report says so. Mode three ## Continuously. Passed scenarios run on a schedule against staging — every deploy, nightly soak, weekly spike — with decoy probes in live work and a track record per service: pass rate, mean time to detect a regression, load headroom over time. Alerting is on regression against sealed expectations, so noise stays low. Surfaces ## Four ways in. A CLI with machine-readable output for agents; a skill your coding agent already knows how to load; an MCP server; and a CI action whose check has a real conclusion and can block the merge. ### CLI Machine-readable output, built for an agent to read rather than a human to eyeball. Early access — not published yet ### Agent skill The `/argus` skill, loaded by your own coding agent to turn intent into a scenario set. Early access — not published yet ### MCP server Reached through OneDroid Synapse, so every call the verifier makes is itself in an audit log you own. Early access — not published yet ### CI action A check with a real conclusion. It can fail the build — which is the whole argument. Early access — not published yet `npx onedroid verify init # in the repo your agent is working in` This command does not work yet. None of the four surfaces above is published at the time of writing: the line is what the first release will look like, not something you can paste today. A site that sells verification does not get to round that up. Ask us for early access and you get it the day it lands. Boundaries ## What Argus is not. ### Not a smoke test It asks what happens at 100,000 users, at a 200-way race, on the twentieth minute of a soak, and keeps asking after the merge. ### Not a code reviewer It never reads the diff. It exercises the running system and reports what happened. ### Not a test generator you keep Scenarios are revealed only after the verdict, so nothing can be optimised for them. ### Not production testing Dev and sandbox only, never live credentials, read-only database access. ### Not proof the builder never saw the tests That is custody — token scope, folder guards, decoy probes — described plainly above. The anchor proves priority, not that the builder never looked. ### Not a score Passed, failed, or harness error — per scenario, with the evidence. No aggregate number, no “safe” badge, nothing to game. A harness error never counts as a pass. What it installs ## It brings its own run layer. Argus reaches its control plane through OneDroid Synapse, the governed MCP gateway, and keeps the scenario corpus and its own track record in OneDroid Engram, versioned in a Postgres you control. The written method behind the gate is open source. Reference material lives at docs.onedroid.ai. ## Find out what your agent actually built. Talk to us Bring us your security review Free runner, Apache-2.0. Email michal@onedroid.ai — you'll reach Michal Bacia, the team that builds the product, not a sales queue. We reply within one business day.