> ## Documentation Index
> Fetch the complete documentation index at: https://docs.proofable.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Propose a verifier

> Add a new Proofable check by opening a discussion, then shipping the schema, catalog row, and guide page.

Public check schemas and the catalog index live in this repository. Open a pull request here. After it merges, the check appears in the live catalog. You do not need access to Proofable infrastructure.

## Before you write code

Open a [Discussion](https://github.com/proofable/docs/discussions) describing:

* **Who** the check is for (a person, an app, or an agent).
* **What** it proves (identity, ownership, permission, safety).
* **Inputs** the integrator supplies. No PII. Deterministic for identical inputs.
* **Outcome** the user sees (verified, processing, failed) and what it unlocks at a gate.

A reviewer will confirm whether the check belongs in the public catalog or is better handled by composing existing checks.

## What a new check needs

| Artifact | Where | What it holds |
| - | - | - |
| Input JSON Schema | `verifiers/schemas/<id>.json` | Request shape an integrator sends |
| Catalog index entry | `verifiers/VERIFIERS.json` | ID, description, flow, tier, interaction, API flags, schema path |
| Guide page | `verification/<id>.mdx` | Integrator-facing guide; linked from `verification/verifiers.mdx` |
| OpenAPI examples | `openapi/public-api.json` | Request and response examples if the shape is new or changed |
| Changelog entry | `CHANGELOG.md` | User-visible change under `[Unreleased]` |

## Conformance

A public check must:

* Return deterministic outputs for identical inputs.
* Carry no PII in inputs or outputs.
* Document external API usage with rate limits and error handling.
* Note gas or performance considerations if it anchors on-chain.

## Submitting a PR

1. Add the input JSON Schema at `verifiers/schemas/<id>.json`.
2. Add the catalog entry to `verifiers/VERIFIERS.json` with `tier: "public"`, the schema path, flow, interaction, and API flags.
3. Add a guide page at `verification/<id>.mdx` and link it from `verification/verifiers.mdx`.
4. Update `openapi/public-api.json` examples if the request or response shape changed.
5. Add a `[Unreleased]` entry in `CHANGELOG.md` describing what builders will see.

Run the public check before requesting review:

```bash theme={"system"}
npm run validate
```

## What not to include

* No wallet addresses or private env names.
* No outcomes the live API does not return. Confirm from running code or tests before documenting a result.
* No second catalog. `verifiers/VERIFIERS.json` is the public index.

## Related

<CardGroup cols={2}>
  <Card title="Verifier catalog" icon="list-tree" href="./verifiers">
    Current public checks.
  </Card>

  <Card title="Verifier schemas" icon="code" href="../verifiers/README.md">
    Request shapes.
  </Card>

  <Card title="Signing format" icon="file-signature" href="./signing-format">
    How a request is signed.
  </Card>

  <Card title="Discussions" icon="comments" href="https://github.com/proofable/docs/discussions">
    Propose before you code.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.