Recursive Engine (RE:GE)

The Question

Every software system tells a story — user flows are plot arcs, state machines are character development, error handling is conflict resolution. We treat these as metaphors. I wanted to find out what happens when you treat them as engineering principles.^[1] Aristotle's six elements of drama — plot, character, thought, diction, spectacle, song — are not literary ornaments but structural primitives. What if narrative structure, from Aristotle through Propp, could be encoded as executable rules?^[2] Not an AI that "writes stories" — a symbolic operating system where narrative principles govern how systems organize and evolve.

What RE:GE Does

RE:GE is a pure Python engine where myths, identities, rituals, and recursive structures are first-class computational objects.^[3] Campbell's monomyth — the hero's departure, initiation, and return — becomes a function signature: entity state in, transformed state out. The engine implements 21 organ handlers that process symbolic values through a ritual syntax DSL:

• Myth organs — encode narrative archetypes as transformation rules. A hero's journey is a function: entity state in, transformed state out.
• Identity organs — manage how entities maintain coherence across transformations. When a character "changes," what persists?
• Ritual organs — define sequences that must execute in order, with pre/post-conditions. Ceremonies as transactions.
• Recursive organs — handle self-reference: entities that describe themselves, systems that modify their own rules.

Beyond these four core categories, the engine includes generative and economic organs (managing three internal currencies: dreampoints, looptokens, mirrorcredits), context and translation organs (defining 10 canonical spatial zones and temporal recursion rules), and a publishing gate that controls the transition from internal symbolic process to external output. The 21-organ count grew from an initial 5 as formal completeness demanded finer distinctions.

System Architecture

RE:GE is organized into eight architectural layers, each with a single responsibility. The design draws from both the handler pattern in enterprise systems and the modular routing philosophy of audio signal processing — the central routing component is called the Soul Patchbay, a heap-based priority queue with collision detection and deadlock prevention.^[13]

The dispatcher implements a six-phase lifecycle for every invocation: PARSE → VALIDATE → QUEUE → EXECUTE → FORMAT → LOG. This is not incidental sequencing — each phase is a distinct processing stage with its own failure modes and recovery strategies. The depth tracker enforces four-tier recursion ceilings that prevent unbounded self-reference while still allowing the system's recursive organs to operate meaningfully.^[5]

Every organ extends the OrganHandler abstract base class, which enforces consistent lifecycle management: invocation validation, state persistence, and participation in system-wide checkpointing. The registry manages organ lookup and bulk state operations. This design ensures that adding a new organ requires implementing a contract, not modifying the routing infrastructure — the open-closed principle applied to symbolic processing.^[7]

The Ritual Syntax

The engine parses and executes a domain-specific language for declaring symbolic operations.^[4] Fowler distinguishes between internal DSLs (embedded in a host language) and external DSLs (with their own parser) — RE:GE's ritual syntax is a fully external DSL, parsed and executed by a dedicated interpreter. This gives it the expressiveness of declaring symbolic operations declaratively while maintaining a clean separation from the underlying Python runtime.

INVOKE myth.hero_journey ON entity:protagonist
	WITH threshold: 0.7
	BINDING outcome TO identity.transform
	WHEN condition.readiness EXCEEDS threshold

Each line of an invocation carries semantic weight. ::CALL_ORGAN names the processor. ::WITH provides the symbolic input. ::MODE selects the organ's processing intention — mythic, recursive, devotional, or shadow_work depending on the organ. ::DEPTH controls recursion limits across the four tiers. ::EXPECT declares the desired output form. ::CHARGE assigns initial significance on a 0–100 scale.

::CALL_ORGAN HEART_OF_CANON
::WITH "the threshold crossing at midnight"
::MODE mythic
::DEPTH standard
::EXPECT narrative
::CHARGE 75

This isn't pseudo-code. It's the actual syntax the engine parses and executes.^[5] Hofstadter's strange loops — systems that, by moving through levels, arrive back where they started — are the engine's native operation mode. The BINDING keyword creates a reference from an organ output to another organ's input, forming loops that are bounded but genuinely recursive. The parser supports chained invocations (multiple ::CALL_ORGAN blocks in sequence), protocol invocations (::CALL_PROTOCOL FUSE01), and fragment references by name or version.

Implementation Details

Why Python. RE:GE has a single runtime dependency: Click for the CLI framework. Everything else — all 21 organs, protocols, bridges, and the orchestration engine — is implemented in pure Python with no external libraries. This was a deliberate constraint.^[14] The system needed to be portable, inspectable, and free of framework lock-in. Python's dynamic typing and metaprogramming capabilities allow the DSL parser to construct Invocation objects reflectively, while the ABC pattern provides the structural guarantees needed for the organ handler contract. Python compatibility is verified across versions 3.8 through 3.12.

The handler pattern. Each of the 21 organs is a class extending OrganHandler, implementing invoke() with organ-specific logic. Organs are registered in a central registry and looked up by name at dispatch time. This is structurally similar to the Strategy pattern but with a crucial difference: organs maintain internal state across invocations, which is persisted via the checkpoint system. An organ is not a stateless function — it is a processor with memory.^[7]

Charge dynamics. The atomic unit of RE:GE is the Fragment — a piece of meaningful content carrying a charge value between 0 and 100. Charge maps to five behavioral tiers (LATENT, PROCESSING, ACTIVE, INTENSE, CRITICAL) that determine how the system routes and prioritizes each fragment. Fragments gain charge through recurrence, ritual processing, or fusion with other high-charge fragments. They lose charge through time-based decay or deliberate archival. This creates an evolving significance landscape rather than a static metadata system.

Persistence layer. The engine persists state to a .rege_archive/ directory organized into six categories. A checkpoint manager maintains system state snapshots that enable the four recovery modes (FULL_ROLLBACK, PARTIAL, RECONSTRUCT, EMERGENCY_STOP). The JSON-based format was chosen for inspectability — every piece of system state is human-readable and diffable — though this imposes scaling limits that future phases will address.

External bridges. RE:GE is not a closed system. Three bridges connect it to external tools, each extending the ExternalBridge abstract base class with connect/disconnect lifecycle, operation logging, and sensitive configuration masking. The Obsidian Bridge exports fragments as Markdown notes with YAML frontmatter into an Obsidian vault and imports notes back as fragments. The Git Bridge installs hooks that log commits as invocation events and maps branch creation to symbolic operations. The Max/MSP Bridge communicates via OSC (Open Sound Control) protocol, sending fragment charge levels as real-time data streams and receiving performance events as invocations — connecting the symbolic operating system to audio-visual creative environments.

Workflow Orchestration

Individual organ invocations solve point problems. For multi-step processes, RE:GE provides a Ritual Chain Orchestrator — a workflow engine that sequences organ invocations with branching, compensation, and error handling.^[15] Six built-in chains ship with the system, each encoding a distinct symbolic process:

The orchestrator supports step mode (pause between phases for inspection), dry run (simulate without executing), and full execution statistics. Compensation logic handles failures at each phase — if fusion fails mid-ceremony, the system rolls back to the pre-fusion state rather than leaving the fragment in an inconsistent state. Three fusion modes (AUTO, INVOKED, FORCED) control the level of human intervention, and fusion is reversible within a 7-day window unless the CANON+ tag has been applied.

The six built-in chains encode distinct symbolic processes: canonization ceremony (fragment to permanent canon), contradiction resolution (deliberation with conditional branching), grief processing (six-phase ritual with compensation), emergency recovery (snapshot and forced fusion), seasonal bloom (growth, mutation, and consolidation), and fragment lifecycle (creation through decay). Each chain defines not just the happy path but also what happens when processing fails at every intermediate step.

Testing the Untestable

The hardest part wasn't building the engine — it was proving it worked. When your system formalizes narrative, how do you write assertions?^[6] Schön's concept of "reflection-in-action" — the practitioner's ability to think about what they are doing while doing it — became the test philosophy. We found three strategies:

Structural invariants (~400 tests) — An identity transformation must preserve entity type. A ritual must execute all steps or none. A recursive invocation must terminate within bounded depth.^[7]

Reference implementations (~500 tests) — Propp's 31 functions, Campbell's monomyth stages, Aristotle's six elements encoded as test cases. If the engine claims to implement "Villainy," we verify the correct state transition.^[2]

Round-trip consistency (~350 tests) — Serialize to DSL, parse back, verify identity. Apply transformation and inverse, verify return to original state.

The test suite is organized across 33 test files covering every architectural layer: parser edge cases and malformed input, priority queuing and collision detection in the routing layer, mode validation and charge dynamics per organ, fusion eligibility and rollback in protocols, all 15 CLI command groups, archive read/write and checkpoint integrity, chain execution with branching and compensation, and the connect/disconnect lifecycle for all three bridges. The testing strategy itself — grounding assertions in established narratological frameworks (Propp's morphology, Campbell's monomyth, Aristotle's elements) rather than inventing arbitrary criteria — was the hardest engineering challenge and the most transferable insight.

Why Symbolic, Not Neural

Interpretability. Every transformation has a trace — which organ fired, what rule applied. As AI systems become more consequential, auditable narrative decisions matter.^[8] Manovich argues that software has become the universal medium through which all cultural forms are experienced — when narrative is encoded as software, interpretability is not a debugging convenience but an aesthetic and ethical requirement.

Composability. Build a myth organ on top of an identity organ on top of a recursive organ. Swap organs in and out. LLMs don't compose this way.^[7]

Governance integration. RE:GE lives within the eight-organ system. Dependency validation, promotion state machine, monthly audits — narrative computation within an institutional framework.^[9] Murray's vision of the computer as a medium for procedural, participatory, spatial, and encyclopedic storytelling aligns precisely with a symbolic engine that makes narrative rules explicit and manipulable.

Outcomes & Impact

RE:GE demonstrates several capabilities that transfer directly to production software engineering. For a hiring manager or technical evaluator, the project is evidence of end-to-end system design — from formal specification through implementation, testing, and integration with external tools:

• DSL design and implementation — Building a fully external domain-specific language with its own parser, validator, and execution engine. The ritual syntax is not embedded in Python but parsed by a dedicated regex-based interpreter with its own error handling and recovery semantics.
• Large-scale modular architecture — 21 distinct handlers with a unified abstract base class, registered in a central lookup, routed through a priority queue with collision detection and deadlock prevention. The system scales by adding organs, not by modifying the routing infrastructure.
• Testing strategy for novel domains — When the domain has no established testing patterns, you invent them. Three distinct strategies emerged from the specific challenge of verifying narrative-computational systems. This approach — grounding tests in external frameworks rather than inventing arbitrary criteria — is transferable to any domain where "correct behavior" is partly subjective.^[12]
• Systems integration — Three external bridges (Obsidian, Git, Max/MSP) demonstrate the ability to connect a symbolic engine to real-world tools through clean abstraction boundaries. Each bridge implements the same lifecycle contract while communicating via entirely different protocols (filesystem, Git hooks, OSC).
• Workflow orchestration — The Ritual Chain Orchestrator implements branching, compensation, step mode, and dry run — the same patterns found in production workflow engines like Temporal or AWS Step Functions, applied to a symbolic domain.^[15]

RE:GE serves as the theoretical foundation (ORGAN-I) for the entire eight-organ system. Its organ model, charge dynamics, and ritual syntax concepts propagate downstream: ORGAN-II applies them to live creative performance systems, ORGAN-III applies the modular processing pattern to commercial data infrastructure, and ORGAN-IV extends the architecture into multi-agent AI orchestration. The dependency flow is unidirectional: theory establishes vocabulary, downstream organs instantiate it.

The Discovery

The most surprising outcome wasn't technical — it was aesthetic. Having 21 distinct organ types with formal interfaces created more creative possibilities than working without structure.^[10] Csikszentmihalyi's research on flow states shows that creativity emerges not from total freedom but from the right constraints — challenge matched to skill, rules that channel rather than restrict. When you know what an identity transformation guarantees, you can safely compose it with a myth transformation. Formalism enables creativity. That insight reshaped how I think about every system I build.

Technical Debt & Future

What's incomplete. The remaining roadmap phases (7–15) outline work that ranges from straightforward to speculative. Phase 7 adds a conversational interface organ (INTERLOCUTOR). Phases 8–9 introduce user-defined ritual chains and a browser-based REPL with visualization. Phase 10 addresses performance optimization for large-scale fragment management — the current JSON persistence layer is adequate for the present corpus but will not scale to thousands of active fragments without migration to a proper database.

Known tradeoffs. The ritual syntax is powerful but has a learning curve. A simpler API (plain Python method calls) would lower the barrier to entry but lose the expressiveness of declaring symbolic operations declaratively.^[4] The 21-organ count grew from an initial 5 as formal completeness demanded finer distinctions — some organs handle edge cases that arise rarely. The decision to keep them separate prioritizes composability: each organ has a clean interface contract, so removing one doesn't cascade.

The symbolic-neural boundary. RE:GE excels at "internal-exploratory" narrative — traversing a defined possibility space — but cannot improvise narrative the way an LLM can.^[11] Ryan's taxonomy of interactivity reveals this tradeoff precisely. The future likely involves a hybrid architecture where RE:GE provides the structural governance and audit trail while a neural component handles generative improvisation within the constraints the symbolic engine defines. The 15% coverage gap maps almost exactly to these unexplored integration points.

Law enforcement system. Seven core laws encode the system's invariants — LAW_01 enforces organ isolation, LAW_04 prevents stagnation (fragments cannot remain in LATENT tier indefinitely), LAW_81 governs fusion violations. Laws can be activated or deactivated through the Mythic Senate organ, and violations trigger consequences tracked in a persistent violation log. This is governance-as-code applied to a symbolic domain: the rules are explicit, versioned, and enforced programmatically rather than by convention.

By the Numbers