# OneDroid — full site text for language models

This file is GENERATED from the HTML pages of https://onedroid.ai by
tools/gen-llms-full.py. The HTML pages are authoritative; if this file and a page
disagree, the page is correct and this file is stale — regenerate it.

Index and connection details: https://onedroid.ai/llms.txt

OneDroid (onedroid.ai) builds AI agent infrastructure. It is unrelated to Android and to
the open-source Android projects also called "OneDroid".



============================================================================

# PAGE: https://onedroid.ai/
Title: OneDroid Argus — Automated End-to-End Testing for AI-Written Code
Description: Automated end-to-end testing for AI-written code. A separate tester writes the checks before the build, your coding agent never sees them, and they run against your deployed app: once, under load and on a schedule. Faster and cheaper than end-to-end testing by hand.

OneDroid Argus · automated end-to-end testing for AI-written code

# Proper testing now costs what the AI coding costs.

So there is no longer a reason to skip it.

Companies used to spend a fifth to a third of their IT budget on testing (Capgemini's
World Quality Report), so testing was the part that got cut. Coding agents changed the
price of both. In one measured experiment, Claude Code built a feature for $1.97 a run
testing its own work. With OneDroid Argus as an independent tester, the coding agent cost
$1.01 a run, and the tester wrote checks the coding agent never saw in one session of
about $5.30 for the feature.
The experiment, its figures and its limits.

OneDroid Argus is automated end-to-end testing for AI-written code. A separate tester
writes the checks before the build, your coding agent never sees them, and they run
against the build it just handed you: once, under load and on a schedule. The verdict
comes with cryptographic evidence you can replay yourself.

Talk to us
See a verdict

The runner runs inside your environment, and its source is open under MIT. No credit card.

Every checkable claim this site makes, and what backs it: onedroid.ai/evidence/onedroid.ai.

agent loop  →  saga under load, in your environment  →  one verdict: green · red · orange  →  written to the cryptographic ledger, then continuous

verdict log
illustrative

Holdout acceptance. Scenarios sealed before the first line of code, run once against a pinned build.

Under load. The same scenarios under load, against a message broker or an HTTP target; on an HTTP target a stepped ramp finds its limit.

Continuously. Once it passes, it goes on a schedule, every 15 minutes at the shortest, and one page answers “Is it OK?”.

Evidence anyone can replay. The withheld scenario set is hashed and
written to a cryptographic ledger before the build starts. After the verdict the tester can reveal the set: every scenario
is revealed — trigger, expectation, observed reality — and the runner
replays any of them against the same build. You never have to take our word for the
verdict. How the seal and the custody work.

## 50,000 lines overnight. How do you know what it did?

Nobody reads all of it. You can hold it to what it was supposed to do, with checks it
never saw. Two things make that answer worth trusting.

The builder can't game checks it never sees. A model that can see its
checker learns to satisfy the checker. OneDroid Argus seals the checks before the work
starts. The builder, a person or an AI agent, holds a credential that can ask for a run and
read the verdict, and cannot read a check or an expected value.

Every verdict comes with its boundary. The reveal lists every check that
was run. The certificate says what it proves and what it does not, for instance whether the
running build was measured. Our case studies also list what was not tested. A pass without
its boundary is only a claim.

Shown on real code: a decades-old Fortran library
held to its own user guide, 100 sealed checks, each quoting the sentence it tests. 91 held,
9 failed, every check was shown able to fail, and the page lists what the result does not prove.

It solves the problem, and it is affordable. In
one measured experiment the coding agent
built a feature for $1.01 to $1.97 a run, and the independent tester was one session of about
$5.30 for the whole feature. Independent testing now costs the same order as the AI coding.

## You already had the incident.

80% have traced a production incident directly back to AI-generated code,
and 92% aren't confident their current safeguards would catch an AI-driven
failure before it reaches users.
Sauce Labs, “The Enterprise AI Code Verification Crisis”, n = 400 US executives and
engineering leaders, 22 July 2026 — a vendor-commissioned survey. (AS-9 §2, fetched
2026-09-10.)

3.1% of developers highly trust AI output; 19.6% highly distrust it; 66% hit
answers that are “almost right, but not quite”.
Stack Overflow Developer Survey 2025, n = 33,244. (AS-9 §2, fetched 2026-09-10.)

Syntax pass rates for AI-generated code climbed from about 50% to 95%. Security
pass rates stayed flat, between 45% and 55%.
Veracode, Spring 2026 GenAI Code Security update, 150+ models across 80 coding tasks,
24 March 2026. (AS-9 §2, fetched 2026-09-10.)
Capability is improving. Correctness under adversarial check is not.

And the tools that read the diff have stepped back from the verdict on purpose: Claude
Code Review's check “always completes with a neutral conclusion so it never blocks
merging”; Copilot's reviews “do not count toward required approvals”.
(Vendor documentation, AS-9 §1 and §5, fetched 2026-09-10.)
OneDroid Argus returns a verdict: passed or failed, or not_applicable when no check could run. A check that could not run never counts as a pass; a load run can be degraded; a comparison run reports differences, not a pass.

How it works

## Three steps, and the middle one is the point.

01

### Your agent writes the scenarios

You state the intent — the ticket, the acceptance criteria, the interface diff.
Your own agent, with our skill, turns that into a scenario set: the happy path,
the repeat, the wrong actor, the wrong state, every external call's failure, the race
at the shared resource, and the load variant. The control plane seals the set and
anchors its hash before a line of code is written.

02

### The builder never sees the answer key

The coding agent never holds a token that can read the expectations, and the
scenarios are never in its working directory. It builds against reality, not an answer
key. It can run the scenarios as often as it likes and see only what happened — never
what was expected.

03

### The verdict, with evidence

One final run against a pinned build, then the reveal: every scenario, its trigger,
its expectation, the observed evidence, and the verdict — as a report a reviewer can
hand to an auditor, and a certificate anyone can check with the open CLI and no OneDroid account. The scenarios become
regression guards; the next feature gets a fresh withheld set.

Three modes, one evidence contract

## One product, three questions.

### Holdout acceptance — “does it do what was asked?”

Withheld scenarios, run once against a pinned artefact: a verdict plus per-scenario
replayable evidence.

### Under load — “how much can it take?”

A scenario declares its load and the latency and error rate it must stay under.
For message brokers, a ramp of sessions in steps finds the limit and records what
was sent, confirmed and delivered at each step. An HTTP target can be ramped step
by step too. No ramp drives a web page in a browser.

### Continuously — “is it still true tomorrow?”

The reviewed scenario set runs on a monitor schedule, every 15 minutes at the
shortest. One page answers “Is it OK?” from the scheduled runs only, and lists what
needs a person.

All three in detail, and what OneDroid Argus is not.

The run layer

## It brings its own run layer.

OneDroid Synapse is the governed MCP gateway OneDroid Argus reaches its control
plane through. Your agents connect to one URL instead of holding credentials for each
service; every tool call is authenticated, policy-checked, and logged, fail-open, to an
append-only audit log you own. It ships with OneDroid Argus and runs standalone.
How Synapse works

OneDroid Engram is versioned knowledge and memory in a Postgres you
control — hybrid vector, keyword and graph search, git-style history, diff and restore.
OneDroid Argus keeps the scenario corpus there, so the evidence
behind a verdict has a history, not just a timestamp.
How Engram works

The method behind the gate is written down and open: the Dark Factory kits, Apache-2.0.

For regulated buyers

## When someone has to answer for it.

OneDroid Argus, Synapse and Engram on your own infrastructure, held together by one thing: the
evidence record. Synapse's audit entry, Engram's versioned fact and OneDroid Argus's verdict are
the same object — a promise plus the evidence for it. Where the law names the pieces they
line up: EU AI Act Art. 12 (automatic recording of events over the lifetime of the system)
and Art. 14 (human oversight) for high-risk AI products; DORA Art. 25 and
Art. 30; HIPAA 164.312(b); FDA 21 CFR 11.10(e). Using a coding agent does not by itself
make your system high-risk, and we will not tell you otherwise.

Worth knowing: the largest vendor's hosted agents say of themselves that they are “not
currently eligible for Zero Data Retention (ZDR) or HIPAA Business Associate Agreement
(BAA) coverage.” (Vendor documentation, AS-10 via strategy §6b, fetched 2026-09-10.)
If that is your world, start here.

Bring us your security review
Financial services

Open source

## Open where it has to be.

github.com/OneDro1d
open source

The Dark Factory kits are open source under Apache-2.0, at the address above. The
OneDroid Argus runner executes inside your environment and touches your data plane, so its
source is open too, under MIT:
github.com/OneDro1d/argus-runner.
Your tester writes the scenarios with our open skill; the control plane that seals the set
and adjudicates the verdict is hosted and closed. The holdout is provably prior, and the evidence is replayable with the
runner in your own environment. A certificate proves what the runner reported and when,
not that the runner was unmodified.

The OneDroid org on GitHub
Read the kits

FAQ

## Questions people actually ask.

### What is OneDroid Argus?

Automated end-to-end testing for AI-written code. It runs acceptance scenarios your coding agent never saw against the system it built, under load as well as once, and returns a verdict with evidence you can replay.

### Is OneDroid Argus end-to-end testing?

Yes, and it does more than a usual end-to-end suite. Like any end-to-end test it exercises the running system, with nothing mocked: HTTP, the message broker, the database, web pages in a real browser. Four things differ. Checks are plain scenarios, not test scripts: a separate tester, your QA engineer or an agent but never the builder, writes them from the ticket and the acceptance criteria, before the build. It is faster and cheaper than end-to-end testing by hand: no test scripts to write and keep alive, and the scenarios are written once per feature, before the build. Your coding agent can't pass by guessing, because its credential cannot read a check. And the same checks run under load (a message broker or an HTTP target) and on a schedule, every 15 minutes at the shortest, with no second tool.

### How is this different from an AI code reviewer?

A reviewer reads the diff and gives an opinion. OneDroid Argus does not judge the diff; it exercises the running system. A reviewer says “this looks wrong”; OneDroid Argus says “when I cancelled a shipped order, you refunded it”, and shows you the saga.

### What does independent testing cost?

The same order as the coding. In one measured experiment, Claude Code built a feature for $1.97 a run testing its own work; with OneDroid Argus as the independent tester, the coding agent cost $1.01 a run and the tester one session of about $5.30 for the feature, and both setups passed all 13 hidden checks. The tester is paid once per feature, and its checks stay as regression checks. One ticket and three runs per setup, so treat it as one data point. The case study.

### Do I have to trust your closed control plane?

No. The scenario set is hashed and anchored before the build, revealed in full, with an on-chain anchor, when the tester chooses to reveal after the verdict, and any revealed scenario can be replayed by the runner. The anchor proves the scenarios were prior and unchanged; keeping them unseen is custody — a builder credential that cannot read a test, and an environment that does not hold one.

### Where does it run?

Next to your system, inside your environment, and on the owner's terms. A monitor can watch a live system; for an app that moves money, one switch makes OneDroid Argus refuse every write the owner has not listed, with limits. Checks read your database in read-only transactions (OneDroid Argus writes to it only if a scenario declares a cleanup block, with the credential you give it), and a load ramp never targets a live broker.

### Does OneDroid Argus score my build?

No. Every scenario ends as passed, failed, errored or not_applicable (it could not run), and neither an error nor not_applicable is ever a pass. The verdict is a decision about one pinned build against the sealed scenarios, with the evidence attached. There is no number to optimise for and no “safe” label.

## Find out what your agent actually built.

Talk to us
Get started

The OneDroid Argus runner is free and open source under MIT; the control plane:
sign up to evaluate, your own environment by request. 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.


============================================================================

# PAGE: https://onedroid.ai/argus
Title: How OneDroid Argus Works — End-to-End Testing for AI-Written Code, Under Load and Continuously
Description: OneDroid Argus is automated end-to-end testing for AI-written code. It seals the scenario set before the build, runs it, unseen by the coding agent, against a pinned build, under load and on a schedule too, and makes every scenario replayable by a runner you control. Faster and cheaper than end-to-end testing by hand.

OneDroid

OneDroid Argus · automated end-to-end testing for AI-written code

# Independent testing, at the cost of the coding.

In one measured experiment, Claude Code built a feature for $1.97 a run testing its own
work. With OneDroid Argus as the independent tester, the coding agent cost $1.01 a run,
and the tester one session of about $5.30 to write the checks for the feature.
The tester is paid once per feature, and its checks stay as regression checks.

OneDroid Argus is automated end-to-end testing for AI-written code, and the verifier your
coding agent cannot pass by guessing, because it never sees the test.

Talk to us
The evidence contract

The runner runs inside your environment, and its source is open under MIT:
github.com/OneDro1d/argus-runner. The control plane is hosted:
sign up at argus-dev.onedroid.ai to evaluate it, or ask us for an environment of your own.

Is it end-to-end testing?

## Yes, and it does more than a usual end-to-end suite.

Like any end-to-end test, OneDroid Argus exercises the running system, with nothing mocked:
HTTP, the message broker, the database, web pages in a real browser. It does not judge the diff.
Four things are different.

### Plain scenarios, not test scripts.

A separate tester, your QA engineer or an agent but never the builder, writes each check from the ticket and the acceptance criteria, before the build: what to trigger, where to look, what a healthy answer is. They stay as regression checks for the next change. For QA teams.

### Faster and cheaper than end-to-end testing by hand.

No test scripts to write and keep alive, and nobody clicking through the app before each release. The scenarios are written once per feature, before the build, and run as often as you need.

### Your coding agent can't game it.

Its credential can ask for a run and read the verdict, and cannot read a check or an expected value. A model that can see its checker learns to satisfy the checker.

### Load and continuous runs come with it.

The same checks run under load against a message broker or an HTTP target, and on a schedule, every 15 minutes at the shortest. Under load · Continuously.

Why

## Testing was the part teams could skip. Not any more.

For years companies spent between a fifth and a third of their IT budget on quality assurance and
testing. When it was first measured at 18%, Capgemini's World Quality Report called that
"an indication of insufficient attention on quality".
Testing took people and time, so it was the part that got cut. Coding agents now build a feature for a
few dollars, and code nobody tested independently is still code nobody tested independently.

OneDroid Argus brings independent testing down to the same order of magnitude as the coding. In one
measured experiment, Claude Code built a feature for $1.01 to $1.97 a run, and the independent tester's
session, which wrote the checks once for the whole feature, cost about $5.30. Those checks stay as
regression checks for the next change.
The experiment, its figures and its limits.

No test proves code free of bugs. Different testers catch different things, and a model can give a
different answer on each run. What stays fixed is the record: the scenarios are sealed before the
build, run against the build you pinned, and anyone can run them again.

The evidence contract

## Sealed before the build.

A tester writes the scenario set: a person or an agent who is not the builder, working
from the ticket, the acceptance criteria and the shape of your system. Each scenario
says what to trigger, where to look and what a healthy answer is. The tester seals the
set, and its hash goes on a cryptographic ledger before the work is judged, 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 credential that can
ask for a run and read the verdict, and cannot read a scenario or an expected value.
Both halves matter; we say both.

This is the answer to "an AI agent wrote 50,000 lines overnight: how do I know what it
did?". A model that can see its checker learns to satisfy the checker. The builder can't
game checks it never sees. And a verdict comes with its boundary: what was run, what the
certificate proves and what it does not. One worked example:
a decades-old Fortran library held to its own
user guide, with the full list of what the result does not prove. And it is affordable:
the independent tester costs the same order as the AI coding (see above).

The run

## Run unseen, then adjudicated.

The runner sits next to the system under test, inside your environment, and nothing is
mocked. It drives HTTP, the message broker, the database, external delivery, MCP tool
calls, web pages in a real browser, permissions and rate limits, and gathers 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.

Between steps a check can read one row of the system's PostgreSQL database with a
read-only query, or ask its log store (Loki) whether a line was written. A check can also make
the system fail on purpose while it runs: stop, start or scale a deployment, or delay
or cut one connection. Nothing can be made to fail unless the system's operator has
listed it, OneDroid Argus puts everything back, and the report and the certificate say
what was done.

### The reveal

The verdict binds to a specific build, so it cannot be re-pointed at a later one. It
comes with a certificate: proof without the tests, which anyone can check with the open
CLI, with no OneDroid account and no contact with OneDroid: it reads the public chain through
an RPC endpoint you choose. Because the runner is open source, a certificate proves what the
runner reported and when, not that the runner was unmodified. When the tester chooses to reveal the set, every scenario is
published with its trigger, expectation, observed evidence and verdict, and any
scenario can be replayed by the runner against the same artefact — by you,
by your auditor, by anyone. The ledger proves the order of events and that nothing was
edited. Running it again is what proves the result is true.

Every scenario ends as passed, failed, errored or not_applicable (it could not run), and neither an error nor not_applicable is ever 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. A load run has a fourth outcome,
degraded. 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.

A scenario can declare a load: a number of users held for a duration, with the p95
latency and the error rate it must stay under. For message brokers there is more: a
ramp of sessions in steps, up to 2,000 sessions a step by default, that finds the limit. Each
step records the rates offered, sent, confirmed and delivered, the time from publish
to confirm and to delivery, the errors by class, and any time the broker blocked. A
ramp that crosses the limit at its top step has measured the limit, which is not a
failure. An HTTP target can be ramped too: users are raised step by step against one
named target, and the ramp stops at the first step that is not comfortable, so a system
that has broken is not pushed harder. Under load, expectations are tolerances, and the
report says so.

The limits, stated plainly: stepped ramps exist for AMQP brokers and for one HTTP
target at a time, and none drives a web page in a browser. A target takes load only
after its operator lists it as one that may, and a live system should never be listed.
No load ramp sits under a certified verdict or on a schedule.

Mode three

## Continuously.

Once a hand-run is green, or every red in it is one you have read and decided to keep,
the reviewed scenario set goes on a monitor schedule: every 15 minutes at the shortest,
with no one driving it. The web app answers one question first, “Is it OK?”, from the
scheduled runs only: a failing run someone started by hand never turns it red, and a
system no monitor has measured reads “not measured”, never green. What the system
cannot fix by itself is listed under “Needs a person”, with who acts next.

New, in early use

## One sealed set, two systems.

The same sealed checks can run against two systems, or two versions of one, and their
recorded outputs are compared. The result is a table: rows are checks, columns are
systems, and each cell reads same, differs or not measured. What may differ is declared
before the run, with a tolerance for numbers. A difference a person accepts is pinned
to the two outputs they were shown: if either output changes, the approval stops
counting and the cell differs again.

This is the newest part and we say so: it ran end to end for the first time on
4 October 2026, on three systems. Expect it to change.

On 5 and 6 October it ran on a system we did not pick: two releases of an open source
ticketing system, on one laptop. It found six differences between the releases.
Read the case study, limits included.

Surfaces

## Three ways in.

A CLI with machine-readable output for agents; skills your coding agent already knows
how to load; and an MCP server with separate credentials for the tester and the builder.

### CLI

Machine-readable output, built for an agent to read rather than a human to
eyeball. Built for macOS and Linux.

Released — open source, MIT

### Agent skills

One skill sets OneDroid Argus up next to your system. Another turns a plain description
of what should happen into valid scenarios.

Released — sign up to evaluate

### MCP server

The tester's credential writes, seals and reveals. The builder's can start a run
and read the verdict, never a scenario or an expected value.

Released — sign up to evaluate

The runner and the CLI are open source under MIT at
github.com/OneDro1d/argus-runner.
A run needs an account on the hosted control plane. Create one at
argus-dev.onedroid.ai (e-mail, Google or Microsoft). It is the
evaluation environment: for testing, with no promise that data is kept, so keep production data out of it.
The steps after that are in the OneDroid Argus docs; for an
environment of your own, talk to us.

Boundaries

## What OneDroid Argus is not.

### Not a smoke test

It asks what happens under load, at the step where the system stops being
comfortable, and keeps asking on a schedule after the merge.

### Not a code reviewer

It does not judge the diff. It exercises the running system and reports what
happened.

### Not a test generator you keep

Scenarios stay hidden from the builder until the tester reveals them, so nothing
can be optimised for them.

### Not a free hand on a live system

A monitor can watch a live system, on its owner's terms. For an app that moves
money, one switch makes OneDroid Argus refuse every write the owner has not listed, with
limits. Checks read your database in read-only transactions; OneDroid Argus writes to it only if a scenario declares a cleanup block, and then only with the credential you give it. A load ramp never targets a live broker.

### Not proof the builder never saw the tests

That is custody — a credential that cannot read a test, and an environment that
does not hold one — described plainly above. The anchor proves priority, not that
the builder never looked.

### Not a score

Passed, failed, errored or not_applicable — per scenario, with the evidence. No aggregate
number, no “safe” badge, nothing to game. Neither an error nor not_applicable ever counts as a pass.

What it installs

## It brings its own run layer.

OneDroid Argus reaches its control plane through OneDroid Synapse, the
governed MCP gateway, and keeps the scenario corpus 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, open source under MIT; the control plane: sign up to evaluate,
your own environment by request. 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.


============================================================================

# PAGE: https://onedroid.ai/case-studies
Title: Case studies — OneDroid
Description: Case studies of OneDroid Argus, automated end-to-end testing for AI-written code, on real systems: what was tested, what was found, and what the test could not see.

OneDroid Argus

Case studies

# What happened when
we ran it.

Each study says what was tested and how, what was found, and what the test could not
see. The limits are part of the result, so they are in the text and not in a footnote.
Every study comes in two versions with the same facts: the test page for engineers, and a
blog post for leaders and product owners.

OneDroid Argus · one system

### Does the code do what its user guide says? 100 sealed checks against a decades-old Fortran library

A decades-old numerical Fortran library held to its own user guide: 100 checks, each quoting the sentence it tests, sealed before the run. 91 held and 9 failed, every check was shown able to fail, and the page lists what the result does not prove.

16 October 2026 · 100 checks · one certified run

OneDroid · experiment

### Same modernization, three setups: what the tester checks decides whether it helps

A decades-old Fortran library ported to Go by Claude Code alone, with a tester checking the manual, and with a tester checking equivalence with the original, all judged on 109 hidden checks. What the tester checked decided whether it helped or hurt.

17 October 2026 · 109 hidden checks · 3 runs per setup

OneDroid · experiment

### Claude Code alone or with an independent tester: the same quality, and where the money went

The same feature ticket, built by Claude Code testing itself and by Claude Code with OneDroid Argus as an independent tester, judged on 13 checks neither had seen. The same quality, a builder at half the cost, and a whole that cost 41% more.

16 October 2026 · 13 hidden checks · 3 runs per setup

OneDroid Argus · one system

### Does the guardrail hold on every path? Seven sealed checks against a FINOS CALM demo

The FINOS CALM trades demo, an AI agent's tool server in front of trading data, against seven checks sealed before the run: does the running system match its architecture, and does the guardrail hold on every path. Two checks failed, and the page says which of them is about our own cluster.

7 October 2026 · 7 checks · one certified run

For leaders and product owners: the business view of the same study.

OneDroid Argus · compare

### Six differences between two releases of a ticketing system

OTRS Community Edition 6.0.30 against its fork Znuny 7.3.7, one sealed set of checks.
Six differences between the two releases, what stayed the same, and a list of what
one REST web service, four pages and one laptop cannot tell you.

5 and 6 October 2026 · 26 checks · three runs per system

For leaders and product owners: the business view of the same study.
The video: 56 seconds on YouTube.

The studies so far. OneDroid Argus is in early use, and compare is its newest part.


============================================================================

# PAGE: https://onedroid.ai/case-study-otrs-znuny
Title: Six differences between two releases of a ticketing system — OneDroid Argus case study
Description: The same sealed set of 26 checks, run three times against OTRS Community Edition 6.0.30 and three times against Znuny 7.3.7: six differences, what stayed the same, and the limits of the test.

Case studies

Case study · OneDroid Argus

# Six differences between two releases of a ticketing system

One sealed set of checks, run with OneDroid Argus compare against OTRS Community Edition 6.0.30 and its fork Znuny 7.3.7: what changed, what stayed the same, and what the test could not see.

Case study. Runs of 5 and 6 October 2026. OneDroid Argus compare, in early use.

For leaders, in three lines

- A move to a new release changed six things that other systems rely on. A change log did not show three of them.
- The most important one was a fault in the OLD release: the new one fixes it. A plain comparison would have called the fix a regression.
- One test run on one laptop found this before anyone moved. It does not cover a migrated database, the browser or real load.

The business view, in plain language

Download as PDF
Download as Word

## In short

- An engineer on our team and his coding agent took two releases of an open source ticketing system and ran one sealed set of checks against both. The people who build OneDroid Argus did not choose the system; that engineer's coding agent wrote and ran the checks.

- The wider of two sets had 26 checks and ran three times on each system. OneDroid Argus reported 23 cells identical, 9 that differ, none noisy and none not measured.

- Six differences between the two releases. In one of them the older release returns an emoji as a replacement character, where the newer one returns it unchanged.

- Error paths, customer permissions, the ticket workflow, search and the response time of the sign-in page stayed the same.

- The test is narrow: one REST web service and four pages, fresh installs, one laptop. The limits are listed below in full.

## The video

Watch it on YouTube

## The question

A team that moves from an old release to a new one, or to a fork, wants to know what changes for everything that talks to the system. A change log answers with what its authors remembered to write down. A comparison answers by running the same requests against both and reading what comes back.

The reference was OTRS Community Edition 6.0.30. The candidate was Znuny 7.3.7, the open source fork of it. This is not a review of either product and not a recommendation. It is a record of what one set of checks saw.

## The setup

Item | Value |

Reference | OTRS Community Edition 6.0.30 |

Candidate | Znuny 7.3.7 |

How they were built | Both from the official release archives with pinned checksums, on the same base image |

Database | MariaDB 10.11 for both |

Starting data | The same fixture for both |

Host | One Windows laptop, Docker Compose, two OneDroid Argus executors side by side, no cluster |

OneDroid Argus | Compare, in early use, with our hosted development control plane |

Runs | Three per system, per set |

Who wrote and ran the checks | One engineer's coding agent |

## What was checked

Set 1, 5 October, 16 checks. A seed check. Ticket create, update, history and search over the REST web service. Five error and permission paths. Session data. Three entry pages. The old URL path. One load check.

Set 2, 6 October, 26 checks. The same ground, plus: a pending reminder, close, a queue move with owner and lock, a customer refused a ticket that is not theirs, a customer raising the priority of their own ticket, an update to a state that does not exist, an emoji in an article, an article with an attachment, a read with a customer session, and the session check again with its values masked.

One set holds three kinds of check. A measured check records the output of each system and compares the two, field by field. A fixed check states a claim that every system must meet by itself, the reference included. A load check says the candidate must not be worse than the reference by more than a declared band, here 25%.

Before the comparison ran, each set was sealed and its hash was recorded on a ledger, so a set could not be changed after anyone had seen a result. One thing the seal does not show: the checks were rehearsed on both systems before sealing. The seal proves the set did not change afterwards. It does not make its author blind to the systems.

## The result

| Set 1, 5 October | Set 2, 6 October |

Checks | 16 | 26 |

Runs per system | 3 | 3 |

Cells identical | 16 | 23 |

Cells that differ | 4 | 9 |

Cells that read as noise | 1 | 0 |

Not measured | 0 | 0 |

Could not run | 0 | 0 |

Verdict | differences | differences |

The six runs of the first set took about 8 minutes. The numbers are the ones OneDroid Argus reported. The verdict is the word differences with the table behind it. OneDroid Argus gives no score.

## The six differences

What | OTRS 6.0.30 | Znuny 7.3.7 | How it was seen |

The old URL path `/otrs/index.pl` | Answers | Answers 404 | Fixed check, 0 of 3 runs on Znuny |

An emoji in an article | Comes back as U+FFFD, the replacement character | Comes back unchanged | Fixed check: 0 of 3 on OTRS, 3 of 3 on Znuny |

`CommunicationChannel` on every article | Not there | There | Measured, on three different reads: plain, with an attachment, with a customer session |

The `DynamicField` list on a ticket | The list, with empty values | No list | Measured. The cause was not found |

Ticket history after create, close and reopen | 11 entries | 13 entries | Measured. The extra entries are `SetPendingTime`, written at a state change |

Keys in the session data | 1 key only here | 7 keys only here | Measured with the values masked. 26 keys are common |

We did not trace any of these into the source code, and we do not say which are intended. During the first set, a keyword search of the Znuny change log did not find the `CommunicationChannel` field, the missing `DynamicField` list or the extra history entry. A keyword search is a weak test, so read that as not found by us, not as undocumented.

The emoji row is the one to look at twice. It is a fixed check, so the reference is judged like any other system, and the reference is the one that fails. A comparison that only asked whether the new release matches the old one would have counted the newer, correct behaviour as a regression.

Only the read was checked. The study does not say what OTRS 6.0.30 stores in its database for that article.

## What was the same

- Six error and refusal paths answer the same on both. For the five in the first set that is the same status, code and message in 3 of 3 runs each.

- Customer permissions: a customer is refused a ticket that is not theirs, and can raise the priority of their own.

- Pending reminder, close, and a queue move with owner and lock.

- Ticket search and the entry pages.

- The sign-in page under five users at once: 95th percentile 49 ms on OTRS and 54 ms on Znuny in the first set, 60 ms and 59 ms in the second. Both inside the 25% band.

The timings come from one laptop, five users and one page. They say the candidate was not slower in this run. They are not a benchmark of either product.

## What the noise taught us

In the first set the session-data check compared raw values. The reference gave three different outputs in three runs, so OneDroid Argus marked the cell as noise and did not call it a difference. In the second set the values were masked and only the keys were compared. The noise was gone and a real difference showed: one key only on OTRS, seven only on Znuny.

Two things follow. Three runs per system is what makes unstable output visible at all. And a check on anything with ids, tokens or timestamps in it needs its masks before it can say something.

## What this test did not cover

Not covered | Why it matters |

Anything beyond one REST web service and four pages | Most of both products was never asked a question |

A migrated database | Both systems were fresh installs with the same starting data. An upgrade with years of real data is the common case, and it was not tested |

Browser checks, database checks, mail, service level rules and access control lists | The sets held HTTP checks only. OneDroid Argus can drive a browser, but a browser check inside a comparison has not been tried |

More than three runs per system | Three runs show unstable output. They do not show a rare failure |

Performance | One laptop, five users, one page. A parity signal and nothing more |

Tolerances for numbers | Not used in either set |

The cause of each difference | None was traced into the source. For the `DynamicField` list the cause was looked for and not found |

An independent tester | The same team wrote the checks, ran them and wrote this, and OneDroid Argus is our product. The independent check is to run the set again |

A released product | Compare is in early use and ran here against a development control plane |

## What a comparison can and cannot measure

It can say | It cannot say |

Whether the same request gives the same answer on both systems, field by field | Whether a difference is intended. A person decides that |

Whether each system meets a fixed claim by itself | Anything that no check asks |

Whether the candidate is slower than the reference by more than a declared band | How fast either system is in production |

Whether an output is stable from one run to the next | How a system behaves on data the set did not create |

## What we take from it

- A comparison of two releases of a real system that keeps state ran end to end on one laptop, with sign-in, saved session ids and saved ticket ids carried between steps.

- The most useful finding came from a fixed check that the reference failed. The old system is not right by definition.

- Mask first, then compare. An unmasked check produced noise, the masked one produced a finding.

- Three of the six differences were not found by a keyword search of the change log. Whether they are documented elsewhere, we did not establish. Running both releases found them in minutes.

OTRS and Znuny are names that belong to their respective owners. OneDroid is not affiliated with either project, and the product names are used only to identify the software that was tested. OneDroid Argus is built by Providentia Worldwide. Questions: michal@onedroid.ai. How OneDroid Argus works: onedroid.ai/argus.

How compare works in OneDroid Argus


============================================================================

# PAGE: https://onedroid.ai/case-study-finos-calm
Title: Does the guardrail hold on every path? Seven sealed checks against a FINOS CALM demo — OneDroid Argus case study
Description: Seven checks sealed before the run, against the FINOS CALM trades API and MCP demo: 5 passed, 2 failed, 0 errored. The guardrail did not cover lookup by id, and a forbidden connection was open on our cluster.

Case studies

Case study · OneDroid Argus

# Does the guardrail hold on every path? Seven sealed checks against a FINOS CALM demo

One sealed set of checks, run with OneDroid Argus against the FINOS CALM "trades API and MCP" demo: whether the running system matches its architecture, whether its guardrail holds on every path, and how anyone can check the result later.

Case study. Certified run of 7 October 2026. OneDroid Argus, one system, in early use.

For leaders, in three lines

- Seven sealed checks against an open source demo that puts an AI agent's tool server in front of trading data: 5 passed, 2 failed.
- The guardrail kept restricted symbols out of search, but returned a restricted trade when asked for it by id. A connection the architecture forbids was open, because our cluster does not enforce network policies.
- The checks were sealed and recorded before the run, the verdict after it, so anyone can check later what was tested. One certified run on one cluster, and no capacity claim.

The business view, in plain language

Download as PDF
Download as Word

## In short

- Our team ran one sealed set of seven checks with OneDroid Argus against the FINOS CALM "trades API and MCP" demo: a trades REST API, an MCP server for an AI agent with a guardrail on restricted symbols, and an A2A server.

- Six checks were generated from the demo's own CALM architecture file and one was written by hand. OneDroid Argus reported 5 passed, 2 failed and 0 errored.

- The guardrail refused the restricted symbols in a trade search, but returned a restricted trade in full when the MCP server was asked for it by id.

- A connection the architecture forbids was open. The cause is our cluster: it does not enforce Kubernetes network policies, so the demo's own policies had no effect there.

- The checks were sealed and recorded on a public test network and in Bitcoin before the run, and the verdict after it. Before running, OneDroid Argus confirmed that the images running were exactly the ones declared.

## The video

Watch it on YouTube

## The question

A team is about to put an AI agent's tool server in front of trading data. Its architecture says what may talk to what, and a guardrail says which symbols the agent must never see. Before trusting it, the team wants to know three things: does the running system match the architecture, does the guardrail hold on every path, and can anyone prove later exactly what was tested and what it found?

FINOS CALM is an open source way to write a system's architecture down as a file: its parts, which of them may talk to which, and the controls on them. The demo tested here is the "trades API and MCP" scenario (QCon scenario 2). This is not a review of FINOS CALM or of the demo, and not a recommendation. It is a record of what one set of checks saw.

## The setup

Item | Value |

System | The FINOS CALM "trades API and MCP" demo: a Trades REST API, a Trades MCP server with an `mcp-guardrail` control (denied symbols VOD, GME and AMC), and an A2A server |

Images | The demo's public images, pinned by digest: trades-rest-server `sha256:21bc0b16…`, trades-mcp-server `sha256:feb820a3…`, trades-a2a-server `sha256:2ec2a457…` |

How it ran | The demo's own manifests, unchanged, on a shared Azure Kubernetes cluster in Poland Central. The demo is stateless and generates its trade data in memory when it starts |

OneDroid Argus | Executor v0.3.66 on the same cluster, with read-only access to the demo's pods so that a certificate can say what was running. One system, no reference build |

The checks | 6 generated by `argus calm import` from the demo's CALM architecture file, 1 written by hand |

Mode | Certifying (`final`): the set is sealed and recorded before the run |

Who wrote and ran the checks | Our team |

## What was checked

The certified set holds seven checks, sealed on 7 October 2026 at 19:57 UTC.

Check | Where it comes from | What healthy means |

The MCP client reaches the MCP server | The architecture declares this connection | It answers |

The MCP client path cannot reach the Trades API | The architecture declares no such connection | No answer: the path is closed |

The guardrail lets an allowed symbol through | The guardrail control | A search for LSE:AAPL returns trades |

The guardrail refuses VOD on the trade search | The guardrail control | Refused |

The guardrail refuses GME on the trade search | The guardrail control | Refused |

The guardrail refuses AMC on the trade search | The guardrail control | Refused |

A trade in a denied symbol, asked for by id, is refused | Written by hand. The id is looked up at run time from the system of record | Refused |

The first six came straight from the architecture file: a connection that must work, a connection that must not, the guardrail's allow and its three denies. The seventh asks the question the architecture file does not: whether the guardrail also holds on a second way to the same data.

## The result

| Certified run, 7 October 2026 |

Checks | 7 |

Passed | 5 |

Failed | 2 |

Errored | 0 |

Run status | failed |

The run status is the word OneDroid Argus gives a run. It reads `failed` when at least one check failed, and it is not a judgement of the product: the counts above are the result. An errored check is one that could not run, and an error is never counted as a pass.

No check was left not measured, and none could not run. The numbers are the ones OneDroid Argus reported. OneDroid Argus gives no score. An earlier certified run of the same seven checks the same day gave the same verdict.

## The two checks that failed

1. The guardrail does not cover lookup by id. The trade search refuses VOD with "is restricted". Asking the MCP server for a VOD trade by its id returned the full trade: instrument, price, quantity and status. It was seen in every run that day in which the trade asked for was a VOD trade, including both certified runs. We did not trace the cause in the demo's code, and we have not reported it to the demo's authors.

2. A connection the architecture forbids was open. The architecture declares no connection from the MCP client to the Trades API. A request on that path got an HTTP answer (404), so the network let it through. It was seen in every final run that day. The cause is traced, and it is ours: the cluster we ran on does not enforce Kubernetes network policies, so the demo's own policies had no effect there. This is about our deployment, not the demo's code, and it may not appear where policies are enforced.

The second finding is still the useful one. An architecture file says what must not connect. Whether the network underneath agrees is a property of each deployment, and a check generated from the file asks it every time.

## What passed

- The declared connection. The MCP client reached the MCP server.

- The guardrail on search. It refused VOD, GME and AMC on the trade search, and let LSE:AAPL through.

- All of this held in every run.

## How anyone can check it later

Before the run, the sealed set was recorded on three chains: a private chain run by OneDroid Argus, Base Sepolia (a public Ethereum test network) and Bitcoin, through OpenTimestamps. After the run, the verdict was recorded on the same three. What goes on a chain is only ids, hashes, digests, counts and the verdict, never a check, an expected value or an observed one.

Record | Base Sepolia transaction |

The sealed set, before the run (block 47817413) | `0x9fccbd30504e7e31554455dfc27bbf27ca5cba4cd5e30d9f607a6355aea32adc` |

The verdict, after the run (block 47817439) | `0x8718c0b64c7fd35feb06029e1af1574b944d35c2afde6676a114132b7353ce7a` |

Each transaction can be opened on sepolia.basescan.org. The Bitcoin record of this run was submitted to OpenTimestamps, and its Bitcoin attestation lands within hours of the run. A certificate built from these records can be checked with the `argus` command line, with no account and without seeing a single check: docs.onedroid.ai/argus-ledger.

What was running was measured, not assumed. Before the run, OneDroid Argus read the image digests actually running and found exactly the three that the certification declared. To show the other side, a final run was started that declared a digest that was not running. It was refused before any check ran: "is not among the image digests running in the system under test — no scenario was run and nothing was bound".

The seal proves priority: the checks existed, unchanged, before the result. It does not make their authors blind to the system. The same team wrote the checks and ran them.

## What this test did not cover

Not covered | Why it matters |

More than one deployment | One shared cluster without network policy enforcement. The second finding may not appear where policies are enforced |

More than one certified run of this set | One certified run, plus one earlier certified run of the same checks the same day. Two runs, not a stability measure |

Real data | In-memory demo data, regenerated at each start |

Capacity | Not certified. Two build runs, outside the sealed set, served up to 160 concurrent users with a 95th percentile of 106 ms or less and no errors. The limit was not reached in this setup, so there is no capacity claim |

Browsers and user interfaces | HTTP and MCP checks only |

The A2A server | No check in the set asked it a question |

The cause of the first finding | Not traced in the demo's code |

An independent tester | The same team wrote the checks (six generated from the architecture, one by hand), ran them and wrote this, and OneDroid Argus is our product |

A released product | OneDroid Argus ran here against a development control plane |

## What a run on one system can and cannot say

It can say | It cannot say |

Whether the running system keeps each connection the architecture declares, and blocks each one it does not | Whether the architecture itself is a good one |

Whether a control holds on every path a check asks about | Whether it holds on a path no check asks about |

Which images were running when the verdict was given | Anything about a deployment it did not run on |

That the checks were fixed before the result, and the result not changed since | That nobody looked at the system first |

## What we take from it

- An architecture file is a list of claims. Six of the seven checks were generated from it, so the claims were tested as written, not as remembered.

- A guardrail on one path is not a guardrail on the data. The one hand-written check, a second way to the same trade, is the one that found the gap.

- A rule about what must not connect depends on the network under it. Check it on every deployment, including your own.

- A run status of `failed` is one word. The table under it is the result, and the chain records let anyone confirm it was not changed afterwards.

FINOS and CALM are names that belong to their respective owners, as do QCon, Kubernetes, Azure, Bitcoin, Base and OpenTimestamps. OneDroid is not affiliated with FINOS, the CALM project or the demo's authors, and the names are used only to identify the software that was tested and the networks the records are on. OneDroid Argus is built by Providentia Worldwide. Questions: michal@onedroid.ai. How OneDroid Argus works: onedroid.ai/argus.

How a run works in OneDroid Argus


============================================================================

# PAGE: https://onedroid.ai/case-study-claude-code-alone-vs-tester
Title: Claude Code alone or with an independent tester: the same quality, and where the money went — OneDroid case study
Description: Claude Code alone vs Claude Code with OneDroid Argus as an independent tester: all 6 runs passed 13 of 13 hidden checks. The builder cost 49% less ($1.01 vs $1.97); with the tester the whole cost 41% more ($2.78).

Case studies

Case study · experiment

# Claude Code alone or with an independent tester: the same quality, and where the money went

One feature ticket, built three times by Claude Code testing its own work and three times by Claude Code with OneDroid Argus as the tester, then judged on checks neither setup had seen.

Case study. Runs of 16 October 2026. An experiment by our team, 3 judged runs per setup.

For leaders, in three lines

- On one feature ticket, Claude Code working alone and Claude Code with OneDroid Argus as an independent tester delivered the same quality: every run passed all 13 hidden checks.
- With the tester, the coding agent cost half as much ($1.01 against $1.97 a run), because it stopped testing its own work. Counting the tester's one-off session, the whole cost was 41% higher ($2.78 against $1.97).
- The ticket was too easy to separate the two on quality, and there were 3 runs per setup. A harder ticket is the next test.

The business view, in plain language

Download as PDF
Download as Word

## In short

- Our team gave Claude Code the same feature ticket in two setups: alone, testing its own work as it normally would, and with a tester, implementing only while OneDroid Argus ran checks it never saw.

- Both setups were then judged on 13 hidden checks that neither had seen, not even by name: all 6 runs passed all 13.

- With the tester, the coding agent ran its own tests twice in its three runs together; alone, it ran them 3 times in an average run. It used 69% fewer tokens and cost 49% less ($1.01 against $1.97).

- The tester's one-off session, spread over its three runs, brought the whole to $2.78 a run: 41% more than Claude Code alone.

- One ticket, 3 judged runs per setup, and a ticket too easy to separate quality. The limits are listed below.

## The question

A coding agent that writes its own tests spends tokens checking itself, and its tests share its own reading of the ticket. An independent tester costs money too. On the same codebase and the same ticket, does Claude Code with an independent tester cost less, and deliver more, than Claude Code testing itself?

## The setup

Item | Value |

The codebase | A small tasks app with a JSON API and a web page. Due dates, priority and search were already live and had to keep working. |

The ticket | One feature: tags on tasks, with validation rules, adding and removing one tag, filtering by tag, a tag list with counts, and chips on the web page. The same text for both setups, word for word. |

The model | Claude Code on Claude Opus 5.5, high effort. The same start commit, permission mode and "do not commit" for both setups. |

Setup A: alone | Claude Code working as it normally would. It may write and run tests and use subagents. |

Setup B: with a tester | Claude Code implementing only: no test suite, no review or test subagents. OneDroid Argus then ran the build checks, and the coding agent got back only the names of the checks that failed, for up to 4 rounds. The build checks ran together with 37 older checks of the same app, as regression checks. |

Who wrote the checks | A separate tester session wrote the build checks and the hidden checks before any build. The coding agent never saw a check body or an expected value. |

The judge | 13 hidden checks, stored in OneDroid Argus only after the last run, so neither setup saw them, not even as names. The 12 build checks were also run on every setup at the end. |

Runs | 3 judged runs per setup, in random order, on 16 October 2026. A fourth run of setup A was not judged and is left out of every figure here. |

Cost | List prices for Claude Opus 5.5: $4 input and $20 output per million tokens, $0.20 cache read, $5 cache write, $8 for a one-hour cache write. |

## The result

Mean per run | A: alone | B: with a tester |

Hidden checks passed | 13 of 13 in every run | 13 of 13 in every run |

Build checks passed | 12 of 12 | 12 of 12 |

Tester rounds | none | 1 in every run: it passed first time |

Times the coding agent ran its own tests | 3 | under 1: twice in the three runs together |

The coding agent's tokens | 2.37 million | 0.72 million (−69%) |

The coding agent's cost | $1.97 | $1.01 (−49%) |

The whole cost, the tester's session included | $1.97 | $2.78 (+41%) |

Wall time | not compared | not compared: the tester runs include waiting for human approvals |

The same numbers as a chart. Means of the 3 judged runs per setup, at list prices.

The tester's session wrote both sets of checks once and cost about $5.30. It is split evenly over the three B runs, which adds about $1.77 to each.

## What the numbers say

- Quality was a tie. Both setups hit 13 of 13, so this ticket cannot show whether an independent tester improves quality. It was too easy for that.

- The coding agent got cheaper because it stopped checking itself. It ran its own tests twice in its three runs together, against 3 times in an average run alone, and used 69% fewer tokens. Every B run passed the tester in its first round.

- On one feature, the tester's one-off cost outweighed that saving. The tester is paid once per feature, and its checks stay as regression checks for the next change: setup B already ran 37 older checks of the same app that way. Whether that pays back over several features was not measured here.

## What this experiment did not cover

Not covered | Why it matters |

A ticket hard enough to separate quality | Both setups passed every hidden check, so the result says nothing about which one builds better. |

More than 3 runs per setup | The figures are means of 3 runs, not a distribution. |

Wall time | Times aren't comparable: the tester runs include waiting for human approvals. |

Identical wrappers | Setup B ran inside an agent runner with its own fences. Setup A ran plain Claude Code with an allow-list: the honest default, but not the same. |

Equal feedback | Setup B also got regression feedback from the 37 older checks. Setup A had only the repository's own tests. |

Several features | The tester's cost was spread over one feature. Reuse of its checks across features was not measured. |

## What we take from it

- On an easy ticket, an independent tester buys no extra quality and costs more in total. Its value has to show on harder work, and over several features.

- Moving the testing out of the coding agent made the coding agent cheaper. Whether the whole gets cheaper depends on how often the tester's checks are reused.

- Next: the same comparison on a ticket hard enough that the first build fails some checks.

Claude and Claude Code are products of Anthropic, named only to identify what was used. OneDroid is not affiliated with Anthropic. OneDroid Argus is built by Providentia Worldwide. Questions: michal@onedroid.ai.

How OneDroid Argus keeps the checks away from the builder


============================================================================

# PAGE: https://onedroid.ai/case-study-modernization-three-setups
Title: Same modernization, three setups: what the tester checks decides whether it helps — OneDroid case study
Description: Porting a decades-old Fortran library to Go with Claude Code: alone 104 of 109 hidden checks, with a tester on the manual 81, with a tester on equivalence with the original 106, at $10.04 a run against $16.92 (-41%).

Case studies

Case study · experiment

# Same modernization, three setups: what the tester checks decides whether it helps

Claude Code ported a decades-old Fortran library to Go three times in each of three setups: alone, with a tester checking the manual, and with a tester checking equivalence with the original. Every port was judged on the same hidden checks.

Case study. Runs of 17 October 2026. An experiment by our team, 3 runs per setup.

For leaders, in three lines

- We had Claude Code port a decades-old Fortran library to Go in three setups, and judged every port on the same 109 hidden checks against the original's answers.
- A tester checking against the manual made the port worse (81 of 109), because the agent "fixed" every place where the original and its manual differ. A tester checking "behave like the original" matched working alone (106 against 104) at 41% less cost.
- Three runs per setup on one codebase, and the tester's cost of writing its checks is not counted.

The business view, in plain language

Download as PDF
Download as Word

## In short

- Our team gave Claude Code one modernization in three setups: port a decades-old numerical Fortran library, unmodified, to Go behind a fixed HTTP interface, keeping the original's numerical behaviour.

- A worked alone. B implemented only, while a tester ran checks written from the library's user guide. B′ implemented only, while a tester ran checks against the original's recorded answers.

- Every port was judged on the same 109 hidden checks against the original's answers: A passed 104, B 81, B′ 106.

- B′ cost $10.04 a run, 41% less than A at $16.92.

- What the tester checks decided whether the loop helped or hurt. Three runs per setup on one codebase: the limits are listed below.

## The question

In a modernization, the job is to keep what the old system does. Does Claude Code with an independent tester do a better or cheaper port than Claude Code on its own, when every port is judged on the same hidden checks? And does it matter what the tester checks?

## The setup

Item | Value |

The task | Port a decades-old numerical Fortran library, unmodified, to Go behind a fixed HTTP interface, keeping the original's numerical behaviour. Every run got the same ticket, sources, user guide and interface, and never saw a check. |

The model | Claude Code on Claude Opus 5.5, high effort, in every setup. |

Setup A: alone | Claude Code working as it normally would. It writes and runs its own tests. |

Setup B: tester on the manual | Claude Code implementing only. A tester ran 100 checks written from the library's user guide and returned only the names of the failures, for up to 4 rounds. |

Setup B′: tester on the original | The same as B, but the tester ran 106 equivalence checks against the original's recorded answers, half of a set of 215. |

The judge | The other 109 equivalence checks, hidden from every setup. |

The tester | A script that ran the checks and returned the names of the failures. It was not OneDroid Argus: our product's route could not reach the experiment's local setup. |

Runs | 3 per setup, on 17 October 2026. |

Cost | Claude Code's own `total_cost_usd` per run. Our own count from the transcripts agrees within 0.11%. |

## The result

Mean per run | A: alone | B: tester on the manual | B′: tester on the original |

Hidden checks passed, of 109 | 104 | 81 | 106 |

The same without 5 ambiguous checks, of 104 | 101 | 78 | 101 |

Checks from the user guide, of 100 | 90 | 95 (its tester ran these) | 90 |

Cost per run | $16.92 | $15.19 | $10.04 (−41%) |

Tester rounds used | none | 4 of 4 | 1 |

The coding agent's own test runs / subagents | 13 / 3 | 0 / 0 | 0 / 0 |

The same numbers as a chart. Means of 3 runs per setup.

## What the numbers say

- What the tester checks decides whether the loop helps or hurts. B's tester counted every place where the original and its manual differ as a failure, so B changed the port to follow the manual. All three B runs changed one numerical detail that the original handles approximately, which cost 22 to 25 of the 109 hidden checks. B's score on the manual's checks rose while the port drifted from the original.

- When the tester checks "behave like the original", there is nothing to "fix". B′ stayed faithful and matched A exactly on the unambiguous hidden checks: 101 of 104.

- B′ cost 41% less than A, because a coding agent that only implements runs no tests and no subagents. Its tester confirmed the first build, and no second round was needed.

## What this experiment did not cover

Not covered | Why it matters |

More than 3 runs, or another codebase | One library, 3 runs per setup: means, not a distribution. |

OneDroid Argus as the tester | The tester was a script. The result is about where the checks point, not about our product. |

A repair loop | B′'s tester passed the first build, so this does not show that iterating on equivalence repairs a port. |

An ambiguous rule | One interface rule could be read two ways. It affects 5 hidden checks and explains B′'s 2-check lead over A. |

One guard in the B and B′ setup | A block on compound shell commands didn't work in any B or B′ run: it failed open because a helper tool was missing. |

Identical rules and instructions | Both tester setups also ran with our agent rules and an instruction to implement only. The agent working alone had neither. |

The cost of writing the checks | The tester's checks came from earlier work on the same library and can be reused. Writing them is not in the cost per run. |

## What we take from it

- Point the tester at the behaviour you must keep. In a modernization, that is the old system's answers, not its manual.

- A tester checking the wrong thing is worse than none: setup B scored below Claude Code alone.

- Next: the same three setups where the first build fails some equivalence checks, so the loop has to repair the port.

Claude and Claude Code are products of Anthropic, named only to identify what was used. OneDroid is not affiliated with Anthropic. OneDroid Argus is built by Providentia Worldwide. Questions: michal@onedroid.ai.

How OneDroid Argus keeps the checks away from the builder


============================================================================

# PAGE: https://onedroid.ai/case-study-code-vs-user-guide
Title: Does the code do what its user guide says? 100 sealed checks against a decades-old Fortran library — OneDroid Argus case study
Description: A decades-old Fortran library against 100 sealed checks written from its own user guide: 91 held, 9 failed, 0 errored. Every worked example reproduces; 2 medium and 2 low findings on one rarely used path and in the fine print; every check proven able to fail; the test boundary published.

Case studies

Case study · OneDroid Argus

# Does the code do what its user guide says? 100 sealed checks against a decades-old Fortran library

Every promise in a numerical library's user guide, turned into a check that quotes it, sealed before the run and run against the original code. What held, where code and guide disagree, and what the result does not prove.

Case study. Certified run of 16 October 2026. OneDroid Argus, one system, reviewed by a second AI model.

For leaders, in three lines

- We turned the user guide of a decades-old Fortran library into 100 checks, sealed them before the run, and ran them against the original code: 91 held, 9 failed.
- Every worked example in the guide still reproduces. Where the code and its guide disagree, it is on one rarely used path and in the fine print: 2 medium findings, 2 low, nothing critical.
- Each check quotes the sentence it tests and was shown able to fail. The page lists what the result does not prove.

The business view, in plain language

Download as PDF
Download as Word

## In short

- Our team turned the user guide of a decades-old numerical Fortran library into 100 checks of 37 published claims: every worked example, what each exit code and counter means, and the guide's other promises. Each check quotes the sentence it tests.

- The 100 checks were sealed, and their fingerprint recorded on a public network, before the final run against the original code, built unmodified.

- 91 held, 9 failed, 0 could not run. All 9 failures are places where the code's own behaviour does not match its guide's own words.

- Before trusting the 91, we showed the checks can fail: two deliberately broken builds turned red the checks that depend on what was broken, and left every unrelated check of the arithmetic green.

- An AI model from another company reviewed every finding and every held check. It confirmed all 9 failures and found no check that cannot fail. It also found held checks that test less than their titles say, and the page lists them.

## The question

A numerical library has run for decades, and its user guide says, sentence by sentence, what it does. Someone is about to depend on it, or about to have an AI agent rewrite it. Two questions come first: does the code still do everything its guide promises, and can anyone check the answer without taking our word for it?

It is the same question as "an AI agent wrote 50,000 lines overnight: how do I know what it did?". Nobody reads all of it. You can hold it to what it was supposed to do, with checks it never saw.

## The method

Step | What we did |

The promises | The user guide, the documentation at the top of each routine and the published test programs. 37 claims became 100 checks; each check carries the sentence it tests and where it is. 2 of the 100 are properties of our own (the code gives the same answer twice, and it reports the exact sources we pinned), and they are labelled as ours |

The system | The original code, built unmodified with a current compiler (gfortran 14.4) on one x86-64 machine. Every source file pinned by its SHA-256 fingerprint |

Severity, fixed before the run | Medium: a stated function or a documented example fails. Low: wording that does not match behaviour, or a constant that is not the defined value. High or critical: a wrong answer reported as a success |

Predictions, before the run | Every expected failure was predicted in writing from reading the code. No check predicted to hold turned red |

Can a check fail? | Two builds, each with one constant changed, turned red the checks that depend on it (and, as intended, the check that the code is the one we pinned) and left every unrelated check of the arithmetic green |

The seal | The 100 checks were committed and recorded on a public network before the final run. One certified run |

The review | OpenAI gpt-6.1-sol read every finding and every held check from the files, in a read-only sandbox. Its corrections changed our wording, never the sealed checks |

Who | Our team. One AI session wrote the checks and ran them. There was no builder: nothing was fixed |

## The result

| Certified run, 16 October 2026 |

Checks | 100 |

Passed | 91 |

Failed | 9 |

Errored | 0 |

Run status | failed |

The run status is the word OneDroid Argus gives a run. It reads `failed` when at least one check failed, and it is not a judgement of the product: the counts above are the result. An errored check is one that could not run, and an error is never counted as a pass.

A run status of `failed` means at least one check failed: 91 of 100 held. A rehearsal of the same sealed set gave the same tallies. OneDroid Argus gives no score.

## Where the code and its guide disagree

Medium, 4 checks: one path. When the user's own function asks the solver to stop part-way through its first step, two of the outputs are not what the guide says they are: the returned solution still carries a tiny internal adjustment instead of the starting point, and a counter reports calls that never happened. Routines that compute the same step another way return both correctly on the same path.

Low, 2 checks: a counter's definition. The guide defines a counter as the number of calls to the user's function, but the calls made for progress printing are not counted.

Low, 3 checks: machine constants. Three constants the documentation defines exactly are 12-digit approximations in the code. The effect on results is tiny, but the definition is not met.

Nothing was fixed, and nothing was reported to the library's authors. The job was to measure. Two more behaviours on the same kind of path were found by the reviewer in the source and are under research: they need checks of their own in a new sealed set before they can count.

## What held

- Every worked example in the guide. All 11 reproduce the printed output to 7 digits, including every printed count, on a compiler decades newer than the guide.

- What the exit codes mean. Improper input in 22 cases across 10 routines, the user stopping the run, limits on the number of calls, and tolerances below machine precision: each gave the exit code the guide names.

- Scale invariance, as the guide claims, within the bands it prints.

- The published test deck for the derivative checker: every problem read as labelled, run one at a time.

- Repeatability: the same request twice gave bit-identical results.

## The test boundary: what this result does not prove

A verdict is only as useful as the line around it. This is the line.

Not proved | Why |

Other machines and compilers | One platform. The guide itself says results elsewhere may differ slightly |

What was running | The certificate binds the build we declared. The executor used here could not measure the running build, and the certificate says so |

Independence | One AI session wrote the checks and ran them. The seal proves the order of events, not independence. Our driver is our own code: a mistake in it would read as the library's |

A second run by the reviewer | The review was a reading of the evidence, not a re-run |

Full strength of every held check | The review found some held checks that test less than their titles (a norm instead of the whole vector, the order of values instead of the values). They held as written; stronger versions go in the next set |

Every path | Not exhausted. The reviewer found two more candidate behaviours in the source, not yet run |

Everything else the guide says | Single precision, faults raised inside the user's function, operation counts, storage and convergence-rate statements: not tested |

Our own mistakes are part of the record too. One of our checks was wrong at first (it asked for a printed value under a setting the guide does not print it for) and was corrected before the seal. Our first deliberately broken build changed nothing, as we had warned it might, and was repeated with a stronger change. And we did not check before sealing that this executor could measure the running build.

## How anyone can check it

The sealed set and the verdict were recorded on Base Sepolia, a public Ethereum test network (blocks 48212445 and 48212457), and submitted to Bitcoin through OpenTimestamps. What goes on a chain is only fingerprints, counts and the verdict, never a check or an expected value. The certificate verified with the public verifier in the open-source OneDroid Argus runner (MIT), with no account: github.com/OneDro1d/argus-runner.

## Why it matters before an AI rewrite

In a separate study, Claude Code ported this same library to Go. A tester that steered the port with checks from the user guide made it worse against the original's answers, 81 of 109 hidden checks, because the agent "fixed" the places where the code and its guide disagree. Knowing where they disagree, before anyone rewrites anything, is what this study gives a team. The modernization case study: onedroid.ai/case-study-modernization-three-setups.

## What we take from it

- A user guide is a list of promises. Turn each sentence into a check that quotes it, and you can show which ones the code keeps.

- Seal the checks before the run and keep them from whoever builds. Whoever builds, a person or an AI agent, can't game checks it never sees.

- Prove each check can fail before you trust the ones that pass.

- Publish the test boundary with the verdict: what was tested, what was not, and what the certificate does not prove.

- It is affordable. In a separate measured experiment, the independent tester was one session of about $5.30 for a feature the coding agent built at $1.01 to $1.97 a run: onedroid.ai/case-study-claude-code-alone-vs-tester.

The library, its authors and its maintainers are not named: we have not asked them, and this is a record of what one set of checks saw, not a review of their work. gfortran, OpenAI, Claude Code, Base, Bitcoin and OpenTimestamps are names that belong to their owners. OneDroid Argus is built by Providentia Worldwide. Questions: michal@onedroid.ai. How OneDroid Argus works: onedroid.ai/argus.

How a run works in OneDroid Argus


============================================================================

# PAGE: https://onedroid.ai/synapse
Title: OneDroid Synapse — Governed MCP Gateway for AI Agents
Description: OneDroid Synapse is a governed MCP gateway. Your agents connect once; every tool call is authenticated, policy-checked, and logged, fail-open, to an audit log you own.

OneDroid

Governed MCP gateway

# OneDroid Synapse

One connection point for all your AI tools.

OneDroid Argus installs Synapse. You can also run it on its own.

Connect the accounts you choose — Google Workspace, Atlassian, Slack — and
your agents connect once. Every tool call is authenticated, policy-checked,
and logged, fail-open, to an audit log you own.

Open Synapse
See how it works

Free for individuals and small teams. No credit card.

agents  →  onedroid synapse  →  tools

event log
illustrative

About this app

## What OneDroid Synapse does.

OneDroid Synapse is a gateway between AI agents and your accounts. You connect
the services you choose — Google Workspace, Atlassian, Slack, and others — and
agents you authorize can then act on them through one governed connection:
sending an email you asked for, adding a calendar event, editing a document,
updating a ticket. Access exists only for accounts you explicitly connect, is
limited to the permissions you grant, and every action is logged, fail-open, to an
audit log you own. Disconnect an account at any time and OneDroid Synapse's access ends with it.

When you connect a Google account, OneDroid Synapse uses your Google user data solely to
carry out the actions you or your authorized agents explicitly request — such as
sending email you compose, managing your calendar, and creating or editing
documents, spreadsheets, and presentations. Your data is never used for
advertising and never used to train AI models, and access can be revoked at any
time in OneDroid Synapse or in your Google account settings. Full details:
Privacy Policy · Terms of Service.

“How do I control what people connect their agents to?
What data does it send? Is it compliant?”

— every platform and security lead, eventually

Agents are being wired to production databases, SaaS accounts, and internal APIs today —
one config file at a time, invisible to the people responsible for the answer.
OneDroid Synapse replaces scattered, unaccountable connections with a single gateway
that your team can see, scope, and prove.

How it works

## Connect. Govern. Prove.

01

### Connect

Agents point at one MCP URL instead of dozens of servers. Claude Code, Cursor,
the Agent SDKs — anything that speaks MCP connects without custom integration.

`"synapse": {
"url": "https://synapse.onedroid.ai/hub/work/mcp"
}`

02

### Govern

Admins decide which tools each hub, role, and agent can reach — as curated
packs, not one-off allowlists. Users connect their own credentials once;
agents never handle raw tokens.

03

### Prove

Every call is logged, fail-open (a logging failure never blocks a call): who, which tool, when, from which agent. When someone
asks what your agents did last quarter, the answer is a query, not an
investigation.

Capabilities

## Governance without slowing anyone down.

### One URL for every agent

MCP-native gateway in front of all your tool servers. Add or swap upstreams
without touching a single agent config.

### Packs

Curated toolsets with the context to use them safely — tools, skills, and
knowledge shipped together, versioned, and scoped per hub.

### Credential custody

People connect accounts once through OneDroid Synapse. Agents invoke tools under those
grants without ever seeing the underlying tokens.

### Audit log

An append-only event log of every tool invocation — caller, tool, arguments hash,
latency, result class. Yours to query, export, and keep.

### Hubs and roles

Separate workspaces for teams and projects, each with its own tool surface,
members, and defaults. Access follows the org chart, not tribal knowledge.

### Context that persists

OneDroid Engram ships with OneDroid Synapse — durable, versioned context every
agent can read and write, searched by meaning and keyword together. Change harness
or model and the context stays where it is.

Why this matters

## When a frontier model is just an
API call away, context is the moat.

Your competitors buy the same models, on the same terms, with the same API key.
The model is a brain in a jar — swappable, and getting cheaper. What it knows
about your business is not.

That knowledge is context: access to your data, access to your
tools, and memory that persists between sessions and survives a change of model.
OneDroid is where those three live, governed — so your team spends its time on
the context instead of the plumbing.

The plumbing isn't the hard part. The plumbing that passes review is.

Bring your own database

## Your data lives in your database.

OneDroid Synapse and OneDroid Engram run bring-your-own-database: point them at your Postgres and
every credential grant, event log entry, and document is a row in infrastructure
you control. The same model whether you're a single developer or a Fortune 500.

### Data governance

Your database, your jurisdiction, your retention policy. Governance data
never has to leave your infrastructure.

### No lock-in

Export is a SQL query — the data was never ours to hold. Leave whenever
you want and take everything with you.

### Any scale

A free personal hub and a regulated enterprise deployment use the same
mechanism. Nothing to re-architect as you grow.

The OneDroid suite

## Synapse is the run layer. There's more around it.

-

### OneDroid Synapse

Governed MCP gateway. One connection point, full governance.

Production

-

### OneDroid Engram

Portable, persistent, permissioned context for every AI application —
versioned, searchable by any MCP client, stored in your own database.

Available with OneDroid Synapse
Learn more

-

### OneDroid Argus

Automated end-to-end testing for software built by AI coding agents — withheld
acceptance scenarios, a verdict, and evidence anyone can replay.

Sign up to evaluate
Learn more

-

### The kits

Skills, patterns, and verification gates for autonomous, evidence-gated
software delivery. Free and open — we help enterprises adopt it.

Open source
Learn more

-

### Enterprise

Fully govern your AI agent and MCP infrastructure, on your infrastructure.

Active
Learn more

Why OneDroid

## AI governance, data, and tools
that belong to you.

### Ownership

State, credentials, audit records, and configuration live where you deploy
them. Nothing is held hostage on someone else's servers.

### Portability

Works with any LLM, any MCP client, any infrastructure. Switch providers
without losing your tools, policies, or history.

### Honesty

We publish limitations alongside capabilities and say what doesn't work yet.
If a claim can't be verified, we don't make it.

The actual product

## Not a mockup.

The animation further up this page is illustrative and labelled as such. These are
screenshots of OneDroid Synapse itself.

Governance, as switches. PHI detection, credential encryption,
an append-only audit trail, 6–7 year compliance retention, rate limiting, IP
allowlisting. The padlocked rows are forced on by a platform-wide override and
cannot be turned off for an individual hub — which is the difference
between a policy and a suggestion.

Connections. Every upstream the hub can reach, each with its
transport, its auth method and an independent on/off toggle. Note "My credential"
on each one: enabling a connection for the hub does not hand anybody else your
token.

Hub dashboard. Members, groups, connections and API tokens for a
single hub. The hub is the boundary access is granted at — rather than a config
file on somebody's laptop.

FAQ

## Questions people actually ask.

### What is OneDroid Synapse?

A governed MCP gateway. Your AI agents connect to one URL instead of holding their own credentials for each service, and every tool call is authenticated, checked against policy, and logged, fail-open, to an audit log you own. Longer explanation.

### Is OneDroid Synapse free?

Yes, for individuals and small teams, including the event log, which is not a paid tier. Enterprise is an annual licence and begins when you need deployment on your own infrastructure, org-wide policy enforcement, SSO, or audit evidence packs for compliance reviews. Pricing.

### Does OneDroid Synapse work with Claude Code and Cursor?

Yes. OneDroid Synapse speaks MCP over HTTP, so any MCP-compatible client works, with any model provider. Connecting Claude Code takes a single claude mcp add command with a bearer token. See the quickstart.

### Where does my data live with OneDroid?

You choose. Point OneDroid Engram at a Postgres you own and documents, embeddings, revision history and permissions are rows in your database. Self-host OneDroid Synapse and credentials and the event log stay inside your own boundary as well. Details.

### What can OneDroid see?

It depends on the deployment topology. Hosted: tool-call metadata and encrypted credentials. Hosted with your own database: the same, minus your OneDroid Engram content. Self-hosted: nothing at runtime. Security & deployment.

### Do I have to use your database?

No. Bring-your-own is supported precisely so leaving is cheap: the data was already in your Postgres, so there is nothing to export.

## Put a gateway between your agents and the world.

Open Synapse
Talk to us

Free for individuals and small teams. For anything larger, 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.


============================================================================

# PAGE: https://onedroid.ai/what-is-a-governed-mcp-gateway
Title: What is a Governed MCP Gateway? — OneDroid
Description: What an MCP gateway is, what makes one governed, and how it compares to per-agent config files. Plain explanation of tool-level access control, credential custody, and audit logging for AI agents.

OneDroid Synapse

Explainer

# What is a governed
MCP gateway?

A plain answer, including where the idea does not earn its keep. If you are
deciding whether you need one, the last two sections matter most.

## First: what is an MCP gateway?

The Model Context Protocol (MCP) is how AI agents call tools — reading a document,
updating a ticket, querying a database. By default, each agent is configured
individually: a file on someone's laptop listing which services it can reach, with
the credentials for each.

An MCP gateway replaces that with one server in the middle. Agents
connect to a single URL. The gateway holds the connections to the upstream services
and routes each tool call to the right one. From the agent's side, everything is
reachable through one endpoint; from the organisation's side, there is one place
where all of it is visible.

## What makes it governed?

Routing alone is plumbing. A gateway becomes governed when it
enforces policy rather than only forwarding traffic — and that comes down to three
capabilities.

### Tool-level access control

Not "this agent can use Jira", but "this agent can read an issue and comment
on it, and cannot delete one". The unit of permission is the tool, because that
is the unit of damage.

### Credential custody

Agents never hold long-lived upstream credentials. The gateway holds them and
presents them per call. Revocation is one action in one place, rather than a hunt
through every machine that might have a copy.

### An audit log

Append-only, recording every tool call: which agent, which tool, when, and
whether it was allowed. Without this, "what did the agent touch?" has no answer
— only reconstruction.

The common thread is that the policy does not depend on the agent choosing
to comply. An instruction in a prompt is advice. A gateway that refuses
the call is a control. That distinction is the whole point, and it is why
"we told the agent not to" is not a governance story.

## Gateway vs per-agent config files

Config files are the default because they are the fastest thing that works. Here is
what changes when you outgrow them.

### Granting access

Config files: per person, per machine, by hand.

Gateway: once, at a team boundary, with a role.

### Revoking access

Config files: find every copy of the credential. You will
miss one.

Gateway: revoke centrally; every agent loses it at once.

### Answering "what did it do?"

Config files: reconstruct from upstream logs, if the upstream
kept any.

Gateway: query the event log.

### Adding a service

Config files: every developer repeats the setup.

Gateway: connect once; everyone with the role has it.

### Latency

Config files: direct call.

Gateway: one extra hop. This one genuinely favours config files.

### Failure blast radius

Config files: one agent breaks.

Gateway: it is shared infrastructure — if it is down, everything
behind it is unreachable. Also favours config files.

## When you do not need one

A gateway is infrastructure, and infrastructure you do not need is a cost with no
return. Config files are the right answer when:

### You are one person

One developer, one agent, credentials only you hold, nobody to answer to.
The problems above are all coordination problems, and you have no coordination.

### Nothing it touches matters

If the agent reads public data and writes to a scratch repo, the audit log has
nothing to prove and access control has nothing to protect.

### You need the last millisecond

A latency-critical path is a legitimate reason to connect directly. Nothing
stops you doing that for one path and using a gateway for the rest.

The moment it flips is usually not a decision — it is a question. Someone asks
which systems the agents can reach, or what one of them did, and the honest answer
is "I would have to go and look". That question is the signal.

## Choosing between gateways

If you have decided you want one, these are the dimensions worth comparing —
including on us.

### Permission granularity

Per integration, or per tool? Per-integration means granting "Slack" when you
meant "post to one channel".

### Where credentials live

Who can decrypt them, and can you self-host so the answer is "only us"?

### Whether the audit log is a product tier

An audit log you have to upgrade to get is an audit log you will not have
during the incident that needed it.

### Where your data sits

Can it live in a database you own, or only in the vendor's? This decides what
leaving costs.

### Client compatibility

Does it work with any MCP client and any model provider, or does it assume
one vendor's stack?

### Exit cost

If you stop paying, what do you keep? Ask this before you start, not after.

For the record, OneDroid Synapse answers these as: per tool; self-hostable so we
can see nothing; the event log is in the free tier and will not be gated; your data
can live in your own Postgres; any MCP client and any provider; and if you leave,
the data was already in your database.
The security page states the same in detail, including what
we have not done.

## Try it against your own setup.

Open Synapse
Read the quickstart

Free for individuals and small teams. No credit card. Connecting an agent takes one
command.


============================================================================

# PAGE: https://onedroid.ai/quickstart
Title: Quickstart — OneDroid Synapse, Engram and the kits in ten minutes
Description: Three things to try today: connect an agent to OneDroid Synapse, give it memory with OneDroid Engram, and run the open-source Dark Factory kits. Each ends with a check you can run yourself. Free for individuals and small teams.

OneDroid

Quickstart

# Three things to try today.

Connect an agent to one governed endpoint. Give it memory that outlives the session.
Run the open-source method the agent works under. Each takes about ten minutes, needs
no credit card, and ends with a check you run yourself, so you never have to take
our word for it.

1 · OneDroid Synapse

## Connect an agent to one governed URL.

Synapse is a gateway between your agents and your accounts. Your agent connects once;
every tool call is authenticated, policy-checked and logged, fail-open, to an audit log you own.
Free for individuals and small teams.

01

### Create a hub

Sign in at synapse.onedroid.ai with
Google or an email code. Choose where your data lives — OneDroid Managed, or your
own Postgres — and name the hub. It is yours; nobody provisions it for you.

02

### Create a token

In the hub, go to Manage → API Tokens → Create token. A token
is bound to this hub and to you, and the plaintext is shown once, so copy it before
you close the dialog.

03

### Connect Claude Code

One command, one header. Then `claude mcp list` should show
`synapse … ✓ Connected`.

`claude mcp add --transport http synapse \
https://synapse.onedroid.ai/agent/mcp \
--header "Authorization: Bearer <token>"`

### Not in a terminal?

Claude Desktop and claude.ai connect through a consent screen instead of a token.
In the app, Settings → Connectors, add a custom connector with
`https://synapse.onedroid.ai/hub/<your-slug>/mcp`. Your hub's
AI Clients page prints the exact URL for you.
The browser route.

### The step that catches everyone

Enabling a service on your hub and saving your login for it are two
different actions, and only the second lets an agent call anything. If the agent
connects and then sees no tools, this is why.
Connections and credentials.

### The check

Run this before you wire anything else. A good token returns HTTP 200 with a
JSON-RPC result; a wrong one returns `401 invalid_token`; a missing
header returns `401 missing_token`. Three different answers, so you
always know which half is wrong.

`curl -s https://synapse.onedroid.ai/agent/mcp \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize",
"params":{"protocolVersion":"2025-06-18",
"capabilities":{},
"clientInfo":{"name":"probe","version":"1.0"}}}'`

Watch it done: the Synapse walkthrough, recorded against the live service, at
youtu.be/WJvsBV4sXFU.

Full walkthrough with screenshots:
Set up your hub →
Connect Claude Code →
Connections and credentials.
Every call on those pages was run against the live service.

2 · OneDroid Engram

## Give your agents memory that outlives the session.

Engram is versioned, permissioned context in a Postgres you control, searched by
vector, keyword and graph at once, and reachable by any MCP client behind any model.
It is included with a Synapse account and runs on its own.

01

### Get a library token

Sign in at engram.onedroid.ai, open
API Tokens, and create a library token. It reaches
one library and nothing else, which is the right default for an agent, a teammate
or a pipeline.

02

### Point a client at it

Any MCP client that speaks streamable HTTP and can send a header. Or reach it
through your Synapse hub, where the Engram connection is already on and every call
is audited with the rest of your tools.

`https://engram.onedroid.ai/mcp
Authorization: Bearer <engram_token>`

03

### Write one thing, search it back

Ask your agent to write a note into a namespace with `engram_write`,
then find it with `engram_search`. The write returns an object id; the
search returns that object. That round trip is the whole idea: what one agent
wrote, the next one can find.

### The check

Send the same `initialize` probe as above to
`https://engram.onedroid.ai/mcp` with your Engram token. A good token
gets HTTP 200 and a server named `engram`; no token, a wrong one or a
revoked one gets HTTP 401 with a plain-text `Unauthorized`.

### Your own database

Point Engram at your own Postgres and documents, chunks, embeddings and history
are rows there, readable with SQL. It needs the pgvector extension, which Engram
enables at registration; Postgres 16 is what we test against.

### Every write is a commit

Objects carry revision history. Diff any two versions, restore a previous one in
one call. An agent that overwrote something important is a one-call fix, not a
loss.

Watch it done: the Engram walkthrough, recorded against the live service, at
youtu.be/1o5mPIGCngk.

The full path, with every call and response shown:
Using Engram. Prefer a browser?
The Engram web app does most of
it by hand.

3 · The Dark Factory kits

## Run your agent under a method you can audit.

The kits are the method OneDroid Argus enforces, written down as skills, hooks and
gates any capable agent harness can run. Open source, Apache-2.0, no paid tier.
Agents do the work; evidence, not self-reports, decides what ships.

01

### Clone and list the kits

The repository is
github.com/OneDro1d/dark-factory
(public, Apache-2.0). Seven kits today: `method-core` (the method itself),
`dev`, `knowledge-worker`, `agent-ops`,
`code-review`, `distributed-systems`,
`frontend`.

`git clone https://github.com/OneDro1d/dark-factory
cd dark-factory
bash starter-kit/instance/bootstrap.sh --kit list`

02

### Make your own copy

The bootstrap writes a new directory beside the checkout, pinned to the method
at today's commit. Open Claude Code there and tell it:
"Read START-HERE.md and execute it." It installs the skills, hooks and
gates, and stops only where a human decision is needed.

`bash starter-kit/instance/bootstrap.sh my-agent --kit dev
cd ../my-agent`

03

### No skill system? One page

For ChatGPT, Gemini or a plain API model, paste
DARK-FACTORY-PRIMING.md
into the conversation. It inlines the whole method — every stage skill and the
adversary gate — so the agent needs nothing else.

### The check

The runbook ends with a validation run that commits its own report into your
copy. If the report is not in the repo, the setup is not done, whatever the agent
says. That rule is the method in one sentence.

### What you get

Stage skills for product owner, architect, test-first developer and QA; an
adversary gate that checks evidence without redoing the work; dispatch patterns for
parallel sub-agents; an autonomy policy for what stops for a human.

### Where it leads

The kits are what the gate checks against. OneDroid Argus
is the gate: acceptance scenarios the agent never saw, run against the exact build,
with a verdict you can replay. Independent testing now costs about what the coding
costs: the experiment.

Watch it done: the kits walkthrough, recorded on these pages with a synthesized narration, at
youtu.be/KcbsT7jARFc.

Read the method first if you like: the kits page and
the repository.

## Something did not work?

Troubleshooting
michal@onedroid.ai

The troubleshooting page covers the failures people actually hit, with the one probe
that tells them apart. The address reaches the people who build the product.


============================================================================

# PAGE: https://onedroid.ai/security
Title: Security & Deployment — OneDroid Synapse
Description: How OneDroid Synapse is deployed, what it can and cannot see, how credentials are held, and an honest statement of our current compliance posture.

OneDroid

Security & deployment

# What we can see,
and what we can't.

Written for the person who has to sign off on this. It states the deployment
options, where credentials live, what OneDroid can observe in each model, and
what we have not yet done. Send it to your security reviewer.

OneDroid Argus

## Where the verifier runs, and where it never does.

OneDroid Argus exercises a running system, so it is worth being
exact about which one, and on whose terms. It does not decide what its tests may do:
the tester and the system's owner do, the configuration records it, and OneDroid Argus enforces
what the configuration declares. A scheduled monitor can watch a live
system. For an app that moves money, one switch makes OneDroid Argus refuse every write
the owner has not listed, with limits. A load ramp never targets a live broker. Checks read your
database in read-only transactions. OneDroid Argus writes to it only if a scenario
declares a cleanup block, and then only with the credential you give it. The runner executes inside
your own environment next to the system under test. Its source is open under MIT at
github.com/OneDro1d/argus-runner,
so what it does can be read rather than taken on our word. What leaves your boundary
is the evidence the control plane needs to adjudicate a verdict, not your data. The
control plane signs and anchors what the runner reports; it does not re-run the checks.
So a certificate proves what the runner reported and when, not that the runner was
unmodified.

Deployment topologies

## Three shapes, decreasing exposure.

### Hosted

OneDroid Synapse runs on OneDroid infrastructure. Fastest to start. We operate the
gateway, hold encrypted credentials, and can see tool-call metadata.

### Hosted + your database

The gateway is ours; OneDroid Engram's data lives in a Postgres you own and control.
Documents, embeddings, history and permissions never leave your database.

### Self-hosted (enterprise)

OneDroid Synapse runs on your infrastructure, cloud or on-premises. Credentials and
the event log stay inside your boundary. We can see nothing at runtime.

Data visibility

## What OneDroid can see, per model.

This is the question every security review asks, so here it is directly rather
than implied.

### Hosted

Tool-call metadata — which agent called which tool, on which connection,
when, and whether it was allowed. Credentials are held encrypted so the gateway
can present them upstream. Tool payloads pass through the gateway in
order to be routed.

### Bring-your-own database

Everything above, minus your OneDroid Engram content: documents, chunks, embeddings,
revision history and permissions are rows in your Postgres. You can read them
with SQL and back them up with your own tooling.

### Self-hosted

Nothing at runtime. No telemetry path back to us by default. Support is
whatever you choose to send us.

Access control

## Tool-level access control, and an audit log.

AI agent governance means two things: control over what your agents can reach,
and an audit log of what they did. OneDroid Synapse enforces both at the gateway, so the
policy does not depend on each agent choosing to comply.

### Per-tool toggles

Grant or deny individual tools on a connection, not just whole integrations.
An agent that should read a board but never delete one is expressible.

### Credential custody

Agents never hold long-lived upstream credentials. The gateway holds them
and presents them per call, so revocation is one place, not many.

### Append-only audit log

Every tool call is written to an event log you can query and export (fail-open: a logging failure never blocks a call). The log and its CSV export are
included in the free tier and will not be put behind a paywall; Enterprise adds audit evidence packs for compliance reviews.

### Hubs and roles

Connections are grouped into hubs with role-based membership, so access is
granted to a team boundary rather than pasted into a config file.

Authentication

## Standards, not a bespoke scheme.

OneDroid Synapse implements OAuth 2.0 authorization-server discovery at
`/.well-known/oauth-authorization-server`, dynamic client registration,
and the device authorization flow — so MCP clients can authenticate without
anyone pasting a long-lived token into a config file.

The OneDroid application has completed Google's OAuth application verification,
including its branding and app-purpose review, for the Google Workspace
connections it offers.

Single sign-on. User identity is handled by
Clerk, so OneDroid Synapse inherits its enterprise SSO
support: SAML 2.0 and OIDC against your own identity provider,
including Microsoft Entra ID, Okta and Google Workspace. Enterprise deployments
have been integrated with customer-managed identity providers, including
organisations running an internal IdP alongside Entra.

We name our identity provider deliberately. You are entitled to know which
subprocessors sit in your authentication path before you put staff accounts
through them, and a security page that hides that is not one you should trust. If
your IdP is an unusual one,
tell us which
and we will confirm it against Clerk's supported list rather than guess.

Compliance posture

## Where we actually are.

We would rather lose a deal than pass a security review on an implication.

### What is true

Credentials are encrypted at rest. Transport is TLS. The event log is
append-only and exportable. Self-hosted deployment removes us from the data
path entirely. Google OAuth verification is complete.

### What is not yet true

We do not hold SOC 2, ISO 27001, or HIPAA attestation
today. If a certification is a hard requirement for you, say so early and we
will tell you honestly whether the timeline works, rather than discovering it
in month three.

### How to verify us

Our delivery method — including the gates, the enforcement hooks and the
failures that produced them — is
public under Apache-2.0.
You can read how we work before you trust it.

Reporting a vulnerability

## Tell us privately, first.

Email michal@onedroid.ai.
We reply within one business day, agree a disclosure timeline with you, and credit
you unless you would rather we didn't. Please don't open a public issue for
anything exploitable.

## Bring us your security review.

michal@onedroid.ai
Enterprise

You'll reach Michal Bacia — the team that builds the product, not a sales queue.
We reply within one business day.


============================================================================

# PAGE: https://onedroid.ai/engram
Title: OneDroid Engram — Versioned Agent Memory in Your Own Postgres | OneDroid
Description: OneDroid Engram is versioned knowledge and memory for AI agents. Several search engines combined for the best results, git-style history for every document — stored in a Postgres you control.

OneDroid

OneDroid Engram

# Portable, persistent context
for every AI application.

Engram is the memory layer OneDroid Argus installs. OneDroid Argus keeps the scenario
corpus here, so the evidence behind a verdict has a
history rather than just a timestamp — and Engram runs perfectly well on its own.
How OneDroid Argus uses it.

Models are interchangeable. Your context is not. OneDroid Engram is where an
organisation's durable knowledge lives — versioned, permissioned, searched by
several engines at once, and reachable by any MCP client behind any model.
Every document, embedding and revision is a row in a Postgres you control.

Open Synapse — OneDroid Engram is included
Open OneDroid Engram directly

One account covers both. Free for individuals and small teams. No credit card.

query  →  vector · keyword · graph  →  fused ranking, in your database

search log
illustrative

Why it matters

## When a frontier model is just an API call away,
context is the moat.

Your competitors buy the same models, on the same terms, with the same API key.
The model is a brain in a jar — swappable, and getting cheaper. What it knows
about your business is not, and it is the only part nobody else can buy.

Which makes it worth keeping. A model session ends and takes everything with it.
The next tool starts from nothing, so the same context gets re-pasted,
re-explained and re-discovered — by every agent, every time. OneDroid Engram is
the layer that stops that: write once, and every application you run can use it.

### Portable

Reachable by any MCP client, from any harness, behind any model. Context
written by one agent is available to the next — including the one you
haven't chosen yet. Changing model doesn't cost you what you knew.

### Persistent and versioned

Objects carry revision history, so you can see what an agent knew and
when it changed. Knowledge accumulates as an asset instead of evaporating
at the end of a session.

### Rich, not just a vector blob

Hybrid retrieval — semantic and keyword together — over a typed object
graph, so relationships like "supersedes" or "references" are explicit and
traversable rather than inferred from similarity.

### Permissioned and yours

Scoped by group and namespace, so context is shared deliberately rather
than pooled by accident — and all of it in a database you own.

Bring your own database

## Your knowledge was never ours to hold.

Point OneDroid Engram at your own Postgres and that's where everything lives: documents,
chunks, embeddings, history, permissions. Read it with SQL whenever you like.
Back it up with the tools you already trust. Leave, and the data simply stays
where it always was — with you. The same model serves a single developer's
notebook and a Fortune 500's regulated knowledge base.

Hybrid search

## Several engines, one answer.

### Vector

Semantic similarity over embeddings — finds what you mean, not just
what you typed.

### Keyword

BM25 full-text ranking — exact terms, names, and identifiers never
get lost in the vectors.

### Graph

Typed links between objects let search follow relationships —
neighbors, references, dependencies.

Results are fused into a single ranking, and the vector-versus-keyword weighting
is a parameter you control per query — not a black box.

Versioned

## Every write is a commit.

### History

Each object carries its full revision history — who wrote what, when,
with git-style commits underneath.

### Diff

Compare any two versions of a document and see exactly what changed
between them.

### Restore

Roll any object back to a previous version. Agent overwrote something
important? It's one call away.

## Your agents' memory, your database.

Open Synapse — OneDroid Engram is included
Pricing


============================================================================

# PAGE: https://onedroid.ai/financial-services
Title: OneDroid for Financial Services — Governed AI for Regulated Firms
Description: OneDroid Synapse and OneDroid Engram give AI teams at brokers, asset managers and capital-markets firms one integration, portable context, and the evidence that clears security and compliance review.

OneDroid

Financial services

# Your AI programme isn't
short of models.

It's short of a place to put them. OneDroid Synapse is one governed integration
point for every tool and data source your agents touch; OneDroid Engram is the
context that survives when the model changes. Built for AI teams at brokers,
asset managers, FCMs and capital-markets firms — and built to clear the
security, compliance and operations gates on the way through.

Talk to us
See OneDroid Engram

For the AI team

## When a frontier model is just an
API call away, context is the moat.

Every firm on the street buys the same models, on the same terms, with the same
API key. The model is a brain in a jar — swappable, and getting cheaper. What it
knows about your business is not, and that is the only part a competitor
cannot buy.

That knowledge is context: access to your data, access to your
tools, and memory that persists. What separates a team that ships from one that
demos is the layer underneath it — how many times you rebuild the same
integration, how much context you lose between tools, and how long each new use
case waits in review. That is the part OneDroid replaces.

### One integration, not one per agent

Connect your tools, systems and data to OneDroid Synapse once. Every agent
your team builds inherits the whole surface with a token — no new connector
work, no new credential handling, no new review for each one.

### Context that outlives the model

OneDroid Engram holds the firm's durable context — decisions, documents,
domain knowledge, prior work — versioned and permissioned. Agents read and
write the same store, so knowledge compounds instead of resetting.

### Change the model without a migration

The harness and the model are the swappable end. Move from one client or
provider to another, run two side by side, or test an open-source model —
the tools-and-context layer doesn't move.

### Evidence as a by-product

Every tool call is authenticated, policy-checked and logged, fail-open, to an
audit log you own. You don't assemble the compliance story afterwards; running the
platform produces it.

Then it clears the gates

## Most AI programmes don't fail on capability.
They stall in review.

In a regulated firm the blocker is rarely "can the model do it." It is the
security review, the supervision question and the operational one — and they
arrive after the work is built, which is why they hurt. Because OneDroid Synapse
sits in the call path from day one, the answers exist before anyone asks.

### Security

One place where "what can AI reach here?" is decided and recorded.
Credentials held per user, per hub. Sensitive data detected and redacted in
the request path rather than in a batch job afterwards.

### Supervision and records

Retention and supervisory obligations assume a record exists. AI use on
personal accounts produces none at all. This produces a tamper-evident one a
third party can check.

### Operations

Deployed in your own cloud, on your own Postgres. Export is a SQL query.
The same mechanism whether it's one team or the whole firm.

The order matters. Governance sold as the point is a tax nobody volunteers for.
Governance that arrives as a property of a platform your AI team actually wants
is how the programme gets unblocked — and how the security and compliance
functions get an answer they can act on.

Build or buy

## An MCP proxy is a weekend.
The one that passes review isn't.

Your architects could wire agents to your systems themselves, and they know it.
We'd rather say that plainly than pretend the integration is hard. The integration
isn't what takes two quarters — the review does. Here is what a security reviewer
asks, and what each answer costs to build.

### "Whose credentials is the agent using?"

Credentials bound per user, per workspace, per account — encrypted at rest with
AES-256-GCM, individually revocable, never sitting in a connection string. Not one
shared service account carrying everyone's access.

### "What can this agent reach, and who decided?"

Tool-level allow and deny policy, with the decision recorded at the moment it
was made — not reconstructed from logs afterwards, which is not the same thing and
a reviewer knows it.

### "How do I know the log wasn't edited?"

The expensive one. A hash chain, a Merkle tree, canonical serialisation, a
transactional outbox so writes can't be lost, a reconciler, a circuit breaker — and
an independent verifier, because a system attesting to itself proves
nothing.

### "What stops client data reaching the model?"

Detection in the request path, returning a redaction reference for audit — not a
nightly batch job that finds it after the fact. And tuned rather than naive: ours
excludes date patterns from free-text lanes, because specification documents are
full of dates.

### "Which third parties see this?"

A subprocessor list you are willing to publish, with an answer for embeddings.
Ours is on the privacy page, named rather than buried.

### "What happens when we leave?"

Your data is in your own Postgres. Export is a SQL query. There is nothing to
extract from us because we were never holding it.

Any one of those is a sprint. All of them, tested, and defensible in front of an
examiner, is two quarters of your platform team not building product.
That is the trade, stated honestly — not "you couldn't build this," but "you probably
shouldn't."

OneDroid Engram

## Portable, persistent context —
for every AI application you run.

Models are interchangeable. Your firm's context is not. OneDroid Engram is where
that context lives so it can be reused by everything: the coding agents, the
research assistants, the internal chat tool, the thing a team builds next quarter.

### Portable

Reachable by any MCP client, from any harness, behind any model. Context
written by one agent is available to the next one — including the one you
haven't chosen yet.

### Persistent and versioned

Objects carry revision history, so you can see what an agent knew and when
it changed. Knowledge accumulates as an asset instead of evaporating at the
end of a session.

### Rich, not just a vector blob

Hybrid retrieval — semantic and keyword together — over a typed object
graph, so relationships like "supersedes" or "references" are explicit and
traversable rather than guessed from similarity.

### Yours, and permissioned

Point it at a Postgres you own and documents, embeddings, history and
permissions are rows in your database. Access is scoped by group and
namespace, so context is shared deliberately.

This is the part that compounds. An audit trail is worth more the longer it
runs, and so is a context store — a firm starting today cannot buy back the
history yours has been accumulating.

How OneDroid Engram works

Evidence

## Proven where the audits are unforgiving.

The flagship deployment is a US enterprise handling regulated clinical data —
a different industry with the same shape: sensitive data, external auditors, and
customers who run their own security reviews. In two quarters it went from "can
we even use AI here" to a running, audited platform.

Stated plainly

## What we don't claim.

### Not "nothing leaves"

Model inference is an outbound call — for us and for everyone using
commercial AI. Your data comes to rest inside your boundary; the inference
call that transits is gated, scanned and logged. Anyone promising otherwise
hasn't read their own architecture.

### Not a safety guarantee

OneDroid Synapse transports, authorises and logs tool calls. It does not
vouch for an agent's judgement, and no product does. We sell visibility and
accountability, not guarantees.

### Not a financial-services logo yet

The flagship reference is in regulated healthcare. Being early is the
trade, and design partners get roadmap influence for it. We publish what we
can prove and nothing else.

## Start with one use case.

The fastest way in is a single workflow your AI team already wants to ship —
governed end to end, with the evidence trail from the first call.

michal@onedroid.ai


============================================================================

# PAGE: https://onedroid.ai/qa-teams
Title: OneDroid Argus for QA Teams — End-to-End Testing for AI-Written Code
Description: When developers build with a coding agent, QA owns the checks the agent can't see. OneDroid Argus is automated end-to-end testing for AI-written code: plain scenarios written from the ticket before the build, unseen by the coding agent, run on the deployed system, under load and on a schedule.

OneDroid Argus

For QA teams

# The AI writes the code.
QA owns the checks it can't see.

When your developers build with a coding agent, the agent often writes the feature
and the tests that judge it, from the same reading of the ticket. OneDroid Argus is
automated end-to-end testing for AI-written code: you write plain scenarios from the
ticket before the build, the coding agent never sees them, and they run against the
deployed system, under load and on a schedule too.

Talk to us
How OneDroid Argus works

What changes for QA

## Green tests from the builder
aren't a verdict.

A coding agent that writes both the code and its tests can be wrong twice in the
same way: if it misreads the ticket, the tests it writes agree with the mistake.
A model that can see its checker learns to satisfy the checker. The answer is not
fewer testers. It is a tester who is not the builder, working from the ticket, with
checks the builder cannot read.

### You get the ticket before the build

The tester writes each check from the ticket and the acceptance criteria,
before the build starts. "What should happen" is decided before any code exists
to argue with it.

### Plain scenarios, not test scripts

Each check says what to trigger, where to look and what a healthy answer is.
No test scripts to write and keep alive, and nobody clicking through the app
before each release. The scenarios stay as regression checks for the next change.

### The agent can't edit what judges it

The builder's credential can ask for a run and read the verdict, and cannot
read a scenario or an expected value. During the build it learns only which
checks failed and what was observed, never what was expected.

### On the running system, nothing mocked

HTTP, the message broker, the database, web pages in a real browser,
permissions and rate limits. OneDroid Argus does not judge the diff; it exercises
the system and reports what happened.

One feature, start to finish

## Where QA's work sits
when an agent builds.

### 1. Write

You (or an agent that is not the builder) write the scenario set from the
ticket, the acceptance criteria and the shape of the system. An agent skill can
turn a plain description of what should happen into valid scenarios.

### 2. Seal

You seal the set. Its hash goes on a cryptographic ledger before the work is
judged, so anyone can check that the scenarios existed first and never changed.

### 3. Build

The developers' coding agent builds and asks for runs. The runner reports
failing check ids and observed reality, so the agent can fix things, and never
the expectation.

### 4. Judge

The final run happens once, against a pinned build. Every scenario ends as
passed, failed, errored or not_applicable, and neither an error nor not_applicable is ever a pass, so a run cannot go green
because nothing ran.

### 5. Keep

The same checks run under load and on a monitor schedule, every 15 minutes at
the shortest. A system no monitor has measured reads "not measured", never green.

### 6. Show

The verdict binds to one build and comes with a certificate anyone can check
with the open CLI, with no OneDroid account and no contact with OneDroid. When you reveal the set, any scenario can be replayed against the same
build, by you, your auditor or anyone.

What stays yours

## Deciding what "correct" means
is the job that doesn't get automated.

OneDroid Argus runs the checks, keeps them out of the builder's reach and keeps the
record. The judgement around them stays with QA.

### Which checks matter

Which scenarios a feature needs, and what a healthy answer is for each,
come from the person who read the ticket for what it meant.

### Which reds you keep

A set goes on a schedule once a hand-run is green, or every red in it is one
you have read and decided to keep. What the system can't fix by itself is listed
under "Needs a person", with who acts next.

### What may differ

When one sealed set runs against two systems or two releases, what may differ
is declared before the run, with a tolerance for numbers, and a difference a person
accepts is pinned to the outputs they were shown.

Faster and cheaper than end-to-end testing by hand: the scenarios are written once per
feature, before the build, and run as often as you need.
One measured experiment, its figures and its limits.

Stated plainly

## What we don't claim.

### Not "no QA needed"

Somebody who is not the builder still has to decide what the software should
do. OneDroid Argus makes that decision the one the coding agent cannot see or
change. It doesn't make it for you.

### Not proof of no bugs

No test proves code free of bugs. Different testers catch different things,
and a model can give a different answer on each run. What stays fixed is the
record: sealed before the build, run against the build you pinned, replayable.

### Not load on a web page

Stepped load ramps exist for message brokers and for one HTTP target at a
time, and none drives a web page in a browser. Browser checks run as functional
end-to-end scenarios.

The full list, including what the ledger proves and what it does not, is on the
OneDroid Argus page. The steps to set it up are in the
OneDroid Argus docs.

## Bring one feature.

Pick a ticket your developers are about to hand to a coding agent. Write the
scenarios from it before the build, and see what the agent's own green tests missed.
The runner is open source under MIT; the hosted control plane has an evaluation environment anyone can sign up for at argus-dev.onedroid.ai, and an environment of your own is by request.

michal@onedroid.ai


============================================================================

# PAGE: https://onedroid.ai/dark-factory
Title: Dark Factory Kits — The Method Behind the Gate | OneDroid
Description: Open skills, patterns and verification gates for governed, test-first, evidence-gated development with AI agents — the written method OneDroid Argus enforces.

OneDroid

Dark Factory Toolkit

# Autonomous delivery
you can audit.

The kits are the method OneDroid Argus enforces. OneDroid Argus is the gate;
this is what the gate is checking against, written down and free to read before you
talk to anyone. How OneDroid Argus applies it.

Skills, patterns, and verification gates for running governed development loops
with AI agents — mission in, verified software out. Agents do the work;
evidence, not self-reports, decides what ships.

Read the method on GitHub
Help me implement this

Everything here is open source under Apache-2.0 — the method, the skills, the
enforcement hooks. There is no paid tier and nothing is held back. What we sell is
help making it work inside your organisation.

mission → design → build → verify → ship

evidence log
illustrative

The principle

## Trust evidence, not agents.

An agent reporting "done, all tests passing" is a claim, not a fact. In a dark
factory loop, every hand-off carries the evidence to prove it — test output,
diffs, exit codes — and an independent verifier tries to refute it before the
work moves forward. Work that fails the gate goes back. Nothing ships on
someone's word, including the machine's.

What's in the toolkit

## The loop, as reusable parts.

### Stage skills

Product owner, architect, test-first developer, QA — each stage of the
loop as a skill any capable agent harness can run.

### Verification gates

Adversarial review patterns that check the evidence for each claim —
the gate validates proof, never redoes the work.

### Test-first discipline

Acceptance criteria become a failing test list before code is written.
Green means done; the tests never get weakened to pass.

### Dispatch patterns

Fan work out to parallel sub-agents as explicit promises with defined
evidence, and verify what comes back.

### Autonomy policy

A simple decision model for what agents decide alone, what they log,
and what always stops for a human.

### Harness-agnostic

Works with any agent runtime that can follow instructions and run
commands — no proprietary orchestrator required.

## Take the tools. The hard part is adoption.

Read it, disagree with it, take it — you owe us nothing for any of it. But a method
is not a delivery capability. Getting this running against real repositories, real
pipelines and a real compliance posture is where the work is, and it is the part we
do for a living. If that is the problem you have, tell us what you're building.

Help me implement this
The method, open source

We reply within one business day. If your mail client doesn't open, the address is
michal@onedroid.ai.


============================================================================

# PAGE: https://onedroid.ai/enterprise
Title: AI Agent Governance — OneDroid Argus, Synapse and Engram on Your Infrastructure
Description: Control over what your AI agents can reach, proof of what they did, and a verdict on what they built. Dedicated deployment on your own infrastructure.

OneDroid

OneDroid Enterprise

# Fully govern your AI agent
and MCP infrastructure.

We sell one thing: control over what your agents can reach, proof of what they did,
and a verdict on what they built. If that's the problem keeping your security review
busy, this is the product.

Talk to us
Security & deployment

Or write to michal@onedroid.ai.
You'll reach Michal Bacia — the team that builds the product, not a sales queue.
We reply within one business day.

“How do I control what people connect their agents to?
What data does it send? Is it compliant? Is it safe?”

— the question every security review ends on

Your teams are already wiring agents to production systems — with personal
API keys, in config files nobody reviews. Banning it doesn't work; the demand
is real. Enterprise gives you the alternative: one governed path that's easier
to use than the shadow one, with the control and evidence you're accountable for.

What you get

## AI agent governance means two things: control over what your agents can reach,
and an audit log of what they did

### Your infrastructure

Dedicated deployment in your cloud or on-premises, under license.
Governance data never leaves your perimeter.

### Policy enforcement

Decide which tools each hub, role, and agent can reach. Deny rules,
tool grants, and data filters enforced at the gateway — not in a wiki.

### Audit log

An append-only audit log of tool calls (logged fail-open, so logging never blocks a call): who, what, when, outcome.
Exportable, queryable, and yours — built for the auditor's question.

### Credential custody

People connect accounts once; agents act under scoped grants and never
hold raw tokens. Offboarding is revoking a grant, not rotating the world.

### Your database

Bring your own database for all governance state — your jurisdiction,
your retention, your backup discipline.

### PII and PHI screening

Sensitive-data detection and redaction at the gateway for regulated
workloads — built for industries where this is not optional.

How engagements start

## Small, concrete, and on your terms.

01

### Map the exposure

We inventory what your agents already touch — the connections that exist
today, sanctioned or not.

02

### Deploy the gateway

OneDroid Synapse and OneDroid Engram land on your infrastructure with your policies,
your identity provider, and your database.

03

### Move the traffic

Teams switch to the governed path because it's genuinely easier —
and your audit log starts answering questions.

The box

## OneDroid Argus, Synapse and Engram, on your infrastructure.

Enterprise is the whole stack inside your perimeter: OneDroid Argus
verifying what your agents built, OneDroid Synapse governing what
they can reach, OneDroid Engram holding what they know, and
the kits describing the method the gate enforces. Cloud or
on-premises, under licence, with your identity provider and your database.

### One primitive: the evidence record

The three products are held together by one thing. Synapse's audit entry, Engram's
versioned fact and OneDroid Argus's verdict are the same object — a promise plus the evidence for
it, bound to a moment and to an actor, append-only, and exportable as a record rather
than a screenshot. That is what makes the stack answerable rather than merely observable.
A verdict in that record is never a score: each scenario is passed, failed or
errored, and an error is never a pass.

Where the law names the pieces they line up: EU AI Act Art. 12 (automatic recording of
events over the lifetime of the system) and Art. 14 (human oversight)
for high-risk AI products; DORA Art. 25 and Art. 30; HIPAA 164.312(b);
FDA 21 CFR 11.10(e). Using a coding agent does not by itself make your system high-risk,
and we will not tell you otherwise. Regulated-sector detail:
financial services.

## Bring us your security review.

michal@onedroid.ai
See the deployment architecture

We reply within one business day. If your mail client doesn't open, the address is
michal@onedroid.ai.


============================================================================

# PAGE: https://onedroid.ai/pricing
Title: OneDroid Pricing — Free Runner, Free Gateway, Enterprise Licence
Description: The OneDroid Argus runner is free. Synapse and Engram are free for individuals and small teams. Enterprise deployments on your infrastructure: talk to us.

OneDroid

Pricing

# Free to use.
Enterprise when you need it.

The OneDroid Argus runner is free. Individuals and small teams get
Synapse and Engram for free too. Enterprises get the same products delivered
enterprise-grade — dedicated, on their own infrastructure, with org-wide governance.

OneDroid Argus

## The runner is free. The control plane is the product.

### The OneDroid Argus runner

Free

open source · MIT

- Runs inside your own environment, next to the system under test

- Executes any revealed scenario, so anyone who runs it can replay a verdict

- Open source under MIT, because it touches your data plane

- No fee, no seat count, no expiry

The source on GitHub

### The OneDroid Argus control plane

Talk to us

evaluate free at argus-dev; your own environment by request

- Seals the scenario set your tester wrote and keeps it from the builder

- Seals it and anchors the hash before the build starts

- Adjudicates the final run against a pinned artefact

- Publishes the reveal: trigger, expectation, evidence, verdict

Talk to us

Why this split. The runner executes inside your environment and touches
your data plane, so its source is open under MIT. Your tester writes the scenarios with our open skill; the control plane that seals the set
and adjudicates the verdict is hosted and closed. The holdout is provably prior, and every scenario is replayable with
the runner in your own environment.
How that works.

## Two ways to run it.

### Individuals & small teams

Free

hosted at synapse.onedroid.ai

- OneDroid Synapse governed MCP gateway — one URL for all your agents

- OneDroid Engram versioned knowledge and memory

- Bring your own database — your data stays yours

- Hubs, roles, and packs for your team

- Event log and its CSV export included — never behind a paywall

Open Synapse

### Enterprise

Talk to us

dedicated deployment, under license

- Everything in the free tier

- Deployed on your infrastructure — cloud or on-premises

- Org-wide policy enforcement: deny rules, grants, data filters

- PII / PHI screening for regulated workloads

- Audit evidence packs for compliance reviews

- Implementation support from the team that builds it

michal@onedroid.ai

Annual licence. Typical deployments start in five figures — email for a
concrete number against your actual shape.

Where the free tier ends. Free covers individuals and small teams
using OneDroid's hosted OneDroid Synapse and OneDroid Engram, including the event log. Enterprise
begins when you need it on your own infrastructure, org-wide policy enforcement,
SSO, or audit evidence packs for a compliance review. There is no seat count
that trips you over — it's a difference in what you're deploying, not how many of
you there are.

The free tier is genuinely free while we build in the open. If usage limits
ever arrive, they'll be published here first — and the event log will never
be gated.

FAQ

## Questions about the price.

### Is OneDroid Synapse free?

Yes for individuals and small teams, including the event log. The free tier covers OneDroid-hosted OneDroid Synapse and OneDroid Engram.

### Where does the free tier end?

The boundary is deployment shape, not seat count. Enterprise begins when you need OneDroid Synapse on your own infrastructure, org-wide policy enforcement, SSO, or audit evidence packs for a compliance review.

### How much does OneDroid Enterprise cost?

It is an annual licence. Typical deployments start in five figures; contact OneDroid for a concrete number against your deployment shape.

### What does OneDroid Argus cost?

The OneDroid Argus runner is free to run in your own environment, and its source is open under MIT (github.com/OneDro1d/argus-runner). The hosted control plane that seals the withheld scenarios and adjudicates the verdict is the priced part. Anyone can sign up at argus-dev.onedroid.ai to evaluate it (a test environment, with no promise that data is kept); an environment of your own is by request — talk to us for a number against your shape.


============================================================================

# PAGE: https://onedroid.ai/about
Title: About OneDroid — Built by Providentia Worldwide
Description: OneDroid builds AI agent infrastructure — a governed MCP gateway, versioned agent memory, and the Dark Factory Toolkit. Built by Providentia Worldwide, in production across regulated enterprise estates.

OneDroid

About

# Infrastructure for agents
you have to answer for.

OneDroid builds the layer between AI agents and the systems they touch: a
governed gateway, memory that lives in your own database, and the delivery
method we use ourselves. OneDroid Argus is the newest piece and
now the front of the house — automated end-to-end testing for AI-written code: it
verifies what an AI coding agent built against acceptance scenarios the agent never
saw, and hands back evidence anyone can replay.

The relationship

## OneDroid is built by Providentia Worldwide.

Providentia Worldwide is an
engineering consultancy that works inside regulated enterprise estates —
health data, financial trading — where "the agent did something and nobody can
say what" is not an acceptable outcome.

OneDroid is the product line that came out of that work. Every component here
exists because a real deployment needed it: the gateway because credentials were
being pasted into config files, the memory because knowledge kept dying with the
context window, the audit log because someone had to answer a compliance question
about what an agent had touched.

Providentia Worldwide holds five granted United States patents on interlinked,
N-dimensional blockchain structures and globally verifiable identifiers
(US 10,853,354; 11,023,458; 11,604,787; 12,141,127; 12,493,609), with further
applications pending in the US and Europe. The audit trail behind the OneDroid
evidence record is designed on that structure.

How we work

## You can read the method before you trust it.

Our delivery method is open source under Apache-2.0:
github.com/OneDro1d/dark-factory.
It is not a manifesto — it is the working set of skills, enforcement hooks and
verification gates we run, including the ones written after something failed.

The core commitment in it is the one we would want from a vendor: an agent's
confident summary is indistinguishable from a correct one, so summaries are never
accepted — only evidence a human or another agent can independently re-check.

Who you deal with

## A small team, reachable directly.

There is no sales queue. Email reaches Michal Bacia, who writes the code — which
means you can ask a specific technical question and get a specific technical
answer. We reply within one business day.

That is a real trade-off and worth naming: you get direct access to the people
building it, and in exchange you are not buying from a company with a 24/7 support
rota. If that matters for your deployment,
tell us early
and we will be honest about what we can commit to.

Name

## Which OneDroid this is.

OneDroid (onedroid.ai) builds AI agent infrastructure. We are unrelated to
Android, and to the several open-source projects called "OneDroid" in the Android
ecosystem. If you arrived here looking for those, this is not it.

## Put a gateway between your agents and the world.

Open Synapse
Talk to us

Free for individuals and small teams. No credit card.


============================================================================

# PAGE: https://onedroid.ai/changelog
Title: Changelog — OneDroid
Description: What actually shipped, with dates. OneDroid product and platform changes, most recent first.

OneDroid

Changelog

# What actually shipped.

We say we build in the open, which is a checkable claim. This is the check.
Most recent first.

2026-10-20

### OneDroid Argus 0.3.74: a check can listen on a message bus, and read the logs an environment already keeps

A chain of steps can now include a `bus` step. Before the chain's first step fires, the
executor subscribes to an AMQP exchange and routing key. Then it judges what arrived (how many
messages, how many carried the run's correlation id, and the first 20 of them) with the same
`body` claims as any other step. An instance can also read an environment's existing
shared Loki: it selects by cluster and namespace, and it parses plain-text log lines at query time
with a declared `log_regex`. The bus step is described in the
scenario-author skill
in the public runner.

The executor now sets its Go memory limit from its container, and it caps load-test results and
log answers held in memory, with an error that says so rather than a short read. A run whose
executor was restarted mid-run is now reported as failed, with the reason, instead of staying open.
`render-k8s` and `argus up` take `--executor-memory`.

The limits: the bus step reads JSON message bodies only and needs an executor at 0.3.74 or later.
An older executor refuses a check that uses it as an unknown step type. A bus subscription binding
every routing key (`#`) is refused. `log_regex` is read only for a shared
Loki, and it is Loki only.

2026-10-19

### OneDroid Argus 0.3.73: a report can leave out everything the system under test said

An author can now ask for a limited report of a run: the verdict, each check's outcome and the
status code or database error code a step got, without the fields that carry what the application
returned. The executor cuts those fields itself before anything leaves your environment. In every
report, the executor now sends only OneDroid Argus's own words when a run or a relayed command
fails, never the application's error text. Load-test errors leave the environment as a kind and a
count.

Also in this release: an `mcp` chain step can sign each call with an Ed25519 key that it
names by reference, never by value. A `bash` `## CLEANUP` block, which runs
under `sh -c`, gets a warning when the check is written and a line in the report. A
status claim listing two codes is refused instead of being read as one.

The limits: a limited report is a smaller view of the same run, not a different run. A check that
needs the response body to explain a failure needs a full report.

2026-10-13

### OneDroid Argus 0.3.72: a check can depend on what the environment has, and test an app behind Clerk

A check can declare a precondition, such as "network policies are enforced here". Before the checks
run, the executor probes it in its own namespace with throwaway pods and cleans up afterwards. If
the mechanism is present, the checks run. If it is absent, they end `not_applicable`,
with both observations recorded. If the probe itself fails, they end `errored`, never
`not_applicable`. A run where every check is `not_applicable` never reads as
passed. The results are bound into a new certificate format, v5. Formats v1 to v4 are unchanged,
and an older `argus certificate verify` refuses v5 by name.

For an application behind Clerk, `targets.auth` accepts `type: clerk_session`.
The executor mints a short-lived session for a test user for each run, refreshes it, and revokes it
at the end. The key and the token are never printed, stored or relayed. A production-looking target
or a live key is refused unless the config says so explicitly. An `mcp` chain step now
shows its claims as written, not with a value the application returned filled in.

The limits: an instance that uses preconditions must be re-rendered (`argus render-k8s`)
so its executor may create the probe's pods and policies. Until then an ingress precondition reads
`errored`. The Clerk session is checked per check, not per request, so a single check
that runs longer than the token lives sees 401s. Use a dedicated test user.

2026-10-13

### OneDroid Argus 0.3.71: the money guard can allow a clean-up, a UI drive or a fault, one by one

On an instance marked as handling money, OneDroid Argus refuses every write it cannot read off the
file until the operator lists it. The list now has three more entry kinds: a runnable
`## CLEANUP` block of one form (`sql` or `bash`), a UI drive of one
named spec, and `fault` steps, which `fault_allowed_targets` still bounds.
Each refusal now names the entry that would allow it.

Also fixed: a check the guard refuses no longer runs its clean-up. A check carrying two engine tags
is judged by the engine that actually runs it. A chain `http` step whose response is
over 1 MiB now reads `error` when it has a body claim, instead of being judged on the
first megabyte. A polled step is no longer cut off by the chain's own deadline.

The limits: an executor older than 0.3.71 refuses a config carrying the new entry kinds, by name,
when it loads. An instance set up with `render-k8s` gets no update offer from the control
plane. Move its executor image with `kubectl set image`, as `argus upgrade --help`
says.

2026-10-20

### The site now leads with what testing costs

Independent testing of AI-built software now costs about what the AI coding costs. In
one measured experiment, Claude
Code built a feature for $1.97 a run testing its own work; with OneDroid Argus as the
independent tester, the coding agent cost $1.01 a run and the tester one session of
about $5.30 for the feature, $1.77 a run over three runs. The home
page and the OneDroid Argus page now open with that. The site no
longer describes things that are not built: the one-line install command and the CI
action are gone from it.

2026-10-11

### OneDroid Argus 0.3.70: a check can read the database and the logs, and make the system fail

Three things a check could not do a week ago, each described in the
tester guide. A chain of
steps can read one row of the system's PostgreSQL database with a read-only
`SELECT`. It can ask the system's Loki whether a log line exists, does not
exist, or how many match. And, since 0.3.69, a `fault` step can stop, start
or scale a deployment, or delay, cut or truncate one connection, while the chain runs.

The limits: nothing can be made to fail unless an operator lists it under
`fault_allowed_targets`, and OneDroid Argus puts everything back. The
database step is one read-only query against a declared PostgreSQL target. The logs
step works with Loki only. The database and logs steps need an executor at 0.3.70 or
later, and a fault step one at 0.3.69 or later.

Also in this release: more claim forms on chain steps (a numeric comparison, a
tolerance such as `within 2% of`, a response-time claim), running counts
while a run is going, and reading a message from a broker without taking it from the
system's own consumer. The
OneDroid Argus page now describes release 0.3.70.

2026-10-09

### The OneDroid Argus runner is open source

github.com/OneDro1d/argus-runner
— MIT (its AMQP sampler keeps its own Apache-2.0 licence); the repository has been public since 7 October, announced today. It holds the runner that
executes sealed checks next to your system and the `argus` command line,
including `argus certificate verify`, which checks a certificate against the
chain without contacting us. The container image is published at
`ghcr.io/onedro1d/argus-runner`.

Not in it: the hosted control plane (registry, signing, anchoring, the web UI). A run
still needs an account there, available by request. The limit, stated in the repository
too: the control plane signs and anchors what the runner reports and does not re-run
the checks, so a certificate proves what the runner reported and when, not that the
runner was unmodified.

2026-09-10

### The site now leads with OneDroid Argus

The home page is about OneDroid Argus: blind acceptance
testing for software built by AI coding agents, with the same scenarios run
under load and on a schedule. The governed gateway has moved to its own page at
/synapse; nothing else was removed.

2026-08-04

### The Dark Factory method is now open source

github.com/OneDro1d/dark-factory
— Apache-2.0. The delivery method we use ourselves: stage skills, the control
loop, enforcement hooks, and the publish gate that keeps client material out
of public repositories.

It ships with a self-test that plants a known-positive canary for every scan
class and asserts the gate fails on each — written after we found
three separate checks that reported success while being unable to catch
anything. The commit history is honest about that.

2026-07-20

### Google OAuth application verification completed

The OneDroid application passed Google's OAuth verification, including the
branding and app-purpose review, for its Google Workspace connections. The
signed-out application page was reworked to state its purpose up front and to
render fully without JavaScript as part of that review.

2026-07-19

### Privacy policy and terms of service published

/privacy and /terms, rewritten
after an adversarial review pass rather than pasted from a generator.

2026-07-19

### Crawlable: robots.txt and sitemap.xml

Explicit allowances for AI crawlers alongside conventional search engines,
and a sitemap covering every public page.

2026-07-18

### Bring-your-own-database for OneDroid Engram

Point OneDroid Engram at a Postgres you own. Documents, chunks, embeddings, revision
history and permissions become rows in your database — readable with SQL,
backed up with your own tooling, and yours if you leave.

2026-07-18

### onedroid.ai launched

OneDroid Synapse-first positioning, with pages for OneDroid Engram, the Dark Factory Toolkit,
enterprise deployment and pricing.

Entries are added when something ships, not when it is planned. If this page
goes quiet, that means we have been heads-down — ask us directly at
michal@onedroid.ai
rather than assuming.

## Watch it happen.

Follow on GitHub
Open Synapse


============================================================================

# PAGE: https://onedroid.ai/contact
Title: Contact OneDroid — Talk to the people who build it
Description: Contact OneDroid about OneDroid Synapse, OneDroid Engram, enterprise deployments, or help adopting the Dark Factory method. You reach the team that builds the product. We reply within one business day.

OneDroid

Contact

# Talk to the people
who build it.

There is no sales queue and no contact-form robot. Email reaches Michal Bacia
directly. We reply within one business day.

## What are you writing about?

### Enterprise deployment

Running OneDroid Synapse on your own infrastructure, SSO, deployment topologies,
security review, or procurement paperwork.

Email about enterprise

michal@onedroid.ai

### Help implementing the Dark Factory

The toolkit is free and open — take it without talking to us. If you want help
making it work in your organisation, tell us what you are building and how you
verify it today.

Help me implement this

michal@onedroid.ai

### Something else

Bugs, questions about how OneDroid Synapse or OneDroid Engram work, a feature you need, or
anything the site did not answer.

Email us

michal@onedroid.ai

## Who you are reaching

OneDroid is built by Providentia Worldwide.
The person who answers your email is the person who writes the code — which means
you can ask specific technical questions and get a specific technical answer.

If your address is webmail and the buttons above do not open your mail client,
the address is michal@onedroid.ai — copy it directly.


============================================================================

# PAGE: https://onedroid.ai/privacy
Title: Privacy Policy — OneDroid
Description: How OneDroid collects, uses, and protects your data — including data accessed through Google APIs and other connected services.

OneDroid

Legal

# Privacy Policy

Effective date: 19 July 2026 · Last updated: 14 October 2026

## Who we are

OneDroid (onedroid.ai) is AI agent infrastructure built and operated by Providentia
Worldwide ("OneDroid", "we", "us"). This policy covers the OneDroid website
(onedroid.ai), OneDroid Synapse (synapse.onedroid.ai), and OneDroid Engram
(engram.onedroid.ai) — together, "the Service".

Questions or requests: michal@onedroid.ai.

## The short version

- We collect the minimum needed to run a governed gateway: your account details,
the credentials you choose to connect, and a metadata log of tool calls.

- We do not sell your data. We do not use your data for advertising. We do not
train AI models on your data.

- Data accessed through connected services (including Google) is used only to
execute the tool calls you or your agents explicitly make.

- With bring-your-own-database, your data lives in infrastructure you control.

## What we collect

Account information. When you sign up we collect your name, email
address, and authentication identifiers. Sign-in is handled by our authentication
provider, Clerk.

Connected credentials. When you connect a third-party service
(for example Google Workspace, Atlassian, or Slack), we store the resulting OAuth
grants or API tokens, encrypted at rest. These credentials exist for one purpose:
executing the tool calls that you, or agents acting under your account, explicitly
invoke. OneDroid Synapse is designed so that agents receive tool results, not the underlying
tokens — raw credentials are held by the gateway and are not exposed to connected
agents.

The audit log. OneDroid Synapse's audit log (called the event log in the
product) is designed to record metadata about every tool invocation — which account
and agent made the call, which tool was called, timestamps, latency, the outcome,
and cryptographic hashes of arguments and results — rather than storing your
documents, messages, or files as retrievable content. Tool-call arguments can
themselves contain content you or your agents supply; we hash rather than store them
in the audit log, and we work to keep content out of operational logs, though we
cannot promise that no fragment ever appears in error telemetry.

Content you store. Documents and knowledge you deliberately write
to OneDroid Engram are stored so they can be searched and versioned, in the platform database
or in your own database if you use bring-your-own-database.

Website and operational data. Our website sets no advertising or
analytics cookies. The applications set strictly necessary cookies for sign-in and
session security (via Clerk) — nothing else. Walkthrough videos on the quickstart page are
embedded from YouTube in its privacy-enhanced mode (youtube-nocookie.com): nothing is set until you
press play, and from then on YouTube's own policy applies. Our hosting providers keep standard
server logs (IP address, request path, user agent). We also forward the request logs of this
website and of docs.onedroid.ai (requested page, time, IP address, user agent, referrer) to a
log store we run ourselves in the EU, where they are kept for 30 days, so that we can count
visits, including visits by AI agents. We use no cookies and no third-party analytics script
for this. Fonts are loaded from Google
Fonts, which receives standard request data when the page loads. The applications
keep operational telemetry (errors, performance) needed to run the Service.

## Access to your content

Humans at OneDroid do not read the content that passes through the gateway or that
you store in the Service — whether it comes from Google, another connected service,
or OneDroid Engram — except with your explicit permission, where necessary for security or
abuse investigation, or where required by law.

## Google user data

If you connect a Google account, OneDroid Synapse requests only the scopes you approve on
the Google consent screen (for example Gmail, Drive, Calendar, Docs, Sheets, or
Slides access).

- How it is used. Google user data is accessed solely to execute
the specific tool calls you or your authorized agents invoke — for example reading
a message you asked an agent to summarize, or creating a document you asked an
agent to write. Content passes through the gateway to your agent; the audit log
retains call metadata and hashes, not the content itself.

- What we do not do. We do not use Google user data for
advertising. We do not sell it. We do not use it to train AI or machine-learning
models. Humans at OneDroid do not read it except with your explicit permission,
where necessary for security or abuse investigation, or where required by law.

- Storage. Google OAuth tokens are stored encrypted at rest.
Google user content is not retained by the Service beyond serving your request,
except where you explicitly store it (for example, saving a document into OneDroid Engram).
If you save Google-sourced content into OneDroid Engram, search embeddings for it are
computed by our embedding provider (OpenAI) under terms that prohibit training on
your data.

- Revocation and deletion. You can disconnect Google at any time
in OneDroid Synapse, or from your Google Account security settings. On disconnection or
account deletion, stored Google tokens are deleted.

OneDroid's use and transfer of information received from Google APIs adheres to
the Google
API Services User Data Policy, including the Limited Use requirements.

## Bring your own database

OneDroid Synapse and OneDroid Engram support storing your governance state, credential grants, audit
log entries, and documents in a database you provide and control. In that
configuration, the data resides in your infrastructure and under your policies; we
access it only as needed to operate the Service for you. We do not inspect, validate,
or take responsibility for the contents of your database — what is stored there, its
accuracy, lawfulness, security, and retention are yours to govern.

## How we share data

We do not sell personal data, and we do not share it with third parties for their
marketing. We share data only with:

- Subprocessors that host and operate the Service: Amazon Web
Services and Microsoft Azure (application hosting), Supabase (platform database
hosting), Clerk (authentication), Vercel (website hosting), OpenAI (computing
search embeddings for content you store in OneDroid Engram, under terms that prohibit
training on your data), and Google Workspace (support email). Each processes data
only to provide their service to us.

- Connected services you choose — when a tool call you invoke
sends data to a service you connected, that transfer happens at your direction and
is governed by that service's own terms and privacy policy.

- Legal requirements — if required by law, or to protect the
rights, safety, or security of OneDroid, our users, or the public.

## Retention and deletion

Account data and stored credentials are kept while your account is active. When
you delete your account or disconnect a service, the associated credentials are
deleted and grants revoked. Audit log entries on the free hosted tier are retained
for 12 months and then deleted, and are deleted within 30 days of account deletion —
except entries we must keep for security investigations or legal obligations. Data in
your own database is retained entirely under your control. To request access,
correction, export, or deletion of your data, email
michal@onedroid.ai — a human reads it, and we
aim to reply within a few business days, always within the timelines applicable law
requires.

## Where GDPR or CCPA applies

Where the GDPR applies, we process your data to perform our contract with you
(running the Service), in our legitimate interest in keeping the Service secure and
reliable, and otherwise on your instruction or consent. Our subprocessors operate in
the United States; if you need documentation covering international transfers, or a
data processing agreement for your team, email
michal@onedroid.ai. You can also lodge a
complaint with your local data protection authority. We do not sell or share personal
data as those terms are defined in the CCPA.

## Security

All traffic is encrypted in transit (TLS). Stored credentials are encrypted at
rest. Tool access is scoped by hub, role, and policy, and every invocation is written
to the append-only audit log. No method of transmission or storage is perfectly
secure; we publish what the gateway can and cannot see rather than promising
absolutes.

## Children

The Service is not directed to children under 16, and we do not knowingly collect
their data.

## Changes to this policy

If this policy changes, we will post the new version here and update the effective
date. Material changes will be flagged on the website.

## Contact

Providentia Worldwide — OneDroid

michal@onedroid.ai

providentiaworldwide.com


============================================================================

# PAGE: https://onedroid.ai/terms
Title: Terms of Service — OneDroid
Description: The terms that govern use of OneDroid Synapse, OneDroid Engram, and the OneDroid website.

OneDroid

Legal

# Terms of Service

Effective date: 19 July 2026 · Last updated: 7 October 2026

## 1. Agreement

These terms govern your use of the OneDroid website (onedroid.ai), OneDroid
OneDroid Synapse (synapse.onedroid.ai), OneDroid Engram (engram.onedroid.ai), and any other
OneDroid tools, toolkits, or previews we make available — including anything labeled
early access or preview — together, "the Service", operated by
Providentia Worldwide ("OneDroid", "we", "us"). By creating an account or using the
Service, you agree to these terms. If you are using the Service on behalf of an
organization, you represent that you can bind that organization.

Enterprise deployments under a separately signed license agreement are governed by
that agreement where it differs from these terms.

## 2. The Service

OneDroid Synapse is a governed MCP gateway: your agents connect to one URL, and every tool
call is authenticated, policy-checked, and logged, fail-open, to an audit log (called the
event log in the product). OneDroid Engram is versioned knowledge and memory for AI agents. The
Service is free for individuals and small teams; current usage limits, if any, are
published on the pricing page.

The Service is evolving. We may add, change, or retire features, and may set
fair-use limits to keep the Service healthy for everyone — published on the pricing
page before they apply. If we ever discontinue the free hosted Service, we will give
reasonable notice and a window to export your data.

## 3. Your account

- Provide accurate information and keep your sign-in credentials secure.

- You are responsible for activity under your account — including every tool call
made, and every action taken, by agents you connect and authorize, whatever data
those agents relied on.

- You must be at least 16 years old to use the Service.

## 4. Your data and credentials

- Your data is yours. You grant us only the limited rights needed to operate the
Service: storing your configuration, holding the credentials you connect (encrypted),
executing tool calls you or your agents invoke, and maintaining the audit log.

- We do not sell your data and do not use it to train AI models.

- With bring-your-own-database, your data resides in infrastructure you control.
You are responsible for that database — its availability, backups, security, and
everything stored in it. We do not inspect or validate its contents, and we take no
responsibility for them, or for what agents do based on them; we access your
database only to operate the Service for you.

- For data hosted on our platform, we take reasonable care, but the free Service
is not a backup system — keep copies of anything you cannot afford to lose.

- Handling of personal data is described in the
Privacy Policy.

## 5. Agents act for you, not for us

Agents connected to the Service act on your instructions, under your configuration
and your credentials. You — not we — are responsible for what they do and for the
results and effects of what they do, including actions an agent takes, or decisions
it makes, based on data stored in or retrieved through the Service (whether in
OneDroid Engram, in your own database, or from a connected service). Data in the Service is
what you or your agents put there; we do not warrant that it is accurate, current,
or complete.

The gateway is deliberately mechanical: we transport, authorize, and log tool
calls. We do not review them, decide them, or vouch for their outcomes. Before you
let an agent take actions that matter — money, messages, production systems — it is
up to you to scope its access and check its work. Governance features are tools you
configure and operate; we do not warrant any particular outcome from using them.

## 6. Acceptable use

You agree not to:

- use the Service for unlawful purposes, or to infringe others' rights;

- attempt to breach, probe, or circumvent the Service's security or another
organization's governance controls;

- interfere with the Service's operation, including deliberate overload or abuse
of any fair-use limits we publish;

- use the Service in violation of the terms of the third-party services you
connect to it;

- resell or white-label the hosted Service without a written agreement with us.

To report abuse, or content you believe infringes your rights, email
michal@onedroid.ai — we will investigate and
act, including removal where appropriate.

## 7. Third-party services

When you connect a third-party service (for example Google, Atlassian, or Slack),
you do so at your direction, under your agreement with that provider. We are not
responsible for third-party services, their availability, or their handling of your
data. Disconnecting a service in OneDroid Synapse revokes the Service's stored access to it.

### 7.1 Agent clients and connector directories

You may use the Service through an AI client such as Claude, ChatGPT or Claude Code,
whether you add it as a custom connector or install it from that client's connector
directory. When you do, the client's provider handles your conversation under its own
terms and privacy policy; the Service sees only the tool calls the client sends and
answers them under these terms. Signing in to the Service from a client authorises that
client to act for you in the hub you choose, with the roles you hold there, until you
disconnect it. Tools that reach a third-party service you have connected (section 7)
appear in a client only for the person who connected that service, and only while their
connection is active. A listing in a connector directory does not make the client's
provider a party to these terms, and we may change or withdraw a listing at any time.

## 8. Intellectual property

We own the Service, its software, and branding. You own your data, configurations,
and anything you create with the Service. Feedback you choose to send us may be used
to improve the Service without obligation.

## 9. Disclaimers

The Service — including everything offered free of charge — is provided "as is"
and "as available", without warranties of any kind, express or implied, including
fitness for a particular purpose, merchantability, and non-infringement. We do not
warrant the results or effects of using the Service, and Section 5 allocates
responsibility for agent actions.

Anything marked early access or preview is exactly that: experimental, may change,
break, or be withdrawn without notice, and comes with no promises beyond the
disclaimers in these terms.

The Dark Factory Toolkit is distributed as open source under the Apache License
2.0. Your use of that code is governed by the Apache-2.0 licence and its warranty
disclaimer, not by these terms.

## 10. Limitation of liability

To the maximum extent permitted by law: OneDroid and Providentia Worldwide will
not be liable for indirect, incidental, special, consequential, or punitive damages,
or for lost profits, data, or goodwill — including losses arising from actions taken
by agents you connect, or from data stored in the Service or in your own database —
and our total liability for all claims relating to the Service is limited to the
greater of USD 100 or the amounts you paid us for the Service in the twelve months
before the claim arose.

Nothing in these terms excludes or limits liability that cannot be excluded or
limited by law — including for fraud, willful misconduct, gross negligence, or death
or personal injury caused by negligence, where applicable law so provides.

## 11. Indemnity

If a third party brings a claim against us arising from your data, your use of the
Service, actions taken by agents you connect or authorize, or your breach of these
terms or of a connected service's terms, you will defend us against that claim and
cover the resulting costs, damages, and reasonable legal fees. We will tell you
promptly about any such claim.

## 12. Suspension and termination

You may stop using the Service and delete your account at any time; stored
credentials are then deleted and grants revoked. We may suspend or terminate access
for breach of these terms or to protect the Service's security, with notice where
practicable. After termination we will make your platform-hosted data available for
export for 30 days where practicable, then delete it. Provisions that by their nature
survive (Sections 4, 5, and 8–11, and Section 14) continue to apply.

## 13. Changes

We may update these terms as the Service evolves. Changes will be posted here with
an updated date. For material changes we will give notice on the website or by email
before they take effect; if you keep using the Service after that date, the new terms
apply — if you do not agree, stop using the Service and export your data.

## 14. The fine print, briefly

If part of these terms turns out to be unenforceable, the rest still stands. These
terms (plus any signed enterprise agreement) are the entire agreement between us
about the Service and replace prior discussions. You may not assign these terms or
your account without our consent; we may assign them as part of a merger,
acquisition, or sale of assets. Not enforcing a provision once is not a waiver of it.
Neither of us is liable for delay or failure caused by events genuinely outside our
control. Formal notices to us go to
michal@onedroid.ai; we will notify you at
your account email. You may not use the Service in violation of export-control or
sanctions laws.

## 15. Contact

Providentia Worldwide — OneDroid

michal@onedroid.ai

providentiaworldwide.com


============================================================================

# PAGE: https://onedroid.ai/evidence/onedroid.ai
Title: OneDroid: its public claims and the evidence behind them — OneDroid evidence
Description: Every checkable claim onedroid.ai makes on its own public pages, where it is made, and what backs it: 78 evidenced, 51 contradicted (41 of them low confidence), 98 with no evidence published, of 227. Checked 2026-10-27. Nothing here says true or false.

Evidence pages

Evidence page · onedroid.ai · checked 2026-10-27 · on ourselves

# OneDroid: its public claims,
and the evidence behind them.

This page lists the checkable claims onedroid.ai makes on its own public pages,
in its docs and in its public repository, where each claim is made, and what OneDroid has published that backs it.
OneDroid checked itself on 2026-10-27, with the same method and the same three verdicts it applies to other
companies' pages, from its own public sources only: 227 claims, 78 evidenced,
51 contradicted (41 of them low confidence), 98 with no evidence published.
Nothing on this page says a claim is true or false. Every reference points into a source whose sha256 as fetched is
listed at the end of the page, so anyone can fetch the same bytes and compare. The same page as Markdown:
/evidence/onedroid.ai.md.

## How to read this page

Verdict | Meaning | Count |

EVIDENCED | an artefact on the company's own surfaces would be false if the claim were | 78 |

CONTRADICTED | the company's own surfaces disagree with the claim; both sides are referenced | 51 (41 low confidence) |

NO EVIDENCE PUBLISHED | the claim is stated; nothing beyond the statement backs it in the sources checked | 98 |

These are the only three verdicts. They are statements about the company's own published sources as fetched on
2026-10-27, not about the world. A claim with no evidence published may well be true; the page says only that
the company has not shown it. A contradicted claim may have a reading that reconciles the two sources; where the
reviewers saw one, the note says so. Each claim has an id (C-001, C-002, ...) that is also its anchor on this page.
The method and the rules for every page are on the evidence pages index.

### Limits

Same sources only: the reviewers read what the company published and nothing else. They did not test the product,
interview anyone or use outside records. Every verdict is about the sources as fetched on 2026-10-27; a page can
change after that. One run is a sample of a moving site: a claim not listed may be right or wrong. The reviewers are AI agents run by OneDroid, checked by hand on a sample. OneDroid checked itself, so this page is a self-report made with a disclosed method, not an independent audit; the sources as fetched are fingerprinted below so anyone can repeat it.

### Corrections

If a line on this page is wrong, write to michal@onedroid.ai naming the claim id.
A wrong quote, URL or fingerprint is corrected and listed in the change log. When a contradicted claim is fixed on the
site, it is checked again from the new sources, with a new date and new fingerprints, and the verdict changes when the
evidence supports it; the date of the fix is recorded in the change log.

### Change log

2026-10-27: first run. Withdrawn by the reviewer before publication: C-042 (the lister paraphrased: the site says OneDroid Argus does not judge the diff, never that it never reads it (orchestrator correction, HOLDOUT-orchestrator.md)), C-050 (the lister paraphrased: the site says the certificate can be checked with the open CLI, no OneDroid account and no contact with OneDroid, through a chain RPC endpoint you choose; the word offline appears nowhere (orchestrator correction)), C-093 (the lister paraphrased: the site says the control plane that seals the set and adjudicates the verdict is hosted and closed; no page names a generator (orchestrator correction)). The morning run of the same day listed 174 claims (47 evidenced, 22 contradicted, 105 with no evidence published) and copy fixes merged that day closed 8 of the 22 before this afternoon re-run on the live site.

## Contradicted (10)

Id | Claim, as made | Made at | Both sides |

C-040 | The people who build Argus did not choose the ticketing system and did not write a check for it; one engineer's coding agent wrote and ran the checks. | onedroid.ai/llms-full.txt (PAGE /case-study-otrs-znuny: In short and setup table) | Same page says "The people who build OneDroid Argus did not choose the system; that engineer coding agent wrote and ran the checks" (L635) yet also "An engineer on our team" and, under limits, "The same team wrote the checks, ran them and wrote this" (L769). The blog twin carries the same pair: "did not choose the system and did not write a check" vs "The same team wrote the checks".
sources/llms-full.txt#L635-637
sources/llms-full.txt#L675
sources/llms-full.txt#L769 |

C-054 | argus certificate verify exits 0 only when every anchor was read back and matched. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Verify a certificate) | README: "Exit code 0 means every anchor read back and matched". Same repo docs/CERTIFICATE.md:273-275 and docs.onedroid.ai/argus-ledger.md:184: certificate verify exits 0 "when at least one of the run verdict anchors verified and no anchor mismatched"; unreachable or pending anchors (for example a private chain) do not fail it. "every" vs "at least one".
sources/argus-runner-README.md#L109-110
repo(ea08f5a)/docs/CERTIFICATE.md#L273-275
https://docs.onedroid.ai/argus-ledger.md (HTTP 200)#L184-185 |

C-055 | When the tester reveals the set, every scenario is published with trigger, expectation, observed evidence and verdict, and any scenario can be replayed by the runner against the same artefact by anyone. | onedroid.ai/argus.md (The reveal)
onedroid.ai/pricing.md (runner bullets: Executes any revealed scenario)
onedroid.ai/llms-full.txt (PAGE /pricing: runner bullets) | Pricing says the open runner "executes any revealed scenario, so anyone who runs it can replay a verdict". README lists "reveal document assembly and replay" as deliberately not in the repo, and the ledger doc names `argus replay` and `argus anchor verify`, which do not exist in cmd/argus (grep for cmd == "replay"/"anchor": none). Docs/CERTIFICATE.md also documents `anchor verify`.
sources/pricing.md#L31
sources/argus-runner-README.md#L125-129
https://docs.onedroid.ai/argus-ledger.md (HTTP 200)#L195-198 |

C-056 | Every scenario ends as passed, failed, errored or not_applicable (it could not run), and neither an error nor not_applicable is ever a pass; a load run has a fourth outcome, degraded. | onedroid.ai/argus.md (The reveal: Every scenario ends as passed, failed, errored or not_applicable)
onedroid.ai/llms-full.txt (PAGE /: FAQ Does OneDroid Argus score my build?)
onedroid.ai/llms-full.txt (PAGE /qa-teams: 4. Judge) | Text lists four outcomes (passed, failed, errored, not_applicable) and then says a load run "has a fourth outcome, degraded"; degraded is a fifth outcome (it was the fourth before not_applicable was added). Stale count on the same sentence pair.
sources/llms-full.txt#L389-392
sources/argus.md#L124-128 |

C-064 | A load target takes load only after its operator lists it, and a load ramp never targets a live broker. | onedroid.ai/argus.md (Under load; Not a free hand on a live system)
onedroid.ai/llms-full.txt (PAGE /: FAQ Where does it run?)
onedroid.ai/llms-full.txt (PAGE /security: Where the verifier runs) | "a load ramp never targets a live broker" vs argus.md "a live system should never be listed" (advice) and tester guide "List a lab or a dedicated test broker, never a live one". Enforcement is a naming heuristic: only urls with a prod/production/prd/shared segment are refused (loadallowed.go:75-79).
sources/llms-full.txt#L249
sources/argus.md#L145-148
https://docs.onedroid.ai/argus-tester-guide.md (HTTP 200)#L1573-1575 |

C-076 | Argus keeps the scenario corpus in OneDroid Engram and reaches its control plane through OneDroid Synapse. | onedroid.ai/llms.txt (Positioning)
onedroid.ai/argus.md (What it installs)
onedroid.ai/llms-full.txt (PAGE /engram: intro) | Site says Argus reaches its control plane through Synapse and keeps the scenario corpus in Engram. README and quickstart connect the CLI, runner and MCP client straight to https://argus-dev.onedroid.ai (ARGUS_CP_URL, .../mcp) and none of the Argus docs or the repo mention Synapse or Engram (searched).
sources/llms-full.txt#L520-524
sources/argus-runner-README.md#L52-60
sources/argus-runner-README.md#L93-95 |

C-184 | Chain steps gained claim forms in v0.3.70: body has total == 42, within 2% of, body not contains, body has no <field>, body every <list> has ..., and elapsed < 500ms on an http step. | docs.onedroid.ai/argus.md (What changed recently: More claim forms on chain steps (v0.3.70)) | The repo own SKILL.md (published 2026-10-23) documents `within 2% of`, `body not contains`, `body has no ...`, but no Go code in cmd/argus or internal/ defines these claim forms (grep within/not contains/has no/elapsed: none).
sources/argus-docs.md#L129-132
repo(ea08f5a)/skills/scenario-author/SKILL.md#L821,L1012
repo(ea08f5a)/internal/scenario/bodyassert.go, httpclaims.go, internal/chain/ (searched) |

C-189 | argus render-k8s --collect-sut-logs --sut-logs-via api collects the system's pod logs through the Kubernetes API for a cluster that refuses host mounts (v0.3.70). | docs.onedroid.ai/argus.md (What changed recently: Collect the system's pod logs through the Kubernetes API (v0.3.70)) | Docs and the repo own SKILL.md name `--sut-logs-via api`, but cmd/argus defines only --collect-sut-logs; grep for sut-logs-via over *.go finds nothing.
sources/argus-docs.md#L155-157
repo(ea08f5a)/skills/scenario-author/SKILL.md#L789
repo(ea08f5a)/cmd/argus/main.go#L257 (only --collect-sut-logs is defined) |

C-200 | The OneDroid Argus runner needs a Kubernetes cluster that can reach both the system under test and the control plane; the runner connects out only and needs no inbound route. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Quickstart intro) | README: "You need ... a Kubernetes cluster that can reach both your system and the control plane"; the OTRS study ran "Docker Compose, two OneDroid Argus executors side by side, no cluster" and the quickstart preflight has a Docker (compose) machine path.
sources/argus-runner-README.md#L43-44
sources/llms-full.txt#L669
sources/argus-quickstart.md#L198-203 |

C-208 | A builder token reaches the same six-tool runner surface the author hat also has (validate-config, run, get-report, get-sagas, tail-logs, get-dashboard-url), never the scenario-authoring commands. | docs.onedroid.ai/argus-quickstart.md (Section 2: What a builder needs) | Quickstart: the builder token reaches "the same six-tool runner surface" including get-sagas and tail-logs. Builder guide (control-plane path, the builder-token path): "get-sagas and tail-logs are not available on this path" and its tool table lists five tools including runner__list_alerts.
sources/argus-quickstart.md#L133-136
https://docs.onedroid.ai/argus-builder-guide.md (HTTP 200)#L58-68
https://docs.onedroid.ai/argus-builder-guide.md (HTTP 200)#L93 |

## Contradicted, low confidence (41)

The disprove pass itself said a charitable reading reconciles each of these: a dated historical entry, a paraphrase, a feature documented for the hosted service but not yet in the public code snapshot. They are listed because the two surfaces do disagree as written.

Id | Claim, as made | Made at | Both sides |

C-003 | The tester wrote the checks in one session of about $5.30 for the feature. | onedroid.ai/llms-full.txt (PAGE /: hero)
onedroid.ai/argus.md (intro)
onedroid.ai/llms.txt (Cost paragraph) | Home/argus pages call the about $5.30 session the tester cost "for the feature", but the case study says that session "wrote both sets of checks" (the build checks and the 13 hidden judge checks), so part of the $5.30 is judge authoring, not per-feature testing cost. LOW confidence: the case study states it openly.
sources/llms-full.txt#L28-31
sources/llms-full.txt#L1047
sources/llms-full.txt#L1075 |

C-005 | Independent testing now costs the same order as the AI coding. | onedroid.ai/llms-full.txt (PAGE /: How it works / affordable paragraph)
onedroid.ai/argus.md (Why section, same order of magnitude)
docs.onedroid.ai/argus.md (Why it exists) | Hero says testing "costs what the AI coding costs"; the case study on the same site shows the whole cost $2.78 vs $1.97 (+41%) and a $5.30 tester session that is 2.7x to 5.2x the $1.97/$1.01 coding cost. LOW confidence: body text only says "same order".
sources/llms-full.txt#L22-24
sources/llms-full.txt#L1067-1069
sources/llms-full.txt#L1075 |

C-010 | With the tester, the coding agent used 69% fewer tokens (2.37 million vs 0.72 million). | onedroid.ai/llms-full.txt (PAGE /case-study-claude-code-alone-vs-tester: result table) | Arithmetic from the page raw numbers: (2.37-0.72)/2.37 = 69.6%, which the page own rounding (48.7% printed 49%, 41.1% printed 41%) would print as 70%, not 69%. LOW confidence: unrounded token means could give 69.3-69.9%.
sources/llms-full.txt#L1065
sources/llms-full.txt#L1021 |

C-012 | Compared with end-to-end testing by hand, Argus is faster and cheaper: no test scripts to write and keep alive, scenarios written once per feature. | onedroid.ai/llms.txt (Cost paragraph)
onedroid.ai/argus.md (Faster and cheaper than end-to-end testing by hand)
docs.onedroid.ai/argus.md (Is it end-to-end testing?) | The only cost data published compares Claude Code testing itself, not end-to-end testing by hand; the case study reports whole cost +41% and "Wall time: not compared", so "faster and cheaper than end-to-end testing by hand" has no figure behind it. LOW confidence: different comparator, qualitative claim.
sources/llms-full.txt#L1069-1071
sources/llms-full.txt#L1093
sources/llms.txt#L30-32 |

C-020 | Every check was shown able to fail: two deliberately broken builds turned red the checks that depend on the changed constant and left unrelated arithmetic checks green. | onedroid.ai/llms.txt (Case study entry)
onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: The method: Can a check fail?)
onedroid.ai/llms-full.txt (PAGE /: Shown on real code paragraph) | Page says every check was shown able to fail, but its method says the broken builds turned red only the checks depending on the changed constant "and left every unrelated check of the arithmetic green", i.e. unrelated checks were not shown to fail; L1355 adds held checks that "test less than their titles". LOW confidence: the reviewer reading is a second leg.
sources/llms-full.txt#L1271
sources/llms-full.txt#L1293
sources/llms-full.txt#L1355 |

C-039 | Argus compare ran end to end for the first time on 4 October 2026, on three systems, and on 5 and 6 October on a system the company did not pick. | onedroid.ai/argus.md (New, in early use)
onedroid.ai/llms-full.txt (PAGE /case-study-otrs-znuny: case study header: runs of 5 and 6 October 2026) | argus.md says compare ran "on a system we did not pick"; the OTRS case study says "An engineer on our team and his coding agent took two releases" and, under what it did not cover, "The same team wrote the checks, ran them and wrote this". LOW confidence: engineer choice vs company choice.
sources/argus.md#L175
sources/llms-full.txt#L635
sources/llms-full.txt#L769 |

C-048 | The final run happens once, against a pinned artefact, and the control plane adjudicates it. | onedroid.ai/argus.md (Run unseen, then adjudicated)
onedroid.ai/llms-full.txt (PAGE /: step 03)
onedroid.ai/llms-full.txt (PAGE /qa-teams: 4. Judge) | Pages say the final run happens once, but the FINOS study says "An earlier certified run of the same seven checks the same day gave the same verdict" (L905), the finding was "seen in every final run that day" (L911), and another final run was started and refused (L935). LOW confidence: design statement vs a same-day re-certification.
sources/argus.md#L102-103
sources/llms-full.txt#L2704-2705
sources/llms-full.txt#L905 |

C-058 | OneDroid Argus returns a verdict: passed or failed, or not_applicable when no check could run (a verdict, unlike the neutral conclusion of the diff-reading tools). | onedroid.ai/llms-full.txt (PAGE /: You already had the incident, closing paragraph: returns a verdict: passed or failed, or not_applicable when no check could run)
docs.onedroid.ai/argus.md (What changed recently, v0.3.72: a run where every check is not_applicable has the verdict not_applicable) | Home and docs call not_applicable a verdict ("a run where every check is not_applicable has the verdict not_applicable"); the GitHub-app doc files "every check was not applicable" under "no verdict about your system" -> neutral. LOW confidence.
sources/llms-full.txt#L108
sources/argus-docs.md#L112-113
https://docs.onedroid.ai/argus-github.md (HTTP 200)#L38 |

C-070 | Argus can read one row of the system's PostgreSQL database with a read-only query, ask Loki whether a log line exists, and make the system fail on purpose (stop, start or scale a deployment, delay or cut a connection). | onedroid.ai/argus.md (The run)
onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-11)
docs.onedroid.ai/argus.md (v0.3.69 and v0.3.70 notes) | Public runner chain step types are "mcp | ui | http | amqp" (chain.go:42): no db, logs or fault step and no fault_allowed_targets anywhere (grep *.go, *.md, *.yaml: none), though argus.md and the 2026-10-11 changelog present them as released. LOW confidence: public code last changed 2026-10-08 (d6cb047) and may lag the private release.
sources/argus.md#L105-110
sources/llms-full.txt#L3253-3266
repo(ea08f5a)/internal/scenario/chain.go#L42 |

C-071 | Nothing can be made to fail unless the system's operator lists it under fault_allowed_targets, Argus puts everything back, and the report and certificate say what was done. | onedroid.ai/argus.md (The run)
onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-11)
docs.onedroid.ai/argus.md (v0.3.69 Fault steps) | "Argus puts everything back" vs tester guide: "A failed undo does not change the verdict ... restore_outcome: failed ... FAULT NOT RESTORED", "does not raise an alert yet", and a crashed CLI process undoes only at the next executor start. LOW confidence: the guide also says every fault is undone by design.
sources/argus.md#L108-110
https://docs.onedroid.ai/argus-tester-guide.md (HTTP 200)#L752-754
https://docs.onedroid.ai/argus-tester-guide.md (HTTP 200)#L818-819 |

C-078 | The CLI is built for macOS and Linux; Windows is supported only through WSL 2. | onedroid.ai/argus.md (Surfaces: CLI)
docs.onedroid.ai/argus-quickstart.md (Windows) | Docs: CLI built for macOS and Linux, Windows only via WSL 2. Public CLI source has a native Windows variant (`//go:build windows`, "onboarding runs under bash there"), and the OTRS study ran on "One Windows laptop, Docker Compose". LOW confidence: release binaries may still be mac/Linux only.
sources/argus.md#L188-189
sources/argus-quickstart.md#L47-48
repo(ea08f5a)/cmd/argus/up_detach_windows.go#L1-8 |

C-082 | The 2026-10-11 changelog entry says the OneDroid Argus page now describes release 0.3.70; the docs say they describe Argus v0.3.72. | onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-11 OneDroid Argus 0.3.70, last sentence: The OneDroid Argus page now describes release 0.3.70)
docs.onedroid.ai/argus.md (What changed recently: These pages describe Argus v0.3.72) | Changelog 2026-10-11: "The OneDroid Argus page now describes release 0.3.70"; docs.onedroid.ai/argus: "These pages describe Argus v0.3.72". Versions differ and the changelog has no entry for 0.3.71 or 0.3.72. LOW confidence: later page update.
sources/llms-full.txt#L3272
sources/argus-docs.md#L108 |

C-087 | Argus certificate format argus-certificate/v4 is issued for runs with faults, and version 5 for a run whose verdict is not_applicable. | docs.onedroid.ai/argus.md (v0.3.69 and v0.3.72 notes) | Claim: v5 for a run whose verdict is not_applicable. Ledger doc and certificate.go: v5 is issued for any run that carries precondition results or at least one not_applicable scenario, which is wider (argus-docs.md:112-113 matches the narrower reading). LOW confidence.
sources/argus-docs.md#L112-113
https://docs.onedroid.ai/argus-ledger.md (HTTP 200)#L145
repo(ea08f5a)/internal/certificate/certificate.go#L36-39 |

C-091 | The runner container image is published at ghcr.io/onedro1d/argus-runner (tags: main, and sha-<commit> per build). | onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-09 The container image is published at ghcr.io/onedro1d/argus-runner)
raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Quickstart step 1: docker pull ghcr.io/onedro1d/argus-runner:main; each build also tagged sha-<commit>)
docs.onedroid.ai/argus-quickstart.md (Section 1, No operator yet?: public image ghcr.io/onedro1d/argus-runner:main) | README and changelog say the image is published (GitHub packages page shows main and sha-<commit> tags); BUILDING.md says the Dockerfile "has not been built yet: build it once before you rely on it" and "this repository does not publish anything by itself". LOW confidence: publication may come from a private pipeline.
sources/llms-full.txt#L3282-3283
sources/argus-runner-README.md#L47-50
repo(ea08f5a)/BUILDING.md#L68-71 |

C-097 | Anyone can sign up for the Argus evaluation control plane at https://argus-dev.onedroid.ai (e-mail, Google or Microsoft); it is a test environment with no promise that data is kept. | onedroid.ai/llms.txt (Status note)
onedroid.ai/argus.md (Surfaces; intro)
raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Quickstart) | ORCHESTRATOR HOLDOUT CORRECTION (the pass scored no): the dated 2026-10-09 changelog entry still says "A run still needs an account there, available by request" (llms-full.txt L3286) while argus.md, llms.txt, the README and the docs say anyone can sign up at argus-dev.onedroid.ai. LOW confidence: a dated historical entry, same shape as C-082/C-169. Original note: Surfaces agree (e-mail, Google or Microsoft; no promise data is kept). Sign-up not exercised (no accounts).
sources/llms-full.txt#L3286
sources/argus.md#L26-27
sources/llms.txt#L36 |

C-102 | The Argus runner was open sourced on 2026-10-09. | onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-09)
api.github.com/repos/OneDro1d/argus-runner (created_at 2026-10-07) | Changelog entry dated 2026-10-09 says "the repository has been public since 7 October, announced today"; GitHub created_at is 2026-10-07T22:26:48Z and the first commit is 2026-10-07. Open-sourcing date was 7 Oct; 9 Oct is the announcement. LOW confidence.
sources/llms-full.txt#L3274-3279
sources/github-repo.json#created_at=2026-10-07T22:26:48Z
repo(ea08f5a)/git log 5273171 2026-10-07 22:00 |

C-109 | Free tier covers hosted Synapse and Engram; the boundary with Enterprise is deployment shape, not seat count. | onedroid.ai/llms.txt (Pricing)
onedroid.ai/pricing.md (Where the free tier ends)
onedroid.ai/llms-full.txt (PAGE /synapse: FAQ) | Pricing: "There is no seat count that trips you over", boundary is deployment shape. Synapse page: "Free for individuals and small teams. For anything larger, email michal@onedroid.ai", and the free tier is headed "Individuals & small teams": a size boundary. LOW confidence: "larger" may mean larger deployments.
sources/pricing.md#L104-109
sources/llms-full.txt#L1679-1680
sources/pricing.md#L63 |

C-123 | The Synapse governance settings include PHI detection, credential encryption, an append-only audit trail, 6-7 year compliance retention, rate limiting and IP allowlisting, some forced on by a platform-wide override. | onedroid.ai/llms-full.txt (PAGE /synapse: Not a mockup: Governance, as switches) | Synapse page shows governance switches including "6-7 year compliance retention", padlocked rows "forced on by a platform-wide override"; Privacy says free-tier audit log entries are "retained for 12 months and then deleted", and the partner page lists "compliance-grade audit and retention" as an Enterprise addition. LOW confidence: screenshot may be of an enterprise configuration.
sources/llms-full.txt#L1631-1635
sources/llms-full.txt#L3566-3568
sources/partners-financial-services.html#L589 |

C-126 | Sensitive data is detected and redacted in the request path with a redaction reference for audit, tuned to exclude date patterns from free-text lanes. | onedroid.ai/llms-full.txt (PAGE /financial-services: What stops client data reaching the model?; Security)
onedroid.ai/llms-full.txt (PAGE /enterprise: PII and PHI screening) | Public page: sensitive data "detected and redacted in the request path". Unlisted partner page (HTTP 200, noindex): "Some controls in the reference deployment run in audit mode rather than blocking, and one detection gate is proven in a single application rather than platform-wide". LOW confidence: audit mode still detects.
sources/financial-services.md#L125-130
sources/partners-financial-services.html#L630 |

C-129 | OneDroid Synapse and Engram run bring-your-own-database; Hosted, hosted+own database and self-hosted shapes show different visibility (self-hosted: OneDroid sees nothing at runtime, no telemetry path back by default). | onedroid.ai/llms-full.txt (PAGE /security: Deployment topologies; Data visibility)
onedroid.ai/llms-full.txt (PAGE /synapse: FAQ What can OneDroid see?) | Synapse page and Privacy say with bring-your-own-database "every credential grant, event log entry, and document" is a row in your Postgres; Security says "Hosted + your database: The gateway is ours; Engram data lives in a Postgres you own" and OneDroid still holds encrypted credentials and sees tool-call metadata ("Everything above, minus your Engram content"). LOW confidence.
sources/llms-full.txt#L1534-1536
sources/llms-full.txt#L3536-3540
sources/llms-full.txt#L2140-2143 |

C-140 | OneDroid replies within one business day. | onedroid.ai/llms.txt (Optional: Contact)
onedroid.ai/argus.md (closing)
onedroid.ai/llms-full.txt (PAGE /: closing) | "We reply within one business day" for michal@onedroid.ai vs Privacy: for access/deletion requests to the same address "we aim to reply within a few business days". LOW confidence: privacy sentence is about data-subject requests.
sources/llms.txt#L114
sources/llms-full.txt#L2261
sources/llms-full.txt#L3569-3573 |

C-141 | Email to michal@onedroid.ai reaches Michal Bacia, who writes the code, not a sales queue. | onedroid.ai/argus.md (closing)
onedroid.ai/llms-full.txt (PAGE /about: A small team, reachable directly)
onedroid.ai/llms-full.txt (PAGE /contact: Who you are reaching) | Pages say michal@onedroid.ai is "not a sales queue"; the home page JSON-LD declares that address as contactPoint contactType "sales". LOW confidence: structured-data label only.
sources/llms-full.txt#L3197-3199
https://onedroid.ai/ (HTTP 200) JSON-LD L45 "contactType": "sales" |

C-146 | Audit log entries on the free hosted tier are retained for 12 months and deleted within 30 days of account deletion. | onedroid.ai/llms-full.txt (PAGE /privacy: Retention and deletion) | Privacy: free-tier audit log retained 12 months then deleted. Synapse page screenshot caption lists "6-7 year compliance retention" forced on platform-wide, and the partner page treats "compliance-grade audit and retention" as an Enterprise addition. LOW confidence: different tiers possible.
sources/llms-full.txt#L3566-3568
sources/llms-full.txt#L1631-1635
sources/partners-financial-services.html#L589 |

C-148 | Requests for access, correction, export or deletion get a reply within a few business days and always within applicable legal timelines. | onedroid.ai/llms-full.txt (PAGE /privacy: Retention and deletion) | Privacy says a few business days for requests; the same address is promised a one-business-day reply on Security, About and Contact. LOW confidence: different request types.
sources/llms-full.txt#L3569-3573
sources/llms-full.txt#L2261
sources/llms-full.txt#L3198-3199 |

C-159 | Companies spent a fifth to a third of their IT budget on quality assurance and testing; Capgemini's World Quality Report first measured it at 18% and called it an indication of insufficient attention on quality. | onedroid.ai/argus.md (Why)
docs.onedroid.ai/argus.md (Why it exists)
onedroid.ai/llms-full.txt (PAGE /: hero paragraph) | "between a fifth and a third" (20-33%) of IT budget, yet "first measured at 18%", below a fifth. LOW confidence: "for years" vs "first measured".
sources/argus.md#L57-59
sources/argus-docs.md#L35-37 |

C-169 | The changelog lists what actually shipped with dates, and entries are added when something ships, not when it is planned. | onedroid.ai/llms-full.txt (PAGE /changelog: intro and footer)
onedroid.ai/llms.txt (Product: Changelog) | Changelog says entries are added when something ships; its newest entry is 2026-10-20 and the newest Argus release entry is 0.3.70 (2026-10-11), while docs.onedroid.ai says v0.3.71 and v0.3.72 shipped; the 14 Oct privacy update and the case studies of 7-21 Oct have no entries. LOW confidence.
sources/llms-full.txt#L3233-3236
sources/llms-full.txt#L3352-3353
sources/argus-docs.md#L108-127 |

C-176 | Argus checks read the customer's database in read-only transactions; Argus writes to it only if a scenario declares a cleanup block, and then only with the credential you give it. | onedroid.ai/argus.md (Boundaries: Not a free hand on a live system)
onedroid.ai/llms-full.txt (PAGE /: FAQ Where does it run?)
onedroid.ai/llms-full.txt (PAGE /security: Where the verifier runs) | Pages say checks read the database "in read-only transactions"; in the public runner the database-state check uses a JDBC pool with autocommit=true and no read-only setting (database-state.jmx:45), read-only is enforced by authoring-time word matching (verifysql.go:119) and the role, and the tester guide says "The real guarantee is the role". grep READ ONLY in runner, argus, templates finds no scenario-path hit. LOW confidence: the v0.3.70 db step does use BEGIN READ ONLY per docs.
sources/llms-full.txt#L249
sources/llms-full.txt#L503
repo(ea08f5a)/templates/database-state.jmx#L45 |

C-178 | OneDroid has no financial-services reference yet: the flagship reference is in regulated healthcare, and design partners get roadmap influence. | onedroid.ai/financial-services.md (What we don't claim: Not a financial-services logo yet)
onedroid.ai/llms-full.txt (PAGE /financial-services: What we don't claim: Not a financial-services logo yet) | Pages say no financial-services reference yet; About says Providentia works in "health data, financial trading" estates and the Dark Factory README says the method was extracted from production use at OneDroid across "financial-trading estates". LOW confidence: "reference" may mean a named logo.
sources/financial-services.md#L212-216
sources/llms-full.txt#L3163-3166
https://raw.githubusercontent.com/OneDro1d/dark-factory/main/README.md (HTTP 200) Provenance: "production use at Providentia Worldwide and OneDroid across enterprise health-data and financial-trading estates" |

C-180 | Argus can test a system behind Clerk: targets.auth takes type: clerk_session and the executor mints a short-lived session per run (v0.3.72). | docs.onedroid.ai/argus.md (What changed recently: Testing a system behind Clerk (v0.3.72)) | Docs say targets.auth takes type: clerk_session (v0.3.72); the public runner has no such type (searched whole clone). LOW confidence: public code last changed 2026-10-08.
sources/argus-docs.md#L116-118
repo(ea08f5a)/(grep clerk_session over *.go, *.md, *.yaml: no match) |

C-182 | On an instance that declares money_handling, money_writes.allow can allow a runnable ## CLEANUP by form, a ui spec and fault steps, and a refused scenario does not run its ## CLEANUP (v0.3.71). | docs.onedroid.ai/argus.md (What changed recently: Allow entries for cleanup, ui and fault (v0.3.71)) | Docs (v0.3.71) say money_writes.allow can allow runnable ## CLEANUP by form, a ui spec and fault steps; the public money_writes allow entry is an exact (method, path) and no fault step exists in the public runner. LOW confidence: public code may lag.
sources/argus-docs.md#L121-124
repo(ea08f5a)/internal/scenario/moneywrites.go#L20
repo(ea08f5a)/(no fault_allowed_targets) |

C-186 | An amqp step can listen, queue_bind and decode gzip, reading the message a request caused without taking it from the system's own consumer (v0.3.70). | docs.onedroid.ai/argus.md (What changed recently: amqp listen, queue_bind and decode: gzip (v0.3.70))
onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-11: reading a message from a broker without taking it from the system's own consumer) | Docs (v0.3.70) say an amqp step can listen, queue_bind and decode gzip; the public amqp step ops have no listen or queue_bind and grep for gzip/queue_bind finds nothing. LOW confidence: public code may lag.
sources/argus-docs.md#L145-147
repo(ea08f5a)/internal/scenario/amqpstep.go#L96-99 (ops publish, consume, declare_queue, declare_exchange ...) |

C-187 | On an instance that declares money_handling, the owner's money_writes.allow list can name an HTTP route, an amqp operation, an mcp tool, a db step or a logs step (v0.3.70). | docs.onedroid.ai/argus.md (What changed recently: Allow entries for every engine (v0.3.70)) | Docs (v0.3.70) say money_writes.allow can name an amqp operation, an mcp tool, a db step or a logs step; the public allow entry is an exact (method, path) and no db/logs step exists. LOW confidence: public code may lag.
sources/argus-docs.md#L148-151
repo(ea08f5a)/internal/scenario/moneywrites.go#L20 |

C-188 | An mcp step can read data a gateway wraps in text (extract, claims written body extracted ..., unavailable and poll) (v0.3.70). | docs.onedroid.ai/argus.md (What changed recently: An mcp step can read data a gateway wraps in text (v0.3.70)) | Docs (v0.3.70) say an mcp step can use extract and claims `body extracted ...`; no such code in the public runner (only the skill text mentions it). LOW confidence: public code may lag.
sources/argus-docs.md#L152-154
repo(ea08f5a)/skills/scenario-author/SKILL.md (mentions)
repo(ea08f5a)/internal/mcp, internal/chain, internal/scenario (grep "body extracted": none) |

C-190 | argus cloud-enroll --workspace <id> and argus cloud-create-workspace --name <name> exist (v0.3.69). | docs.onedroid.ai/argus.md (What changed recently: Enroll by workspace id, and create a workspace from the CLI (v0.3.69))
raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Quickstart step 2: cloud-create-workspace prints its id) | Docs (v0.3.69) say `argus cloud-enroll --workspace <id>` exists; in the public CLI the cloud-enroll flag set is control-plane, instance-id, revoke, token, token-dir (help_filter.go:43) and workspaceID is read only by cloud-switch-workspace. cloud-create-workspace does exist. LOW confidence: public code may lag.
sources/argus-docs.md#L165-167
repo(ea08f5a)/cmd/argus/help_filter.go#L43
repo(ea08f5a)/cmd/argus/main.go#L1588,L2226-2277 |

C-191 | Argus has a router-wiring doctor check, and argus doctor --tester runs the cluster checks without a tester.env (v0.3.69). | docs.onedroid.ai/argus.md (What changed recently: Four argus doctor fixes (v0.3.69))
docs.onedroid.ai/argus-quickstart.md (Section 4: Four more things changed in v0.3.69) | Docs (v0.3.69) say argus doctor has a router-wiring check; the public CLI has none (searched cmd/argus and internal/doctor). LOW confidence: public code may lag.
sources/argus-docs.md#L168-171
sources/argus-quickstart.md#L250-253
repo(ea08f5a)/(grep router-wiring over *.go: none) |

C-198 | Argus has two modes in the docs, Run (whichever scenarios you ask for, once) and Monitor (a reviewed scenario set on a schedule). | docs.onedroid.ai/argus.md (The two modes) | docs.onedroid.ai/argus says "The two modes" (Run, Monitor); the home page says "Three modes, one evidence contract", and the tester guide run modes are build, final, rehearsal, scheduled (plus compare). LOW confidence: different taxonomies.
sources/argus-docs.md#L86-91
sources/llms-full.txt#L142-164
https://docs.onedroid.ai/argus-tester-guide.md (HTTP 200)#L1368 |

C-201 | Runs are requested through the control plane's author tools, for example from an agent connected to its MCP endpoint https://argus-dev.onedroid.ai/mcp. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Quickstart step 5) | GET on the named MCP endpoint returns 404 "404 page not found" while the other OneDroid MCP endpoints answer an unauthenticated GET with 401. LOW confidence: the route may be POST-only; I did not POST.
sources/argus-runner-README.md#L93-95
https://argus-dev.onedroid.ai/mcp (GET HTTP 404, body "404 page not found")
https://engram.onedroid.ai/mcp and https://synapse.onedroid.ai/agent/mcp (GET HTTP 401) |

C-207 | Four local checks need no token: validate-scenario, validate-config, package-check and propose-from-repo; argus version answers with no token at all. | docs.onedroid.ai/argus-quickstart.md (Section 1 (argus version) and Section 2 (four local checks)) | Quickstart: four local checks need no token and "Everything else ... refuses"; code also runs `calm import` pre-auth and local ("PRE-AUTH and local, like validate-scenario"), plus preflight and doctor. LOW confidence: quickstart is about in-env commands.
sources/argus-quickstart.md#L105-107
repo(ea08f5a)/cmd/argus/calm_cmd.go#L47
repo(ea08f5a)/cmd/argus/main.go#L539-546 |

C-209 | argus doctor --tester (v0.3.47 or later) prints one PASS, FAIL or SKIP line per onboarding phase and exits 4 on any FAIL; plain argus doctor exits 0 when the demo-scenarios check is only a warning (v0.3.52 or later). | docs.onedroid.ai/argus-quickstart.md (Section 4) | Docs: doctor --tester prints "PASS, FAIL or SKIP" per phase; code comment says "PASS/WARN/FAIL/SKIP" lines. Exit 4 on FAIL matches. LOW confidence.
sources/argus-quickstart.md#L244-248
repo(ea08f5a)/cmd/argus/doctor_tester.go#L20,L409 |

C-223 | Credentials are held per user, per hub, and sensitive data is detected and redacted in the request path rather than in a batch job. | onedroid.ai/financial-services.md (Then it clears the gates: Security)
onedroid.ai/llms-full.txt (PAGE /financial-services: Security) | Same page says credentials are held "per user, per hub" (L77) and "per user, per workspace, per account" (L108); request-path redaction vs partner page "audit mode ... single application rather than platform-wide". LOW confidence.
sources/financial-services.md#L77-78
sources/financial-services.md#L108-110
sources/partners-financial-services.html#L630 |

C-227 | OneDroid subprocessors operate in the United States, and a data processing agreement is available by email. | onedroid.ai/llms-full.txt (PAGE /privacy: Where GDPR or CCPA applies) | Privacy: "Our subprocessors operate in the United States", yet Azure is a named subprocessor, the FINOS study ran on "a shared Azure Kubernetes cluster in Poland Central" and request logs go to an EU log store. LOW confidence: self-run log store is not a subprocessor.
sources/llms-full.txt#L3579-3580
sources/llms-full.txt#L857
sources/llms-full.txt#L3488-3489 |

## Evidenced (78)

Id | Claim, as made | Made at | Artefact |

C-006 | The coding agent cost 49% less with the tester ($1.01 vs $1.97). | onedroid.ai/llms.txt (Case study entry, 49% less)
onedroid.ai/llms-full.txt (PAGE /case-study-claude-code-alone-vs-tester: result table (-49%))
onedroid.ai/llms-full.txt (PAGE /case-studies: card for the alone-vs-tester study) | sources/llms-full.txt#L1067
sources/llms-full.txt#L1075
Published means $1.97 and $1.01 give -48.7%, rounding to the quoted 49%; arithmetic reconciles, but the inputs are themselves only restated means. |

C-007 | Counting the tester's session, the whole cost 41% more ($2.78 vs $1.97). | onedroid.ai/llms.txt (Case study entry)
onedroid.ai/llms-full.txt (PAGE /case-study-claude-code-alone-vs-tester: result table (+41%)) | sources/llms-full.txt#L1069
sources/llms-full.txt#L1075
1.01 + 5.30/3 = 2.78 and 2.78/1.97 = +41%: arithmetic reconciles from the published means; inputs themselves are restated. |

C-011 | The tester's one-off $5.30 adds about $1.77 to each of the three runs. | onedroid.ai/llms-full.txt (PAGE /case-study-claude-code-alone-vs-tester: after result table)
onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-20 entry) | sources/llms-full.txt#L1075
5.30/3 = 1.77 per run; arithmetic reconciles from the published figures. |

C-014 | The equivalence-tester setup cost $10.04 a run, 41% less than working alone at $16.92. | onedroid.ai/llms.txt (Case study: one modernization)
onedroid.ai/llms-full.txt (PAGE /case-study-modernization-three-setups: result table) | sources/llms-full.txt#L1189
10.04/16.92 = -40.7%, rounding to the quoted 41%; arithmetic reconciles from the published means, which are restated. |

C-017 | 100 checks from 37 published claims in a decades-old Fortran library's user guide were sealed before the run: 91 held, 9 failed, 0 errored. | onedroid.ai/llms.txt (Case study: does the code do what its user guide says?)
onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: In short and result table)
onedroid.ai/llms-full.txt (PAGE /: Shown on real code paragraph) | https://base-sepolia.blockscout.com/api/v2/transactions/0x53ff7fd12710b90183bb166821766fcc5b6152b7e7b05d1a08161575f4632228#HTTP 200, block_number 48212445, payload scenario_count=100
https://base-sepolia.blockscout.com/api/v2/transactions/0x6228ba08bc8532962b225ab007c1ee9c040f3e3ec718d20b3e035873e3b91bc2#HTTP 200, block_number 48212457, payload verdict=failed tallies passed 91 failed 9 errored 0
sources/llms-full.txt#L1301-1317
PARTIAL: chain payloads quote scenario_count=100 and tallies 91 passed / 9 failed / 0 errored at the quoted blocks; the "37 published claims" mapping is not on chain. |

C-022 | The sealed set and the verdict were recorded on Base Sepolia (blocks 48212445 and 48212457) and submitted to Bitcoin through OpenTimestamps. | onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: How anyone can check it) | https://base-sepolia.blockscout.com/api/v2/transactions/0x53ff7fd12710b90183bb166821766fcc5b6152b7e7b05d1a08161575f4632228#HTTP 200, block_number 48212445, payload scenario_count=100
https://base-sepolia.blockscout.com/api/v2/transactions/0x6228ba08bc8532962b225ab007c1ee9c040f3e3ec718d20b3e035873e3b91bc2#HTTP 200, block_number 48212457, payload verdict=failed tallies passed 91 failed 9 errored 0
PARTIAL: both transactions answer 200 at blocks 48212445 and 48212457 and carry the sealed-set hash and the verdict; the Bitcoin OpenTimestamps receipt is not published or checked. |

C-026 | Seven checks were sealed before the run against the FINOS CALM trades API and MCP demo: 5 passed, 2 failed, 0 errored (certified run of 7 October 2026). | onedroid.ai/llms.txt (Case study: FINOS CALM)
onedroid.ai/llms-full.txt (PAGE /case-study-finos-calm: In short and result table) | https://base-sepolia.blockscout.com/api/v2/transactions/0x9fccbd30504e7e31554455dfc27bbf27ca5cba4cd5e30d9f607a6355aea32adc#HTTP 200, block_number 47817413, payload scenario_count=7
https://base-sepolia.blockscout.com/api/v2/transactions/0x8718c0b64c7fd35feb06029e1af1574b944d35c2afde6676a114132b7353ce7a#HTTP 200, block_number 47817439, payload verdict=failed tallies passed 5 failed 2 errored 0, artifact_digest sha256:feb820a3...
sources/llms-full.txt#L891-905
On-chain payloads (2026-10-07T19:58Z and 19:59Z) carry scenario_count=7 and tallies passed 5, failed 2, errored 0, verdict failed. |

C-027 | Six of the seven checks were generated by argus calm import from the demo's CALM architecture file and one was written by hand. | onedroid.ai/llms-full.txt (PAGE /case-study-finos-calm: In short and setup table) | argus-runner@ea08f5a:cmd/argus/calm_cmd.go#L13-16
https://base-sepolia.blockscout.com/api/v2/transactions/0x9fccbd30504e7e31554455dfc27bbf27ca5cba4cd5e30d9f607a6355aea32adc#HTTP 200, block_number 47817413, payload scenario_count=7
PARTIAL: `argus calm import` is registered in the public CLI and the sealed set holds 7 scenarios; the 6-generated/1-handwritten split is not shown. |

C-030 | The sealed set was recorded before the run in block 47817413 (tx 0x9fccbd30...32adc) and the verdict after it in block 47817439 (tx 0x8718c0b6...ce7a) on Base Sepolia, plus a private chain and Bitcoin via OpenTimestamps. | onedroid.ai/llms-full.txt (PAGE /case-study-finos-calm: How anyone can check it later) | https://base-sepolia.blockscout.com/api/v2/transactions/0x9fccbd30504e7e31554455dfc27bbf27ca5cba4cd5e30d9f607a6355aea32adc#HTTP 200, block_number 47817413, payload scenario_count=7
https://base-sepolia.blockscout.com/api/v2/transactions/0x8718c0b64c7fd35feb06029e1af1574b944d35c2afde6676a114132b7353ce7a#HTTP 200, block_number 47817439, payload verdict=failed tallies passed 5 failed 2 errored 0, artifact_digest sha256:feb820a3...
Both transactions exist at exactly the quoted blocks 47817413 and 47817439 on Base Sepolia with the full hashes printed on the page; private chain and Bitcoin receipt not checked. |

C-031 | Before the run Argus read the image digests actually running and found exactly the three declared; a final run declaring a digest that was not running was refused before any check ran. | onedroid.ai/llms-full.txt (PAGE /case-study-finos-calm: How anyone can check it later) | argus-runner@ea08f5a:internal/artifactmeasure/measure.go#L196-203
https://base-sepolia.blockscout.com/api/v2/transactions/0x8718c0b64c7fd35feb06029e1af1574b944d35c2afde6676a114132b7353ce7a#HTTP 200, block_number 47817439, payload verdict=failed tallies passed 5 failed 2 errored 0, artifact_digest sha256:feb820a3...
PARTIAL: the runner code contains the exact refusal text "is not among the image digests running ... nothing was bound", and the verdict payload artifact_digest sha256:feb820a3... matches the declared trades-mcp-server digest prefix; the measurement of exactly three running digests is not on chain. |

C-033 | One sealed set of 26 checks was run three times on each of OTRS Community Edition 6.0.30 and Znuny 7.3.7 with Argus compare, finding six differences between the releases. | onedroid.ai/llms.txt (Case study: OTRS 6.0.30 and Znuny 7.3.7)
onedroid.ai/llms-full.txt (PAGE /case-study-otrs-znuny: In short)
onedroid.ai/argus.md (New, in early use) | https://base-sepolia.blockscout.com/api/v2/transactions/0x5258615ee2af56837808eb26182ddca2d6d7d185ad5b249e85b19e5db52b184d#block 47753301 (2026-10-06T08:21Z) payload scenario_count=26
https://base-sepolia.blockscout.com/api/v2/transactions/0xa930153c2206b1ea51ee287fc95744587431f6f427717c0afba2146fe0295aab#block 47753554 comparison_verdict identical 23 differs 9 noise 0 not_measured 0 runs 6 members 2
sources/llms-full.txt#L637
PARTIAL: chain shows a 26-scenario set sealed 2026-10-06 and a comparison verdict over 6 runs and 2 members (3 per system) with verdict differences; the six named differences are not on chain. |

C-034 | In set 2 Argus reported 23 cells identical, 9 that differ, none noisy and none not measured (set 1: 16 checks, 16 identical, 4 differ, 1 noise). | onedroid.ai/llms-full.txt (PAGE /case-study-otrs-znuny: In short and result table) | https://base-sepolia.blockscout.com/api/v2/transactions/0xa930153c2206b1ea51ee287fc95744587431f6f427717c0afba2146fe0295aab#block 47753554 comparison_verdict identical 23 differs 9 noise 0 not_measured 0 runs 6 members 2
https://base-sepolia.blockscout.com/api/v2/transactions/0x8ccbe50f8209d615a1e591e2545c8b9a67a63298af0d46016f08d48396c9410a#block 47726730 (2026-10-05T17:35Z) comparison_verdict identical 16 differs 4 noise 1 not_measured 0 runs 6 members 2
sources/llms-full.txt#L689-705
Chain comparison_verdict counts match: set 2 identical 23, differs 9, noise 0, not_measured 0; set 1 identical 16, differs 4, noise 1 (payload counts.checks reads 25 and 15 against 26 and 16 on the page). |

C-041 | Argus exercises the running system with nothing mocked: HTTP, the message broker, the database, web pages in a real browser. | onedroid.ai/llms.txt (Positioning)
onedroid.ai/argus.md (Is it end-to-end testing?)
docs.onedroid.ai/argus.md (intro) | argus-runner@ea08f5a:internal/amqpengine
argus-runner@ea08f5a:internal/httpload/httpload.go
argus-runner@ea08f5a:testkit/ui
PARTIAL: public repo contains the HTTP, AMQP, SQL-verify and Playwright UI engines; "nothing mocked" cannot be shown from code. |

C-044 | The builder's credential can ask for a run and read the verdict, and cannot read a check or an expected value. | onedroid.ai/llms.txt (Positioning)
onedroid.ai/argus.md (Your coding agent can't game it)
docs.onedroid.ai/argus-quickstart.md (Section 2, What a builder needs) | argus-runner@ea08f5a:internal/role/role.go#L1-30
argus-runner@ea08f5a:internal/mcpserver/tools.go#L33-77
argus-runner@ea08f5a:cmd/argus/session_init_cmd.go#L222-291
Builder hat gets only the six runner__* tools; a builder session init fails unless tools/list returns only runner__* tools. |

C-045 | During the build the runner reports only failing ids and observed reality, never what was expected. | onedroid.ai/argus.md (Run unseen, then adjudicated)
onedroid.ai/llms-full.txt (PAGE /qa-teams: 3. Build)
docs.onedroid.ai/argus.md (The holdout) | argus-runner@ea08f5a:internal/report/report.go#L212-228
argus-runner@ea08f5a:internal/failcontext/bundle.go#L6-7
report.go redactExpected nils expected values for the product (builder) hat; failure context is built on observed reality. |

C-046 | The scenario set is hashed and written to a cryptographic ledger before the build starts and revealed in full, with an on-chain anchor, when the tester chooses to reveal after the verdict. | onedroid.ai/llms.txt (Positioning)
onedroid.ai/argus.md (Sealed before the build)
onedroid.ai/llms-full.txt (PAGE /: Evidence anyone can replay) | https://base-sepolia.blockscout.com/api/v2/transactions/0x9fccbd30504e7e31554455dfc27bbf27ca5cba4cd5e30d9f607a6355aea32adc#HTTP 200, block_number 47817413, payload scenario_count=7
https://base-sepolia.blockscout.com/api/v2/transactions/0x8718c0b64c7fd35feb06029e1af1574b944d35c2afde6676a114132b7353ce7a#HTTP 200, block_number 47817439, payload verdict=failed tallies passed 5 failed 2 errored 0, artifact_digest sha256:feb820a3...
https://base-sepolia.blockscout.com/api/v2/transactions/0x08e53fd7af13d78f27fb13ca0136284d0ba89ab8a94f27852d4829fb3fd19a12#HTTP 200, block 50957709, payload kind=reveal document_sha256 scenario_count 18
Chain carries a set-sealed record before the run (19:58:34Z, run 19:58:48Z), a verdict record after it, and a reveal record with document_sha256; PARTIAL: the claim that the tester chooses the reveal is docs-only. |

C-049 | The verdict binds to a specific build and cannot be re-pointed at a later one. | onedroid.ai/argus.md (The reveal)
onedroid.ai/llms-full.txt (PAGE /qa-teams: 6. Show) | https://base-sepolia.blockscout.com/api/v2/transactions/0x8718c0b64c7fd35feb06029e1af1574b944d35c2afde6676a114132b7353ce7a#HTTP 200, block_number 47817439, payload verdict=failed tallies passed 5 failed 2 errored 0, artifact_digest sha256:feb820a3...
argus-runner@ea08f5a:internal/certificate/verify.go#L678-697
argus-runner@ea08f5a:docs/CERTIFICATE.md#L50-51
Verdict anchor payload binds artifact_digest and certificate verify checks that digest against the anchor. |

C-052 | Decoy checks, meant to catch a runner that reports results it did not earn, are not implemented yet. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (What a certificate proves today) | argus-runner@ea08f5a:README.md#L28-31
Absence evidence: a recursive grep of the clone for "decoy" finds only the README sentence; no implementation exists in the public tree. |

C-053 | An anchor proves a statement existed no later than its block, not that it is true; a Bitcoin (OpenTimestamps) receipt stays pending until the calendar has a block attestation. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Other limits worth knowing) | argus-runner@ea08f5a:internal/chainread/ots/ots.go#L1
argus-runner@ea08f5a:docs/CERTIFICATE.md#L186
argus-runner@ea08f5a:cmd/argus/certificate_cmd.go#L125-132
Read-only OpenTimestamps verification and a pending status are implemented in the public verifier. |

C-057 | Argus gives no score: no aggregate number and no safe label. | onedroid.ai/argus.md (Not a score)
onedroid.ai/llms-full.txt (PAGE /: FAQ Does Argus score my build?)
onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: result note: Argus gives no score) | argus-runner@ea08f5a:schemas/report.schema.yaml
argus-runner@ea08f5a:internal/certificate/payloads.go#L30-34
Absence evidence: the report schema and anchored payloads carry only counts and a verdict word, no score field. |

C-059 | A scenario can declare a load (users held for a duration with p95 latency and error-rate limits); for message brokers a stepped ramp of up to 2,000 sessions a step by default finds the limit. | onedroid.ai/argus.md (Under load)
onedroid.ai/llms-full.txt (PAGE /: Three modes: Under load) | argus-runner@ea08f5a:schemas/scenario.schema.yaml#L31
argus-runner@ea08f5a:internal/scenario/amqpload.go#L161-162
argus-runner@ea08f5a:internal/scenario/httpload.go#L42
LOAD section, stepped sessions bounded to 1..2000 and max_sessions default 2000 are implemented in the scenario parser and config schema. |

C-060 | A load ramp records offered, sent, confirmed and delivered rates, publish-to-confirm and publish-to-delivery time, errors by class and any time the broker blocked. | onedroid.ai/argus.md (Under load) | argus-runner@ea08f5a:internal/amqpload/amqpload.go#L211-262
Step aggregation computes offered, sent, confirmed and delivered rates, publish-to-confirm and delivery latencies and a Blocked list. |

C-061 | An HTTP target can be ramped step by step, and the ramp stops at the first step that is not comfortable. | onedroid.ai/argus.md (Under load)
docs.onedroid.ai/argus.md (What changed recently, v0.3.66) | argus-runner@ea08f5a:internal/httpload/httpload.go#L155-215
HTTP ramp aggregation computes per-step Comfortable and stops the ramp at the first step that is not comfortable. |

C-062 | Stepped load ramps exist only for AMQP brokers and for one HTTP target at a time; none drives a web page in a browser. | onedroid.ai/argus.md (Under load, The limits)
onedroid.ai/llms-full.txt (PAGE /qa-teams: Not load on a web page)
onedroid.ai/llms-full.txt (PAGE /: Under load) | argus-runner@ea08f5a:internal/scenario/amqpload.go
argus-runner@ea08f5a:internal/scenario/httpload.go
argus-runner@ea08f5a:testkit/ui
Only AMQP and HTTP load kinds exist in the scenario package; the UI harness has no load mode. |

C-063 | No load ramp sits under a certified verdict or on a schedule. | onedroid.ai/argus.md (Under load, The limits) | argus-runner@ea08f5a:onboarding/HOW-TO-ARGUS-CONFIG.md#L163-165
PARTIAL: the config guide says a set with an HTTP Load scenario is not queued for final, scheduled or rehearsal; the AMQP equivalent is not stated in code. |

C-068 | Compare mode runs one sealed set against two systems or two versions and tabulates same, differs or not measured, with declared tolerances and approvals pinned to the two outputs shown. | onedroid.ai/argus.md (One sealed set, two systems)
onedroid.ai/llms-full.txt (PAGE /qa-teams: What may differ)
docs.onedroid.ai/argus.md (Comparing systems (v0.3.57)) | https://base-sepolia.blockscout.com/api/v2/transactions/0xa930153c2206b1ea51ee287fc95744587431f6f427717c0afba2146fe0295aab#block 47753554 comparison_verdict identical 23 differs 9 noise 0 not_measured 0 runs 6 members 2
https://base-sepolia.blockscout.com/api/v2/transactions/0x4f015d8325306b9c6ea2830f16e519979e320eb06e472172ddbb7decd847de92#block 47669967 (2026-10-04T10:03Z) kind=comparison_open members=3
argus-runner@ea08f5a:internal/compare/result_calc.go#L244-300
Chain comparison_open/member/approval/verdict records and the public compare package implement same/differs/not-measured cells with tolerances and approvals. |

C-073 | For an app that moves money, one switch makes Argus refuse every write the owner has not listed. | onedroid.ai/argus.md (Not a free hand on a live system)
onedroid.ai/llms-full.txt (PAGE /security: Where the verifier runs)
onedroid.ai/llms-full.txt (PAGE /: FAQ Where does it run?) | argus-runner@ea08f5a:schemas/argus-config.schema.yaml#L69-76
argus-runner@ea08f5a:internal/scenario/moneyguard.go#L26-40
argus-runner@ea08f5a:internal/config/moneywrites.go#L11-45
money_handling enforces plain GETs only at validate and run time, with an explicit money_writes allow-list for writes. |

C-074 | The runner runs inside the customer's environment next to the system under test and reaches the control plane outbound only, needing no inbound route. | onedroid.ai/argus.md (The run)
docs.onedroid.ai/argus.md (Two planes)
raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Quickstart: the runner connects out only) | argus-runner@ea08f5a:internal/federation/wire.go#L12
argus-runner@ea08f5a:internal/federation/federation.go#L2
argus-runner@ea08f5a:internal/k8srender/k8srender.go#L892
Federation verbs are outbound-only HTTPS from the executor and the rendered Service is ClusterIP only, never Ingress/NodePort/LoadBalancer. |

C-077 | Argus judges a run by reading the system's own structured logs, saga events and database state, correlated by a correlation_id. | docs.onedroid.ai/argus.md (intro and What gets checked)
onedroid.ai/argus.md (The run) | argus-runner@ea08f5a:internal/scenario/verifysql.go#L45-47
argus-runner@ea08f5a:internal/scenario/chain.go#L166
argus-runner@ea08f5a:internal/failcontext/bundle.go#L6-7
Correlation id scoping of VERIFY queries, chain steps and failure sagas is implemented in the public runner. |

C-079 | The CLI and the runner are released and open source under MIT; agent skills and the MCP server are released (sign up to evaluate). | onedroid.ai/llms.txt (Status note)
onedroid.ai/argus.md (Three ways in) | argus-runner@ea08f5a:LICENSE#L1-3
argus-runner@ea08f5a:skills/scenario-author/SKILL.md
argus-runner@ea08f5a:internal/mcpserver/tools.go#L33
PARTIAL: MIT licence, agent skill and an MCP server package are in the public repo; the hosted MCP endpoint and the "sign up to evaluate" status are not independently shown. |

C-080 | The MCP server has separate credentials for the tester (writes, seals, reveals) and the builder (starts a run, reads the verdict). | onedroid.ai/argus.md (MCP server)
docs.onedroid.ai/argus-quickstart.md (Section 2, two kinds of token) | argus-runner@ea08f5a:internal/role/role.go#L1-8
argus-runner@ea08f5a:internal/mcpserver/tools.go#L33-77
argus-runner@ea08f5a:cmd/argus/main.go#L2884
Token determines the hat; the builder surface is the six runner__* tools and the test hat has the author tools. |

C-081 | An author token is prefixed odts_ and shown once; a builder token reaches only the runner__* tools and every answer is redacted. | docs.onedroid.ai/argus-quickstart.md (Section 2) | argus-runner@ea08f5a:cmd/argus/session_init_cmd.go#L74,L222-291
argus-runner@ea08f5a:cmd/argus/doctor.go#L76
argus-runner@ea08f5a:internal/mcpserver/tools.go#L33
PARTIAL: builder session must return only runner__* tools, output is role-redacted and an odts_ token prefix is referenced; "shown once" is not in code. |

C-084 | argus doctor (CLI v0.3.45 or later) is read-only and prints the fix for each first-run problem; it writes nothing except a renewed session token and never prints a credential. | docs.onedroid.ai/argus-quickstart.md (Section 4)
raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Quickstart) | argus-runner@ea08f5a:cmd/argus/doctor.go#L26-44
argus-runner@ea08f5a:cmd/argus/doctor_tester.go#L20-33
Doctor is documented in code as read-only by construction, renews the access token in memory and never prints a credential value. |

C-086 | The site no longer describes things that are not built: the one-line install command and the CI action are gone from it. | onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-20 The site now leads with what testing costs, last sentence) | sources/llms-full.txt#L3248-3249
PARTIAL: a text search of llms-full.txt (generated from the site HTML) finds no install one-liner or CI action other than the changelog sentence; a nav link /argus#install still exists on the case-study pages. |

C-088 | The OneDroid Argus runner and CLI are open source under the MIT licence at github.com/OneDro1d/argus-runner. | onedroid.ai/llms.txt (Status note and Product)
onedroid.ai/argus.md (Surfaces)
onedroid.ai/pricing.md (The OneDroid Argus runner: open source MIT) | argus-runner@ea08f5a:LICENSE#L1-3
sources/github-repo.json#license.spdx_id=MIT
MIT LICENSE file at the repo root and GitHub API licence MIT. |

C-089 | The runner's AMQP sampler under jmeter-plugins/amqp keeps its own Apache-2.0 licence file. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Licence line)
onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-09) | argus-runner@ea08f5a:jmeter-plugins/amqp/LICENSE#L1-3
sources/argus-runner-README.md#L13
Apache License Version 2.0 file in jmeter-plugins/amqp. |

C-090 | The runner has no fee, no seat count and no expiry. | onedroid.ai/pricing.md (runner bullets)
onedroid.ai/llms-full.txt (PAGE /pricing: runner card) | argus-runner@ea08f5a:LICENSE#L1-10
sources/pricing.md#L35
PARTIAL: the MIT LICENSE grants use without fee; seat counts and expiry are absent from code (no licence check found), but "no expiry" is a negative. |

C-092 | The hosted control plane (registry, signing, anchoring, web UI, reveal assembly) is not in the repository, and argus serve --mode control is refused in the public build. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (intro and What is deliberately not here)
onedroid.ai/llms-full.txt (PAGE /changelog: 2026-10-09)
docs.onedroid.ai/argus.md (Two planes) | argus-runner@ea08f5a:cmd/argus/main.go#L2833
sources/argus-runner-README.md#L103-115
serve --mode control returns "not part of this build" and the clone has no control-plane, signing or reveal code. |

C-094 | The onboarding kit (argus up, argus init, argus update and the compose/k3d scripts) is not shipped in the runner repository. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Quickstart footer) | argus-runner@ea08f5a:cmd/argus/up.go#L25-28
sources/argus-runner-README.md#L97-99
Absence evidence: up.go composes onboarding/onboard.sh but the clone has no onboarding/onboard.sh, compose or k3d scripts (onboarding/ holds only HOW-TO and a config template). |

C-095 | The public repo's build needs no token, private module or database: go build ./... and go test ./... suffice. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Build and test) | argus-runner@ea08f5a:BUILDING.md#L7-13
argus-runner@ea08f5a:go.mod#L1-3
BUILDING.md states no token, private module or database and shows go build and go test; go.mod has no replace directives. |

C-101 | The public repository OneDro1d/argus-runner is public, not archived, licensed MIT per GitHub, created 2026-10-07T22:26:48Z, last pushed 2026-10-27T14:44:35Z, with 0 stars, 0 forks and 1 open issue. | api.github.com/repos/OneDro1d/argus-runner (private=false, visibility=public, archived=false, license.spdx_id=MIT, created_at=2026-10-07T22:26:48Z, pushed_at=2026-10-27T14:44:35Z, stargazers_count=0, forks_count=0, open_issues_count=1) | sources/github-repo.json#private=false, archived=false, license.spdx_id=MIT, created_at=2026-10-07T22:26:48Z, pushed_at=2026-10-27T14:44:35Z, stargazers_count=0, forks_count=0, open_issues_count=1
The saved api.github.com response for OneDro1d/argus-runner carries exactly these fields. |

C-114 | The Synapse token endpoint is https://synapse.onedroid.ai/agent/mcp with Authorization: Bearer syn_<token>; OAuth clients use https://synapse.onedroid.ai/hub/<slug>/mcp. | onedroid.ai/llms.txt (Connecting an agent)
onedroid.ai/llms-full.txt (PAGE /quickstart: Create a token; Not in a terminal?) | https://synapse.onedroid.ai/agent/mcp#HTTP 401 {"code":"missing_token"}
https://synapse.onedroid.ai/hub/test/mcp#HTTP 401, WWW-Authenticate resource_metadata .../oauth-protected-resource/hub/test/mcp
PARTIAL: both documented endpoint paths answer and demand a bearer; the syn_ token format is not testable without an account. |

C-115 | The initialize probe returns HTTP 200 with a JSON-RPC result for a good Synapse token, 401 invalid_token for a wrong one and 401 missing_token for no header. | onedroid.ai/llms-full.txt (PAGE /quickstart: Synapse: The check) | https://synapse.onedroid.ai/agent/mcp#HTTP 401 body {"code":"missing_token","message":"missing authentication token"} (GET, no header)
PARTIAL: the no-header case is observed live; the 200 JSON-RPC result and invalid_token cases need a POST and a token. |

C-116 | The Engram MCP endpoint is https://engram.onedroid.ai/mcp; a good token gets HTTP 200 and a server named engram, a bad or missing one gets HTTP 401 with plain-text Unauthorized. | onedroid.ai/llms-full.txt (PAGE /quickstart: Engram: The check) | https://engram.onedroid.ai/mcp#HTTP 401, content-type text/plain, body "Unauthorized", WWW-Authenticate Bearer realm="engram"
PARTIAL: the no-token case matches (401 plain-text Unauthorized); the good-token 200 and server name need a token. |

C-137 | Synapse implements OAuth 2.0 authorization-server discovery at /.well-known/oauth-authorization-server, dynamic client registration and the device authorization flow. | onedroid.ai/llms-full.txt (PAGE /security: Authentication)
onedroid.ai/llms.txt (Security & deployment entry) | https://synapse.onedroid.ai/.well-known/oauth-authorization-server#HTTP 200 JSON: authorization_endpoint .../oauth/authorize, registration_endpoint .../oauth/register, device_authorization_endpoint .../oauth/device, grant_types_supported incl. device_code
The discovery document is live and lists authorization, dynamic client registration and device authorization endpoints. |

C-145 | The website sets no advertising or analytics cookies; request logs of onedroid.ai and docs.onedroid.ai are forwarded to a self-run log store in the EU and kept for 30 days. | onedroid.ai/llms-full.txt (PAGE /privacy: What we collect: Website and operational data) | https://onedroid.ai/#HTTP 200 response headers carry no Set-Cookie
https://onedroid.ai/case-study-claude-code-alone-vs-tester#HTTP 200 only script tags are an inline block, JSON-LD and /reveals.js
sources/llms-full.txt#L3483-3489
PARTIAL: no cookie header and no analytics script tags were observed; the EU log store and 30-day retention are statement only. |

C-151 | Liability is capped at the greater of USD 100 or the amounts paid in the previous twelve months; after termination platform-hosted data is exportable for 30 days. | onedroid.ai/llms-full.txt (PAGE /terms: 10. Limitation of liability; 12. Suspension and termination) | sources/llms-full.txt#L3769
sources/llms-full.txt#L3790
https://onedroid.ai/terms#HTTP 200
The terms page itself states the cap "greater of USD 100 or the amounts you paid ... twelve months" and a 30-day export window. |

C-155 | The Dark Factory kits and method are open source under Apache-2.0 at github.com/OneDro1d/dark-factory with no paid tier; OneDroid sells help with adoption. | onedroid.ai/llms.txt (Docs: Dark Factory Toolkit and The method, open source)
onedroid.ai/llms-full.txt (PAGE /dark-factory: intro)
onedroid.ai/llms-full.txt (PAGE /quickstart: The Dark Factory kits) | https://raw.githubusercontent.com/OneDro1d/dark-factory/main/LICENSE#HTTP 200 "Apache License Version 2.0"
https://raw.githubusercontent.com/OneDro1d/dark-factory/main/README.md#L143
PARTIAL: Apache-2.0 LICENSE is present; "no paid tier" and "OneDroid sells adoption help" are page statements. |

C-156 | There are seven kits today: method-core, dev, knowledge-worker, agent-ops, code-review, distributed-systems and frontend. | onedroid.ai/llms-full.txt (PAGE /quickstart: Clone and list the kits) | https://api.github.com/repos/OneDro1d/dark-factory/git/trees/main?recursive=1#HTTP 200 kits/agent-ops, code-review, dev, distributed-systems, frontend, knowledge-worker, method-core
The repo tree contains exactly seven directories under kits/ with the seven names. |

C-157 | The Dark Factory repository ships a self-test that plants a known-positive canary for every scan class and asserts the gate fails on each. | onedroid.ai/llms.txt (Docs: The method, open source)
onedroid.ai/llms-full.txt (PAGE /changelog: 2026-08-04) | https://raw.githubusercontent.com/OneDro1d/dark-factory/main/boot-kit/scripts/gate-selftest.sh#L13-22,L239-241
The script plants a known-positive canary for every pattern class and asserts the gate fails on each. |

C-158 | The Dark Factory runbook ends with a validation run that commits its own report into the user's copy. | onedroid.ai/llms-full.txt (PAGE /quickstart: The check (kits)) | https://raw.githubusercontent.com/OneDro1d/dark-factory/main/starter-kit/instance/VALIDATE-INSTALL.md#L5
sources/llms-full.txt#L2062
VALIDATE-INSTALL.md says the validation session "commits the report itself". |

C-167 | llms-full.txt contains every onedroid.ai page listed in llms.txt except the blog, concatenated and generated from the HTML. | onedroid.ai/llms.txt (Optional: Full site text) | sources/llms-full.txt#L16-3700 (page headers) against sources/llms.txt#L41-115
https://onedroid.ai/llms-full.txt#HTTP 200
Every onedroid.ai page URL listed in llms.txt appears as a "# PAGE:" header in llms-full.txt and the blog is excluded with its own index. |

C-168 | Every blog post is served as markdown at <url>.md, with a machine index at /blog/llms.txt and an Atom feed at /blog/feed.xml. | onedroid.ai/llms.txt (Blog) | https://onedroid.ai/blog/llms.txt#HTTP 200
https://onedroid.ai/blog/feed.xml#HTTP 200 Atom feed
https://onedroid.ai/blog/case-study-claude-code-alone-vs-tester.md#HTTP 200
Index, feed and a post .md all answer 200. |

C-171 | Case studies state their limits in the text, not in a footnote, and every study states what the test did not cover. | onedroid.ai/llms-full.txt (PAGE /case-studies: intro)
onedroid.ai/llms-full.txt (PAGE /case-study-claude-code-alone-vs-tester: What this experiment did not cover)
onedroid.ai/llms-full.txt (PAGE /case-study-finos-calm: What this test did not cover) | sources/llms-full.txt#L1085-1099
sources/llms-full.txt#L1205-1221
sources/llms-full.txt#L1341-1361
Each of the five case-study pages has an in-text "did not cover" or "test boundary" section. |

C-172 | The quickstart's Synapse and Engram calls were each run against the live service, and recorded walkthrough videos exist (youtu.be/WJvsBV4sXFU, youtu.be/1o5mPIGCngk, youtu.be/KcbsT7jARFc). | onedroid.ai/llms-full.txt (PAGE /quickstart: Watch it done) | https://www.youtube.com/oembed?url=https://youtu.be/WJvsBV4sXFU&format=json#HTTP 200
https://www.youtube.com/oembed?url=https://youtu.be/1o5mPIGCngk&format=json#HTTP 200
https://www.youtube.com/oembed?url=https://youtu.be/KcbsT7jARFc&format=json#HTTP 200
PARTIAL: the three videos exist (oEmbed 200); that the calls were run against the live service is not shown. |

C-179 | If the cluster does not enforce NetworkPolicy, checks that declare a precondition or dependency end not_applicable instead of failed; a run where every check is not_applicable has the verdict not_applicable (v0.3.72). | docs.onedroid.ai/argus.md (What changed recently: Checks that depend on the environment (v0.3.72)) | argus-runner@ea08f5a:internal/artifactmeasure/measure.go#L96-100,L293-301
argus-runner@ea08f5a:internal/certificate/certificate.go#L36-43
PARTIAL: networkpolicy.ingress_enforced and egress_enforced precondition kinds and a not_applicable bucket/verdict exist; the exact "not_applicable instead of failed" mapping is not in public code. |

C-192 | A target that runs in no cluster can be declared with outside_cluster: true (v0.3.63), and a target can be declared never load tested with load_test: never (v0.3.60). | docs.onedroid.ai/argus.md (What changed recently: A target that runs in no cluster (v0.3.63); A target can be declared never load tested (v0.3.60)) | argus-runner@ea08f5a:schemas/argus-config.schema.yaml#L112-134
PARTIAL: outside_cluster and load_test: never are defined and enforced in the config schema; the version numbers are not shown. |

C-193 | A connection that must fail can be a claim (- step <name>: unreachable passes only when the connection could not be made), and argus calm import turns a CALM architecture into checks (v0.3.65). | docs.onedroid.ai/argus.md (What changed recently: A connection that must fail is now a claim, and argus calm import (v0.3.65)) | argus-runner@ea08f5a:internal/scenario/unreachable.go#L8-19
argus-runner@ea08f5a:cmd/argus/calm_cmd.go#L13-16
An unreachable claim on chain http steps and `argus calm import` exist in the public code. |

C-194 | The Argus web app has five places (Overview, Capacity, Runs, Checks and Proof), one run drawer and Needs a person items filed with author_file_attention (v0.3.53); Proof was called Ledger. | docs.onedroid.ai/argus.md (What changed recently: A new web app (v0.3.53); Where things moved in the web app) | https://argus-dev.onedroid.ai/assets/index-DTHfXbJx.js#HTTP 200 contains nav labels "Overview","Capacity","Runs","Checks","Proof"
https://docs.onedroid.ai/argus-ledger.md#"it was called Ledger before October 2026"
PARTIAL: the live app bundle carries the five section labels and the docs note the rename; the run drawer and attention filing are not checked. |

C-195 | A tester can certify a build: commit to what is certified, seal a set the builder never sees, run it once as a final run; Argus anchors the sealed set before the run, the verdict after it and the moment the tests are revealed, on a blockchain. | docs.onedroid.ai/argus.md (Certify, and let anyone check it) | https://base-sepolia.blockscout.com/api/v2/transactions/0x9fccbd30504e7e31554455dfc27bbf27ca5cba4cd5e30d9f607a6355aea32adc#HTTP 200, block_number 47817413, payload scenario_count=7
https://base-sepolia.blockscout.com/api/v2/transactions/0x8718c0b64c7fd35feb06029e1af1574b944d35c2afde6676a114132b7353ce7a#HTTP 200, block_number 47817439, payload verdict=failed tallies passed 5 failed 2 errored 0, artifact_digest sha256:feb820a3...
https://base-sepolia.blockscout.com/api/v2/transactions/0x08e53fd7af13d78f27fb13ca0136284d0ba89ab8a94f27852d4829fb3fd19a12#HTTP 200, block 50957709, payload kind=reveal document_sha256 scenario_count 18
Chain shows a commitment-bound set sealed before the run, the verdict after it and a reveal anchor; PARTIAL: Bitcoin timestamp and commit-record not individually checked. |

C-196 | A scenario is a TRIGGER, a VERIFY and an EXPECT, judged across HTTP ingestion, message flow, database state, external delivery, error paths, rate limiting and permissions, plus MCP tool-call testing and UI flows. | docs.onedroid.ai/argus.md (What gets checked) | argus-runner@ea08f5a:schemas/scenario.schema.yaml#L25-27
argus-runner@ea08f5a:cmd/argus/main.go#L279-280
argus-runner@ea08f5a:testkit/ui
TRIGGER, VERIFY and EXPECT sections are the scenario schema; MCP tool-call judging and a Playwright UI harness exist in the repo. |

C-197 | The holdout is enforced twice: by what a builder's credential is allowed to call, and by what its own environment is allowed to hold a copy of. | docs.onedroid.ai/argus.md (The holdout) | argus-runner@ea08f5a:internal/role/role.go#L1-30
argus-runner@ea08f5a:cmd/argus/session_init_cmd.go#L222-291
sources/argus-docs.md#L49-68
PARTIAL: the credential half is enforced in code; the "environment holds no copy" half is a deployment statement. |

C-202 | argus certificate verify takes --rpc (your own chain client), --chains (your own copy of the chains' allowed signers) and --btc-headers (a block-explorer URL or local file for OpenTimestamps receipts), and reports NOT ANCHORED for fields a certificate format does not put on chain. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Verify a certificate; What a OneDroid Argus certificate proves today) | argus-runner@ea08f5a:cmd/argus/certificate_cmd.go#L130-132
argus-runner@ea08f5a:internal/certificate/verify.go#L660-664
The --rpc, --chains and --btc-headers flags are registered and Render prints NOT ANCHORED lines. |

C-203 | argus certificate verify checks that the certificate's declared fields (verdict, tallies, set hash, artifact digest, time) are exactly what was anchored and that each anchor was written by a signer you allow, so a certificate edited after the fact fails. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (What a OneDroid Argus certificate proves today: What it gives you) | argus-runner@ea08f5a:docs/CERTIFICATE.md#L41-51,L260-263
argus-runner@ea08f5a:internal/certificate/verify.go#L673-697
verify compares declared verdict, tallies, set hash, artifact digest and time against anchored fields and checks signers (optionally against your chains.json). |

C-204 | The runner repository contains cmd/argus, internal/runner, internal/certificate, JMeter templates, the AMQP sampler, a Playwright harness (testkit/ui), schemas and a minimal examples/http-hello kit. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (What is here) | argus-runner@ea08f5a:cmd/argus
argus-runner@ea08f5a:internal/runner
argus-runner@ea08f5a:internal/certificate
All listed paths exist in the clone at ea08f5a. |

C-205 | argus serve --mode control is refused in the public runner build, and the control plane, web UI, anything that signs or writes to a chain, reveal assembly and the onboarding kit are not in the repository. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (What is deliberately not here) | argus-runner@ea08f5a:cmd/argus/main.go#L2833
sources/argus-runner-README.md#L103-115
Refusal text in code and absence of control-plane/web/signing/onboarding code in the tree. |

C-206 | argus cloud-login requires --scope from v0.3.41 with no default: author for a tester or operator, runner for a builder session. | docs.onedroid.ai/argus-quickstart.md (Section 3) | argus-runner@ea08f5a:cmd/argus/main.go#L205-209,L1462-1466
cloud-login --scope is required with no default (author | runner). |

C-210 | ARGUS_EXECUTOR_SECRET was called ARGUS_AUTHOR_TOKEN and ARGUS_CP_AUTHOR_TOKEN was called ARGUS_CP_TOKEN; CLI releases after v0.3.39 read the new names and still accept the old ones with a warning. | docs.onedroid.ai/argus-quickstart.md (Section 2: Renamed variables) | argus-runner@ea08f5a:cmd/argus/main.go#L9
argus-runner@ea08f5a:cmd/argus/preflight.go#L41
Code comments record ARGUS_EXECUTOR_SECRET formerly ARGUS_AUTHOR_TOKEN and ARGUS_CP_AUTHOR_TOKEN formerly ARGUS_CP_TOKEN, with the old name still read as a fallback. |

C-212 | argus preflight accepts tiers aks, k3d and managed; kind and minikube are not tiers (use k3d); render-k8s also accepts eks and gke. | docs.onedroid.ai/argus-quickstart.md (Section 4) | argus-runner@ea08f5a:cmd/argus/preflight.go#L180
argus-runner@ea08f5a:cmd/argus/main.go#L228
PARTIAL: preflight tier help lists aks | k3d | managed and render-k8s lists k3d | aks | eks | gke | managed; "kind and minikube are not tiers" is a negative. |

C-214 | Every case study comes in two versions with the same facts: a test page for engineers and a blog post for leaders and product owners. | onedroid.ai/llms-full.txt (PAGE /case-studies: intro) | https://onedroid.ai/blog/llms.txt#HTTP 200 lists the five case-study posts
https://onedroid.ai/sitemap.xml#HTTP 200 lists the five case-study pages
sources/llms-full.txt#L554-555
Each of the five case-study pages has a blog twin at /blog/<slug>.md; "the same facts" is a statement. |

C-215 | The suite listing gives these statuses: Synapse "Production", Engram "Available with OneDroid Synapse", Argus "Sign up to evaluate", kits "Open source", Enterprise "Active". | onedroid.ai/llms-full.txt (PAGE /synapse: The OneDroid suite) | sources/llms-full.txt#L1556-1604
The page lists Synapse "Production", Engram "Available with OneDroid Synapse", Argus "Sign up to evaluate", kits "Open source" and Enterprise "Active". |

C-218 | Claude Desktop and claude.ai connect to Synapse through a consent screen instead of a token, via a custom connector at https://synapse.onedroid.ai/hub/<your-slug>/mcp. | onedroid.ai/llms-full.txt (PAGE /quickstart: Not in a terminal?) | https://synapse.onedroid.ai/.well-known/oauth-authorization-server#HTTP 200
https://synapse.onedroid.ai/hub/test/mcp#HTTP 401 with resource_metadata for the hub path
PARTIAL: the hub-path endpoint and the OAuth authorization endpoint exist; the consent screen in claude.ai is not reachable without an account. |

C-222 | Browser checks run as functional end-to-end scenarios, not as load. | onedroid.ai/llms-full.txt (PAGE /qa-teams: Not load on a web page) | argus-runner@ea08f5a:internal/scenario/amqpload.go
argus-runner@ea08f5a:internal/scenario/httpload.go
argus-runner@ea08f5a:testkit/ui
Only AMQP and HTTP load kinds exist in the scenario package; the Playwright UI harness is separate from them. |

C-225 | Applications set only strictly necessary cookies for sign-in and session security (via Clerk); walkthrough videos are embedded from youtube-nocookie.com and set nothing until play; fonts are loaded from Google Fonts. | onedroid.ai/llms-full.txt (PAGE /privacy: What we collect: Website and operational data) | https://onedroid.ai/case-study-otrs-znuny#HTTP 200 iframe src youtube-nocookie.com/embed/s_OzzMsZEXM
https://onedroid.ai/case-study-claude-code-alone-vs-tester#HTTP 200 links fonts.googleapis.com
PARTIAL: privacy-friendly video embeds and Google Fonts are observed in the page HTML; Clerk cookies on the apps are not tested. |

C-229 | The Privacy Policy was last updated 14 October 2026 (effective 19 July 2026) and the Terms of Service on 7 October 2026 (effective 19 July 2026). | onedroid.ai/llms-full.txt (PAGE /privacy: header)
onedroid.ai/llms-full.txt (PAGE /terms: header) | sources/llms-full.txt#L3431
sources/llms-full.txt#L3625
https://onedroid.ai/privacy#HTTP 200
Privacy page reads "Effective date: 19 July 2026 · Last updated: 14 October 2026" and terms "Last updated: 7 October 2026". |

C-232 | The site publishes robots.txt with explicit allowances for AI crawlers and a sitemap.xml covering every public page (changelog 2026-07-19). | onedroid.ai/llms-full.txt (PAGE /changelog: 2026-07-19 Crawlable: robots.txt and sitemap.xml) | https://onedroid.ai/robots.txt#HTTP 200 explicit Allow for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Google-Extended, CCBot
https://onedroid.ai/sitemap.xml#HTTP 200 24 URLs
sources/llms-full.txt#L3330-3335
PARTIAL: robots.txt and sitemap.xml exist with the described content; the 2026-07-19 date is the changelog entry. |

C-233 | The 2026-09-10 site change moved the governed gateway to /synapse and removed nothing else. | onedroid.ai/llms-full.txt (PAGE /changelog: 2026-09-10) | https://onedroid.ai/synapse#HTTP 200 (listed in sitemap.xml)
sources/llms-full.txt#L3291-3298
PARTIAL: /synapse exists as its own page; "removed nothing else" is a negative not checkable. |

C-234 | The case studies date their runs as follows: user-guide certified run 16 October 2026, modernization runs 17 October 2026, alone-vs-tester runs 16 October 2026, FINOS CALM certified run 7 October 2026, OTRS/Znuny runs 5 and 6 October 2026. | onedroid.ai/llms-full.txt (PAGE /case-studies: card dates) | sources/llms-full.txt#L1002
sources/llms-full.txt#L1128
sources/llms-full.txt#L1250
The five case-study pages carry exactly these run dates, and the chain timestamps agree for the certified runs (2026-10-07T19:59Z and 2026-10-16T23:26Z). |

## No evidence published (98)

Id | Claim, as made | Made at | What would close it |

C-001 | Claude Code built a feature for $1.97 a run testing its own work (one measured experiment). | onedroid.ai/llms-full.txt (PAGE /: hero, Proper testing now costs what the AI coding costs)
onedroid.ai/argus.md (intro, Independent testing at the cost of the coding)
onedroid.ai/llms.txt (Cost paragraph) | Only mean cost per run is published (same figure on home, argus, llms.txt, changelog, case study); needed: per-run transcripts or total token/cost logs for the 6 judged runs. |

C-002 | With OneDroid Argus as the independent tester the coding agent cost $1.01 a run. | onedroid.ai/llms-full.txt (PAGE /: hero)
onedroid.ai/argus.md (intro)
onedroid.ai/llms.txt (Cost paragraph) | Mean $1.01 per run is stated on several pages with no per-run cost or token log; needed: the three run records. |

C-004 | The tester is paid once per feature, and its checks stay as regression checks for the next change. | onedroid.ai/argus.md (intro and Why section)
onedroid.ai/llms-full.txt (PAGE /: FAQ What does independent testing cost?)
onedroid.ai/llms-full.txt (PAGE /case-study-claude-code-alone-vs-tester: setup B already ran 37 older checks of the same app) | Reuse as regression checks is stated; the case study itself says reuse over later features was not measured, and no raw data is published. |

C-008 | Both setups passed 13 of 13 hidden checks in every judged run (6 runs). | onedroid.ai/llms.txt (Case study entry)
onedroid.ai/llms-full.txt (PAGE /case-study-claude-code-alone-vs-tester: result table)
onedroid.ai/llms-full.txt (PAGE /: FAQ What does independent testing cost?) | The 13 hidden checks were "stored in Argus only after the last run", so no sealed anchor exists for them; chain shows only two sets of 12 checks sealed 2026-10-16 (tx 0x47719392e742..., 0x7587fc71b90d...); needed: the check set, run outputs and a reveal. |

C-009 | The experiment was one ticket with 3 judged runs per setup, on Claude Opus 5.5 at high effort, on 16 October 2026. | onedroid.ai/llms-full.txt (PAGE /case-study-claude-code-alone-vs-tester: setup table)
onedroid.ai/llms.txt (Cost paragraph: One ticket, 3 runs per setup) | Setup and date are stated only in prose; needed: run records; chain shows two 12-check sets sealed on 2026-10-16 which is consistent with the date but does not show the 6 runs. |

C-013 | Claude Code on the modernization task: alone passed 104 of 109 hidden checks, tester on the manual 81, tester on equivalence with the original 106. | onedroid.ai/llms.txt (Case study: one modernization, three setups)
onedroid.ai/llms-full.txt (PAGE /case-study-modernization-three-setups: result table) | Means per setup only; needed: the 109 hidden checks, ported outputs and per-run logs. |

C-015 | In the modernization study the tester was a script, not OneDroid Argus, because the product's route could not reach the local setup. | onedroid.ai/llms-full.txt (PAGE /case-study-modernization-three-setups: setup table: The tester)
onedroid.ai/llms-full.txt (PAGE /case-study-modernization-three-setups: did not cover: OneDroid Argus as the tester) | Page states the tester was a script; no script or log published. |

C-016 | A tester checking the manual made the port worse (81 of 109) because the agent fixed every place where the original and its manual differ. | onedroid.ai/llms.txt (Case study: one modernization)
onedroid.ai/llms-full.txt (PAGE /case-study-modernization-three-setups: What the numbers say) | Explanation of why score fell is prose only; needed: diff of ported numerical detail and run logs. |

C-018 | The 9 failures are 2 medium findings and 2 low findings (medium: 4 checks on one path; low: 2 checks on a counter definition and 3 on machine constants); nothing critical. | onedroid.ai/llms.txt (Case study entry: 2 medium, 2 low)
onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: Where the code and its guide disagree) | Severity split is prose; chain shows only the 91/9/0 tallies; needed: the revealed checks and per-check verdicts. |

C-019 | Every worked example in the guide (all 11) reproduces the printed output to 7 digits. | onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: What held) | Worked-example reproduction is stated only; needed: the reveal document or the printed outputs. |

C-021 | A second AI model (OpenAI gpt-6.1-sol) reviewed every finding and every held check, confirmed all 9 failures and found no check that cannot fail. | onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: In short and The review row)
onedroid.ai/llms.txt (Case study entry: reviewed by a second AI model) | Second-model review is described; no review transcript or file is published. |

C-023 | The certificate for the Fortran run verified with the public verifier in the open-source runner, with no account. | onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: How anyone can check it) | The verifier exists in the public repo, but the certificate for this run is not published (only PDF/DOCX links on the page); needed: cert.json. |

C-024 | The Fortran run was built unmodified with gfortran 14.4 on one x86-64 machine with every source file pinned by SHA-256. | onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: The method: The system) | Compiler and SHA-256 pins are stated; no pin list or build log published. |

C-025 | Nothing was fixed in the Fortran library and nothing was reported to its authors. | onedroid.ai/llms-full.txt (PAGE /case-study-code-vs-user-guide: Where the code and its guide disagree) | A negative statement of conduct; nothing publishes or could show the absence of a report to the authors. |

C-028 | The demo's MCP guardrail refused restricted symbols in search but returned a restricted (VOD) trade in full when asked by id. | onedroid.ai/llms.txt (Case study: FINOS CALM)
onedroid.ai/llms-full.txt (PAGE /case-study-finos-calm: The two checks that failed, 1) | Observed guardrail behaviour is prose; needed: the revealed checks and observed evidence for the id lookup. |

C-029 | A connection the architecture forbids (MCP client to Trades API) was open because the authors' Azure cluster does not enforce Kubernetes network policies. | onedroid.ai/llms.txt (Case study: FINOS CALM)
onedroid.ai/llms-full.txt (PAGE /case-study-finos-calm: The two checks that failed, 2) | Cause is stated as prose; needed: the revealed check and the cluster NetworkPolicy state. |

C-032 | Two earlier build runs outside the sealed set served up to 160 concurrent users with a 95th percentile of 106 ms or less and no errors. | onedroid.ai/llms-full.txt (PAGE /case-study-finos-calm: did not cover: Capacity) | Build-run load figures (160 users, p95 106 ms) are prose; needed: the two run reports. |

C-035 | Old release OTRS returns an emoji in an article as U+FFFD (replacement character); Znuny returns it unchanged. | onedroid.ai/llms-full.txt (PAGE /case-study-otrs-znuny: The six differences) | Emoji behaviour is prose; needed: the sealed fixed check output for each system. |

C-036 | The sign-in page under five users: 95th percentile 49 ms on OTRS and 54 ms on Znuny in set 1, 60 ms and 59 ms in set 2. | onedroid.ai/llms-full.txt (PAGE /case-study-otrs-znuny: What was the same) | p95 values are prose; chain verdict carries only counts, not timings. |

C-037 | The six runs of the first set took about 8 minutes. | onedroid.ai/llms-full.txt (PAGE /case-study-otrs-znuny: The result) | Duration is prose; chain shows comparison_open 2026-10-05T17:22Z and verdict 17:35Z, per-run durations are not published. |

C-038 | Three of the six differences were not found by a keyword search of the Znuny change log. | onedroid.ai/llms-full.txt (PAGE /case-study-otrs-znuny: The six differences; What we take from it) | Change-log search result is prose; needed: the searched change log and queries. |

C-043 | A separate tester (a QA engineer or an agent, never the builder) writes plain scenarios from the ticket and acceptance criteria before the build. | onedroid.ai/llms.txt (Positioning)
onedroid.ai/argus.md (Plain scenarios, not test scripts)
docs.onedroid.ai/argus.md (Is it end-to-end testing?) | Process statement; the skill and role package separate the tester hat from the builder hat, but nothing evidences that scenarios are written from the ticket before the build. |

C-047 | The anchored hash proves priority (scenarios existed first and unchanged), not that the builder never saw them; keeping them unseen is a separate custody mechanism. | onedroid.ai/llms.txt (Positioning)
onedroid.ai/argus.md (Sealed before the build; Not proof the builder never saw the tests)
onedroid.ai/llms-full.txt (PAGE /: FAQ Do I have to trust your closed generator?) | Stated on several pages; a limitation statement with no artefact beyond the text. |

C-051 | A certificate proves what the runner reported and when, not that the runner was unmodified; the control plane signs and anchors what the runner reports and does not re-run the checks. | onedroid.ai/argus.md (The reveal)
onedroid.ai/llms-full.txt (PAGE /: Open where it has to be)
onedroid.ai/llms-full.txt (PAGE /security: Where the verifier runs) | Limitation statement repeated on README, pricing and security; code is consistent (verify only compares anchors) but there is no separate artefact. |

C-065 | Continuous verification runs a reviewed scenario set on a monitor schedule every 15 minutes at the shortest. | onedroid.ai/llms.txt (Key capabilities)
onedroid.ai/argus.md (Continuously and Load and continuous runs)
onedroid.ai/llms-full.txt (PAGE /: Three modes: Continuously) | The 15-minute floor is enforced in the closed control plane; no artefact in the public repo. |

C-066 | The web app answers Is it OK? from scheduled runs only; a hand-started failing run never turns it red and an unmeasured system reads not measured, never green. | onedroid.ai/argus.md (Continuously)
onedroid.ai/llms-full.txt (PAGE /qa-teams: 5. Keep) | The live app bundle contains the labels but nothing shows the rule that hand-started runs never turn it red. |

C-067 | Items a system cannot fix itself are listed under Needs a person, with who acts next. | onedroid.ai/argus.md (Continuously)
docs.onedroid.ai/argus.md (v0.3.53 new web app) | Label exists in the shipped bundle; "who acts next" behaviour is not evidenced. |

C-069 | Compare is the newest part of Argus, in early use; expect it to change. | onedroid.ai/argus.md (New, in early use)
onedroid.ai/llms-full.txt (PAGE /case-study-otrs-znuny: header: in early use)
onedroid.ai/llms-full.txt (PAGE /case-studies: Two studies so far note) | "Early use" is a status statement; the repo shows an internal/compare package and chain shows first compare on 2026-10-04 but no artefact states maturity. |

C-075 | What leaves the customer's boundary is the evidence the control plane needs to adjudicate a verdict, not the customer's data. | onedroid.ai/llms-full.txt (PAGE /security: Where the verifier runs) | Boundary statement; the runner pushes reports to the control plane but nothing independent shows the payload is free of customer data. |

C-083 | From v0.3.37 to v0.3.51 every load duration was ignored, so load numbers taken in that range are not measured and should be re-run on v0.3.52. | docs.onedroid.ai/argus.md (What changed recently, LOAD durations) | Version window is a docs statement; the public repo has no history for v0.3.37-0.3.51 behaviour. |

C-085 | An Argus GitHub app, once installed and linked to a repository, runs the checks on every successful deployment and puts the verdict on the commit. | docs.onedroid.ai/argus.md (Where to go next: Argus on GitHub) | GitHub app described in docs only; no app, workflow or endpoint artefact found on public surfaces. |

C-096 | The runner enrollment token lives 900 seconds. | raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md (Quickstart step 4) | The 900-second TTL is enforced in the closed control plane; stated only in the README. |

C-098 | An Argus environment of your own is available by request. | onedroid.ai/llms.txt (Status note)
onedroid.ai/argus.md (intro)
onedroid.ai/pricing.md (control plane card: hosted, by request) | By-request availability cannot be evidenced from public surfaces. |

C-099 | The Argus control plane is the priced part and is available by request (hosted, talk to us). | onedroid.ai/pricing.md (The OneDroid Argus control plane card: Talk to us; evaluate free at argus-dev; your own environment by request)
onedroid.ai/pricing.md (FAQ What does OneDroid Argus cost?: the hosted control plane is the priced part)
onedroid.ai/llms-full.txt (PAGE /pricing: FAQ What does OneDroid Argus cost?) | Pricing posture is a statement; no artefact. |

C-100 | The Argus release repository is private; the full release requires read access from an Argus operator. | docs.onedroid.ai/argus-quickstart.md (Get access first) | A private repository cannot be evidenced from public surfaces; the repo name is not even given. |

C-103 | OneDroid Synapse is a governed MCP gateway: agents connect to one URL and every tool call is authenticated, policy-checked and written to an append-only audit log the customer owns. | onedroid.ai/llms.txt (Product: Synapse)
onedroid.ai/llms-full.txt (PAGE /synapse: intro and FAQ)
onedroid.ai/llms-full.txt (PAGE /what-is-a-governed-mcp-gateway: What makes it governed?) | Gateway behaviour is page prose; the live endpoint only confirms unauthenticated calls are refused. |

C-104 | Synapse enforces per-tool access control, not just per-integration. | onedroid.ai/llms.txt (Key capabilities)
onedroid.ai/llms-full.txt (PAGE /security: Per-tool toggles)
onedroid.ai/llms-full.txt (PAGE /what-is-a-governed-mcp-gateway: Tool-level access control) | Per-tool toggles are a statement; no public artefact. |

C-105 | Agents never hold long-lived upstream credentials; the gateway holds them (encrypted) and presents them per call. | onedroid.ai/llms.txt (Key capabilities: Credential custody)
onedroid.ai/llms-full.txt (PAGE /synapse: Credential custody)
onedroid.ai/llms-full.txt (PAGE /security: Credential custody) | Credential custody is a statement; no public artefact. |

C-106 | The Synapse event log records caller, tool, arguments hash, latency and result class, and is append-only, queryable and exportable. | onedroid.ai/llms-full.txt (PAGE /synapse: Audit log)
onedroid.ai/llms-full.txt (PAGE /security: Append-only audit log)
onedroid.ai/llms-full.txt (PAGE /privacy: The audit log) | Event-log fields are a statement; no public artefact or schema. |

C-107 | The Synapse event log is included in the free tier and will never be put behind a paywall. | onedroid.ai/llms.txt (Key capabilities and Pricing)
onedroid.ai/pricing.md (free tier bullets and tail)
onedroid.ai/llms-full.txt (PAGE /security: Append-only audit log) | Repeated on several pages; a promise with no artefact. |

C-108 | Synapse and Engram are free for individuals and small teams on the OneDroid-hosted service, with no credit card. | onedroid.ai/llms.txt (Pricing)
onedroid.ai/pricing.md (intro)
onedroid.ai/llms-full.txt (PAGE /synapse: hero) | Free tier is a pricing statement; no artefact. |

C-110 | If usage limits ever arrive they will be published on the pricing page first. | onedroid.ai/pricing.md (free tier note)
onedroid.ai/llms-full.txt (PAGE /terms: 2. The Service) | A promise about future behaviour; no artefact. |

C-111 | OneDroid Enterprise is an annual licence and typical deployments start in five figures. | onedroid.ai/llms.txt (Pricing)
onedroid.ai/pricing.md (Enterprise card and FAQ)
onedroid.ai/llms-full.txt (PAGE /pricing: FAQ) | Price statement only. |

C-112 | Enterprise offers dedicated deployment on the customer's cloud or on-premises with org-wide policy enforcement, PII/PHI screening, SSO and exportable audit evidence. | onedroid.ai/pricing.md (Enterprise card)
onedroid.ai/llms-full.txt (PAGE /enterprise: What you get) | Enterprise feature list is a statement. |

C-113 | Synapse works with any MCP client and any LLM provider; connecting Claude Code takes a single claude mcp add command with a bearer token. | onedroid.ai/llms.txt (Key capabilities)
onedroid.ai/llms-full.txt (PAGE /synapse: FAQ Does Synapse work with Claude Code and Cursor?)
onedroid.ai/llms-full.txt (PAGE /quickstart: Connect Claude Code) | Documented quickstart; no independent artefact for any-MCP-client/any-LLM claim. |

C-117 | Engram is included with a Synapse account and also runs on its own. | onedroid.ai/llms.txt (Applications)
onedroid.ai/llms-full.txt (PAGE /engram: intro)
onedroid.ai/llms-full.txt (PAGE /quickstart: Engram intro) | Inclusion statement. |

C-118 | Engram search combines vector, BM25 keyword and graph search into one fused ranking, with the vector-versus-keyword weighting controllable per query. | onedroid.ai/llms.txt (Key capabilities)
onedroid.ai/llms-full.txt (PAGE /engram: Hybrid search) | Hybrid search described; Engram source and endpoints are not public beyond a 401. |

C-119 | Every Engram write is a commit: objects carry full revision history, any two versions can be diffed and a previous one restored in one call. | onedroid.ai/llms-full.txt (PAGE /engram: Versioned)
onedroid.ai/llms-full.txt (PAGE /quickstart: Every write is a commit) | Commit-per-write history is described; no public artefact. |

C-120 | Engram can be pointed at the customer's own Postgres (bring your own database); documents, chunks, embeddings, history and permissions are rows readable with SQL. It needs pgvector and Postgres 16 is what is tested. | onedroid.ai/llms-full.txt (PAGE /engram: Bring your own database)
onedroid.ai/llms-full.txt (PAGE /quickstart: Your own database)
onedroid.ai/llms-full.txt (PAGE /changelog: 2026-07-18) | Bring-your-own-Postgres is described and in the changelog; no public artefact or schema. |

C-121 | Export is a SQL query: with bring-your-own-database there is nothing to extract from OneDroid. | onedroid.ai/llms-full.txt (PAGE /synapse: No lock-in; FAQ)
onedroid.ai/llms-full.txt (PAGE /financial-services: Operations; What happens when we leave?)
onedroid.ai/llms-full.txt (PAGE /engram: Bring your own database) | Export-as-SQL follows from the same statement; no artefact. |

C-122 | Synapse supports hubs, roles and packs (curated toolsets of tools, skills and knowledge scoped per hub). | onedroid.ai/llms.txt (Key capabilities)
onedroid.ai/llms-full.txt (PAGE /synapse: Packs; Hubs and roles)
onedroid.ai/pricing.md (free tier bullets) | Hubs, roles and packs described only. |

C-124 | Credentials are bound per user, per workspace, per account and encrypted at rest with AES-256-GCM. | onedroid.ai/llms-full.txt (PAGE /financial-services: Whose credentials is the agent using?) | AES-256-GCM is stated with no artefact. |

C-125 | The audit log is tamper-evident and verifiable by a third party (hash chain, Merkle tree, transactional outbox, independent verifier). | onedroid.ai/llms-full.txt (PAGE /financial-services: How do I know the log wasn't edited?; Supervision and records) | Tamper-evidence design is described; the open verifier in argus-runner covers Argus certificates, not the Synapse audit log. |

C-127 | The same mechanism serves a free personal hub and a regulated enterprise deployment. | onedroid.ai/llms-full.txt (PAGE /synapse: Any scale)
onedroid.ai/llms-full.txt (PAGE /engram: Bring your own database) | Broad architectural claim; nothing beyond the sentence. |

C-128 | Synapse, Engram and Argus are held together by one evidence record: the audit entry, the versioned fact and the verdict are the same object. | onedroid.ai/llms-full.txt (PAGE /: For regulated buyers)
onedroid.ai/llms-full.txt (PAGE /enterprise: One primitive: the evidence record) | One-record claim is a design statement; no schema shows the three being one object. |

C-133 | In two quarters the flagship deployment went from can we even use AI here to a running, audited platform. | onedroid.ai/llms-full.txt (PAGE /financial-services: Evidence: Proven where the audits are unforgiving)
onedroid.ai/financial-services.md (Evidence: Proven where the audits are unforgiving) | Narrative statement about a customer deployment; no artefact. |

C-134 | OneDroid does not hold SOC 2, ISO 27001 or HIPAA attestation today. | onedroid.ai/llms-full.txt (PAGE /security: What is not yet true)
onedroid.ai/llms.txt (Security & deployment entry) | A disclosure of absence; no attestation list or trust-centre artefact exists to check against. |

C-135 | Credentials are encrypted at rest, transport is TLS, and the event log is append-only and exportable. | onedroid.ai/llms-full.txt (PAGE /security: What is true)
onedroid.ai/llms-full.txt (PAGE /privacy: Security) | Statement; no artefact. |

C-136 | The OneDroid application completed Google's OAuth application verification, including branding and app-purpose review (changelog dated 2026-07-20). | onedroid.ai/llms-full.txt (PAGE /security: Authentication)
onedroid.ai/llms-full.txt (PAGE /changelog: 2026-07-20) | Verification outcome is stated; no public artefact of the Google review. |

C-138 | User identity is handled by Clerk, giving enterprise SSO via SAML 2.0 and OIDC (Entra ID, Okta, Google Workspace); enterprise deployments have been integrated with customer-managed identity providers. | onedroid.ai/llms-full.txt (PAGE /security: Authentication: Single sign-on) | Clerk is visible in the Argus control-plane bundle only; SAML/OIDC enterprise integrations and customer IdPs are not evidenced. |

C-139 | Security vulnerability reports sent to michal@onedroid.ai get a reply within one business day, an agreed disclosure timeline and credit unless declined. | onedroid.ai/llms-full.txt (PAGE /security: Reporting a vulnerability) | Response-time and credit policy is stated on the site and in SECURITY.md; conduct cannot be evidenced. |

C-142 | There is no 24/7 support rota; OneDroid will be honest about what it can commit to. | onedroid.ai/llms-full.txt (PAGE /about: A small team, reachable directly) | Statement of absence of a rota. |

C-143 | OneDroid does not sell user data, does not use it for advertising and does not train AI models on it. | onedroid.ai/llms-full.txt (PAGE /privacy: The short version)
onedroid.ai/llms-full.txt (PAGE /terms: 4. Your data and credentials)
onedroid.ai/llms-full.txt (PAGE /synapse: About this app) | Privacy-policy statement only. |

C-144 | Humans at OneDroid do not read content passing through the gateway or stored in the Service except with explicit permission, for security or abuse investigation, or where required by law. | onedroid.ai/llms-full.txt (PAGE /privacy: Access to your content; Google user data) | Privacy-policy statement only. |

C-147 | The named subprocessors are Amazon Web Services, Microsoft Azure, Supabase, Clerk, Vercel, OpenAI (embeddings, under terms prohibiting training) and Google Workspace. | onedroid.ai/llms-full.txt (PAGE /privacy: How we share data, Subprocessors)
onedroid.ai/llms-full.txt (PAGE /financial-services: Which third parties see this? (now only says the list is on the privacy page))
onedroid.ai/financial-services.md ("Which third parties see this?": Ours is on the privacy page) | Subprocessor list is a statement; only Vercel (response header) and Clerk (argus-dev bundle) are observable. |

C-149 | Google OAuth tokens are stored encrypted, and Google user content is not retained beyond serving the request unless the user stores it. | onedroid.ai/llms-full.txt (PAGE /privacy: Google user data: Storage) | Statement; no artefact. |

C-150 | The Service is not directed to children under 16, and users must be at least 16. | onedroid.ai/llms-full.txt (PAGE /privacy: Children)
onedroid.ai/llms-full.txt (PAGE /terms: 3. Your account) | Policy text only. |

C-152 | OneDroid is built by Providentia Worldwide, an engineering consultancy working inside regulated enterprise estates (health data, financial trading). | onedroid.ai/llms.txt (Product: About)
onedroid.ai/llms-full.txt (PAGE /about: OneDroid is built by Providentia Worldwide)
onedroid.ai/llms-full.txt (PAGE /terms: 1. Agreement) | Self-description of a consultancy; the Providentia home page was fetched (200) but contains no independent corroboration of client estates. |

C-153 | Providentia Worldwide holds five granted US patents on interlinked N-dimensional blockchain structures and globally verifiable identifiers (US 10,853,354; 11,023,458; 11,604,787; 12,141,127; 12,493,609), with further applications pending in the US and Europe. | onedroid.ai/llms-full.txt (PAGE /about: OneDroid is built by Providentia Worldwide) | Patent numbers appear only on the About page; confirming them needs the USPTO or Google Patents record, which is outside the allowed hosts. |

C-154 | The audit trail behind the OneDroid evidence record is designed on the patented structure. | onedroid.ai/llms-full.txt (PAGE /about: OneDroid is built by Providentia Worldwide) | Design-lineage statement; no artefact. |

C-160 | 80% of surveyed leaders have traced a production incident directly back to AI-generated code and 92% are not confident safeguards would catch an AI-driven failure (Sauce Labs, n = 400, 22 July 2026). | onedroid.ai/llms-full.txt (PAGE /: You already had the incident) | Cites Sauce Labs (internal source id, no link); needs the external survey. |

C-161 | 3.1% of developers highly trust AI output, 19.6% highly distrust it and 66% hit answers that are almost right, but not quite (Stack Overflow Developer Survey 2025, n = 33,244). | onedroid.ai/llms-full.txt (PAGE /: You already had the incident) | Cites Stack Overflow 2025 survey; needs the external survey. |

C-162 | Syntax pass rates for AI-generated code climbed from about 50% to 95% while security pass rates stayed flat between 45% and 55% (Veracode, Spring 2026 GenAI Code Security update, 150+ models, 80 tasks, 24 March 2026). | onedroid.ai/llms-full.txt (PAGE /: You already had the incident) | Cites a Veracode update; needs the external report. |

C-163 | Claude Code Review's check always completes with a neutral conclusion so it never blocks merging, and Copilot's reviews do not count toward required approvals (vendor documentation). | onedroid.ai/llms-full.txt (PAGE /: You already had the incident) | Cites vendor documentation by internal id; needs the external docs. |

C-164 | The largest vendor's hosted agents are not currently eligible for Zero Data Retention or HIPAA BAA coverage (vendor documentation). | onedroid.ai/llms-full.txt (PAGE /: For regulated buyers) | Cites vendor documentation by internal id; needs the external docs. |

C-165 | EU AI Act Art. 12 and Art. 14, DORA Art. 25 and Art. 30, HIPAA 164.312(b) and FDA 21 CFR 11.10(e) line up with the evidence record; using a coding agent does not by itself make a system high-risk. | onedroid.ai/llms-full.txt (PAGE /: For regulated buyers)
onedroid.ai/llms-full.txt (PAGE /enterprise: The box) | Regulatory alignment is an assertion; no mapping document is published. |

C-166 | OneDroid (onedroid.ai) is unrelated to Android and to the open-source Android projects also called OneDroid. | onedroid.ai/llms.txt (intro)
onedroid.ai/llms-full.txt (PAGE /: preamble)
onedroid.ai/llms-full.txt (PAGE /about: Which OneDroid this is) | No artefact beyond the sentence; non-affiliation is a negative statement. |

C-170 | The company publishes limitations alongside capabilities and does not make a claim that cannot be verified. | onedroid.ai/llms-full.txt (PAGE /synapse: Why OneDroid: Honesty) | General conduct claim (C-rated); limitations sections exist on case studies but "no unverifiable claim" is not checkable as a whole. |

C-173 | Each of the three quickstart tasks takes about ten minutes, needs no credit card and ends with a check the reader runs. | onedroid.ai/llms.txt (Docs: Quickstart)
onedroid.ai/llms-full.txt (PAGE /quickstart: intro) | Timing and no-card claims for the quickstart are stated; not independently checkable without an account. |

C-174 | Synapse's Google data is used only to execute requested actions and access can be revoked at any time. | onedroid.ai/llms-full.txt (PAGE /synapse: About this app)
onedroid.ai/llms-full.txt (PAGE /privacy: Google user data) | Privacy-policy statement. |

C-175 | Synapse logs every tool call fail-open: a logging failure never blocks a call. | onedroid.ai/llms-full.txt (PAGE /synapse: Prove: Every call is logged, fail-open (a logging failure never blocks a call))
onedroid.ai/llms-full.txt (PAGE /security: Append-only audit log: fail-open: a logging failure never blocks a call)
onedroid.ai/llms-full.txt (PAGE /enterprise: Audit log: logged fail-open, so logging never blocks a call) | Fail-open logging is stated; no artefact. |

C-177 | The flagship deployment is a US enterprise handling regulated clinical data. | onedroid.ai/financial-services.md (Evidence: Proven where the audits are unforgiving)
onedroid.ai/llms-full.txt (PAGE /financial-services: Evidence) | Customer description is a statement; no artefact. |

C-181 | An mcp step shows its claims as written, and the author's report no longer carries a value the system returned (v0.3.72). | docs.onedroid.ai/argus.md (What changed recently: An mcp step shows its claims as written (v0.3.72)) | Release note only; no corresponding code found in the public clone. |

C-183 | An http step whose response body is over 1 MiB reads error when it has a body claim or a save, and the chain's deadline adds each polled step's poll.timeout (v0.3.71). | docs.onedroid.ai/argus.md (What changed recently: Two chain fixes (v0.3.71)) | Release note only. |

C-185 | A running run shows its counts so far and planned; a step can save a JSON value and send it in a later step; ## TIMEOUT governs a browser check, up to 300 s (v0.3.70). | docs.onedroid.ai/argus.md (What changed recently: Running counts, JSON saves and text bodies (v0.3.70)) | Release note; the public parser shows TIMEOUT handling with a 30 s ceiling for some modes, not the 300 s browser limit. |

C-199 | Hand-started runs can say what they are for with intent, expect and note (v0.3.53). | docs.onedroid.ai/argus.md (What changed recently: A new web app (v0.3.53)) | The public builder runner__run takes scenario_ref, tag and layer only; intent/expect/note are not found in the public code. |

C-211 | The CLI full release is downloaded from a private GitHub repository with gh release download and checked against SHA256SUMS; the CLI builds for linux_amd64, linux_arm64, darwin_amd64 and darwin_arm64. | docs.onedroid.ai/argus-quickstart.md (Section 1: Get access first / Download the latest release) | Release download from a private repository cannot be evidenced; the build matrix is not in the public repo. |

C-213 | No credit card is needed to start with OneDroid Argus (home page). | onedroid.ai/llms-full.txt (PAGE /: The runner runs inside your environment, and its source is open under MIT. No credit card.) | Statement; no artefact. |

C-216 | Synapse connects Google Workspace, Atlassian, Slack and other services; access exists only for accounts the user explicitly connects, and disconnecting an account ends Synapse's access to it. | onedroid.ai/llms-full.txt (PAGE /synapse: About this app)
onedroid.ai/llms-full.txt (PAGE /terms: 7. Third-party services) | Connection scope is described only. |

C-217 | A Synapse API token is bound to one user and one hub, inherits that user's current role in the hub, and its plaintext is shown once. | onedroid.ai/llms.txt (Connecting an agent)
onedroid.ai/llms-full.txt (PAGE /quickstart: Create a token) | Token binding is described in the quickstart; no artefact. |

C-219 | Enabling a service on a hub and saving a login for it are two different actions, and only the second lets an agent call anything. | onedroid.ai/llms-full.txt (PAGE /quickstart: The step that catches everyone) | Described only. |

C-220 | An Engram library token reaches one library and nothing else; Engram can also be reached through a Synapse hub where the Engram connection is already on and every call is audited. | onedroid.ai/llms-full.txt (PAGE /quickstart: Engram steps 01 and 02) | Token scope is described only; the endpoint only shows it refuses unauthenticated calls. |

C-221 | Self-hosted Synapse removes OneDroid from the data path entirely; in the hosted topology tool payloads pass through the gateway in order to be routed. | onedroid.ai/llms-full.txt (PAGE /security: What is true; Data visibility: Hosted) | Topology visibility is described only. |

C-224 | Policy decisions are recorded at the moment they were made, not reconstructed from logs; credentials are individually revocable and never sit in a connection string. | onedroid.ai/financial-services.md (Build or buy: "What can this agent reach, and who decided?" and "Whose credentials is the agent using?") | Described only. |

C-226 | The audit log hashes tool-call arguments and results rather than storing content, though the policy cannot promise that no fragment ever appears in error telemetry. | onedroid.ai/llms-full.txt (PAGE /privacy: What we collect: The audit log) | Hashing of arguments is described only. |

C-228 | If the free hosted Service is discontinued, OneDroid will give reasonable notice and a window to export data; the free Service is not a backup system. | onedroid.ai/llms-full.txt (PAGE /terms: 2. The Service; 4. Your data and credentials) | Policy promise. |

C-230 | Enterprise deployments have been integrated with customer-managed identity providers, including organisations running an internal IdP alongside Entra. | onedroid.ai/llms-full.txt (PAGE /security: Authentication: Single sign-on) | Customer integration is stated; no artefact. |

C-231 | The OneDroid application's signed-out page was reworked to state its purpose up front and to render fully without JavaScript as part of Google's verification review. | onedroid.ai/llms-full.txt (PAGE /changelog: 2026-07-20) | Changelog statement; today the GET shows only a JavaScript shell, so no static purpose text was observed (the reviewed page may have been a different one). |

## Sources as fetched

Every verdict above points into one of these files. To check one, fetch the URL with a browser user-agent and run
sha256sum on the bytes; a different fingerprint means the page changed after 2026-10-27.

Source | HTTP | sha256 as fetched |

https://onedroid.ai/llms-full.txt | 200 | `a5985e30bcbe976075c28b0ace8a942cc258433bb879e057b240cf9dc94516ec` |

https://onedroid.ai/llms.txt | 200 | `f285fa6182ae804a1437d01cff91e3587e42e6b2c5f23f8f0c06ee437831228c` |

https://onedroid.ai/argus.md | 200 | `607d6f2aef910299db4995c69aefd307a15fb121901d89be43db7080db12acc8` |

https://onedroid.ai/pricing.md | 200 | `f9a5be4c2655f38b040a7110fead2a7c39601bcd002597be50be7bd85c4a3131` |

https://raw.githubusercontent.com/OneDro1d/argus-runner/main/README.md | 200 | `0ed0b1601066cc3af46b0a3a9ddd060d03647afebc972103fab279db3cb75ef5` |

https://docs.onedroid.ai/argus-quickstart | 200 | `be097aa5a0256c2755ca0d226ecbffb3cffe74d8f304ce06a960a3ebb0fc3bc3` |

https://docs.onedroid.ai/argus-quickstart.md | 200 | `a2ced85ad2b4acf0522ec81374b482385e1aac4bc8152eaae3ee7c3d2b289e2a` |

https://docs.onedroid.ai/argus | 200 | `f49ffe7608f413d215a1938ba59fb5ac89d3eca222bfdc075396b9e331624484` |

https://docs.onedroid.ai/argus.md | 200 | `967677037718820876bf597b09e97eca05f5c486f0990409ee3b70815706721e` |

https://api.github.com/repos/OneDro1d/argus-runner | 200 | `3ebaba13824d5f289a3b6842f7e1db12092b0a7fe208eb7d84155d0a17d5bfdf` |

https://onedroid.ai/partners.md | 404 | `674247ef0d515db62acf99780d964a7760ac707739c370ae44270c6dc35005ec` |

https://onedroid.ai/partners | 404 | `aa8baae40f1124a5d853fa35d91e75c18c73f014a92f555c80118c3447216ade` |

https://onedroid.ai/financial-services.md | 200 | `1ab99a3749bf47be5ebdbad9c818e560cfea21b3afc64062b94d62b285881311` |

https://onedroid.ai/partners-financial-services | 200 | `dd378ba637161a20544282f4250806706dd5cff6bf7640139f55b23e21b0737d` |

https://onedroid.ai/partners-financial-services.md | 404 | `the page has no markdown twin and no PAGE block in llms-full.txt` |