SiliconSaga · Cervator · Jul 21, 2026 · Jul 21, 2026 · Jul 21, 2026 · Jul 21, 2026
diff --git a/docs/adrs/0009-guildhall-practice-model.md b/docs/adrs/0009-guildhall-practice-model.md
@@ -18,7 +18,7 @@ Spotify's premium **Skill Exchange** (skills on user profiles, opportunity marke
 
 Chosen: the split hub model, named the **Guildhall** (norse kenning skin *Gildaskáli*; "practice layer" was rejected for its verb reading). Concepts: **Skill** (unowned shared vocabulary on people, have/learning axis) · **Craft** (demand-side skill bundle a muster calls for) · **Gildi** (the fellowship — purely people, craft- or aspect-aligned) · **Aspect** (the cross-cutting concern, AOP sense — it **holds the Standards** and ships both the bar and the paved road to clear it) · **Standard → Trials** (tiered checks; every trial declares a remediation **vísir**) · **Vísir** (procedure doc; teaching grade in `/docs`, operational parameterized grade in `/runbooks`). The split that carries the model: *crafts are what people do; aspects are what things must uphold.*
 
-Mapping introduces **no new custom kinds**: gildi = `Group` with `spec.type: gildi`; skills/crafts/aspects = vocabularies; standards = Git-backed YAML for the future scorecard plugin (Tech Insights evaluated first); vísar = annotation-referenced Git markdown; enrollment = `siliconsaga.org/aspects` annotation. A **kennings layer** maps canonical technical terms to per-instance display lexicons (norse/plain/custom — e.g. corporate "Practice Hub"), which keeps parent-facing surfaces on plain language by construction.
+Mapping introduces **no new custom kinds**: gildi = `Group` with `spec.type: guild`; skills/crafts/aspects = vocabularies; standards = Git-backed YAML for the future scorecard plugin (Tech Insights evaluated first); vísar = annotation-referenced Git markdown; enrollment = `siliconsaga.org/aspects` annotation. A **kennings layer** maps canonical technical terms to per-instance display lexicons (norse/plain/custom — e.g. corporate "Practice Hub"), which keeps parent-facing surfaces on plain language by construction.
 
 ### Consequences
 

diff --git a/docs/demo-visir.md b/docs/demo-visir.md
@@ -26,7 +26,7 @@ App: `http://localhost:3000` (backend on 7007). Sign in as **Guest**. First boot
 **Verify checklist** (run the day before a demo, not the morning of):
 
 - [ ] Catalog loads; the Kind dropdown includes **Cycle** and **Saga**
-- [ ] `ravenline` Group shows the org tree (two departments — `rl-engineering`, `foxholm`) plus two `gildi`-typed Groups
+- [ ] `ravenline` Group shows the org tree (two departments — `rl-engineering`, `foxholm`) plus two `guild`-typed Groups
 - [ ] `guild-hall` Component (type `hub`) exists, owned by `team-devex`, linking to this vísir
 - [ ] `security-practice` Component (type `practice`) shows its links into the aspect repo
 - [ ] Create page lists **Apply the Security aspect** (the adoption template)
@@ -41,7 +41,7 @@ App: `http://localhost:3000` (backend on 7007). Sign in as **Guest**. First boot
 **2. Catalog tour (6 min).**
 
 - *Catalog → Kind dropdown*: **Cycle** and **Saga** next to Component/Group. Talking point: two custom kinds total; the entire practice layer adds **zero** more — typed Groups, vocabularies, annotations, links.
-- *`ravenline` Group → relations graph*: the org tree — two departments, engineering and the acquired **Foxholm** returns line — plus two **guilds** (`spec.type: gildi`) cross-cutting it — one practice-aligned (Security), one role-aligned (Release Captains). A guild is deliberately just a typed Group: membership, rollups, and the graph come free. Point out Dagny: a Foxholm engineer in the security guild — the guild spans departments, and that's the whole point.
+- *`ravenline` Group → relations graph*: the org tree — two departments, engineering and the acquired **Foxholm** returns line — plus two **guilds** (`spec.type: guild`) cross-cutting it — one practice-aligned (Security), one role-aligned (Release Captains). A guild is deliberately just a typed Group: membership, rollups, and the graph come free. Point out Dagny: a Foxholm engineer in the security guild — the guild spans departments, and that's the whole point.
 - *`team-devex` → `guild-hall`*: the instance you are standing in is itself cataloged (type `hub` — anticipating hub pages: singleton overviews per plugin feature group), owned by the DevEx team, and its vísir is this document. Dogfood moment.
 - *`security-practice` Component (type `practice`)*: the **practice** is the institution (the guild runs it); its **aspect** is the module — a repo holding the blocked standard, the paved road, the adoption templates, and the remediation docs. The entity links go straight into that repo, one click each.
 - *Create page → **Apply the Security aspect***: the **adoption** — applying a practice is a self-service action, not a wiki page. Run it against `label-service` (the pristine, unenrolled component): the mock edition logs its weave plan — annotation, CI includes, stewardship stubs, PR. Then the CLI beat: the same repo ships `SKILL.md`, the identical adoption for agents — *some users never leave their terminal, and neither do their agents.*

diff --git a/docs/guildhall-model.md b/docs/guildhall-model.md
@@ -9,7 +9,7 @@ graph TD
     subgraph "People layer"
         SKILL["Skill (vocabulary term on a person's profile)"]
         CRAFT["Craft / Role (skill bundle; what staffing asks for)"]
-        GILDI["Gildi / Guild (Group spec.type:gildi) — the fellowship"]
+        GILDI["Gildi / Guild (Group spec.type:guild) — the fellowship"]
     end
 
     subgraph "Concern layer"

diff --git a/docs/plans/2026-07-10-guilds-skills-standards-design.md b/docs/plans/2026-07-10-guilds-skills-standards-design.md
@@ -133,7 +133,7 @@ Follows the established discipline: no kind introduced merely to filter; nothing
 
 | Concept | Realization |
 |---|---|
-| Gildi | **`Group` with `spec.type: gildi`** — joins the typed-Group tree (organization/sport/…/gildi). Membership (`memberOf`), ownership rollups, and the graph come free. What the gildi stewards (craft or aspect refs) is a `siliconsaga.org/*` annotation. Dovetails with the parked CODEOWNERS-virtual-team idea: a gildi is a virtual team that is *supposed* to exist. |
+| Gildi | **`Group` with `spec.type: guild`** — joins the typed-Group tree (organization/sport/…/guild). Membership (`memberOf`), ownership rollups, and the graph come free. What the gildi stewards (craft or aspect refs) is a `siliconsaga.org/*` annotation. Dovetails with the parked CODEOWNERS-virtual-team idea: a gildi is a virtual team that is *supposed* to exist. |
 | Skill | A **vocabulary, not entities** (Skill Exchange's exact shape): YAML-defined skill list; a profile decorator attaches selections to `User` entities so search indexes them. Matches the ResourceType-as-vocabulary precedent. |
 | Craft | **Vocabulary-first**: a named bundle (skill refs + vísir refs) in the same YAML family. Promotable to something heavier only if matching mechanics demand it — the cheapest commitment while the structure is still finding its shape. |
 | Aspect | **A repo — the module** (§3.1), holding standard(s), paved road, adoption templates, and remediation vísar together, versioned by Git itself. The registry (`aspects.yaml`, vocabulary-family) maps aspect id → module; version pins land there when module versioning gets real. No new kind — enrollment is the `siliconsaga.org/aspects` annotation on the adopting entity, and the practice's catalog face is a Component of `spec.type: practice` declared in the module's own `catalog-info.yaml` (per-repo, live-topology shape). |