notes: docs/partner/core-group-readme

This data as json

path title type status classification words body
docs/partner/core-group-readme KERISuite Knowledge Base: a preview for reviewers front-page v0.2.2, 2026-11-03: the per-source license rule (ADR 0005); was: v0.2.1 โ€” 2026-10-21: the licenses stated (ADR 0004); was: v0.2 โ€” 2026-10-15: written in full by Claude for Mark's review (release plan ยง7, Wednesday); counts as of 15 October; not yet read by Mark partner 784 # The KERISuite Knowledge Base: a preview This repository is an index of the KERI Suite. It covers the specifications, papers and talks, implementations and infrastructure, meetings, deployments, and the policy around them. Each item links to the original and carries a short abstract; the main papers and talks also have a longer summary. It links and summarizes, and copies nothing that someone else published. I am Mark Scott, the curator. I keep this as a reader and writer in the KERI community, not as one of its builders. I'm sharing it with a few of the people whose work it describes before Mini KERIConf on 2 November, so that it can be corrected before anyone else relies on it. One disclosure up front: I also founded Authentic Data Enterprises, which builds on the suite. That work lives in a separate place and nothing here presents it as the community's. ## What is in it - **About 500 items.** The figure covers: - Every link on keri.one, and every paper and deck in Samuel Smith's Papers repository. - Daniel Hardman's papers that bear on the suite. - The specifications and their versions, and the repositories, with language, license, latest release and what each depends on. - The KERIConf 2026 talks, and the policy documents. - **The meeting record.** Every meeting page the Trust over IP wiki holds, each with an abstract and the decisions its minutes record: - the KERI Suite Working Group from its first meeting in November 2024; - the ACDC Task Force from 2021 to 2024; - the did:webs Task Force from 2023; - the 2022โ€“2023 KERI Dev Focus Calls, from Kent Bull's notes. - **Labels on every item:** its level (intro, practitioner, implementer, normative) and the kind of evidence it carries. A specification is normative, and a project's account of itself is presenter-reported or vendor-reported. ## Where to start - **[[300-Research/310-KERISuite/INDEX|INDEX]]** lists everything by topic, in reading order, in seventeen parts from "start here" to "the state of the suite". A coverage line at the top says how much has an abstract and how much has a summary so far. - The same items four other ways: [[300-Research/310-KERISuite/learning/resources-index|by type]], [[300-Research/310-KERISuite/learning/by-date|by date]], [[300-Research/310-KERISuite/learning/by-source|by the page each was found on]] (a completeness check on keri.one, the Papers repository and the meeting pages), and [[300-Research/310-KERISuite/learning/by-level|by level]]. - Two reading paths: [[300-Research/310-KERISuite/learning/reading-path-reader|for a reader]] and [[300-Research/310-KERISuite/learning/reading-path-developer|for a developer]]. Summaries appear in the index as I finish reviewing them. This preview has fewer than the register holds, and more will follow. ## How it sits beside KERISSE, WOT-terms, KERIDoc and vlei.wiki Those resources do things this one doesn't try to: - **KERISSE** searches the community's documents. - **WOT-terms** and the specifications' glossary define the terms. - **KERIDoc** documents the code. - **vlei.wiki** covers the vLEI ecosystem. This repository links to each of them rather than rebuilding them. What it adds is the map across the pieces: one index across sources, an abstract per item, the meeting record with its decisions, and which specification is at which version and which implementation supports it. ## What I am asking of you Corrections first: anything wrong, out of date, mislabeled, or missing, and above all anything about your own work. An issue is the easiest way, and there is a template. A pull request may add a file under `inbound/`. I apply what holds up to the source and credit it by name. Before 2 November is ideal, and Mini KERIConf works too. ## One request - **This is a closed preview.** Whether and how it is published later is a separate decision, and I'll ask you before then. ## Licenses The code is under the Apache License 2.0, as keripy, KERISSE, WOT-terms and KERIDoc are. What this base writes itself (the abstracts, labels, notes, vocabularies and generated pages) is under CC BY 4.0, the Creative Commons Attribution license, which is also the content license Trust over IP's working groups list for their deliverables: take any of it with a credit to the KERISuite Knowledge Base. Everything it indexes keeps its own license, and what the base shows of a source follows it: the text where the license allows it, under a credit line, and otherwise an abstract and a link; conversation is never republished ([[300-Research/310-KERISuite/decisions/0005-2026-11-03-what-kskb-shows-of-a-source|ADR 0005]]). The files are plain (YAML, Markdown, SQLite) on open-source tools, so nothing in it locks anyone into a vendor or a host. The record: [[300-Research/310-KERISuite/decisions/0004-2026-10-21-licenses-and-no-lock-in|ADR 0004]]. ## What it is not It's not a restatement of the specifications or the glossary, which win wherever they disagree with a page here. It's not a tracker of every company, and it's not anyone's marketing. **Contact:** Mark Scott, markoscott@id4all.me, or on the WebOfTrust Discord.

Links from other tables