Documentation

The NEBULA documents

One normative specification and five guides, rendered directly from the specification repository at e44c684. Nothing on these pages is transcribed by hand, so nothing on them can drift from the source — and where a page and the file it names disagree, the file wins.

New to NEBULA
Start with the specification — it is short, and every other document points back into it. Then the integration guide for the HTTP layer around it.
Shipping it
The bundled in-memory store is a test fixture. Production store is the six methods as SQL; Operations is what to measure and what to do when a token is stolen.
Reviewing it
The threat model states what is out of scope as plainly as what is in it. Compliance mapping is control by control, and is not a certification.

One of these documents is normative and five are not. The specification defines conformance: its 53 requirements are numbered [N-1][N-53], each one a permanent anchor you can cite (https://nebulatoken.dev/spec/#N-30). The five guides explain how to use it and carry no requirements of their own; where a guide and the specification disagree, the specification wins.

The normative specification

The one document an implementation is measured against.

The guides

Non-normative. Each answers one question the specification deliberately leaves alone.

Conformance artefacts

Machine-readable, and the reason conformance is a fact rather than a claim. These are files rather than pages, so they link to the repository at e44c684.

  • spec/test-vectors.json

    46 shared cases across verifier hashing, device hashing and canonical parsing, plus 11 published constants. Data, not prose: a conforming implementation executes them.

  • spec/behavior-vectors.json

    38 normative scenarios against an injected clock — rotation, replay, the grace window, expiry, sender binding, pepper rotation, concurrent-refresh conflicts, revocation.

  • spec/traceability.json

    Requirement to test, one row per [N-*]: which vectors and which scenarios cover it, and which are verified by review instead.

  • spec/schema

    Ready-to-apply table definitions for PostgreSQL, MySQL and SQLite. The guidance that goes with them is in the production store guide.

  • COMPATIBILITY.md

    What version 1 freezes, what may still move, and the support window — read before you depend on anything not in the specification.