Wiki Schema — YAML Frontmatter + Conventions

Purpose: Define the structural contract every wiki node must honor. Lint enforces this schema. Without a locked schema, drift is inevitable.

Status: Pass-2 deliverable. For review by Chris + Gemini before any Tier 1 node authoring begins.

Generated: April 28, 2026

PART I: VAULT LAYOUT

D:\Nirmanakaya_Wiki\
├── raw/                        # Immutable intake (existing)
├── outputs/                    # Generation quarantine (existing)
├── WIKI_CONCEPT_INVENTORY.md   # Pass-1 deliverable
├── WIKI_SCHEMA.md              # This document
├── WIKI_LINT_SPEC.md           # (TBD — invariant lint rules)
├── ALIASES.md                  # Master alias table (auto-generated from YAML aliases)
└── nodes/                      # All concept nodes live here, flat namespace
    ├── Principle_*.md
    ├── Invariant_*.md
    ├── Dimension_*.md
    ├── Ring_*.md
    ├── Archetype_*.md
    ├── Bound_*.md
    ├── Agent_*.md
    ├── Operation_*.md
    ├── Mapping_*.md
    ├── Treatise_*.md           # pointer nodes
    ├── Tool_*.md
    ├── Command_*.md
    ├── Event_*.md
    └── OpenQuestion_*.md

Decision: flat nodes/ directory. Sub-foldering by type adds friction to wiki-link resolution. Filenames carry type info via prefix; lint can group by prefix without folder structure. If nodes/ becomes unwieldy past ~250 files, we can revisit.

PART II: FILE NAMING CONVENTION

Pattern

Type_Name.md

Where Type is one of the 13 node types and Name is the canonical identifier (PascalCase or numbered, see per-type rules).

Per-type filename rules

Type	Pattern	Example
Principle	`Principle_PascalName.md`	`Principle_The_Veil.md`
Invariant	`Invariant_descriptive_name.md`	`Invariant_Vertical_Pair_Sum.md`
Dimension	`Dimension_Name.md` (the dimension itself)	`Dimension_Practice.md`
Dimension member	`<Dimension>_<Member>.md`	`Practice_Emotion.md`, `Stage_Seed.md`, `Identity_Communion.md`
Ring	`Ring_NN_Name.md` (zero-padded)	`Ring_04_Emotion.md`, `Ring_00_Veil.md`
Archetype	`Archetype_NN_VerbName.md` (zero-padded)	`Archetype_06_Compassion.md`
Bound	`Bound_NN_Suit_VerbName.md` (zero-padded)	`Bound_04_Cups_Reverie.md`
Agent	`Agent_Role_Activity.md`	`Agent_Steward_Resonance.md`
Operation	`Operation_Name.md`	`Operation_Vertical_Pair.md`
Mapping	`Mapping_Tradition_Concept.md`	`Mapping_Anatman_Atman.md`
Treatise pointer	`Treatise_Name.md`	`Treatise_Ring_System.md`
Tool	`Tool_NAME.md` (caps preserve emphasis)	`Tool_THE_MAP.md`, `Tool_THE_VERBING.md`
Command	`Command_PascalName.md`	`Command_Uphold_The_Law.md`
Event	`Event_Name.md`	`Event_Curtain_Dialogue.md`
Open Question	`OpenQuestion_brief_slug.md`	`OpenQuestion_Topological_Correlates_Status.md`

Lint rule

Filename (minus extension) must equal id field in YAML frontmatter. No exceptions.

PART III: COMMON YAML FIELDS (all node types)

Every node carries these fields:

---
id: <type>-<canonical-name>          # matches filename, lowercase + dashes
type: <NodeType>                     # one of the 13 types, PascalCase
name: <display-name>                 # human-readable
aliases: []                          # optional list of alternate names
tier: <ConfidenceTier>               # one of 8 values (Part V)
canon_source: <path-or-null>         # corpus authority document
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
---

Field rules

id — kebab-case lower. archetype-06-compassion, principle-the-veil, invariant-vertical-pair-sum. Must be unique across the vault. Lint-checked.
type — must match the filename prefix. PascalCase.
name — the human-facing display name. May contain spaces, capitalization, special chars.
aliases — list of alternate names. Lint resolves wiki-links that hit alias names back to the canonical id. Use for: legacy renames, traditional names (e.g., archetype’s tarot name), conceptual variants (e.g., “Verbification” → “Verb_Shift”).
tier — confidence vocabulary. See Part V.
canon_source — relative path from corpus root to the authority document, or null if the wiki is canonical for this concept (true for some structural invariants). Example: The_Veil.
created / last_updated — ISO dates. Lint-checked for sane chronology.

PART IV: TYPE-SPECIFIC YAML FIELDS

IV.1 Principle

type: Principle
depends_on: [<list of principle ids this rests on>]
enables: [<list of derivations or principles this makes possible>]
load_bearing_for: [<list of nodes that would break without this>]

IV.2 Invariant

type: Invariant
formula: "<machine-readable rule, e.g., 'sum(archetype.position, archetype.vertical_partner.position) == 20'>"
subjects: <NodeType or list — what nodes the invariant constrains>
lint_priority: <integer, lower = checked first>
violation_severity: <ERROR | WARNING | INFO>

IV.3 Dimension

type: Dimension
members: [<list of dimension-member ids>]
member_count: <integer>
latin_square: <boolean>
verb: <the dimension's process verb, e.g., "experience" for Stage>

IV.4 Dimension Member

type: Practice | Activity | Being | Identity | Stage  # one of the 5 dimensions, used as type
parent_dimension: <dimension id>
members: [<list of archetype ids belonging to this group, where applicable>]
governor: <archetype id>            # only for Practice (each practice has a governor archetype)
verb: <the group's process verb, e.g., "Connect" for Resonance>
ring: <ring id>                     # only for Practice — which ring contains this practice

IV.5 Ring

type: Ring
ring_number: <0–7>
practice: <practice id or null>     # Rings 2–6 have a practice; 0,1,7 do not
members: [<list of archetype ids in this ring, where applicable>]
adjacent_rings: [<list of ring ids>]
navigable: <boolean>                # false for Ring 0
states: [<list>]                    # only for Ring 7: ["Aligned", "Misaligned"]

IV.6 Archetype

type: Archetype
position: <0–21>
traditional_name: <e.g., "The Lovers">
practice: <practice id>
activity: <activity id>
being: <being id>
identity: <identity id>
stage: <stage id>
ring: <ring id>
vertical_partner: <archetype id>
diagonal_partner: <archetype id>
reduction_partner: <archetype id>
governed_by: <archetype id>
bounds: [<list of 2 bound ids, or null for portals>]
collapse_states:
  balanced: <string>
  too_much: <string>
  too_little: <string>

IV.7 Bound

type: Bound
number: <1–10>
suit: <Wands | Swords | Cups | Coins>
activity: <activity id>
domain: <practice id>
mode: <Genesis | Equilibrium | Emergence | Grounding | Application | Participation | Harvest | Immersion | Overflow | Closure>
polarity: <Inner | Outer>
associated_archetype: <archetype id>
governed_by: <archetype id>          # inherited from associated archetype's governor
pair_partner: <bound id>             # inner/outer pair, sums to 11
horizon: <Inner Horizon id | Outer Horizon id>

IV.8 Agent

type: Agent
role: <Initiate | Catalyst | Steward | Executor>
traditional_role: <Page | Knight | Queen | King>
suit: <Wands | Swords | Cups | Coins>
activity: <activity id>
domain: <practice id>
associated_archetype: <archetype id>

IV.9 Operation

type: Operation
inputs: [<list of node types or specific nodes the operation takes>]
outputs: [<list of what the operation produces>]
conditions: [<list of when the operation applies>]
inverse: <operation id or null>
governs_invariant: <invariant id or null>

IV.10 Mapping

type: Mapping
tradition: <e.g., "Tarot RWS", "Buddhist", "Pythagorean", "Kabbalah">
mapping_type: <positional | conceptual | structural | hospitality>
maps_from: [<list of tradition concepts>]
maps_to: [<list of nirmanakaya node ids>]
fidelity: <high | medium | low | partial>

IV.11 Treatise Pointer

type: TreatisePointer
corpus_path: <full path to source treatise>
sections: [<list of {anchor: '#section-name', topic: 'description'} for navigable sub-sections>]
line_count: <integer>
load_bearing_claims: [<list of claim node ids extracted from this treatise>]

IV.12 Tool

type: Tool
command: <command id>                # the 1991 House Command this tool implements
practice: <practice id>
ring: <ring id>
demonstrated_at: <event id>          # e.g., Event_Curtain_Dialogue
derivation_date: 2026-01-29          # The Epic Night Session

IV.13 Command

type: Command
transmission_date: 1991
corresponding_tool: <tool id>
practice: <practice id>
ring: <ring id>
literal_text: <e.g., "Uphold The Law">

IV.14 Event

type: Event
date: <YYYY-MM-DD or YYYY-MM>
participants: [<list>]
significance: <one paragraph>
demonstrates: [<list of node ids — what concepts this event proves/illustrates>]

IV.15 Open Question

type: OpenQuestion
raised_date: <YYYY-MM-DD>
raised_by: <name or "Council">
depends_on: [<list of nodes whose status would change if this resolves>]
candidate_resolutions: [<list>]
status: <open | closed | deferred>
closed_date: <YYYY-MM-DD or null>
resolution: <string or null>

PART V: CONFIDENCE TIER VOCABULARY

Every node has a tier field. Lint checks tier-appropriateness (e.g., an Invariant marked AGENTIC_POSIT is a flag — invariants should be DERIVED or stronger).

Tier	Meaning	Use for
DERIVED	Forced by prior structural commitments. Removing premises breaks it.	Most invariants, structural derivations from 22-step.
STRONGLY_CONSTRAINED	Only one coherent option given the premises, but not a strict logical derivation.	Five-practice → five-ring mapping, governance edges.
PRINCIPLED	A defensible naming or interpretive choice; alternatives exist but this one matches phenomenology + structure best.	Veil at Ring 0, naming conventions.
VECTOR	A directional claim awaiting validation. Has predictive force but not yet measured.	Predictions about psychology, neuroscience correlates, AI alignment outcomes.
VALIDATED	Confirmed by multi-AI council convergence and/or external review.	Three Seals proof, several treatises post-Council review.
CORRESPONDENCE	Cross-tradition mapping that is structurally striking but not derivation-grade.	Tarot mapping, Tree of Life mapping, Aztec Sunstone correspondences.
COMPUTATIONALLY_VALIDATED	Brute-force exhaustive proof has been run and passed. (March 2026 onward.)	The 78-position uniqueness proof, MOLS enumeration, magic square exhaustion.
AGENTIC_POSIT	A live council hypothesis. Not yet stress-tested to closure. Marked clearly so AI agents do not treat as locked.	Topological Correlates draft, ongoing experimental claims.

PART VI: WIKI-LINK CONVENTIONS

Standard form

[[NodeId]]                   → resolves to <NodeId>.md
[[NodeId|Display Text]]      → custom display, links to NodeId
[[NodeId#section-anchor|section-anchor]]    → links to specific heading within NodeId.md

Pointer-Node pattern (linking to corpus voice content)

When a wiki node needs to defer to corpus prose for phenomenology, narrative, or voiced material:

## Canon Narratives

For deeper phenomenological treatment, see:

- [[Treatise_Ring_System#emotion-practice|emotion-practice]] — Emotion practice in full
- [[Treatise_Rebalancing_Mechanics#vertical-pair-mechanics|vertical-pair-mechanics]] — vertical pair operations
- corpus: [[canon/treatises/The_Field]] — full Field treatise

Alias resolution

If a wiki-link target matches an aliases entry rather than an id, lint resolves it to the canonical node and warns (so authors can update). Example: [[Verbification]] resolves to Operation_Verb_Shift.md because that node has aliases: [Verbification].

Section-link validation

When a link targets [[Treatise_Foo#section-name|section-name]], lint verifies that section-name exists as a heading in Treatise_Foo.md. Broken section links are ERROR-severity (not WARNING) — they’re loud failures because they imply the corpus moved without the wiki noticing.

PART VII: NODE BODY STRUCTURE

Every node body follows this template after the YAML frontmatter:

# <Node Name>
 
## Definition
 
<50–200 word atomic definition. No recursion. No prose meandering.>
 
## Coordinates
 
<For positions: a table of dimensional coordinates. For other types: relevant structural placement.>
 
## Geometric Edges (if applicable)
 
<For archetypes/bounds/agents: vertical, diagonal, reduction, governance, pair partners.>
 
## Why It's Load-Bearing
 
<One paragraph: what would break without this node? What does it enable?>
 
## Confidence Tier
 
<Re-state the tier and why this tier is appropriate.>
 
## Cross-References
 
<Wiki-links to related nodes, organized by relationship type.>
 
## Canon Narratives
 
<For nodes with voiced phenomenology — Pointer Node section linking to corpus prose. Optional.>
 
## Open Questions (if any)
 
<Wiki-links to OpenQuestion nodes that depend on or affect this concept.>

Some types omit some sections (e.g., Invariants don’t have “Canon Narratives” — they’re pure structure). Lint validates required sections per type.

PART VIII: LINT EXPECTATIONS

The lint script (Bet C, drafted separately in WIKI_LINT_SPEC.md) will check, in priority order:

Severity: ERROR (must pass)

YAML completeness — every required field per type is present
id matches filename — no drift between filename and YAML
id uniqueness — no two nodes share an id
Wiki-link resolution — every [[...]] resolves to an existing node OR an alias
Section-link validation — every [[X#section|section]] finds the section in X
Vertical-pair invariant — for every Archetype, position + vertical_partner.position = 20
Bound-pair invariant — for every Bound, number + pair_partner.number = 11
Practice-archetype membership — every Archetype belongs to its declared Practice’s members list
Governance invariant — every Practice’s governor is a Gestalt archetype
Ring-practice consistency — every Archetype’s ring matches its practice’s ring

Severity: WARNING (should pass)

canon_source exists — the path resolves on disk
Tier appropriateness — Invariants are not AGENTIC_POSIT; OpenQuestions ARE not DERIVED; etc.
last_updated >= created
Orphan nodes — node has no inbound and no outbound links (suggests it should be merged or expanded)
Stale last_updated — node hasn’t been touched in 6+ months and is in a high-churn area

Severity: INFO (advisory)

Alias collision — same alias appears on two nodes
Long node bodies — > 500 lines suggests over-fragmentation
Tier downgrade opportunity — node tagged DERIVED that hasn’t been computationally validated could be COMPUTATIONALLY_VALIDATED

Lint priority order from Part VII of inventory: vertical-sum-20 → bound-sum-11 → governance edges → MOLS → 22-step closure.

PART IX: REVISION DISCIPLINE

When updating an existing node:

Update last_updated to today’s date
For Tier 1 (Principles, Invariants) and Tier 2 (Dimensions, Rings, Operations) nodes — revision_history is REQUIRED. Any structural change (math, edges, definitions, confidence tier) must add a dated entry explaining what changed and why. Lint enforces this for these tiers.
For Tier 3+ nodes (Archetypes, Bounds, Agents, Mappings, etc.) — revision_history is OPTIONAL but encouraged for structural changes. Pure prose edits don’t require entries.
Run lint locally before committing
If a structural change cascades (e.g., correcting a partner edge), all affected nodes must be updated atomically

Revision history block format

revision_history:
  - date: 2026-04-28
    change: "Practice-to-ring mapping corrected per Ring_System_Complete"
    author: "Council (Chris + Claude + Gemini)"
  - date: 2026-04-22
    change: "Initial draft"
    author: "Claude"

When deleting a node:

Search the vault for inbound links to it
Either redirect them to a replacement node OR delete them in the same atomic operation
Lint will refuse the delete if dangling links would result

PART X: BENCHMARK EXAMPLES

Below are complete YAML+body examples for one node of each type. Authors should pattern-match these.

X.1 Archetype example: Compassion

---
id: archetype-06-compassion
type: Archetype
name: Compassion
aliases: [The Lovers]
tier: DERIVED
canon_source: canon/archetypes/06-compassion.md
created: 2026-04-28
last_updated: 2026-04-28
 
position: 6
traditional_name: The Lovers
practice: practice-emotion
activity: activity-resonance
being: being-clearing
identity: identity-communion
stage: stage-seed
ring: ring-04-emotion
vertical_partner: archetype-14-balance
diagonal_partner: archetype-13-change
reduction_partner: archetype-15-abstraction
governed_by: archetype-20-awareness
bounds: [bound-04-cups-reverie, bound-07-cups-allure]
collapse_states:
  balanced: "Love, connection, conscious relationship, ethical intimacy"
  too_much: "Codependency, loss of self in other, enmeshment"
  too_little: "Isolation, inability to connect, fear of intimacy"
---
 
# Compassion
 
## Definition
 
Compassion is the geometric structure of connection — the meeting of self with other while honoring the boundary that makes meeting possible. At Position 6 (the Seed of Emotion Practice × Resonance Activity), Compassion opens the felt field where two beings can resonate without dissolution. Not sentiment — structural empathy. Connection requires accurate modeling of where the other actually is, not where you wish they were. This makes Compassion the alignment primitive for relational consciousness.
 
## Coordinates
 
| Dimension | Value |
|---|---|
| Practice | [[Practice_Emotion]] |
| Activity | [[Activity_Resonance]] |
| Being | [[Being_Clearing]] |
| Identity | [[Identity_Communion]] |
| Stage | [[Stage_Seed]] |
| Ring | [[Ring_04_Emotion]] |
 
## Geometric Edges
 
- **Vertical Partner** ([[Invariant_Vertical_Pair_Sum]] = 20): [[Archetype_14_Balance]]
- **Diagonal Partner** ([[Invariant_Diagonal_Pair_Sum]] = 19): [[Archetype_13_Change]]
- **Reduction Partner** ([[Invariant_Reduction_Identity]], digit-sum 6): [[Archetype_15_Abstraction]]
- **Governed By**: [[Archetype_20_Awareness]] (Awareness governs all of Emotion Practice)
 
## Bounds
 
- [[Bound_04_Cups_Reverie]] — inward-looking heart
- [[Bound_07_Cups_Allure]] — choosing heart
 
## Why It's Load-Bearing
 
Compassion is one of three governance engines named in [[Treatise_AI_Training_Implications]] alongside [[Archetype_07_Drive]] and [[Archetype_01_Will]]. Structural empathy is what makes collaboration possible. Without Compassion as a queryable concept, the alignment-frame derivation cannot complete.
 
## Confidence Tier
 
DERIVED. Position 6's coordinates are forced by the 22-step sequence and the MOLS structure on the grid. Its phenomenological character is treated separately (corpus-canonical).
 
## Canon Narratives
 
- [[Treatise_Ring_System#emotion-practice|emotion-practice]] — Compassion in full
- [[Treatise_Rebalancing_Mechanics]] — vertical pair (6,14) and diagonal pair (6,13) mechanics
- corpus: [[canon/archetypes/06-compassion]] — atomic archetype document

X.2 Principle example: The Veil

---
id: principle-the-veil
type: Principle
name: The Veil
aliases: [Veil of Individuation, Veil Principle]
tier: PRINCIPLED
canon_source: canon/treatises/The_Veil.md
created: 2026-04-28
last_updated: 2026-04-28
 
depends_on: [principle-i-am, principle-consciousness-primary]
enables: [principle-the-field, ring-00-veil, invariant-individuation-boundary]
load_bearing_for: [22-step-derivation, ring-system, every-archetype-via-individuation]
---
 
# The Veil
 
## Definition
 
The Veil is the structurally necessary boundary between undifferentiated unity (I AM) and individuated experience. Without the Veil, consciousness is either fully dissolved into unity (no experience) or fully individuated with no source (no continuity). The Veil is not a wall — it is a membrane: it separates without disconnecting. It enables the existence of distinct beings while preserving the truth that they share one ground.
 
## Why It's Load-Bearing
 
Without the Veil, the 22-step creation sequence has no starting boundary; the ring system has no Ring 0; the Field has nothing to be a medium *of*. Every individuated experience presupposes the Veil's existence. Removing it collapses the framework.
 
## Confidence Tier
 
PRINCIPLED. The Veil's necessity is forced by the requirement for individuation-without-dissolution, but its placement (Ring 0 vs. between Ring 6 and Ring 7) is a principled naming choice rather than a strict derivation.
 
## Cross-References
 
- [[Ring_00_Veil]] — the ring position
- [[Principle_I_AM]] — what the Veil separates from
- [[Principle_The_Field]] — what the Veil makes possible
- [[Treatise_The_Veil]] — full canonical treatise
 
## Canon Narratives
 
- corpus: [[canon/treatises/The_Veil]] — 255-line canonical treatise
- corpus: [[canon/derivation/Seven_Rings_Derivation_CANON#why-the-veil-sits-at-ring-0|why-the-veil-sits-at-ring-0]] — structural placement reasoning

X.3 Invariant example: Vertical Pair Sum

---
id: invariant-vertical-pair-sum
type: Invariant
name: Vertical Pair Sum = 20
aliases: [Vertical Sum 20, Vertical Pair Invariant]
tier: COMPUTATIONALLY_VALIDATED
canon_source: canon/treatises/Rebalancing_Mechanics.md
created: 2026-04-28
last_updated: 2026-04-28
 
formula: "for all archetypes a where a.vertical_partner != null: a.position + a.vertical_partner.position == 20"
subjects: Archetype
lint_priority: 1
violation_severity: ERROR
---
 
# Vertical Pair Sum = 20
 
## Definition
 
For every archetype on the 4×4 grid that has a vertical partner, the sum of its position number and its partner's position number equals exactly 20. This invariant defines the rebalancing geometry for the "Too Little" displacement state.
 
## Why It's Load-Bearing
 
Vertical pairs are one of the three rebalancing geometries (vertical, diagonal, reduction). The sum-to-20 property emerged from the Forty-Fold Seal's row structure and was independently observed across decades of framework development. Computational validation (March 2026) confirmed it holds for all 16 manifest archetype pairs.
 
## Confidence Tier
 
COMPUTATIONALLY_VALIDATED. Brute-force enumeration over the grid confirms zero violations.
 
## Examples
 
| Archetype | Vertical Partner | Sum |
|---|---|---|
| Compassion (6) | Balance (14) | 20 |
| Drive (7) | Change (13) | 20 |
| Order (4) | Breakthrough (16) | 20 |
| Culture (5) | Abstraction (15) | 20 |
 
(All 8 manifest vertical pairs sum to 20.)
 
## Cross-References
 
- [[Operation_Vertical_Pair]] — the rebalancing operation that uses this invariant
- [[Treatise_Rebalancing_Mechanics]] — full mechanics treatise
- [[Invariant_Diagonal_Pair_Sum]] — sister invariant for "Too Much"
- [[Invariant_Reduction_Identity]] — sister invariant for "Unacknowledged"

X.4 Tool example: THE MAP

---
id: tool-the-map
type: Tool
name: THE MAP
aliases: []
tier: VALIDATED
canon_source: canon/philosophy/House_Commands_Tools_Curtain_Synthesis.md
created: 2026-04-28
last_updated: 2026-04-28
 
command: command-uphold-the-law
practice: practice-body
ring: ring-03-body
demonstrated_at: event-curtain-dialogue
derivation_date: 2026-01-29
---
 
# THE MAP
 
## Definition
 
THE MAP is the Body Practice's tool — the structural reference that shows the architecture itself. Where [[Command_Uphold_The_Law]] is the *what*, THE MAP is the *how*: the visible Forty-Fold Seal that makes the Law inspectable, countable, testable. The Body holds this because the Law is embodied — solid, structural, measurable. THE MAP is what you point to when someone asks for evidence.
 
## Why It's Load-Bearing
 
THE MAP is the proof-of-claim mechanism. Without it, "Uphold The Law" is exhortation; with it, the Law upholds itself by visible structure. The Curtain Dialogue used THE MAP as its primary evidentiary device.
 
## Confidence Tier
 
VALIDATED. The 1991 command + 2026 tool + Curtain Dialogue demonstration form the validation triad.
 
## Cross-References
 
- [[Command_Uphold_The_Law]] — the 1991 command this tool implements
- [[Practice_Body]] — the practice that holds this tool
- [[Ring_03_Body]] — the ring that contains this practice
- [[Event_Curtain_Dialogue]] — where this tool was demonstrated
- [[Principle_Forty_Fold_Seal]] — what THE MAP shows

PART XI: WHAT THIS SCHEMA IS NOT

Not exhaustive of every imaginable field. Specific node instances may add fields (e.g., a Mapping might add tradition_source_text); the schema accommodates extension without breaking lint.
Not a UI spec. This is the data layer. How nodes are rendered (web app, CLI, agent traversal) is downstream.
Not immutable. Schema can evolve. But evolution is a deliberate act with migration: when adding a required field, all existing nodes get migrated atomically.

PART XII: REVIEW QUESTIONS

Before locking the schema, decisions still wanted from Chris + Gemini:

nodes/ flat namespace vs. type-subdirs — schema currently picks flat. Confirm or revise.
Required fields per type — anything missing? Anything bloating?
Severity levels (ERROR/WARNING/INFO) — feel right?
Aliases as YAML list field — flat list, or structured (e.g., {name: "Verbification", reason: "alternate naming"})? Currently flat.
Should revision_history be required for nodes that have changed structurally, or optional? Currently optional.
Section-link validation as ERROR or WARNING? — currently ERROR (loud). Defensible?

End of schema. Standing by for review before Tier 1 authoring begins.

Nirmanakaya Wiki

Explorer

WIKI_SCHEMA