Ludic Agential Semioverse Repository

This specification defines what an Agential Semioverse Repository looks like when its content domain is games and play. It extends the general ASR’s type vocabulary and typed relations with content types and relations specific to ludic knowledge.

The general ASR defines types like term, lesson, and text that describe what a page is for, but not what makes it valid within a particular domain. Games content has structural requirements that differ from mathematical or sociological content: a term that names a mechanic without specifying what it does is incomplete, while a specification that defines a game type without identifying constitutive criteria cannot distinguish its subject from neighboring types. Games deal in mechanics, boundaries, and classifications — its validity depends on making those concrete.

Validity principle: mechanical specification

Games content is governed by mechanical specification. Content is valid when the structures, constraints, and boundaries it describes are specified concretely enough that a reader can recognize them in practice. A term that names a mechanic must specify what the mechanic does to game state. A specification that defines a game type must provide constitutive criteria that distinguish it from neighboring types. A lesson that teaches game analysis must include a worked example applying the concepts to a concrete game.

The dependency graph is a directed network with two distinct layers. The structural layer defines vocabulary: terms name mechanics, roles, states, and structures. The analytical layer organizes that vocabulary: specifications classify game types by constitutive features, lessons teach how to apply structural analysis, and texts instantiate the structures in playable form. The two layers connect through typed relations — a specification uses mechanics (terms), a text models a game type (specification), a lesson teaches concepts by working through examples.

Machine verification is partially possible: frontmatter completeness and relation consistency can be checked, but the adequacy of a game analysis or the playability of a game text cannot be automated.

Content types

term

A vocabulary entry naming a game element — a mechanic, role, state, structure, or analytical concept.

• MUST have defines: with the canonical term name.
• MUST include a definition in the body (opening sentence or paragraph).
• SHOULD specify what the named element does — how it affects game state, player experience, or game structure.
• SHOULD have cites: when the term has a known origin or key theorist.
• MAY specify used-in: linking to specifications or topics where this element appears.
• MAY specify extends: for terms that refine prior terms (e.g., trump extends suit).

type: term
defines:
  - "mechanic"
cites:
  - "Salen and Zimmerman"

lesson

A curriculum module that teaches game analysis through structured sequence. Lessons are pedagogical: they develop the ability to analyze games structurally, not just to know about them.

The kind: field subdivides lessons into finer categories:

• lesson — standard pedagogical lesson with exercises
• curriculum — curriculum index organizing a lesson sequence
• history — historical narrative tracing a tradition’s development
• genealogy — lineage narrative tracing how game types relate and diverge

All lesson subtypes share the same validation requirements:

• MUST have teaches: listing what concepts or skills the lesson develops.
• MUST include at least one concrete example or worked analysis in the body.
• SHOULD have requires: listing prerequisite pages (other lessons or terms).
• MAY specify uses-mechanic: listing mechanic terms the lesson analyzes.

type: lesson
kind: lesson
teaches:
  - "game"
  - "rules"
  - "voluntariness"
  - "uncertainty"
requires:
  - /games/curricula/what-is-a-game.md

specification

A formal structural analysis defining a game type, system, or tradition by its constitutive and descriptive features. Specifications distinguish their subject from neighboring types and identify boundary cases.

• MUST include a constitutive features section — the features whose presence or absence decides whether something IS this type.
• MUST include a boundary cases section — items that share some but not all constitutive features.
• SHOULD include a common but non-constitutive features section.
• SHOULD have classifies: listing what the specification categorizes.
• SHOULD have uses-mechanic: listing the mechanics central to the type.
• MAY specify boundary-with: linking to related specifications whose boundaries overlap.

type: specification
classifies:
  - /games/topics/card-games/index.md
uses-mechanic:
  - /games/terms/mechanic.md
boundary-with:
  - /games/topics/board-games/index.md

Note: Existing specification files use type: topic with kind: specification. This spec recognizes type: specification as the correct typing; existing files should be updated when enriched.

text

An original game text, design document, or analytical essay. Texts in this domain include playable games (rule texts), game design analyses, and critical essays about games and play.

• MUST state what the text is (a game, an analysis, a design document) in the opening paragraphs.
• SHOULD have cites: for sources and influences.
• SHOULD have authors: crediting who wrote it.
• MAY specify models: linking to the specification or game type the text instantiates.
• MAY specify uses-mechanic: listing mechanics the text employs.

type: text
authors:
  - emsenn
models:
  - /games/topics/role-playing-games/tabletop-role-playing-games/index.md
uses-mechanic:
  - /games/topics/role-playing-games/terms/dice-resolution.md

topic

An organizing node for a game family, tradition, or area of inquiry. Topics collect related terms, lessons, and specifications under a coherent subject.

• MUST describe what the topic covers and how it relates to the parent discipline.
• SHOULD link to its constituent content (terms, lessons, specifications).
• MAY specify extends: for topics that are subtypes of broader topics.

type: topic
extends:
  - /games/topics/role-playing-games/index.md

Relation vocabulary

These typed relations extend the general ASR’s semantic frontmatter relation set.

The general ASR relations (defines, cites, teaches, requires, extends, part-of, questions, addresses) remain available and are not redefined here.

Structural graph

specification ──classifies──► topic ◄──extends── topic
  │                             │
  │                        uses-mechanic
  │                             │
  ├──uses-mechanic──► term ◄──defines── term
  │                             │
  │                         teaches
  │                             │
  ├──boundary-with──► spec       ▼
  │                          lesson
  │
  └──◄──models──── text

Terms define vocabulary. Specifications classify game types by constitutive criteria. Lessons teach structural analysis through worked examples. Texts instantiate game types as playable artifacts. The uses-mechanic relation traces how abstract structural elements appear across concrete analyses — this is the domain’s characteristic structure.

What ludic validity is not

This spec does not evaluate whether a game is good, fun, or well-designed. It tracks whether the structural elements are present: does the term say what the mechanic does? Does the specification provide constitutive criteria? Does the lesson include a worked example? The infrastructure makes gaps visible; filling them is the work of the discipline.

Formal artifacts

• Ontology — OWL classes and properties for ludic content types
• SHACL Shapes — validation shapes for ludic relations

Lean correspondence

Games content has a two-layer graph structure (structural vocabulary and analytical organization) that maps to a concrete Lean structure.

What this domain’s axioms look like formally. The theory for term requires defines: (MUST) — what the mechanic does. The theory for specification requires constitutive features and boundary cases (structural, not frontmatter-checkable). The typed relations (uses-mechanic, classifies, boundary-with, models) form the edges between layers: specifications classify by using mechanics, texts model specifications, lessons teach through examples.

What satisfaction means beyond field presence. The current Python approximation checks field presence. Full satisfaction for a specification would verify that its constitutive features actually distinguish it from specifications it has boundary-with — this requires comparing the content of two pages, not just checking that one page has the right fields.

Current satisfaction data. 106 typed pages checked, 92 satisfied (86.8%), 14 errors, 106 warnings. Errors are MUST violations (index pages mistyped as term/lesson). Warnings are SHOULD gaps (missing cites:).

Lean target. Formalize the two-layer structure as a functor from the structural category (objects: mechanics, morphisms: composition) to the analytical category (objects: specifications/lessons/texts, morphisms: classifies/models/teaches). The functor preserves the uses-mechanic relation: if a specification uses mechanics M1 and M2, and those mechanics compose, the specification should be classifiable by their composition. This is a structural coherence condition that Lean can express and verify.