Technology · Object Context

A product graph, not a code graph.

A code graph answers "what calls updateOrder". Object Context answers "how does an order get from placed to refunded, what fires when it does, and which three services read the field you are about to rename". This page explains how that structure is built, verified and kept synchronized with the code.

01 · Objects

Ten collections, one graph.

The model lives in the repository as plain JSON — ten linked collections, every reference a stable id, so they form one graph instead of ten lists: modules · entities · serverUnits · serverFunctions · apiRoutes · frontendUnits · events · processes · statusFlows · reactions. Diff it, review it in a PR, grep it.

The last four collections are what make it a product graph. Most tools build a code graph — functions, calls, imports. Journeys, lifecycles, events and reactions carry what the software means: which states an object may legally walk, what fires on each transition, and which path a user's action takes through the whole product.

02 · Relationships

Inbound as well as outbound.

Every link is directional and typed: a function writes fields an entity owns, calls other functions, emits and subscribes to events, answers a route; a screen consumes routes; a lifecycle carries transition effects; a journey names the objects its steps walk. Outbound links tell you what a thing uses. Inbound links tell you what breaks when you change it — and inbound is the direction everyone forgets.

Reach is computed breadth-first along those links, bounded to two hops — unbounded reach on a connected product is just the whole product. Naming an area counts as touching everything inside it.

Risk componentWeightWhy
Sensitive data reached×4Money, credentials or personal data — marked in the model, not guessed.
User journeys affected×3Someone walks through these — breaking one is visible to them.
Lifecycles touched×3State machines carry effects that fire on every transition.
Module boundaries crossed×2A change spanning several areas is a bigger thing than one inside one.
Endpoints · screens · downstream functions · internal processes×1Contracts, visible surface and machinery in reach.

The total is divided by what the whole product would score, so risk reads as a share of the product — the same reading in every project.

03 · Evidence

Every object names its source.

Each object carries the paths of the files it was read from. A claim in the model is checkable: open the file, see the behavior. When the interpreter meets a reference it cannot resolve, it records the unknown with its evidence instead of inventing a link.

The trust rule

A model with twelve recorded unknowns is trustworthy; a model with twelve invented links is not — and from the outside the two look identical. That is why unresolved references are first-class data, shown with the model, never papered over.

04 · Confidence

Reading everything, completely.

On a system too large for one context window, an agent asked to "map this" does not fail with an error — it reads part, summarizes, and hands you a model that looks complete. The entities survive that treatment; the links between distant parts do not, and in a legacy system those links are the product.

So the ingest does not read first. It measures — file and line counts per folder — cuts the source into fragments, orders them so the things everything else points at are built first, and writes one queue task per fragment. Each task runs with a fresh context holding only its own slice and reads it in full. On Supabase that was 359 tasks over 3,972 files — 459,339 lines actually read, none skimmed.

05 · Synchronization

A model older than the code says so.

The model lives next to the code and refreshes after changes; staleness is detected and stated at the top of the view — naming the file that moved most recently — rather than discovered in production. The queue and progress log are on disk, so a new session continues exactly where the previous one stopped.

This is what makes the context reusable: interpreted once, kept current, consumed by every next task — instead of each person and each agent reconstructing the product from source, every time, forever.