By participating you agree to the Code of Conduct.
If you are integrating Proofable into a product, use docs.proofable.me and the live product first. The table below is for people proposing changes here.
| Need | Where |
|---|---|
| Product documentation | docs.proofable.me |
| Possible bugs | Issues |
| Ideas and questions | Discussions |
| Security reports | dev@proofable.me (do not post publicly) |
| Release notes | CHANGELOG.md |
The published documentation at docs.proofable.me, the OpenAPI description, and the public verifier catalog. Client code lives in proofable/sdk; MCP discovery metadata lives in proofable/mcp.
- Corrections where a page no longer matches what the live product does.
- Verifier proposals that spell out the user-visible outcome you want.
- Runnable examples, and the errors a builder will actually hit.
Do not share keys, tokens, bearer secrets, or private proof content in public issues or change descriptions.
The public verifier catalog lives in this repo: JSON Schemas under verifiers/schemas/ and the machine index at verifiers/VERIFIERS.json. Open a Discussion first, then a PR with the spec, the schema, and the docs page together. After merge, the check appears in the live catalog. See Propose a verifier.
Put a user-facing note under ## [Unreleased] in CHANGELOG.md. Use Added, Changed, Deprecated, Removed, Fixed, or Security. Write what a builder will notice. Leave out ticket IDs, private repository names, and process notes.
These paths are local-only or generated elsewhere (see .gitignore):
.env,.npmrc, secrets, and key material- Generated OpenAPI output and build artifacts
Explain what builders or end users will experience differently (for example new fields, new errors, or renamed concepts). If you adjust verifiers or any documented HTTP surface, keep the written API reference and examples in step with the live product.