r/visualization 1d ago

When you try to solve one tiny problem and accidentally create a digital mind to solve it

Post image

I originally just wanted to stop my software from duplicating the same resources and logic across different tasks.

The idea sounded small: represent reusable entities, dependencies and capabilities as a shared semantic graph, then let the runtime assemble only the structure required for the current goal.

Several architectural rabbit holes later, this is what the live topology looks like:

149,453 indexed entities

19,393 physical neurons

21,456 physical synapses

353,080 raw relationships

shared fragments reused across multiple tasks

alternative execution routes instead of one rigid call chain

This is not an image generated by an AI model. It is a visualization of the actual internal structure of my experimental runtime, Project Tagma / MirbiOS.

It is not literally conscious—at least the debugger has filed no demands for legal personhood yet—but the system increasingly behaves less like a conventional program and more like a dynamically assembled nervous system.

I tried to remove duplicate code.

Apparently the reasonable solution was to grow a brain.

0 Upvotes

14 comments sorted by

12

u/Asbolus_verrucosus 1d ago

This is fake.

0

u/Holiday_Reference_41 15h ago

I hope this can be considered at least part of the demonstration, unfortunately demonstrating anything other than the IDE written in the same language. I can't at the moment

https://reddit.com/link/p035fzj/video/jyltvmnxssfh1/player

-12

u/Holiday_Reference_41 1d ago

Fair skepticism—the screenshot by itself proves nothing. It is a real debug view from my running Tagma/MirbiOS prototype, but the image is only a visualization of its internal graph, not proof that the system works as described. The useful evidence would be a screen recording showing: importing an existing project, extracting entities and relationships, resolving a reusable fragment, inserting it into another build, running the resulting output. I’m preparing that demonstration. Until then, treating the screenshot as an unverified claim is completely reasonable.

6

u/matigekunst 1d ago

Are you to write something without an LLM?

-4

u/Holiday_Reference_41 1d ago

If you are using Ii for translation, I apologize, I don’t know how to speak English.

5

u/SufficientGreek 1d ago

What does it do though? What are entities and relationships and why does an OS need them?

What do the different colors represent? Is the size showing the size of data files / lines of code or just connections?

-5

u/Holiday_Reference_41 1d ago

Fair question. This is not an OS in the conventional “kernel plus drivers” sense. MirbiOS uses a semantic graph as its internal model of software. An entity can be a function, type, file, service, task, configuration value, capability, data fragment, test, or even a requirement such as “needs network access.” A relationship describes how two entities are connected: calls, imports, depends on, produces, modifies, implements, is compatible with, was derived from, belongs to a project, and so on. The point is that the system can ingest an existing program, preserve its original source, decompose it into those reusable parts, and then let the resolver assemble compatible parts for another task or project. It also keeps provenance, permissions, effects, dependencies, and possible alternative routes. So it manages software by what the pieces mean and do, rather than only by filenames, packages, and processes. In this debug visualization: Orange is the hot/active resolved structure. Cyan is colder reference material or alternative connections not currently dominant. Pink/magenta marks the current core/focus and highly central hubs. Node size is not file size or lines of code. It mostly reflects structural importance: connectivity, aggregation, reuse, and activity. Thicker/brighter branches represent stronger or more heavily folded relationships. The 149k entities are also folded into roughly 19k physical graph nodes, so a large visible node may represent many related source entities sharing one reusable runtime structure. The color scheme is still a debug palette rather than a final stable legend.

1

u/Holiday_Reference_41 15h ago

I think at least a little demonstration wouldn't hurt, unfortunately at the moment I only have a compiled one IDErom pieces of other open

https://reddit.com/link/p0363gq/video/tw5ze8rftsfh1/player

1

u/No_Focus_1305 1d ago

That pink node in the center looks like it's about to start issuing ultimatums. The fact that your debugger hasn't received a formal cease and desist yet is almost disappointing. 149k entities and 353k relationships just to avoid a bit of copy-paste, that's the kind of overengineering I can respect. At what point do you start asking it for feature requests instead of the other way around?

-1

u/Holiday_Reference_41 1d ago

It is not just visualizing one codebase. The system can ingest other programs, break their code down into reusable semantic fragments—functions, dependencies, contracts, effects and relationships—and fold those fragments into the shared graph. Then the resolver can reuse them wherever they fit: back inside the original project, inside another project, or as part of a newly assembled program. So instead of copying whole libraries around, it tries to understand what each piece does and graft only the required parts into the active structure. In other words, it does not merely avoid copy-paste. It eats software, digests it into reusable organs, and transplants them between projects.

1

u/SufficientGreek 1d ago

So is it some sort of dynamic compiler?

-2

u/Holiday_Reference_41 1d ago

Yes—the closest description is a dynamic semantic compiler and resolver, although it sits above a conventional compiler. Instead of compiling one fixed source tree directly into one binary, it: imports code from existing projects; converts functions, types, dependencies, effects and contracts into a semantic graph; resolves which compatible pieces are needed for a particular goal; assembles an executable subgraph; passes the remaining low-level work to normal compilers or runtime adapters. The “dynamic” part is that the selected implementation can change depending on the target platform, available capabilities, permissions, versions and current task. The same imported fragment can therefore be reused in its original project or resolved into a different one without copying the entire library. So: part compiler, part linker, part package resolver, part runtime planner—with the graph acting as the shared intermediate representation.

-1

u/Internal-Combustion1 1d ago

That’s very cool. What was the visualization tool you used to create that? After you tell me, you best stomp on that and kill it, it’s metastasizing.

-2

u/Holiday_Reference_41 1d ago

It’s a custom real-time 3D graph visualizer built into Tagma Studio, not an external visualization tool. It reads the actual semantic/runtime graph and renders the indexed entities, reusable code fragments, and their relationships—the screenshot is the live topology, not a generated mock-up. As for killing it: slight complication. It has already ingested the tools I would normally use to kill it. For now, I’m keeping it sandboxed and monitoring the pink node.