Decision 0007 establishes a derivation chain for the endeavor’s theory: TCCC → insurgent → disaster → military → medicine → FOSS → business. The cross-domain derivation text traces what each domain contributes to what an endeavor IS. This text documents a different derivation: where the endeavor draws from when turning theory into practice — when abstract concepts become concrete implementations.
The practice derivation problem
The endeavor’s theory is written in neutral, formal vocabulary: closure operators, fixed points, method-practice gaps, non-interference theorems. This vocabulary is domain-independent by design (per content neutrality). But implementing that theory requires concrete architectural decisions: how should a script interact with the repository? What should a tool’s interface look like? How should agents coordinate through shared artifacts?
These implementation decisions are not neutral — they inherit from specific programming traditions. The endeavor’s practice derivation draws primarily from MUDs, especially LPMUDs and their descendants. This is not an abstract academic choice: emsenn has personal experience building and running MUDs, including multiple MUD engines (qtMUD in Python and Crystal, racket-mud in Racket) and the Teraum MUD world. The derivation from MUD architecture is grounded in the same kind of first-hand operational knowledge that TCCC contributes to the theory — not borrowed from literature, but learned through practice.
MUDs as the longest-running networked semioverse
MUDs are the longest-running instances of anything resembling a semioverse implemented on networked computers. Since MUD1 in 1978, MUDs have maintained persistent shared worlds where signs (room descriptions, object names, command responses) and computational objects (rooms, items, NPCs with state and behavior) coexist in a formally specified semantics, operated on by multiple agents simultaneously, governed by coded rules that constitute the world’s method.
MUDs do not describe themselves in semiotic terms. But the structural correspondence is exact: a MUD is an interactive semioverse with handles (object references), interaction surfaces (commands), agents (players and NPCs), tools (objects with behaviors), and norms (coded rules and social conventions). The LPMud tradition adds a clean separation between infrastructure (driver) and application logic (mudlib) that maps directly to the ASR’s separation between scripts and content. Nearly five decades of continuous operation and iteration make MUDs the richest empirical source for how semioverse- like systems actually work under sustained use — including failure modes, governance problems, coordination challenges, and the relationship between builders (method-makers) and players (practitioners).
What MUDs contribute
Driver/mudlib separation
The LPMud architecture separates the driver (engine: networking, object lifecycle, memory management, a programming language) from the mudlib (application: game world, mechanics, player experience, written entirely in the driver’s language). The driver provides infrastructure; the mudlib provides meaning. The driver is written once by engine programmers; the mudlib is written continuously by world builders who may not be professional programmers.
The ASR inherits this separation. The infrastructure layer (scripts, MCP server, build system, validation tools) is the driver. The content layer (specifications, terms, concepts, texts, skills) is the mudlib. The infrastructure provides a standard interaction surface (frontmatter validation, triage enrichment, plan tracking, predicate graph queries); the content builds on that surface to create the endeavor’s actual knowledge.
This is why scripts live alongside skills rather than in a separate scripts/ directory: the driver and mudlib are co-developed, and the skill (mudlib) gives the script (driver component) its meaning.
World-building as programming
In a MUD, creating a forest means writing code. A room is a software object with a description, exits, and behaviors. There is no separation between “content” and “code” — the world is code, and code is the world. This insight connects directly to the semiotic framework’s claim that everything in the semioverse is both a sign (it has a description, it responds to interpretation) and a computational object (it has state, it responds to operations).
The ASR instantiates this: a term file is both content (human-readable definition) and code (machine-readable frontmatter that participates in the predicate graph). A skill is both documentation (SKILL.md instructions) and a callable unit of computation. The MUD tradition provides the empirical precedent for this convergence.
Object inheritance and base classes
MUD mudlibs provide base classes: room, weapon, monster, player. A
builder inherits from these and overrides or extends behavior. The
ASR’s type system works the same way: the type field in frontmatter
(term, concept, text, specification, etc.) determines which schema
applies, which validation rules fire, and how the file participates
in the predicate graph. Each type is a base class; each file is an
instance.
Permission models and sandboxing
LPC includes a permission system controlling what code can access what resources — anticipating modern sandboxed environments. The ASR’s region declarations (what a skill reads and writes) serve the same function: they bound what a skill can affect, enabling the non-interference theorem’s application. The MUD tradition’s experience with untrusted builder code running on shared infrastructure is directly relevant to the endeavor’s multi-agent coordination problem.
The dual with modern programming
The MUD heritage informs what the practice does — the architectural patterns, the convergence of content and code, the driver/mudlib separation. But how that practice is specified follows modern programming conventions: typed interfaces, JSON schemas, structured logging, version control, CI/CD, formal verification where possible.
This is another instance of the derivation-presentation dual. The practice derives internally from MUD architecture (the deepest experiential source for this endeavor’s author), but presents externally in the vocabulary of modern software engineering (the most accessible form for implementers). The MUD patterns are the empirical content; the modern conventions are the presentation language.
Relationship to the domain derivation chain
The domain derivation chain (decision 0007) operates at the level of organizational theory — what an endeavor IS. The MUD heritage operates at the level of implementation pattern — how an endeavor’s tools WORK. These are complementary, not competing:
- Theory: TCCC teaches context-determined practice → the spec says method must be context-responsive
- Practice: MUDs teach driver/mudlib separation → the scripts provide infrastructure while skills provide application logic
The theory says what; the MUD heritage says how. Both are needed. The theory without the practice heritage would produce specifications with no implementation intuition. The practice heritage without the theory would produce tools with no principled justification.