Sawabona documentation

Everything here is for someone using Sawabona: issuing licences, selling against them, running the engine on their own infrastructure, or auditing a proof it produced.

Nothing here depends on anything unpublished.

Start here

• Getting Started — a validated licence in five minutes: server → product → plan → licence → SDK
• Reference — the same ground at length, plus the CLI, the API surface, security practices and troubleshooting
• License service guide — revoke, rotate, transfer, heartbeats, offline tokens

Selling your software

• Selling your product with Sawabona — collect the money in your payment account, and have the licence stop when the payment does
• Payment provider integration — wiring a provider, step by step
• Payment architecture — the plugin design, which events create a licence, and whose account collects

Reference

• Architecture — the packages, and which SDK to pick
• Quick reference — the commands and calls you reach for most
• Environment variables — every prefix and convention
• API Reference — every endpoint, with request and response shapes. The machine-readable surface is the OpenAPI document the running engine serves at /api-docs/openapi.json
• API Schemas — the types
• CLI Reference — every command
• Refusal codes — the stable code beside every refusal, and what each one asks the holder to do. Four of the five licence refusals answer HTTP 400, so the status alone does not say which
• Notification channels — where security alerts go
• Telemetry schema — what the engine records, and for how long

Client SDKs

• Client SDKs — nine languages, one proof kernel, so a proof computed in any of them is byte-identical
• Using sawabona-core as a library — embedding the engine in your own Rust binary

Running it yourself

The BUSL's Additional Use Grant lets you operate the engine on infrastructure you own. These are yours, not ours.

• Deployment Guide — self-hosting the engine
• Production security checklist — before you take real money through it
• Secrets management
• Security hardening
• Encryption at rest

Verifying what it produced

The proof protocol is published so an independent implementation can be written from it, and so an auditor can check a proof without asking us. The kernel is Apache-2.0 for the same reason.

• How Geometric Proof actually works — two worked examples
• Geometric Proof specification — the protocol, including how the figure family is derived rather than announced
• Entitlement signing (Ed25519) — what a client can verify on its own
• Threat model
• Security overview
• Open-source security — why the algorithms are public and only the keys are not
• Greek figures · Zodiac figures — two of the three collections a challenge can draw from. Which one it draws from is derived from the bootstrap secret and cannot be configured

Working on Sawabona itself

The licence invites it: you may use, copy, modify and redistribute the engine to license and distribute your own software. So the documents you need for that are published, not kept back.

• Developer guide — the layout, the crates, how the pieces fit
• Testing — the suite, and how to run it against a real Postgres
• Project structure — the file tree
• Releasing — cargo-dist, for your own builds as much as ours

Contribution process: CONTRIBUTING.md.

---

Questions and issues: https://github.com/theAIstep/sawabona/issues