06 — Product Architecture

SUMMA becomes much easier to understand once the reader stops seeing it as a single application and starts seeing it as a layered machine.

That machine is not layered for decoration. The layers exist because the problem itself has layers. A difficult legal record does not arrive with one clean problem. It arrives with file problems, source problems, continuity problems, issue problems, timing problems, trust problems, and later strategic problems. If the system tried to solve all of those at once in one undifferentiated step, it would become vague, theatrical, and unreliable. The architecture therefore has to move in stages, with each stage doing a different kind of work.

The first architectural responsibility is intake.

Intake is the point where material enters the system. In principle this sounds simple, but in serious review environments it is not. The system is not only receiving a file. It is receiving a file into a context. The context may include a disclosure drop, a particular stage of the case, a known folder structure, an existing workspace, or a history of prior material already under review. Intake therefore has two responsibilities at once. It must receive the material, and it must place the material into a meaningful environment without collapsing its identity. If intake is weak, everything after it becomes weaker. A badly received record remains harder to trust no matter how clever the later layers try to be.

That leads directly to the next architectural responsibility: source preservation.

Source preservation means the system must retain disciplined knowledge of what the material is, where it came from, how it entered the environment, and how to get back to it later. A serious legal-review system cannot afford to turn the record into a generic blob. The original file, its place in a production, its relationship to surrounding material, and its stable return path all matter. This is one of the deepest themes in the SUMMA architecture: preservation before interpretation. The system is not permitted to become intelligent by becoming vague.

Once source identity is preserved, the system can begin imposing higher structure.

This is where manifests and related structural records matter. A manifest is not glamorous, but it is one of the architectural devices that helps make a serious system inspectable. A manifest says, in effect: here is what this bundle, workspace, packet, or artifact contains; here is the state it represents; here is the inventory you can rely on. In a project like SUMMA, manifests matter because they support auditability, reproducibility, and safe re-entry. They are part of the architecture’s memory.

Hashing belongs to this same general family of trust infrastructure.

A hash is a fingerprint-like identifier derived from content. In the repo, hashes matter because Git uses them to identify tracked history. In the product and evidentiary world, they matter because they help support integrity, identity, comparison, and exact reference. Hashing does not solve the legal problem by itself, but it helps create a stronger technical basis for saying that one thing is the same as, different from, or derived from another thing. In a system concerned with trust, that matters a great deal.

Once the record is preserved and its structural identity begins to stabilize, the architecture can move toward anchoring and citation.

Anchors are one of the major turning points in the machine. A flat file system lets the user find a document. An anchored system makes it easier to get back to the exact place where pressure, meaning, or importance lives. Citation structures formalize that further by turning return paths into disciplined, reusable references. This is essential because serious review work does not operate only at the level of whole documents. It often operates at the level of one page, one passage, one statement, one timestamp, one contradiction, or one sequence point. If the architecture cannot support exact return, the higher layers become progressively more fragile.

That is why anchoring sits near the center of the machine.

From there, the architecture can begin turning the record into structured objects. In SUMMA, one of the main homes for this is the casecards lane. This is where the file stops being only a document environment and starts becoming a structured case environment. Cards such as citation references, fact cards, event cards, entity cards, issue cards, and workspace-level objects allow the system to hold more than storage. They allow it to hold organized meaning. This does not mean the system suddenly “knows the case” in a human lawyer’s sense. It means the architecture is becoming capable of preserving structured units of understanding without severing them from source.

Linking is what prevents those structured units from becoming isolated islands.

A serious architecture cannot stop at creating objects. It has to connect them. Facts connect to citations. Issues connect to fact clusters. Events connect to timelines. Entities connect to statements, actions, or contradictions. Linking is therefore one of the mechanisms through which the architecture becomes navigable rather than merely categorized. It is also one of the reasons the machine can begin supporting higher-order review behavior later. Without links, the system has fragments. With links, it begins to have a working graph of the case environment.

That graph-like structure makes issue bundles possible.

Issue bundles are one of the major signs that the architecture has crossed from orderly storage into real review support. Once the system can gather relevant facts, source anchors, contradictions, exhibits, and signals around a meaningful issue, it begins to reflect how serious legal work actually happens. Reviewers do not think only in filenames. They think in problems: credibility problems, timeline problems, disclosure problems, search problems, witness problems, theory-of-case problems. Issue bundles are architectural containers for that kind of thinking.

The workbench sits above this as the higher-order review environment.

The workbench is where structured objects, issue bundles, pressure logic, navigation, continuity, and user workflow begin interacting in a way that supports active serious review. A workbench is not just a nicer viewer. It is a place where the case becomes more inhabitable. It helps the reviewer move between overview and source, between issue and exhibit, between current posture and stale understanding. It is one of the clearest expressions of the system’s premium ambition because it turns structure into an environment for thought.

Pressure logic and the pressure engine build further on that.

Pressure is one of the core SUMMA ideas because it names something that ordinary storage systems usually ignore. A file is not difficult only because it is large. It is difficult because certain parts of it exert more strain than others. Some issues are more dangerous than others. Some contradictions matter more. Some exhibits carry disproportionate strategic weight. Some developments change the posture of the whole file. Pressure-oriented architecture tries to make that visible. At the highest end of the premium ladder, this becomes the strategic pressure engine: the attempt to surface not just what exists, but what matters most and why.

No serious architecture can end there, however, because a machine also has to produce usable output.

This is where the export layer matters. Internal structure is valuable, but only up to a point if it cannot be turned into artifacts, dashboards, packets, briefs, summaries, manifests, and other deliverable outputs. The export layer is how the machine expresses its structured understanding in forms that human beings can use, read, transfer, preserve, or build on. It is one of the places where the architecture becomes visible to the operator.

The training and docs layer also belongs to the architecture, even if it looks less technical at first glance.

A company like SUMMA cannot afford to treat explanation as an afterthought. The docs site, the manuals, the lexicon, and the training materials are part of the architecture because they determine whether the machine can be learned, transferred, audited, and scaled across people. A product that cannot explain itself clearly is, in practice, weaker than one that can. Documentation is therefore not just wrapping paper. It is one of the system’s real operational layers.

Seen as a whole, then, the architecture moves in a sequence. Material enters through intake. Source identity is preserved. Structural records support trust. Anchors and citations create exact return paths. Structured objects begin holding case meaning. Linking creates a navigable internal graph. Issue bundles make problem-centered review possible. The workbench creates a serious review environment. Pressure logic surfaces what matters most. Export layers produce usable outputs. Training layers make the machine learnable.

That is the architecture in its broadest form.

The reader should leave this chapter with one central understanding: SUMMA is not one clever feature sitting on top of a file pile. It is a layered architecture designed to move the record from raw accumulation toward structured, source-linked, pressure-aware usability. Every premium ambition in the system depends on that architecture being strong underneath.