Skip to content
Reality Graph
DEEN

Product

How Reality Graph works: one run, from a sentence to a verdict

Reality Graph preparesYour taskMissionContextYour coding toolnot oursReality Graph verifiesChecksEvidenceVerdictthe tool writes the code, we establish what happened
How Reality Graph works: you type the task as one sentence in the coding tool you already use. Reality Graph records the run and its mission before the first edit, bounds the context to it, then executes the approved checks itself and reads the changed files out of Git. One verdict at the end, and accepting it is your call.
Request accessExplore features

Last updated:

The loop

Six stages, and the one that writes code is not ours

Nothing here asks you to fill in a form or approve a plan. You type the task into the coding tool you already use; Reality Graph records the run before the work starts and establishes what happened after it ends.
  1. 01You and your tool

    You type the task

    One plain sentence, in your coding tool, the way you always write it. No new interface to learn.

  2. 02Reality Graph

    The run is recorded before work starts

    A prompt-submit hook persists the run and its mission first, so the yardstick exists before the first edit rather than being reconstructed after it.

    Read more
  3. 03Reality Graph

    Context is bounded and scrubbed

    The tool receives what the mission declares, in a fixed order, with credentials removed before the prompt is assembled.

    Read more
  4. 04You and your tool

    Your coding tool writes the change

    Codex, Claude Code, whichever you run. Its login, approvals and model controls stay untouched, and Reality Graph never edits your source.

    Read more
  5. 05Reality Graph

    Checks run, evidence comes from Git

    At the stop boundary Reality Graph executes the approved checks itself and reads the changed files and diff out of the repository.

    Read more
  6. 06Reality Graph

    One verdict, and your decision

    Verified, verified with limitations, or blocked, computed the same way every time. Accepting it is the human step, and nothing is committed or pushed without one.

    Read more
One governed run. Reality Graph never performs the stage where code is written, which is why it works beside a coding agent rather than competing with one. Every stage links to the page that documents it.

In practice

One sentence in your own tool, and a record you did not write

Nobody adopts a workflow that starts with filling in a file, so this one does not. You install the hooks once per project, then keep working exactly as you did.

Claude Code, with Reality Graph observing

Example – illustrative session, not real run data
$ realitygraph integrate claude
  hooks written to .claude/settings.json   (reversible, project-scoped)

$ claude
> Fix the checkout validation bug without touching payments

  reality graph   run rg-4f2a recorded before the first edit
  …Claude Code works…
  reality graph   stop: 3 changed files read from Git
                  pytest -q executed  ->  exit 0
                  verdict BLOCKED - protected path changed:
                  src/payments/gateway.py

Nothing in that session asked you to approve a plan. The prompt-submit hook records the run and its mission before Claude Code starts, and the stop boundary is where Reality Graph reads the repository, executes the approved checks and writes one review. There is no second command to run.

The human step is at the other end. A verdict is a signal, not a decision: you accept it or you do not, and nothing gets committed or pushed without that acceptance. The facts underneath come from the repository, so a run is never judged on the model’s own account of it. Git is required, and capture stops above 500 KB of scrubbed diff.

By design

It sits between your coding tool and your review, and replaces neither

Every line below is a decision, not a gap. A layer that claimed both neighbours\u2019 jobs would be trusted for none of them.

What you get

  • Turn one sentence into a contract you confirm, with acceptance criteria that cannot be empty.
  • Bound the context to what the contract declares and remove credentials before the prompt exists.
  • Execute the approved checks itself and record the exit code it observed.
  • Read changed files and diffs from Git and compute one deterministic verdict.
  • Leave a local record: runs, receipts and evidence in plain files you can export.

What it is not

  • Write, fix, stage, commit or push your code.
  • Prevent anything. A protected path is detected afterwards, never intercepted.
  • Replace review, CI or a sandbox. It has no pipeline integration and no isolation.
  • Work as a team tool. One operator, one machine, no accounts and no shared history.
  • Prove your code is correct. The verdict is a signal for your team, not a certificate.

Each stage has its own page: the contract, the context pack and the verdict. Which tools it runs beside is covered on integrations.

Questions people actually ask

Do I have to write the mission myself?
No, and you are not asked to approve one either. The prompt-submit hook derives the goal, the requirements, the expected paths, a floor of protected paths and the test command from your own sentence, and records them before the first edit. You can still write a mission by hand, and the automation form asks for an explicit confirmation, but the everyday path does not interrupt you.
How is this different from code review or a linter?
A linter judges the code in front of it. A reviewer judges the change against their memory of what was asked. Reality Graph judges the run against a contract written before it started, using changed files it reads out of Git. It answers whether this was the requested change and whether it stayed inside its boundaries, not whether the code is good.
Does Reality Graph write or fix code?
No. That is the stage in the chain that is deliberately not ours. Your coding tool writes the change, and Reality Graph does not write your source, stage your index, commit or push.
Can a green test suite still end blocked?
Yes. Blocking conditions are evaluated separately from check results, so a run whose tests all pass is still blocked if a protected path changed or a required result is missing. There is a test in the product that asserts exactly this.
Which coding tools does this work with?
The Codex CLI and Claude Code are bound through reversible project hooks, which is what makes the automatic recording possible. Every other tool works beside Reality Graph with a prompt you paste yourself, and Reality Graph never injects into, launches or reads back from another tool.

Run one change through the loop and read the record

The interesting moment is not the verdict. It is noticing what the record says that nobody would have written down otherwise.

Request accessExplore features