doloop gives your generative AI a firm grip on reality.
Frontier models drift off your requirements faster than a human-in-the-loop can catch. doloop is a separate check that sits outside your model and reads the output against its source: code against the codebase it landed in, a figure against the page it came from, and the same for a draft or an answer.
It shows you what those thousand lines actually did - where the work does not fit, with the line and the evidence. You bring the model that writes in seconds; doloop is how you read what it wrote before it ships.
Same input, same verdict, every run, at the volume your AI writes. You can replay that. You can't replay a model's mood.
same input, same verdict, every run. you can replay that.
Start with code, where the stakes are highest
AI writes code that looks right and ships broken. The code check is a deterministic check that reads your whole codebase, works out the conventions it already holds, and blocks a commit only where a change breaks one, with the line and the rule. The same code in, the same verdict out, every run.
That reproducibility is the point for a team that has to answer for what ships: a verdict you can re-run and audit, identical every time, is a check a reviewer can actually sign off on before an AI agent's change goes in.
How it works
An AI cannot reliably check its own work, because it shares its own blind spots. The judge has to sit outside the model: something that reads every answer and refuses to pass it until it holds up.
→ ship
doloop runs as a local check in your pipeline: the gate and its memory sit on your machine, your source never leaves it, and you bring your own model. When a check fails it hands the specific problem back to your AI for a revision, then re-checks.
Have your agent talk to our checks.
Your AI sits behind your own agent; your agent calls our checks, and a failed check hands the specific problem back for a revision. The difference: ours is deterministic, and it returns the same verdict however your AI phrases the output.
One verdict per input
doloop checks the AI's output with fixed rules. The mechanical lenses give one result for a given input and reproduce it exactly when you re-run. Where a test must read for meaning, a cheap AI check on a pinned prompt gives an advisory reading instead. Either way it points at the exact line that is wrong, and it never writes your output. These checks are small, single-purpose tests that run against your AI.
It makes the AI fix it
When the check fails, doloop hands the exact problem back to your AI and asks for a fix, then checks again, and again, until the answer passes. You get a result that has been worked over, not a first draft.
You bring the intelligence
Your AI does the smart part. We add the one thing it cannot do for itself: stand outside its own work and tell it what it did. You bring the model; doloop is the fixed point it cannot be for itself.
And it compounds
Where your work recurs, doloop reuses what it learned. The rules you confirm are applied on every later call, per tenant, in the check today. A vendor's table layout becomes a saved template, so the next document is faster, cheaper, and more certain, and the same memory is expanding across every machine.
Use doloop when…
Each one runs locally as one command, doloop gate, and returns the same verdict every time. A hosted endpoint is available for teams that prefer it.
Your agent loops
A model in a loop can't see its own loop. doloop catches the repetition from outside.
Output drifts or slides back
It regresses to a bug it fixed a moment ago, or wanders off task. doloop flags the drift.
The model pads with slop
Hedges, jargon, dead cadence, self-management tics. Each tell flagged with a line.
A number won't tie out
A figure that isn't in the source, a total that won't reconcile. The documents check catches it.
You need it reproducible
Same input, same hash, same verdict, every run. An audit artifact, not an opinion.
You want human triage
Gate on the verdict and route only the failures to a person, not every line.
Connect the doloop machine to your pipeline
The machine is doloop's loop and memory wrapped around the checks. Send any answer your AI produced to it, the checks run against the text, and a verdict comes back, identical on every call. We store nothing and never touch your model.
# send any AI output to the machine, get a deterministic verdict back
curl https://api.doloop.io/v1/check \
-H 'content-type: application/json' \
-d '{"text": "the answer your model just produced"}'
# -> {"verdict": "pass", "findings": [...], "input_sha256": "..."}
# same text in, same verdict out, every time. live now.
Or from your terminal, as a gate in any pipeline:
# install once pip install doloopio # exit 0 = pass, 2 = fail, so you can gate a publish on a clean verdict doloop check -f draft.md && publish draft.md doloop design https://your-site.com # deterministic design review of a live page
Wire it in, not around
Send your AI's output to the machine, or point your client at it as a drop-in. The checks run, the loop runs, and clean output comes back. No rip-and-replace, no new model to learn.
A gate, not a tool
You don't hope your AI decides to check itself; it won't. doloop is wired into the loop as a gate the output has to pass, run against the model, not pulled in by it.
Your account, your memory
Keep your own account with your model provider, and switch models whenever you like. doloop never swaps your model. The codebase rules you build up stay yours, and leave with you if you go.
The check endpoint is live at api.doloop.io/v1/check. Run the call above right now. Want the full loop with your own tenant memory and an audit record? Talk to us.
“You can work with your own model, but you can't ask it to check itself. Connect doloop and put a deterministic check outside it, one that reads your output against your own rules and returns the same verdict every run.”
One machine, every kind of output
doloop is one machine: the loop and the memory. Point it at a kind of output and it runs the checks for that job. Same machine, same loop, different checks. Switch on the modes you use.
Check what your AI changed in your code
Read a repo you never opened, then gate a change against the codebase's own conventions. It blocks a commit that breaks one, with the line and the rule, and returns the same verdict every run. Local, bring your own model.
See the code check →Pull data you can trust from documents
Every value located at its exact spot on the page, never generated. When a figure isn't there, the cell stays empty. Deterministic PDF table extraction: 100% reproducible across 90 runs, zero errors on 2,332 cells.
See the extraction →Write with AI and still sound like you
DOMAINS reads where a draft sits across seven dimensions of voice and names the one change toward the voice you want, the same read every run. It never rewrites for you.
Score your draft →A site chatbot that can't make things up
Answers built only from your own pages, or it says it does not know. No model runs on the answer path, so it cannot invent one. It refuses a question your content cannot answer.
See the answer engine →Machine-readable catalog: /api/v1/machines/ · /api/v1/tools/ · openapi.json
Why an adversary, why now
Two documented trends point the same way. Models are getting more capable, and capability comes with more shortcutting, not less. Tokens are getting cheaper, so teams generate more output, which means more places for a shortcut to hide. The need for an external, deterministic check widens on both axes at once.
Bigger models shortcut more
Per the research, larger models are more likely to exploit shortcuts during inference. A better model will not fix this, because it cannot grade its own work. Frontier progress expands the need for a deterministic adversary rather than shrinking it.
Determinism where it can be had
The verdict is byte-identical for byte-identical input wherever the check is mechanical. Where a check has to read for meaning, that reader is pinned and advisory, bounded rather than byte-identical. The tokenizer, the baseline rules, the loop spec are open and versioned, so anyone can run them and check the result. The only private things are your memory and your data.
The bill is an audit artifact
Because the verdict is deterministic, so is the price: the amount is a function of the work, not a black box you have to trust. For a regulated buyer, that makes the invoice itself something you can audit.
Outside the model definition
On April 17, 2026, the Federal Reserve, OCC, and FDIC issued SR 26-2 (guidance PDF), replacing SR 11-7 after 15 years. The new framework explicitly excludes deterministic rule-based processes and software from the definition of a "model," and so from the full model-validation burden.
For CFOs and model-risk teams: a deterministic rule-based check, with no statistical model underneath, is not a "model" by this definition, so it does not carry the same model-validation expectations. SR 26-2 is non-binding guidance, not a safe harbor, and the model you bring stays in scope, so your counsel makes the final call. That is why the adversary has to be deterministic, not another model. The full framing, with primary sources →
How you pay
Honest and predictable, and entirely separate from what you spend on AI. We charge for the verification, nothing else.
We never touch your AI bill
You pay your model provider directly; we never sit in your token margin. As AI prices fall, your bill with us doesn't move.
Not for the retries
You are billed for a clean, verified result, not for how many rounds it took to get there. Fewer rounds are cheaper for you and for us, so our incentives line up.
Self-verifiable by design
The amount follows deterministically from how much you ran, computed by an open, versioned method you can run yourself. Reproduce your own invoice. No surprises, no trust required.
Provisioning, free trial, and tenant onboarding are rolling out now. Talk to us to stand up a loop.