Documentation
From model to implementation.
The specifications define what interoperable software must do. These guides explain why the pieces exist, how they connect, how to implement them, and how to tell whether an implementation behaves correctly.
Reading path
Four layers between overview and specification.
You do not need to read every normative rule before understanding the protocol. Start with the conceptual model, follow a request through the architecture, implement one capability at a time, then validate behavior against the specifications and test vectors.
Concepts
Build the mental model: identity roots, operation history, resource identifiers, services, and the boundary between protocol and application.
Read guide →Guide 02Architecture
See how controllers, writers, directories, mirrors, resolvers, resource services, gateways, and applications fit together.
Read guide →Guide 03Implementer Guide
Turn the specifications into code with a staged implementation path for resolution, writing, resource dereferencing, caching, and failure handling.
Read guide →Guide 04Conformance & Test Vectors
Check observable behavior against the normative specifications and use deterministic vectors to catch canonicalization, hashing, signature, and state-machine errors.
Read guide →Reference implementation
Then run the same rules.
The guides now connect to a dependency-free reference package and an interactive resolver. The playground verifies the normative DID vector in-browser, resolves editable operation histories, parses sq: URIs, and can fetch the reference directory profile over HTTP.
Resolver Playground
Move from prose to observable protocol behavior without involving a sizuq.com account or application database.
Run the protocol →Normative boundary
Guidance explains. Specifications decide.
Pages under /docs are informative. They may simplify terminology, recommend implementation order, or show one reasonable deployment topology. If guidance and a normative specification ever disagree, the requirements in the applicable specification take precedence.
Use Concepts and Architecture to understand the system without treating explanatory diagrams or deployment examples as protocol requirements.
Use the Implementer Guide as a checklist, then follow the exact syntax, canonicalization, signatures, state transitions, and error semantics in the specifications.
Conformance is defined by observable behavior required by did:sizuq and sq:, not by resemblance to the reference deployment.
Normative documents
When details become byte-level, switch to the specs.
The method specification defines identity creation and state derivation. The URI scheme specification defines durable resource identifiers and dereferencing. Standards status tracks external registration without changing either protocol’s semantics.
did:sizuq
Canonicalization, identifier derivation, operation envelopes, signatures, rotation, recovery, deactivation, resolution, and normative vectors.
Open specification →Resourcessq:
URI syntax, identity-root semantics, normalization, service discovery, dereferencing, security, privacy, and interoperability behavior.
Open specification →