notes: docs/public/user-guide

This data as json

path title type status classification words body
docs/public/user-guide KSKB user guide: how the KERISuite Knowledge Base is laid out and how to use it reference v0.1.3, 2026-11-03: the per-source license rule (ADR 0005); was: v0.1.2 — 2026-10-23: a section on what KSKB is, a knowledge base as distinct from a knowledge system; was: v0.1.1 — 2026-10-21: the licenses (ADR 0004); was: v0.1 public 725 # KSKB user guide > For readers. KSKB is a curated record of the KERI Suite (KERI, ACDC, CESR, TSP, and the ecosystem built on them): what the specifications say, where to learn, what is implemented, who is building on it, what the working group decided, what happened at the conferences, and where governments have taken an interest. It is maintained by Mark Scott, a reader and writer in the KERI community, and it cites the community's own sources rather than replacing them. ## If you have an hour 1. Read the reading path at the top of [[../../learning/kerisuite-learning-resources|Where to learn the KERI Suite]] and follow its first two steps: the *Hitchhiker's Guide to KERI* and the *KERI for Muggles* deck. 2. Keep the KERI Suite glossary open: https://trustoverip.github.io/kerisuite-glossary/. 3. Skim [[../../research/KERI_Reference_skinny|the two-page reference]]. ## If you have a day Work through GLEIF's vLEI training notebooks 101 (the KLI, identifiers, rotation, witnesses, credentials), then read the KERI specification's introduction and the matching sections of [[300-Research/310-KERISuite/research/KERI_Reference_skinny|the two-page reference]] that match what you just did. The learning-resources note lists everything with who maintains it and how current it is. ## If you are building Start at [[300-Research/310-KERISuite/development/README|development/]] for the implementation notes and the two device analyses, then GLEIF's notebooks 102 (KERIA and Signify) and the Veridian getting-started pages, then Kent Bull's configuration and key-derivation posts. The [[300-Research/310-KERISuite/standards/README|standards/]] folder holds the working group's monthly minutes, where implementation questions get settled. ## How the folders are laid out | Folder | Ask it for | |---|---| | [[300-Research/310-KERISuite/research/README\|research/]] | the syntheses: the two-page reference, the full synthesis, the cryptography note | | [[300-Research/310-KERISuite/specifications/README\|specifications/]] | notes on each standard and the version matrix | | [[300-Research/310-KERISuite/learning/README\|learning/]] | where to learn, and the generated indexes of every resource | | [[300-Research/310-KERISuite/development/README\|development/]] | implementations, repositories, analyses | | [[300-Research/310-KERISuite/standards/README\|standards/]] | the working group, task forces, Trust over IP, IETF, ISO | | [[300-Research/310-KERISuite/ecosystem/README\|ecosystem/]] | organizations building on the suite | | [[300-Research/310-KERISuite/events/README\|events/]] | KERIConf, IIW sessions, SEDI | | [[300-Research/310-KERISuite/policy/README\|policy/]] | government interest and legislation | | [[300-Research/310-KERISuite/docs/README\|docs/]] | how this system itself works (this guide is in [[300-Research/310-KERISuite/docs/public/README\|docs/public/]]) | Every folder has a README that says what is in it. The file names carry no numbers; the folder names are the same in every knowledge system in this vault, so a reader of one can read the others. ## How to trust what you read Every claim about a version, a deployment, a date, or a role carries an evidence label: normative (from a specification), code-observed, presenter-reported, vendor-reported, officially listed, or unverified. Quotations are exact or marked as paraphrase. Where a note and a specification disagree, the specification is right and the note is corrected with a dated line. If you find an error, [[../contributor/contributing|here is how to say so]]. ## Licenses, and taking it with you KSKB's code is under the Apache License 2.0, the license of the KERI community's own implementations (keripy, KERISSE, WOT-terms, KERIDoc), and its own content (abstracts, labels, notes, the generated pages) under the Creative Commons Attribution 4.0 license (CC BY 4.0); the sources it indexes keep their own licenses, and what KSKB shows of each follows that license: the text where it allows it, under a credit line, and otherwise an abstract and a link (ADR 0005). Everything is plain files in open formats, so a reader can take the register, the notes or the database and read them with any tool. The decision is recorded as ADR 0004 (an architecture decision record) in the decisions folder, which the reviewers' copy carries. ## What KSKB is A knowledge base: a curated reference about a subject that others own, assembled from their sources. Its records describe things that exist elsewhere: a card for each source, a summary, a vocabulary, an index. It makes no claims of its own and takes no positions; what it adds is selection, description and labeling, and it is curated continuously. It is not a knowledge system, the other kind, in which an owner keeps a working record in their own voice, with claims, positions and decisions behind a review gate. ## What KSKB is not Not the specifications, which are Trust over IP's; not the glossary, which is the working group's; not a company's site; not Mark's own architecture work, which lives in a separate system that depends on this one.

Links from other tables