Adopt Self-Sovereign Graph Publication

A Deep Context graph is a self-contained repository carrying typed markdown nodes with named-edge predicates. Standing one up is a self-sovereign act: the first steward runs a local Graph Inception ceremony — the Open Integrity inception ceremony that produces the graph's did:repo:<sha1> DID, signed by the steward's own SSH key — and the new graph stands as its own publication unit thereafter, owing nothing structural to any other graph. A graph may begin from a fresh empty directory, from a clone of an existing graph (this graph or any other), or from any other starting material; the inception ceremony is the same in every case. After Inception completes and the graph's Actions and Pages settings are enabled, subsequent pushes build and deploy the graph's own Pages site. The GitHub Web UI edit path remains a first-class contribution surface for ongoing content edits. Curation discipline lives in named conventions that travel with the nodes rather than in editorial permissions.

A graph may optionally claim scion-of lineage from a donor graph by recording scion_of: in its identity file — signaling that the new graph began as a clone of the donor's content and intends to track the donor as upstream. Scion-of is the narrower case, not the typical case. Most graphs are not scions: a graph that authors fresh content carries no donor, and a graph that grafts content from a donor (per-node copies recorded via grafted_from::) without intending upstream tracking is not a scion either. The scion-of claim applies specifically to the parallel-fork case where contributors with divergent vocabularies want their lineage from a common donor to remain navigable rather than collapsed into independent histories. Scion-of is recorded canonically in .deep-context-identity.yml at the graph root: this_did: carries the graph's own DID (always); scion_of: carries the donor's DID (when the scion claim applies, otherwise null). The relationship is also expressible at the graph layer as a scion_of::[[did:repo:<donor-sha1>]]↗ edge when the scion wants it traversable via graph queries. No git-fork relationship to a donor is maintained because git-fork would share the root commit and therefore share the DID, which would collapse the identity sovereignty each graph needs to participate in cross-graph references unambiguously.

Identity sovereignty and identity-over-URL compose here. Because the DID is content-derived (the SHA1 of the Open Integrity inception commit), the same graph carries one DID across any git host (GitHub, GitLab, Radicle, and others); cross-host mirroring does not change identity. A resolver that walks from a DID to the graph's current host(s) does not yet exist — the DID widget in each page's footer records the identity in anticipation rather than because anything resolves it today.

Scion-of as optional lineage claim

A scion is a graph that explicitly claims content lineage from another graph (the donor) by recording scion_of:: in its identity. The scion claim signals upstream-tracking intent: the scion's first steward expects to monitor the donor's evolution, may pull updates from the donor as new content lands, may peer with sibling scions of the same donor, and intends the scion-of relationship to remain visible to readers of either graph. The horticultural metaphor pulls from the aristocratic sense — a scion is a descendant who carries a line forward under their own name — paired with the cryptographic sense of fresh-roots-and-inherited-fruit: the scion's DID is its own (a fresh Open Integrity inception), but its content lineage points back to the donor.

A scion is distinct from a graph that has merely grafted content from a donor. A graph may carry many grafted_from:: edges (one per grafted node) recording per-node content provenance without claiming scion_of:: lineage at the graph level. The graft-without-scion case is the common pattern; the scion case is specifically for parallel-fork tracking where contributors with divergent vocabularies need structural support for the divergence. Per-node copy is one axis (graft); whole-graph lineage is another (scion). The same graph may carry both kinds of edges simultaneously when both apply, but most graphs carry neither (seed graphs author fresh content) or grafts only (recipients that adopt material without claiming lineage).

The term replaces "fork" for the lineage-claim relationship. "Fork" in the GitHub sense is a git operation that shares the parent's commit history, including the inception commit, and therefore shares the DID. A scion is not a fork in that sense. Two scions of the same donor have distinct DIDs and may diverge freely; a git-fork is one repository observed from two URLs. "Scion" leaves "fork" to mean what it means in git and does not fight for the term.

Graph Inception Ceremony

Identity sovereignty requires that the Open Integrity inception commit be signed by the first steward's own SSH key. No hosting platform's Actions runner has access to that key — Actions run with an ephemeral token and cannot produce a commit cryptographically traceable to the first steward. The Inception ceremony is therefore local-only, and the first steward is the only party who can perform it. The ceremony below describes the typical case of standing up a new graph from a clone of an existing graph (whether or not scion-of lineage is claimed); a steward starting from a fresh empty directory follows the same Open Integrity inception step (4) and identity-file write (6), skipping the clone-and-discard-history steps (1-3).

Concretely:

  1. Clone the donor graph to the first steward's machine — git clone <donor-url> <new-graph-dir>. What the first steward just got is a working directory of donor content plus the donor's full commit history.
  2. Read the donor's DID from .deep-context-identity.yml at the new-graph-dir root. The donor ships this file with its own DID under this_did: — that value is the donor's identity, which the new graph may optionally record as scion_of: if the new graph claims scion-of lineage.
  3. Remove the new-graph-dir's .git directory entirely. This discards the donor's history; the working-directory content remains.
  4. Run the Graph Inception skill. The skill checks for a configured signing SSH key (user.signingkey pointing at the first steward's SSH private or public key, with the corresponding public key in the first steward's GitHub allowed-signers), guides setup if missing, and then runs the Open Integrity inception ceremony (.scripts/oi-inception.sh) to produce a fresh root commit signed by the first steward. The new root commit's SHA1 is the new graph's DID.
  5. Commit the donor's content as the new graph's initial content commit (also signed by the first steward).
  6. Update .deep-context-identity.yml: write the new graph's own DID as this_did. If the new graph claims scion-of lineage from the donor, write the donor's DID as scion_of:; otherwise leave scion_of: null. Most graphs do not claim scion-of (the new graph is its own thing, with grafted nodes optionally recorded via grafted_from:: per node).
  7. Create a new GitHub repository under the first steward's GitHub account (via gh repo create <name> or the GitHub web UI). This repository has no inherited state; it starts empty.
  8. Add it as the new graph's origin remote and push.
  9. In the new graph's GitHub Settings → Actions → General, allow Actions to run.
  10. In the new graph's GitHub Settings → Pages, set Source = GitHub Actions.
  11. Subsequent pushes trigger the build-and-deploy Action and publish the graph's own Pages site with its own DID in the footer.

A deploy-gate step in the build Action reads .deep-context-identity.yml and compares this_did against the current repo's root-commit SHA1; if they do not match, Inception has not been completed correctly and the site is not deployed. This prevents a partial setup from publishing with the wrong identity in the footer.

Inception runs once per graph. Subsequent contributions use either the GitHub Web UI or local clones; only the initial Open Integrity inception requires the author-signed ceremony.

The first steward is the graph's founding principal — the cryptographic identity whose SSH key signs the inception commit and whose public key sits in the graph's allowed-signers. The first steward can add additional principals later by amending allowed-signers and delegating signing authority via the Open Integrity chain mechanism; additional principals become co-stewards whose Open-Integrity-signed commits extend the chain of cryptographic authority the first steward founded. A graph's identity sovereignty therefore flows from an individual at inception but is not bound to that individual indefinitely — stewardship can expand as the practice around the graph grows.

Scion chains are first-class. A scion may itself be the template for further scions: a steward who clones DeepContext.com and stands up iterations.com may publish that scion as the template a later steward clones to stand up iterations-research.com, which carries scion_of: did:repo:<iterations.com-DID> rather than DeepContext.com's DID. Each link in the chain has its own did:repo:<sha1> (the SHA1 of its own Open Integrity inception commit), and .deep-context-identity.yml records only the immediate predecessor — multi-step lineage is reconstructed by walking scion_of: from each scion to its template, and from that template to its own template, until reaching a root template (a graph whose scion_of: is null). DeepContext.com is one starting point of the family of possible chains; it is not the root template, and any DeepContext graph may be the template for the next scion. Within-chain lineage and across-chain peering are independent dimensions: a scion may peer with siblings or with its own template while still being downstream of a common ancestor several steps back.

scion_of:: records initial lineage (how a scion began) and does not impose a fixed hierarchical relationship over time. Two scions of the same template — or a scion and its template — may become peers that exchange nodes bidirectionally through content-level operations. DeepContext.com is designed as a minimal seed rather than an active contribution target, so node flow from scions back to this repository is not expected; peering between two richer scions (for example, iterations.com and its own scions) is expected and normal, with nodes passed in both directions. Peer relationships are a separate architectural concept from initial scion lineage, not modeled by .deep-context-identity.yml; the practice may seed a corresponding Predicate when the first peering actually occurs and its shape is observable rather than speculated.

Why

The practice's durability does not survive dependency on any single repository or editorial authority. The self-sovereign decentralized identity community, and several collaborative-wiki efforts, supply adjacent cases where centralization produced either bus-factor vulnerability or authority calcification. Self-sovereign graph publication is the architectural response: if anyone can stand up a graph, no one can own the practice.

The graph publication model makes the project's other Convictions operational rather than aspirational. [[Vocabulary Diversity Is a Feature]] requires that contributors can hold their own vocabularies; standing up a graph is the mechanism by which a contributor whose vocabulary diverges can continue the practice under their own identity. [[Terms Become Common Through Unanimity, Not Precedent]] requires that new common terms are chosen deliberately; the parallel-graph path is the escape hatch when unanimity cannot be reached. [[Translation Over Convergence]] names what agents do across vocabularies; standing up a parallel graph (with grafts where helpful, scion-of when upstream tracking is desired) is what people do when translation cost exceeds what they are willing to pay. Scion-of specifically applies when the new graph wants the upstream-tracking relationship visible structurally — the case where contributors with divergent vocabularies want their lineage from a common donor to remain navigable rather than collapsed into independent histories.

The per-graph DID is not cosmetic. Each graph's DID is content-addressed — derived from the inception-commit SHA-1 — and therefore stable across hosts. A graph that moves from GitHub to Radicle keeps its DID; cross-graph references from peers do not break when hosting changes. URL-based federation is brittle to hosting decisions; DID-based federation is not. The federation layer's future cross-graph reference resolution runs on DIDs precisely because graphs have them, regardless of whether any specific graph claims scion-of lineage.

The commitment derives the pipeline's other architectural choices. Python-only with standard-library-plus-one-dependency exists so a graph does not need to configure external build services. All pipeline code and all configuration live inside the repository so a graph is self-contained. No committed secrets, no external repo references, no required package registries beyond PyPI. The GitHub Web UI is a supported edit path so a contributor can make changes without installing git or a local editor. Each of these choices is an implementation of the self-sovereign-graph commitment; changing the commitment would cascade through them.

Alternatives Considered

Git-fork as the publication unit. Let a reader fork the repository on GitHub, inheriting the full commit history including the root commit. Rejected because a git-fork shares the parent's root commit and therefore shares the parent's did:repo:<sha1> DID. Two repositories claiming the same DID are identity collision; graphs need distinct identities to participate in federation unambiguously. The git-fork model also chains sync obligations between parent and fork in ways that make vocabulary divergence expensive; graphs diverge without a git-upstream relationship and sync content via explicit content-level operations (grafting nodes, optionally claiming scion-of when the lineage claim is intended) rather than git merges.

Centralized publication, copies as read-only. One canonical repository exists; others may mirror it for offline reading but cannot publish independently. Rejected because it vests practice continuity in a single actor. If the canonical publisher steps away, the practice has no default continuation. The self-sovereign identity community's post-COVID fracture is one of the concrete failures this alternative invites.

Template with no ongoing deployment. Provide a template repository new graphs can instantiate from, but do not commit to each graph producing its own live site. Rejected because it treats graph creation as initial setup rather than the ongoing practice. The commitment is specifically that a graph is a live site on every push, not a project waiting for a deploy to be manually configured.

Pages-enabled but private-repo-only. Permit graph publication among authorized collaborators only; keep the practice invite-only. Rejected because it recreates the authority-over-vocabulary dynamic the project is specifically trying to avoid. [[Consensus Creates Priesthoods]] records the pattern: whoever controls invitation controls which vocabularies count. Public graph publication removes that lever entirely.

Graph publication via external tooling (static site hosting elsewhere). Let graphs use whatever hosting they prefer (Netlify, Vercel, personal servers). Rejected because it moves the graph-publish step outside GitHub's friction floor. A contributor who can edit a markdown file in the GitHub Web UI can stand up and publish a graph; a contributor who has to configure Netlify cannot, or will not. This rejection is specific to the current cycle's friction-floor concern; later cycles may relax it once alternative hosting's friction profile is understood.

Enforce Open-Integrity-signed commits exclusively. Require every post-inception commit to carry an authorized SSH signature, per Open Integrity's chain-of-authority model. Rejected because it conflicts with the GitHub Web UI edit path — Web UI commits are signed by GitHub's internal key, not the committer's SSH key, and would all be rejected as unauthorized. The enforcement would raise the friction floor to "every contributor configures SSH signing," which moves graph publication toward terminal-first contribution and collapses the non-developer edit path. The graph publication model accepts two-tier provenance instead: Open-Integrity-signed commits extend the chain of cryptographic authority, and Web UI commits participate in the graph's history without extending the chain. Both are legitimate contributions; they carry different provenance strength, and the graph's rendering layer makes the distinction visible where it is load-bearing.

Single-click graph standup via GitHub template plus Bootstrap Action. Let a first steward click "Use this template" and have a GitHub Action perform the Open Integrity re-root automatically on first push, so no local clone is required. Rejected because the Action has no access to the first steward's SSH key, so the Open Integrity inception commit would be signed by the Actions runner's ephemeral token rather than by the first steward. That weakens identity sovereignty to "whoever controls the Actions token at inception time," which defeats the commitment the graph publication model rests on. The model accepts a mandatory local step at inception in exchange for Open-Integrity-grade identity sovereignty the first steward actually owns; the template-repository setting is therefore not enabled on this repository, and the graph-creation entry point is git clone rather than "Use this template."

Treat scion as the universal pattern. Treat every standing-up of a Deep Context graph as a scion of its donor — record scion_of: in .deep-context-identity.yml whenever a graph's content originated from a clone, regardless of whether the new graph intends to track the donor as upstream. Rejected because most graphs that begin from a clone of a donor are not making a lineage claim — they are using the donor's content as starting material, then diverging on their own purpose without intending to track the donor. Recording scion_of: in those cases overstates the relationship: a reader sees a lineage claim where none was intended, and the donor sees a downstream that may never sync. Scion-of is reserved for the parallel-fork-tracking case where the lineage claim is load-bearing; per-node content provenance for graphs that grafted but did not claim scion-of is recorded via [[grafted_from -- per-node content provenance from a donor graph]] instead. The cost of this distinction is that a graph standing up via the Inception ceremony must consciously decide whether to claim scion-of (the default is null); the benefit is that the scion_of:: edge means what it says when present.

No new graphs stand up. If DeepContext.com runs for an extended period with zero external graphs (let alone scions), the graph publication machinery is carrying cost (pipeline self-containment, no-external-deps discipline, Open Integrity inception ceremony, re-root tooling) for no realized benefit. The revisit would ask whether the self-sovereign-graph commitment is actually load-bearing for this practice or whether it is aspirational architecture that the reality of the practice does not need.

Graphs stand up but no scion-of claims happen. If new graphs are created and adopt the meta-layer (Contracts, Predicates, Skills) via grafts, but no graph ever claims scion_of:: lineage from a donor, the scion-of vocabulary specifically is unused. The revisit would distinguish "graph publication works as such" (the broader architectural claim) from "scion-of as a status carries weight" (the narrower vocabulary claim) and consider whether the scion-of edge and scion_of: field could be dropped without losing what the practice actually exercises.

Graphs stand up but the Web UI edit path is unused. If graphs exist but contributors always work from local clones, the Web-UI-edit commitment specifically — and the Open Integrity-signing compromise that enables it — is over-designed. The revisit would distinguish "graph-able at all" from "graph-able via Web UI" and might tighten Open Integrity-signing requirements while relaxing the Web UI path.

DID management proves too high-friction. If the Open Integrity inception ceremony, the Python reimplementation, or the allowed-signers maintenance turns out to filter out the contributors the practice is trying to reach, the stance would narrow — keep graph instantiation as the mechanism but reduce the cryptographic-identity layer to something lighter. The revisit would ask what level of identity sovereignty is actually necessary for the practice vs aspirationally nice to have.

Two-tier provenance creates confusion. If the mixed Open-Integrity-signed and Web-UI-signed history turns out to be harder to reason about than either pure path, the revisit would choose one. The default lean would be toward Web UI — preserving the non-developer edit path — with Open Integrity-signing restricted to specific operations (graph inception, key rotation, major content migrations) rather than every commit.

Concentration of contribution stays high even with graph publication. If the graph mechanism works technically but contribution still concentrates in one or two actors, the commitment's value proposition is not working. The revisit would ask whether the concentration is downstream of the graph publication commitment itself (standing up parallel graphs alone is not enough to distribute participation) or downstream of other factors the project has not yet named.

A successor architecture preserves the same properties more simply. If a different mechanism produces the same content-lineage-plus-identity-sovereignty property with less pipeline overhead, the commitment survives but its implementation changes. The property is what is held; the specific machinery is how it is held today.

Local Inception friction filters out the contributors the practice is trying to reach. If would-be first stewards consistently drop off at the "clone locally, configure SSH signing, run Inception" ceremony — because signing-key configuration is too opaque, because Open Integrity tooling expects a command-line fluency the target audience does not have, or because the multi-step ceremony is experienced as forbidding — the local-only commitment is filtering what it should admit. The revisit would ask whether a lighter-weight tier (a GitHub-Actions-signed inception accepted as a weaker sovereignty tier, suitable for stewards who do not need full Open Integrity discipline) could sit alongside the local-signed tier rather than replace it. The full-sovereignty path stays available for stewards who want it; a lighter path is admitted for those for whom full sovereignty is not load-bearing.

Relations