The Problem
Understanding real software is the expensive part.
When you inherit, debug, or extend a large system, the hard questions are very practical. What does this thing really do? Where is a particular behavior implemented? If the product misbehaves, where should you look first? If you change this part, what else might break?
This matters for ordinary software, but it matters even more for embedded systems and complex control applications. The visible problem may be in a machine, a vehicle, a control loop, or a business process. The relevant cause is somewhere in the codebase, behind functions, modules, callbacks, state, timing, and error paths.
The debugging task is not only finding a suspicious line. It is finding where the behavior probably happens, and understanding the side effects before creating a new problem.
Why Not Just Ask A Model?
A large context window is useful. It is not a memory.
The obvious AI solution is to throw source code into a strong model and ask questions. That works surprisingly often. It also becomes expensive and fragile as the repository grows.
With a large codebase, the model either reads more and more code, which costs time and money, or it reads only part of the system. The skipped part may be exactly where the hidden side effect lives. The failure mode is not that the answer looks bad. The failure mode is that the answer sounds reasonable while being grounded in the wrong slice of the system.
Large codebases need a persistent semantic map, not repeated heroic rereading.
Meaning Cells
A reusable layer of meaning above source code.
Siloquy tries to put the meaning of a program into small, dense units called Meaning Cells. A Meaning Cell is connected to source evidence, but it is easier to inspect than raw source. Cells can exist at different levels: line, block, branch, function, module, and system.
The mental image is simple: imagine the program as if it contained only comments, but comments with structure, hierarchy, dependency, and flow. The code remains the authority. The meaning layer becomes the first surface a human or agent can navigate.
An agent can skim Meaning Cells, follow hierarchy, inspect dependencies, and only open source when it needs ground truth. A human gets the same advantage. The system becomes easier to ask about because the meaning has a place to live.
The Scientific Core
Build meaning cheaply, incrementally, and with evidence.
The interesting technical problem is how to build Meaning Cells reliably without requiring a giant model to reread everything. The target is a relatively low-cost crawler that analyzes small pieces, assigns meaning, and builds upward.
For that to work, cells need useful dependency shape. Lower-level cells should be understood before higher-level cells depend on them. Real software is not a clean tree, but there are useful axes: containment, control flow, data flow, call relationships, synchronous and asynchronous behavior, semantic dependency, and side effects.
Small pieces become larger pieces. Local meaning becomes abstract meaning. The map becomes reusable.
Dynamic Views
Diagrams should be interfaces, not wall art.
Most people understand complex software better through diagrams than through raw listings. Siloquy should show UML-style diagrams, call graphs, flow diagrams, hierarchy views, dependency views, and other projections where they help.
The important part is that these diagrams should not be static exports. A reader should be able to open a module, inspect internal calls, fold it back into the larger system, switch between flow and dependency views, inspect branches and error paths, and jump from a diagram node to Meaning Cells and then to source code.
Creating Code
The same structure can guide new software.
Siloquy is not only for reading old systems. The same structure can support creating new software. The target is not prompt-in, code-out. That is useful for small work, but risky when the result arrives as one large blob.
Serious software should descend through intention, architecture, top-level Meaning Cells, detailed Meaning Cells, diagrams and flows, simulation where useful, and finally code. The user should be able to stop, inspect, and correct the meaning before the mistake is buried in implementation.
The future I want is conversation in, visible logic out, inspectable architecture out, and code only when the meaning is clear.
Why Portae Exists
Agentic work needs a place.
When I started building Siloquy, I wanted agents to help write it. The idea was too complex for clever chat alone. The work needed documents, requirements, reviews, comments, tasks, orders, messages, tests, and decisions. That is why Portae exists.
Portae is the process and orchestration surface around agentic work. It gives agents and humans one visible place for Decks, Cards, review comments, Orders, Messages, backlog items, test cases, and implementation evidence.
Named agents with roles can receive work, ask questions, review each other, and report back. Humans can intervene where a real decision is needed, not on every generated detail.
Vibe coding gives output. Siloquy and Portae give an inspectable construction process.