# The Proof guide

Set up Dbrij Proof step by step: what you need, what to press, and how you know each step worked.

Canonical page: https://dbrij.com/products/proof/guide

## Set up Proof, step by step

By the end every feature of your app is mapped, checked, and rechecked after each deploy, with regressions called out.

Before you start, have these ready

- An app on Dbrij Hosting or a GitHub repository, and a deployed address the checks can reach. AI credits for mapping.

1. ### Watch a target

  Point Proof at a repo and the address it runs at. Open Targets, press Watch a target and pick a Dbrij Hosting service or a GitHub repository with its branch.
  [Open Targets](https://dbrij.com/proof)
  You will know it worked when the target is listed on Targets.
2. ### Let Deputy map it

  Every feature, with the endpoints behind it. The scan starts by itself once the target is added, and runs on AI credits.

  You will know it worked when the target shows its overview and a list of features.
3. ### Run checks

  Each feature probed against the live app. Open the target and press Run checks.

  You will know it worked when each feature shows whether it works.
4. ### Turn on automatic scanning

  Recheck after every deploy and daily. It is on for a new target; if the target says automatic scanning is off, press Resume.

  You will know it worked when the Updates tab fills after the next deploy or the daily sweep.
5. ### Write journeys

  The flows a person would recognise, checked end to end. On the target’s Journeys tab press Write the journeys, then Play on any one of them.

  You will know it worked when each step of a journey comes back with a plain verdict.

## Questions people ask

### Does Proof change my code?

No. It only reads the code and writes the map beside it.

## How each part works

### [What Proof is](#what-proof-is)

Proof reads your code to list every feature, then probes each one against the live deployment. After each deploy and in a daily sweep it rechecks, and Updates explains in plain words what changed.

Most teams do not have an honest answer to the question "what does our app actually do". The documentation was written once and drifted, the person who knew has left, and the only complete record is the code itself, which most of the company cannot read. Proof closes that gap: Deputy, Dbrij's AI, reads the actual codebase and writes a feature map in plain language.

The result is not a report that goes stale in a drawer. Each thing you watch is a **target** carrying a living map: an overview of the system, an inventory of its features, and the scan history behind them. Rescan after the code changes and the map moves with it.

### [Connecting a target](#connecting-a-target)

A target is one system under watch, and it comes in two kinds:

- **A GitHub repo.** Pick the repository and the branch, and Deputy reads the code as it is on that branch.
- **A Dbrij Hosting service.** Point Proof at a deployed service and the repo behind it comes along by itself. The target then also shows a live hosting health panel, so the map sits beside whether the thing is actually up.

Targets live in your personal space or in a company, so a solo developer's side project and a company's product sit each where they belong.

### [What a scan produces](#what-a-scan-produces)

A scan is Deputy walking the codebase and writing down what it found. Opening a target shows the result as a system map:

- **An overview**: what the system is, said in plain language a product manager can hand to anyone.
- **The feature inventory**: every capability listed with where it lives in the code, how confident the scan is about it, and its current health.
- **Entry points**: the routes and endpoints read straight out of the code, which is what makes a feature checkable rather than just described.
- **Checks and journeys**: endpoints are probed and each feature shows how much of it actually answers. Journeys go further: Deputy writes whole processes end to end, anyone presses play, and each step comes back with a plain language verdict.

A scan is honest about its own limits. If Deputy could describe the system but not read any routes, or read the routes but not finish the write up, the map says so on a banner and tells you a rescan will fill the gap.

### [Keeping the map honest](#keeping-the-map-honest)

A map is only useful while it is true, so Proof is built around the rescan. After a push, rescan the target: new features appear in the inventory, and features that no longer exist in the code are archived rather than silently deleted, kept behind a show archived toggle.

- **Your words survive.** Edit any feature's wording and rescans never overwrite what you wrote. The scan updates the facts; you own the language.
- **Health is summarised up top.** The target shows counts per health state, so a map full of broken endpoints cannot look fine at a glance.

### [Good to know](#good-to-know)

- A passing test suite doesn’t mean the features work; Proof checks the running app.
- Mapping, journeys and the written updates draw on AI credits; running the checks does not.
- Automatic scanning can be paused; the buttons still work.

- **Scans run on Deputy**, so they draw on your AI credits, managed from the AI credits page in the rail.
- **Proof works in a personal space or a company.** In a company, who can use it is granted on the [Access](https://dbrij.com/product-access/proof) page.
- The subscription covers AI system scans of your connected repos, a living feature inventory with confidence levels, an editable map your rescans never overwrite, and targets for deployed services and bare repos alike.
- **The map is a foundation.** It is the base the checks and journeys already run on, and for attaching evidence of working features to milestones.