Map conceptual dependencies across the emsemioverse stack

Summary

Create a formal mechanism for mapping the conceptual dependencies between layers of the emsemioverse — the “inspired by” / “grounds” / “extends” / “instantiates” relationships that are currently implicit. These are not implementation dependencies (plan X depends on plan Y) but conceptual ones: relationality inspires the semiotic universe, which grounds the interactive semioverse, which is extended by the agential semioverse, which is instantiated by the ASR, whose method is specified by the semiotic-* specs, which are practiced by the emsemioverse endeavor.

Motivation

The emsemioverse has a conceptual stack:

relationality (philosophy)
  ↓ inspires
semiotic universe (mathematics)
  ↓ grounds
interactive semioverse (mathematics)
  ↓ is extended by
agential semioverse (mathematics)
  ↓ is instantiated by
ASR specification (technology)
  ↓ whose method is defined by
semiotic-* specifications (technology)
  ↓ which are practiced by
emsemioverse endeavor (personal project)

These relationships are real and load-bearing — the spec depends on the math, the math depends on the philosophy — but they are currently expressed only in prose. There is no machine-readable way to ask: “what does the agential semioverse depend on?” or “what concepts in the ASR spec are really properties of the interactive semioverse?”

This matters for three reasons:

1. Relocation sweep (plan 0044): knowing the dependency graph tells you where content should live. If a concept depends only on semiotic universe concepts, it belongs at the semiotic universe level, regardless of where it was first written.

2. Predicate graph enrichment: the predicate graph currently tracks part-of, defines, cites-decisions, and similar relations. It does not track “conceptually depends on” or “is grounded in” — the relations that constitute the stack.

3. Progressive formalization: the direction of travel from informal to formal (policy 001) requires knowing what the informal content conceptually depends on, so formalization can proceed in dependency order.

What kind of dependencies

These are not the same as implementation dependencies or plan dependencies. They are conceptual:

• inspires: A philosophical stance that motivates a formal structure. Relationality inspires the semiotic universe’s choice of Heyting algebras over Boolean algebras (constructive, not classical). The inspiration is real but not a formal derivation.

• grounds: A formal structure that provides the vocabulary for another. The semiotic universe’s closure operators ground the interactive semioverse’s definition of handles and footprints. Grounding is a formal dependency — you cannot define handles without closure operators.

• extends: A formal structure that adds to another while preserving its properties. The agential semioverse extends the interactive semioverse by adding agents, skills, and tools. Everything true of the interactive semioverse remains true.

• instantiates: A specification that implements a formal structure. The ASR instantiates the agential semioverse as a concrete repository format. The instantiation may add implementation-specific constraints.

• specifies an aspect of: A specification that defines one dimension of a larger method. Semiotic-markdown specifies the file format aspect of the semiotic-endeavor’s method.

• practices: An endeavor that uses a method. The emsemioverse practices the semiotic-* specifications.

Research phase

Existing work in the predicate graph

The predicate graph already has typed edges. Check:

• What edge types exist? (part-of, defines, cites-decisions, depends-on, etc.)
• Can conceptual dependencies be expressed as a new edge type?
• Or do they need a separate graph (a “conceptual dependency graph” alongside the predicate graph)?

Existing work in other knowledge systems

Research how other systems represent conceptual dependencies:

• OWL ontologies: rdfs:subClassOf, owl:imports
• Mathematical dependency: Lean’s import system
• Specification dependency: RFC references
• How do existing knowledge graphs distinguish “uses the concept of” from “is implemented using”?

Existing content about this

Check whether the ASR theory already addresses this:

• theory/operational-closure.md — may map formal layers to repository operations
• composite-semioverse concept — may address composition of layers

Step 0: Specify the map’s keys and values

Before building the map, specify what it contains. This is itself a small specification — it defines the vocabulary the map uses.

Dependency edge types (keys)

Each edge in the dependency map has a type drawn from this vocabulary. The types are ordered from weakest to strongest coupling:

Key	Meaning	Example
inspires	A philosophical stance that motivates a formal structure. Not a formal derivation; the inspired structure could exist without the inspiration, but wouldn’t have been conceived.	relationality → semiotic universe
grounds	A formal structure that provides the vocabulary for another. The grounded structure cannot be defined without the grounding one. Formal dependency.	semiotic universe → interactive semioverse
extends	A formal structure that adds to another while preserving all its properties. Everything true of the base remains true.	interactive semioverse → agential semioverse
instantiates	A specification that implements a formal structure as a concrete system. May add implementation-specific constraints.	agential semioverse → ASR
specifies-aspect-of	A specification that defines one dimension of a larger method. The aspect is self-standing but composes into the whole.	semiotic-markdown → semiotic-endeavor
practices	An endeavor that uses a specification as its method. The practice may diverge from the spec (method-practice gap).	emsemioverse → semiotic-* specs
derives-from	A derivation source that contributes substance, practice, or design patterns. Unlike inspires, the contribution is concrete and traceable.	MUD heritage → ASR; Starfleet → semiotic-endeavor; TCCC → semiotic-endeavor

Node attributes (values)

Each node in the map has:

Field	Type	Meaning
path	string	Path to the primary file representing this node
layer	integer	Position in the conceptual stack (0 = philosophy, 1 = mathematics/foundations, 2 = mathematics/structures, 3 = mathematics/extensions, 4 = technology/specifications, 5 = technology/method-aspects, 6 = personal/practice)
discipline	string	The discipline this node belongs to
status	string	stable, draft, stub, empty — how formalized the node currently is

Edge attributes

Each edge has:

Field	Type	Meaning
type	string	One of the edge types above
what	string	Brief description of what the dependency carries (e.g., “closure operators”, “lifecycle structure”, “driver/mudlib separation”)
strength	string	formal (cannot exist without), structural (shaped by), inspirational (motivated by)

Observation: planning granularity gap

The goals-and-plans system currently has two levels: goals (strategic objectives) and plans (tactical work units). The conceptual stack reveals at least one missing level between them — something like “workstreams” or “threads” that group related plans into coherent sequences serving a goal. The sequence “map dependencies → relocate content → rewrite agential semioverse → complete endeavor spec” is a workstream, but the planning vocabulary has no name for it.

The semiotic-PM specification may already have the theory to fill this gap (milestones partially serve this function), but the connection between milestones and conceptual dependency is not yet made. This should be explored during the research phase.

Steps

1. Research: survey existing predicate graph edge types, OWL/RDF patterns for conceptual dependency, and existing ASR theory on layer composition. Also check whether the planning granularity gap (goals → ??? → plans) is addressed by existing semiotic-PM concepts like milestones.

2. Backfill gaps: before encoding the map, ensure the supporting theory exists. Specifically:

   • Do we have a term/concept for “conceptual dependency” as distinct from “implementation dependency”?
   • Do we have a term for “layer” in the conceptual stack sense?
   • Does the predicate graph spec support typed edges beyond the current set? Create any missing term/concept files needed.

3. Design: choose a representation for conceptual dependencies. Options:

   • New frontmatter field (conceptually-depends-on: [list of paths])
   • New predicate graph edge type (grounded-in, extends, instantiates)
   • A standalone dependency map file (a single document recording the full stack with typed edges)
   • Some combination

4. Encode the stack: apply the chosen representation to the emsemioverse’s conceptual hierarchy. Start with the main stack (relationality → semiotic universe → interactive semioverse → agential semioverse → ASR → semiotic-* → emsemioverse) and then add cross-cutting dependencies (e.g., semiotics grounding from linguistics, MUD heritage from computing, Starfleet procedural patterns).

5. Validate: check that the encoded dependencies are consistent — no cycles, no missing layers, every “extends” has a matching base object.

6. Integrate with relocation sweep: use the dependency map to guide plan 0044. Content that depends only on Layer N concepts should live at Layer N.

Done when

• The dependency map vocabulary (edge types, node attributes, edge attributes) is specified and documented
• Any missing terms/concepts needed to support the map exist as files
• A representation for conceptual dependencies is chosen and documented (as a decision record or spec section)
• The main emsemioverse stack is encoded with typed dependency edges
• The dependency map is usable by the relocation sweep (plan 0044) as a guide for where content belongs
• At least one cross-cutting dependency (e.g., MUD heritage, semiotics grounding, Starfleet patterns) is also encoded
• The planning granularity observation is recorded (even if not resolved by this plan)

Dependencies

Independent of other plans, but its output feeds plan 0044 (relocation sweep). Benefits from the predicate graph specification already in the ASR.

Log

2026-03-08 — Created from emsenn’s observation that the conceptual dependencies across the stack (“relationality inspires semiotic universe which grounds interactive semioverse…”) need a better mapping mechanism than prose. The relationships are real and load- bearing but currently implicit.

2026-03-08 (update) — Added Step 0: specify the map’s keys and values before building the map. Added dependency edge type vocabulary (7 types from inspires to derives-from), node attributes (path, layer, discipline, status), and edge attributes (type, what, strength). Added observation about planning granularity gap (goals → ??? → plans). Added Step 2: backfill gaps (missing terms/concepts). Added Starfleet as a cross-cutting dependency to encode. These additions came from emsenn’s direction to “first specify the keys and values we’ll be using to construct our map.”

2026-03-08 (execution) — Completed Steps 0-5:

• Step 0 (specify keys/values): done in plan body above.
• Step 1 (research): surveyed predicate graph (supports new edge types via frontmatter; extends already exists; 299 handle-valued triplets). Surveyed operational-closure.md (maps formal layers to repository operations). Surveyed composite-semioverse (every Thing is a semioverse). Confirmed planning granularity gap between goals and milestones.
• Step 2 (backfill gaps): created terms/conceptual-dependency.md and terms/conceptual-layer.md. Both were absent.
• Step 3 (design): chose combination approach — standalone map document as reference, with frontmatter predicates (conceptually- extends, conceptual-layer) for individual files. The standalone map is at conceptual-dependency-map.md.
• Step 4 (encode): created conceptual-dependency-map.md with 12 main stack nodes, 6 cross-cutting sources, 13 main stack edges, 8 cross-cutting edges, and 5 intra-layer edges.
• Step 5 (validate): confirmed no cycles, all extends have bases, all instantiates have formal structures. Identified known gaps (N0 stub, N1-N3 draft, Layer 3 content deficit).
• Step 6 (integrate with relocation): map includes usage section with explicit procedure for determining where a file belongs. Remaining: individual files have not yet been updated with conceptual-layer and conceptually-extends frontmatter. That is a follow-on task — encoding the map into file-level predicates.

2026-03-08 — Completed. All acceptance criteria met: vocabulary specified, terms created, representation chosen, main stack + 7 cross-cutting sources encoded, map usable by plan 0044, planning granularity gap recorded. Frontmatter enrichment of individual files (adding conceptual-layer and conceptually-extends predicates) is deferred as a follow-on; it doesn’t block the map’s usability.