Quickstart

What you can do now

The public preview is illustrative. The authenticated product can connect the configured GitHub App and process authorized pull-request events through the isolated runner. A run may still stop on missing configuration, an unsupported recipe, a stale head, or an infrastructure or delivery failure.

1. Inspect the public proof flow

Open the interactive example, or use Inspect the proof flow on the home page. The data and repository shown there are simulated. Use the flow to inspect how Deton presents a candidate, proof state, verdict, and illustrative publication fields; do not treat it as a run against your code or as a captured artifact.

2. Read the state definitions

Read Core concepts before interpreting the example. In particular:

• a candidate is not a confirmed vulnerability;
• unsupported, inconclusive, stale, and error do not establish safety;
• no candidate found does not establish safety;
• only confirmed can make supplied fields eligible for in-memory security-issue construction; it does not prove live execution, delivery, or canonical publication.

3. Create an account and connect GitHub

The sign-up page creates an account. After authentication, the Dashboard, Runs, Repositories, Coverage, Packets, and Integrations surfaces can be inspected. Empty states are expected when no repository is connected.

Open Integrations, install the configured GitHub App for the repositories you authorize, and return to Deton after the callback completes.

4. Open or update a pull request

An authorized pull_request webhook creates an idempotent run. Deton re-reads the PR head, fetches the exact diff and commit archive, stages a short-lived hash-bound source reference, and asks the isolated runner to execute only a supported recipe. The final head is checked again before GitHub output.

Boundaries that still apply

You cannot rely on a quiet, empty, unsupported, inconclusive, stale, or failed result as a safety statement. Only supported recipes and proof-enabled families can attempt sandbox confirmation, and only a fully accepted observation can become a publishable finding.

The public demo and checked-in fixture remain synthetic examples; they are not evidence about a customer repository.

Before granting GitHub access

Review GitHub access before installation. It records the exact checked-in permission manifest and explains why write access is limited to check runs and pull-request comments, not source changes.