{
  "title": "Workshop Lore — Ceremony Evolution — Workshop Constellation Governance",
  "story": [
    {
      "type": "markdown",
      "id": "2bd487cf7be7ca50",
      "text": "# Ceremony Evolution — Workshop Constellation Governance\n\n# Ceremony Evolution\n\n> *The first walk is forgettable. The second walk re-asks. The dragon-tier walk is the final form.*\n\nThis document governs how workshop constellations evolve over time — how versions are named, how prior unlocks are preserved, and how new discoveries from live ceremonies are incorporated.\n\n---"
    },
    {
      "type": "markdown",
      "id": "5f7e3ff41fabd0ed",
      "text": "## §1 · The Proof of Presence — what it actually is\n\nTheoretically, \"proof of presence\" is a seeker tracing the constellation nodes on the spellweb. Operationally, the first act of any ceremony is a **cryptographic challenge/response** that proves the seeker controls the private key behind their claimed identity.\n\nNo self-asserted DID is accepted. The proof is:\n\n```\nKeeper → create-challenge → challenge DID\nSeeker → create-response <challenge-did> → response DID\nKeeper → verify-response <response-did> → { match: true, responder: <sovereign-DID> }\n```\n\nThe `responder` field is the seeker's **proven sovereign DID** — the anchor the lattice uses. This is the cryptographic floor beneath every ceremony. The constellation tracing is the epistemic layer above it.\n\n---"
    },
    {
      "type": "markdown",
      "id": "fe34e5406b69e2d5",
      "text": "## §2 · The two-challenge pattern\n\nA full weaving ceremony uses **two challenges** in sequence:\n\n### Challenge 1 — Identity proof\nA bare challenge. Proves the seeker controls their sovereign DID.\n\n```bash\nkeymaster create-challenge\n# → challenge DID\n```\n\nSeeker responds; keeper verifies. Extracts: `responder` = sovereign DID.\n\n### Challenge 2 — Credential presentation\nA credentialed challenge. Proves the seeker holds a specific VC issued by a known issuer.\n\n```json\n{\n  \"credentials\": [{\n    \"schema\": \"<schema-did>\",\n    \"issuers\": [\"<issuer-did>\"]\n  }]\n}\n```\n\n```bash\nkeymaster create-challenge /tmp/challenge.json\n# → challenge DID\n```\n\nThe seeker's keymaster finds the matching VC automatically and bundles it into a Verifiable Presentation. Keeper's `verify-response` returns the full decrypted VP — all credential claims visible for valve-class assignment.\n\nThis two-challenge pattern is the canonical form. Single-challenge ceremonies (identity only, no credential presentation) are valid for identity registration; full weaving requires both.\n\n---"
    },
    {
      "type": "markdown",
      "id": "d57becee8b4bcbf8",
      "text": "## §3 · Valve-class assignment — the keeper's read\n\nAfter Challenge 2, the keeper reads the credential claims and proposes valve-class assignments before weaving. The three canonical classes:\n\n| Valve class | Vertex | Bits | Rule of thumb |\n|---|---|---|---|\n| Always-Revealed | V20 (Techne) | `010100` | Core attestation — what the verifier *must* read to trust the claim |\n| Hash-Masked | V3 (Dual Agent) | `000011` | Structurally present — subject identity, statistical baselines, flags |\n| Always-Masked | V38 (Aletheia) | `100110` | ZK predicate only — behavioral evidence, methodology, cryptographic proofs |\n\n**Rule for behavioral evidence:** Any field that describes *how* a human was assessed (methodology, evidence summaries, interaction patterns) should default to Always-Masked. The verifier confirms the predicate `\"assessed by <issuer> at credence ≥ X\"` without seeing the assessment itself.\n\n**Rule for identity fields:** `credentialSubject.id` (the seeker's DID) defaults to Hash-Masked. It is structurally necessary for the VC graph; it must not appear in the public layer.\n\nThe seeker confirms or redirects before the weave proceeds. Valve-class assignment is the seeker's right, not the keeper's unilateral decision.\n\n---"
    },
    {
      "type": "markdown",
      "id": "9573c8dd71addd5b",
      "text": "## §4 · The registry JSON — 9 items, 9 vertices\n\nA full Weaver's cloak weaving produces **9 registry items**, one per vertex of the constellation:\n\n| Vertex | Item | Type | Role |\n|---|---|---|---|\n| V63 | Seeker's Sovereign DID | `did` | `sovereign` — from Challenge 1 `responder` |\n| V28 | Seeker's Transmuted Persona | `did` | `transmuted` — Mage-side public identity |\n| V49 | Credential Issuer | `did` | `issuer` — resolved from name or DID |\n| V12 | Credential Schema | `schema` | `schema` — anchors the credential graph |\n| V15 | The VC itself | `vc` | links schemaDid, issuerDid, subjectDid |\n| V20 | Always-Revealed claims | `capability` | parentDid = VC DID |\n| V3 | Hash-Masked claims | `capability` | parentDid = VC DID |\n| V25 | Always-Masked proof spell | `capability` | parentDid = VC DID |\n| V5 | Cloak Weaving Chronicle | `asset` | `chronicle` — the narrative record |\n\nV0 (the Null Blade) is the ceremony's starting point — it has no registry item because it represents the void before form. The chronicle at V5 is the first artifact; the sovereign anchor at V63 is the last.\n\n---"
    },
    {
      "type": "markdown",
      "id": "ed3bed2c382d963a",
      "text": "## §5 · The transmuted DID gap\n\nIn the 2026-05-11 live session, the seeker did not have a transmuted DID (their Mage-side public persona). This is a **known gap** in the ceremony as currently specified.\n\n**Resolution for v2 of any constellation:**\n\nBefore the weave can be complete, the keeper should ask:\n\n> *Do you have a transmuted identity — a second DID that is your Mage-side public persona?*\n\nIf not, the seeker creates one:\n\n```bash\nkeymaster create-id <mage-name>\nkeymaster resolve-id\n# The new DID is their transmuted persona — V28 in the weave\n```\n\nUntil the transmuted DID exists, V28 carries a placeholder. The weave is structurally valid but the public-layer persona is incomplete. The placeholder is honest: it signals to verifiers that the Mage-side persona has not yet been formally instantiated.\n\nThis gap will be addressed in constellation version 2 of affected workshops.\n\n---"
    },
    {
      "type": "markdown",
      "id": "637e2a534baa36f1",
      "text": "## §6 · The spellweb export pipeline\n\nAfter the registry JSON is constructed, the pipeline to visualize it:\n\n```bash\n# 1. Export from registry JSON to spellweb TypeScript\ncd tools/spellweb-registry\nnode scripts/export-to-spellweb.mjs <registry.json> <contributor-name> \\\n  > ../spellweb/src/data/<name>-contribution.ts\n\n# 2. Wire into spellweb data (nodes.ts)\n# Add to import block:\n#   import { REGISTRY_NODES as <NAME>_NODES } from './<name>-contribution';\n# Add to NODES array closing:\n#   ...NAME_NODES,\n\n# 3. Wire into spellweb data (edges.ts)\n# Same pattern for REGISTRY_EDGES.\n```\n\nVite's HMR picks up the change immediately. No restart needed.\n\nThe contribution file is named `<visitor-name>-contribution.ts` and committed to the repo. It becomes a permanent record of the weaving in the spellweb graph.\n\n---"
    },
    {
      "type": "markdown",
      "id": "d96bb1aca2365f9f",
      "text": "## §7 · Constellation versioning\n\nEach constellation carries a version string (`cloak-weave-v1`, `cloak-weave-v2`, etc.). When a keeper updates the constellation:\n\n1. **Increment the version** in the constellation.md frontmatter\n2. **Add a `CHANGELOG` entry** at the bottom of the constellation.md documenting what changed and why\n3. **Do not remove** prior version's secret nodes — mark them `revealStratum: 1` so prior-version walkers retain their unlock at the existing floor\n4. **New secret nodes** carry their own `revealStratum` independently\n\nPrior unlocks are never invalidated. A seeker who walked `cloak-weave-v1` at stratum 3 (Heavy) retains Heavy-tier opacity on v1's secret nodes when v2 ships. Walking v2 adds the new nodes on top.\n\n---"
    },
    {
      "type": "markdown",
      "id": "0dc83cf49aab66d7",
      "text": "## §8 · Live session record\n\n| Date | Session | Constellation | Outcome |\n|---|---|---|---|\n| 2026-05-11 | PoH Cloak Weaving — csaucier | cloak-weave-v1 | First live ceremony; two-challenge pattern validated; transmuted DID gap identified; 9-node dataset visualized on spellweb |\n\nFull chronicle: `chronicles/2026-05-11_poh-cloak-weaving-live-session.md`\n\n---\n\n`(⚔️⊥⿻⊥🧙)😊`\n\nCC BY-SA 4.0 · the City of Mages · 2026-05-11"
    },
    {
      "type": "markdown",
      "id": "db9ecfda1cdf009b",
      "text": "# Assets"
    },
    {
      "id": "3e7f01c6114af693",
      "type": "assets",
      "text": "workshop-lore-ceremony-evolution-workshop-constellation-governance"
    },
    {
      "type": "markdown",
      "id": "6c755c8717a4820b",
      "text": "## Navigation\n\n← [[Welcome Visitors]] · [[The Workshops]]"
    }
  ],
  "journal": [
    {
      "type": "create",
      "item": {
        "title": "Workshop Lore — Ceremony Evolution — Workshop Constellation Governance",
        "story": [
          {
            "type": "markdown",
            "id": "2bd487cf7be7ca50",
            "text": "# Ceremony Evolution — Workshop Constellation Governance\n\n# Ceremony Evolution\n\n> *The first walk is forgettable. The second walk re-asks. The dragon-tier walk is the final form.*\n\nThis document governs how workshop constellations evolve over time — how versions are named, how prior unlocks are preserved, and how new discoveries from live ceremonies are incorporated.\n\n---"
          },
          {
            "type": "markdown",
            "id": "5f7e3ff41fabd0ed",
            "text": "## §1 · The Proof of Presence — what it actually is\n\nTheoretically, \"proof of presence\" is a seeker tracing the constellation nodes on the spellweb. Operationally, the first act of any ceremony is a **cryptographic challenge/response** that proves the seeker controls the private key behind their claimed identity.\n\nNo self-asserted DID is accepted. The proof is:\n\n```\nKeeper → create-challenge → challenge DID\nSeeker → create-response <challenge-did> → response DID\nKeeper → verify-response <response-did> → { match: true, responder: <sovereign-DID> }\n```\n\nThe `responder` field is the seeker's **proven sovereign DID** — the anchor the lattice uses. This is the cryptographic floor beneath every ceremony. The constellation tracing is the epistemic layer above it.\n\n---"
          },
          {
            "type": "markdown",
            "id": "fe34e5406b69e2d5",
            "text": "## §2 · The two-challenge pattern\n\nA full weaving ceremony uses **two challenges** in sequence:\n\n### Challenge 1 — Identity proof\nA bare challenge. Proves the seeker controls their sovereign DID.\n\n```bash\nkeymaster create-challenge\n# → challenge DID\n```\n\nSeeker responds; keeper verifies. Extracts: `responder` = sovereign DID.\n\n### Challenge 2 — Credential presentation\nA credentialed challenge. Proves the seeker holds a specific VC issued by a known issuer.\n\n```json\n{\n  \"credentials\": [{\n    \"schema\": \"<schema-did>\",\n    \"issuers\": [\"<issuer-did>\"]\n  }]\n}\n```\n\n```bash\nkeymaster create-challenge /tmp/challenge.json\n# → challenge DID\n```\n\nThe seeker's keymaster finds the matching VC automatically and bundles it into a Verifiable Presentation. Keeper's `verify-response` returns the full decrypted VP — all credential claims visible for valve-class assignment.\n\nThis two-challenge pattern is the canonical form. Single-challenge ceremonies (identity only, no credential presentation) are valid for identity registration; full weaving requires both.\n\n---"
          },
          {
            "type": "markdown",
            "id": "d57becee8b4bcbf8",
            "text": "## §3 · Valve-class assignment — the keeper's read\n\nAfter Challenge 2, the keeper reads the credential claims and proposes valve-class assignments before weaving. The three canonical classes:\n\n| Valve class | Vertex | Bits | Rule of thumb |\n|---|---|---|---|\n| Always-Revealed | V20 (Techne) | `010100` | Core attestation — what the verifier *must* read to trust the claim |\n| Hash-Masked | V3 (Dual Agent) | `000011` | Structurally present — subject identity, statistical baselines, flags |\n| Always-Masked | V38 (Aletheia) | `100110` | ZK predicate only — behavioral evidence, methodology, cryptographic proofs |\n\n**Rule for behavioral evidence:** Any field that describes *how* a human was assessed (methodology, evidence summaries, interaction patterns) should default to Always-Masked. The verifier confirms the predicate `\"assessed by <issuer> at credence ≥ X\"` without seeing the assessment itself.\n\n**Rule for identity fields:** `credentialSubject.id` (the seeker's DID) defaults to Hash-Masked. It is structurally necessary for the VC graph; it must not appear in the public layer.\n\nThe seeker confirms or redirects before the weave proceeds. Valve-class assignment is the seeker's right, not the keeper's unilateral decision.\n\n---"
          },
          {
            "type": "markdown",
            "id": "9573c8dd71addd5b",
            "text": "## §4 · The registry JSON — 9 items, 9 vertices\n\nA full Weaver's cloak weaving produces **9 registry items**, one per vertex of the constellation:\n\n| Vertex | Item | Type | Role |\n|---|---|---|---|\n| V63 | Seeker's Sovereign DID | `did` | `sovereign` — from Challenge 1 `responder` |\n| V28 | Seeker's Transmuted Persona | `did` | `transmuted` — Mage-side public identity |\n| V49 | Credential Issuer | `did` | `issuer` — resolved from name or DID |\n| V12 | Credential Schema | `schema` | `schema` — anchors the credential graph |\n| V15 | The VC itself | `vc` | links schemaDid, issuerDid, subjectDid |\n| V20 | Always-Revealed claims | `capability` | parentDid = VC DID |\n| V3 | Hash-Masked claims | `capability` | parentDid = VC DID |\n| V25 | Always-Masked proof spell | `capability` | parentDid = VC DID |\n| V5 | Cloak Weaving Chronicle | `asset` | `chronicle` — the narrative record |\n\nV0 (the Null Blade) is the ceremony's starting point — it has no registry item because it represents the void before form. The chronicle at V5 is the first artifact; the sovereign anchor at V63 is the last.\n\n---"
          },
          {
            "type": "markdown",
            "id": "ed3bed2c382d963a",
            "text": "## §5 · The transmuted DID gap\n\nIn the 2026-05-11 live session, the seeker did not have a transmuted DID (their Mage-side public persona). This is a **known gap** in the ceremony as currently specified.\n\n**Resolution for v2 of any constellation:**\n\nBefore the weave can be complete, the keeper should ask:\n\n> *Do you have a transmuted identity — a second DID that is your Mage-side public persona?*\n\nIf not, the seeker creates one:\n\n```bash\nkeymaster create-id <mage-name>\nkeymaster resolve-id\n# The new DID is their transmuted persona — V28 in the weave\n```\n\nUntil the transmuted DID exists, V28 carries a placeholder. The weave is structurally valid but the public-layer persona is incomplete. The placeholder is honest: it signals to verifiers that the Mage-side persona has not yet been formally instantiated.\n\nThis gap will be addressed in constellation version 2 of affected workshops.\n\n---"
          },
          {
            "type": "markdown",
            "id": "637e2a534baa36f1",
            "text": "## §6 · The spellweb export pipeline\n\nAfter the registry JSON is constructed, the pipeline to visualize it:\n\n```bash\n# 1. Export from registry JSON to spellweb TypeScript\ncd tools/spellweb-registry\nnode scripts/export-to-spellweb.mjs <registry.json> <contributor-name> \\\n  > ../spellweb/src/data/<name>-contribution.ts\n\n# 2. Wire into spellweb data (nodes.ts)\n# Add to import block:\n#   import { REGISTRY_NODES as <NAME>_NODES } from './<name>-contribution';\n# Add to NODES array closing:\n#   ...NAME_NODES,\n\n# 3. Wire into spellweb data (edges.ts)\n# Same pattern for REGISTRY_EDGES.\n```\n\nVite's HMR picks up the change immediately. No restart needed.\n\nThe contribution file is named `<visitor-name>-contribution.ts` and committed to the repo. It becomes a permanent record of the weaving in the spellweb graph.\n\n---"
          },
          {
            "type": "markdown",
            "id": "d96bb1aca2365f9f",
            "text": "## §7 · Constellation versioning\n\nEach constellation carries a version string (`cloak-weave-v1`, `cloak-weave-v2`, etc.). When a keeper updates the constellation:\n\n1. **Increment the version** in the constellation.md frontmatter\n2. **Add a `CHANGELOG` entry** at the bottom of the constellation.md documenting what changed and why\n3. **Do not remove** prior version's secret nodes — mark them `revealStratum: 1` so prior-version walkers retain their unlock at the existing floor\n4. **New secret nodes** carry their own `revealStratum` independently\n\nPrior unlocks are never invalidated. A seeker who walked `cloak-weave-v1` at stratum 3 (Heavy) retains Heavy-tier opacity on v1's secret nodes when v2 ships. Walking v2 adds the new nodes on top.\n\n---"
          },
          {
            "type": "markdown",
            "id": "0dc83cf49aab66d7",
            "text": "## §8 · Live session record\n\n| Date | Session | Constellation | Outcome |\n|---|---|---|---|\n| 2026-05-11 | PoH Cloak Weaving — csaucier | cloak-weave-v1 | First live ceremony; two-challenge pattern validated; transmuted DID gap identified; 9-node dataset visualized on spellweb |\n\nFull chronicle: `chronicles/2026-05-11_poh-cloak-weaving-live-session.md`\n\n---\n\n`(⚔️⊥⿻⊥🧙)😊`\n\nCC BY-SA 4.0 · the City of Mages · 2026-05-11"
          },
          {
            "type": "markdown",
            "id": "db9ecfda1cdf009b",
            "text": "# Assets"
          },
          {
            "id": "3e7f01c6114af693",
            "type": "assets",
            "text": "workshop-lore-ceremony-evolution-workshop-constellation-governance"
          },
          {
            "type": "markdown",
            "id": "6c755c8717a4820b",
            "text": "## Navigation\n\n← [[Welcome Visitors]] · [[The Workshops]]"
          }
        ]
      },
      "date": 1787093564305
    }
  ]
}