Siloquy · dynamic UML · Meaning Cells · repository evidence
Dynamic, navigable, multi-layer UML for large codebases.
Siloquy transforms a repository into a navigable representation: source structure, Siloquy-AST, SCIR, Meaning Cells, dependency hierarchies, flow, and generated UML views. It is not generic code search. It is a way to see what a software system means and where the evidence lives.
From source code to dynamic UML humans and agents can inspect.
Siloquy starts with the real repository and keeps a chain of evidence back to source. The goal is not to hide complexity; the goal is to make the structure, intent, and flow inspectable enough that humans and agents can reason about the same system through multiple UML and graph layers.
Operator manual Handle MeaningCell graph and sequence views How Flow Diag., Seq. Diag., TOM flow, context menus, and inspection work in the Siloquy viewer.Repository ingestion
Files, symbols, modules, and relations are collected as source-backed evidence, ready for generated views.
Siloquy-AST & SCIR
Concrete source structure is normalized into intermediate forms that can be compared, queried, and explained.
Meaning Cells
Small units of meaning become the bridge between raw code and readable architecture-level understanding.
Multi-layer UML
Generated UML views stay dynamic and navigable, from local code structures up to architecture-level system shape.
MDG & TOM flow
Trace-oriented flow connects execution, data movement, dependencies, and handover points.
Viewer evidence
The viewer keeps generated UML, diagrams, and summaries tied to source evidence, so a beautiful picture remains accountable.
Many signals, one system model.
A large codebase rarely has one simple story. Siloquy lets several signals exist at once: UML layers, hierarchy, flow, dependencies, semantic annotations, diagrams, and evidence. The crossings are the important part: where meaning from one signal changes what another signal means.
- Move from a graph node to the source evidence that supports it.
- Compare structural hierarchy with runtime or dependency flow.
- Use dynamic UML as an interface to inspectable repository facts.
Diagrams that answer back.
Generated UML and graph views should not be decorations. They should be dynamic interfaces into the repository: every box, edge, and cluster should be able to explain why it exists, what source supports it, and what work item in Portae cares about it. Soon the Guide can become the conversational operator for this surface: writing architecture and code through Siloquy's UML interface.
