All projects

Personal project · Systems architecture

TMR — theMonoRepo

TMR (theMonoRepo) is my experimental computing environment for people and agents to interact with shared semantic objects through web, voice and spatial interfaces. It brings together coding agents, graph navigation and a declarative interaction runtime.

DEMO / 2026-11-05Worker Studio / Unity Shell
Worker Studio running in glasses. 1 min 7 sec · November 5, 2026. Original recording on LinkedIn .

Working components shown here: Worker Studio in glasses, Compass over an example graph, and the PIM command runtime. The complete integration around a shared semantic graph is still in progress. Transformer graph heads and a hyperbolic language-graph renderer are research directions; the infrastructure diagram describes the wider architecture.

Infrastructure Link to heading

TMR / INFRASTRUCTURE

Shells, Exobrain & stream processing

Architecture sketch
theMonoRepo: shells, Exobrain and stream processing The user interacts with Web or Unity, two implementations of Shell. Web contains Worker Studio as an application, with Compass for semantic graph navigation. Shell input reaches PIM, and driver agents can also input directly to PIM. Exobrain contains the Molecule SSOT graph, PIM graph linearizer and services. Shells send video and audio streams to Mixer. Mixer calls local models and publishes events on NATS. Worker Studio connects coding-agent adapters. Reader uses local speech services. Exobrain Graph · interaction · services Chant / model declarations Shell implementations agent input linearization interaction input projections / state video + audio streams events model calls / results event input agent execution content / state speech User Voice · touch · controls Web Implements Shell Worker Studio Application Compass · component Unity Implements Shell Glasses · spatial I/O Renders Web app surfaces Driver agents Direct PIM input PIM Graph linearizer Context · paths · sequences Molecule SSOT graph State · relations · operations Coding-agent adapters Codex · Claude · plugins Mixer Audio / video stream processing Calls models · publishes events Local model services Recognition · synthesis Perception · decisions Reader Reading state · speech playback Live text · seek · speed NATS Event transport / pub-sub

User → shell → Exobrain

  1. UserInteracts with a shell.
  2. Web / UnitySeparate implementations of Shell.
    Web contains Worker StudioApplication: workers, sessions, coding agents and the Compass component.
  3. PIM · graph linearizerShell input reaches PIM. Driver agents also enter PIM directly.
  4. Molecule SSOT graphState, relationships and operations inside Exobrain.

Streams, models & events

  1. Web / Unity shellsVideo and audio streams.
  2. Mixer ↔ local model servicesProcessing requests and model results.
  3. Mixer → NATSPublishes events for subscribers.

Applications & services

  1. Web → Worker StudioThe Web shell contains the application.
  2. Worker Studio ↔ coding-agent adaptersCodex, Claude and other providers.
  3. Reader ↔ local model servicesReading state, speech synthesis and playback.

Shells and Exobrain

The user interacts with Web or Unity shells. Web contains Worker Studio. Shell input reaches PIM; shell streams reach Mixer, which calls local models and publishes events on NATS.

  1. User / shells
  2. PIM / Molecule
  3. Mixer / models / NATS
Connection notes
Shell implementations
Web and Unity implement Shell. The user interacts with these shells. Web contains Worker Studio as an application; Unity renders spatial and Web application surfaces.
Graph interaction
Shell input reaches PIM, the linearizer of the Molecule SSOT graph. Driver agents can send input directly to PIM.
Streams and models
Shell audio and video streams enter Mixer. Mixer calls local model services, receives their results and publishes events on NATS.
Applications and services
Worker Studio connects coding-agent providers through adapters. Reader uses model services for speech synthesis and playback.
Architecture sketch. Web and Unity implement Shell; Worker Studio is an application inside Web; Compass is a graph-navigation component.

Shells and applications Link to heading

The user interacts with a shell. Web and Unity implement Shell. Web contains Worker Studio as an application; Unity presents spatial surfaces in glasses. Shells carry user input to PIM. Driver agents can also supply input directly to PIM.

Exobrain Link to heading

Molecule is the SSOT graph; PIM is its linearizer. Exobrain contains the graph, interaction runtime and services. PIM resolves shell and driver-agent input against the graph.

Worker Studio connects pluggable coding-agent providers. Reader handles reading state and speech playback. Recognition, synthesis and other model execution belong behind service interfaces.

Molecule: code, data and execution in the graph Link to heading

Molecule’s intended design is a homoiconic, metacircular Zig/Lisp cross. Homoiconicity means code and data share a manipulable representation; metacircularity means expressing the evaluator in the language it evaluates. Here that representation is a graph. The intended runtime carries execution state explicitly, rather than making the host function-call stack the execution model. Object references belong to identities, independently of organizational location.

The current Chant engine is a TypeScript prototype with graph-backed expressions, bindings, calls and macro expansion. The self-expressed evaluator and execution without reliance on the host call stack remain design goals.

Streams and events Link to heading

Shells → Mixer → NATS. Shells supply video and audio streams. Mixer invokes local models and receives their results, then emits events on NATS for subscribers.

The diagram is an architecture sketch. The recording shows Worker Studio running in glasses on November 5, 2026.

PIM: interaction model and runtime

Lattice groups: one object, many organizations Link to heading

Lattice groups organize shared objects through multiple relations and coexisting hierarchies. A document can belong to a project, have an author, be produced by a task and be referenced by another document. These relationships provide several ways to find and work with the same object. No single containment tree has to become the authoritative organization of everything.

Identity belongs to the object; organization lives in its relations. Relations are first-class parts of the shared structure, with their own types and identities. A view can follow selected relations in a chosen direction to derive a hierarchy for its current context: projects and their documents, people and their work, tasks and their outputs, or documents and their references. Those views can coexist.

LATTICE GROUPS / IDENTITY AND ORGANIZATION

Four routes. One document.

Interactive architecture example

Release notes belongs to Atlas. Its identity is doc:42.

Several relations reach the same document Project Atlas includes Release notes. Mira authored it, Task 17 produced it, and Review memo references it. Every route reaches the same object, doc:42. Project Boreal currently has no membership edge to this document. includes authored produced references Project Atlasproject:atlas Project Borealproject:boreal Miraperson:mira Task 17task:17 Review memodoc:7 Release notesdoc:42ONE SHARED OBJECT Change one membership edge; preserve the object and unrelated relations.
Release notesdoc:42ONE SHARED OBJECT
  • Project Atlasincludes → doc:42
  • Miraauthored → doc:42
  • Task 17produced → doc:42
  • Review memoreferences → doc:42

Every route reaches the object above.

DERIVED HIERARCHICAL VIEWS / SEVERAL APPEARANCES OF THE SAME OBJECT

  • By projectProject Atlas↳ Release notes doc:42
  • By authorMira↳ Release notes doc:42
  • By producing taskTask 17↳ Release notes doc:42
  • By incoming referenceReview memo↳ Release notes doc:42
Persistent reference to doc:42Release notes · doc:42Unaffected by the project move
Query: documents in Atlasdoc:42Follows current project membership
Query: documents in BorealNo matching documentFollows current project membership
Illustrative reference contract: four relational routes and four view occurrences identify one document. Switching project membership changes the project view and the two membership queries. Its identity and the three unrelated relations remain unchanged. This diagram edits an example in the page.

In the example, Release notes is one object, doc:42. Changing its project membership from Atlas to Boreal changes that relationship. Its author, producing task and the reference from Review memo remain attached to the same document. Repeated appearances in the four views are occurrences of that one object. Reorganization does not inherently require copying the document or rewriting unrelated references.

A persistent reference and a relational query answer different questions. A stored reference to doc:42 identifies the document itself. “Documents in Atlas” asks what currently belongs to Atlas, so its result correctly changes after the move. A reference obtained from an earlier query can still identify doc:42; rerunning that query can return a different set of objects.

This separation requires an explicit identity and persistence contract. Multiple hierarchies alone do not guarantee durable references. Current Chant and Compass preserve shared identities within graph operations and projections; reference lifetimes across storage and integrations are part of the broader integration work. “Lattice groups” names this relational organization in the project; it does not assign universal meet/join operations to the whole graph.

The motivation is developed in Why I created another markup language, with relational discovery and interaction explored in Dynamically Generated Languages.

Compass: semantic graph navigation Link to heading

Compass renders the semantic neighborhood of an object. Inheritance, dependencies and composition are visible in both directions: inherits from / derived types, depends on / used by, properties / property of. Follow a relation, inspect a node, or make it the new center.

The Compass component rendering an example semantic graph. Explore a relation, choose a node, then Focus selected. Switch between the focus surface and radial sectors while retaining the current navigation. Open Compass in a full window .

The graph keeps its identities across navigation paths. A shared ancestor can appear through several inheritance routes without becoming several objects; cycles have explicit boundaries. The focus surface and radial sectors are two renderers over the same model and navigation state.

Walkthrough: make Readable the center Link to heading

Start with Document at the center of Compass and Readable selected in its Inherits from relation. This walkthrough follows the current Worker Studio command wiring:

  1. Input. Say “worker studio” to enter its interaction context, then “compass focus.” The voice adapter supplies the recognized words.
  2. PIM resolution and dispatch. PIM selects the Studio interaction frame and forwards the utterance into the application. Studio’s registered voice matcher resolves “compass focus” to the Compass action focusSelected(). PIM owns the application context; the renderer’s matcher owns this command binding.
  3. Graph operation. Compass resolves the selected occurrence to the existing node identity readable, changes its navigation model from focusId: document to focusId: readable, and projects the new focus’s outgoing and incoming relationships.
  4. Interface update. Readable becomes the center. Entity appears under Inherits from; Document appears under Derived types. The same objects now appear in a different neighborhood.

This is graph traversal and a view-state change over an example graph. A persistent edit to the Molecule SSOT graph remains a separate integration step. In the embedded demo, select Readable and press Focus selected to reproduce the graph operation and interface update; the embed does not include Worker Studio’s voice adapter.

Capability interfaces and UI polymorphism Link to heading

Capabilities are another application of the shared structure. An object can be Readable, Editable and Navigable at the same time. Those descriptions can guide the selection of a Reader, Editor or Compass presentation while preserving the object’s identity and relationships. A capability grouping is one way to organize objects alongside their projects, authors and other relations.

Compass already preserves its focused graph and navigation when switching layouts. Resolving presentations automatically from general capability descriptions remains a broader integration goal.

Research direction: a transformer graph head Link to heading

The proposed graph head would output Molecule expressions. It would map a model’s semantic representation into expressions of objects, relationships and composition, which an interpreter could turn into explicit graph structure.

There is no trained graph head or demonstrated model input/output pair in the current prototype. Model architecture, training objective and evaluation remain to be specified. The diagram describes the interface being investigated.

RESEARCH DIRECTION / PROPOSED INTERFACE

A graph head for language

  1. 01 / REPRESENTATION Sm Semantic space

    Representation width m
    Context encoded by a model

  2. 02 / GENERATION Hθ Transformer graph head

    Proposed expression generator
    Objects · relations · composition

  3. 03 / OUTPUT Expr Molecule expressions

    Target output language
    Objects and relationships

  4. 04 / INTERPRETATION L Language structure

    Interpreted graph structure
    Types, capabilities and relations

Hθ : Sm → ExprMolecule interpret : ExprMolecule → L
Proposed interfaces for expression generation and interpretation. No trained head or model input/output result is demonstrated here. Spatial rendering is a separate stage.

In this interface sketch, Sₘ denotes the model representation space; m would be its chosen feature width. Hθ denotes a head with learned parameters θ, ExprMolecule the target expression language, and L the interpreted graph structure. These names specify the proposed mapping. They do not supply a trained function or identify latent coordinates with language concepts.

Continuous 3D views of language Link to heading

General language structure is the subject of the visualization. The research direction is to lay out a selected region of that graph in a navigable 3D view. Focus, relation families and level of detail would determine what is exposed. “Continuous” refers to navigation and view transitions while graph identities, group memberships and relationships remain stable.

RESEARCH DIRECTION / VISUALIZATION ARCHITECTURE

  1. STRUCTURELanguage graphLattice groups · relations · focus
  2. LAYOUT3D hyperbolic spaceBranching · local detail · distant context
  3. PRESENTATIONContinuous navigationFocus transitions · stable graph identities
GRAPH VISUALIZATION3D graph navigation and rendering
Graph navigation and rendering. Andrej Jovanovic / @digitalbabel · 59 sec. Original recording on Instagram .

Hyperbolic geometry gives branching structure room around the focus. In a bounded 3D view, distant context compresses toward the boundary; bringing a region into focus reveals its local detail. A hierarchy can guide spatial placement while shared nodes and cross-links retain the graph’s richer structure. H3’s 3D hyperbolic graph layout is a reference for this focus-and-context approach.

Relations, group memberships and object identities remain in the model. The renderer chooses a spatial view of the graph. Compass and the recording above demonstrate graph interaction and rendering; they do not establish an implemented hyperbolic embedding of the language structure.

Throne: layered attention Link to heading

Throne is the design for a unified, general-purpose interface to this structure. Layered attention gives the current object or activity the richest presentation, keeps its working context nearby, and retains the wider structure in the periphery. Bringing something into focus changes the detail and interaction available around it while preserving its identity and relations.

The same structure is intended to support 2D, 3D and hyperbolic views: a screen layout, a spatial scene, or a focus-and-context projection. These are different geometries for organizing attention over shared objects. The design brings applications, media and agent activity into the same interface.

THRONE / A UNIFIED INTERFACE

Layers of attention

Open the prototype
  1. FOCUSThe current object

    Rich content and direct interaction.

  2. WORKING CONTEXTRelated objects and actions

    The relationships relevant to the current activity.

  3. PERIPHERYThe wider structure

    Compact representations and routes for discovery.

The current Throne geometry prototype. Open Scene controls to change the scene model, ring geometry and near/far views. Semantic integration, media-bearing nodes and hyperbolic layouts belong to the broader interface design.

Nodes can be “emotionally overloaded.” A node can carry video, a reel, sound, motion and visual associations alongside its structured meaning. The aim is maximum expressive density: a medium that conveys narrative, atmosphere and recognizable context within the object’s presentation. A compact peripheral node could unfold into a playable scene, a document or an editor as it receives attention. Its media is a presentation of the same object, with its references and relationships intact.

A Throne or Ophanim represented by two intersecting turquoise rings covered with eyes
Throne / Ophanim illustration by Paladium · CC BY-SA 4.0.

Why “Throne”?

I imagined the unified interface and drew it. Only afterward did I recognize the same form in imagery of a Throne angel I had seen before. That coincidence gave the interface its name.

Harnesses, data and metadata ownership Link to heading

An immense unfinished stone Tower of Babel, with arched tiers, scaffolding and builders beneath towering clouds
Tower of Babel
A hand carrying a blazing bronze torch, with a temple on Mount Olympus rising above the clouds behind it
Fire of Olympus
A hand holding a wooden and bronze staff crowned by a glowing openwork sphere, with fine luminous connections extending outward
Staff / scepter Mage · Developer · Ruler

Molecule / Chant is designed as a general-purpose substrate for harnesses. Tasks, tool contracts, execution state and results share an explicit language and graph. Different harnesses can coordinate models and tools around that representation.

An additional capability advantage over existing harnesses remains unproven. The stronger motivation is ownership of the information produced and accumulated through their use.

That includes both data—inputs, documents, generated artifacts and results—and metadata: stable identities, types, relationships, provenance and execution context. The aim is to retain these together in storage the user controls, with representations that remain inspectable and usable across applications, models and harnesses.

Ownership therefore becomes an architectural requirement: inspectable definitions, portable serialization and control over persistence and access. Changing a model or execution framework should preserve the accumulated information and the structure needed to interpret it.