Aspects Across Systems

The root board's Aspects screen shows what passes between your apps: the events they exchange, the calls they make to each other, and where AI runs. Use it to see who breaks when a contract changes, across repos, and which app's agents reach what.

Each view is built from every app's own aspects when you open it, so it always matches the apps.

Before you start

Each app needs the aspects the views read:

Run them in each app's repo with the code plugin. Each app also needs a node on the root board, with the app board as its layer.

Read the events between systems

Open Aspects on the root board and choose Events.

Channels with the same broker and name, from every app, fold into one lane. The lane's From side lists the apps that publish on the channel, and each event type lists the apps that receive it. An app that carries an event type without sending or receiving it shows as declares. The row Every event type lists the apps that listen to the whole channel.

No app here publishes it means no app on the board names a producer for the channel; a webhook still shows the route it arrives at. The line above the lanes counts event types whose copies disagree, event types no app subscribes to, and channels with no publisher among these apps.

Select a lane for the apps the channel comes from, each with a link to open it in its own app. Select an event type for Published by, Received by and, when an app only declares it, Declares it only.

When copies disagree

When a subscriber's copy of an event reads a field no publisher sends, or reads it as another type, the event type and that app are marked in orange. The event type's panel shows Copies disagree:

Web Shop reads orderstatus as string; the publisher sends orderstatus.

Reading fewer fields than the publisher sends isn't flagged. When no system on the board publishes the event, only type disagreements between the copies are flagged. An event whose schema ProvenMap can't read, such as an Avro blob, is never compared.

Read who calls whom

Open Aspects on the root board and choose Clients.

Expand

Each app's clients fold onto the root node their target names: http://catalog-api, catalog-api and CatalogApi all match the node catalog-api. A name no node matches gets its own column in italics, and its panel says No system answers to this name. Draw the missing system, or rename the node to the name the code uses.

Choose a cell to open the dependency. When the called app has extracted its api.surface, each call links to the endpoint it reaches.

Open an app board from the root and each endpoint you open on its Endpoints tab shows Called by: the other apps whose clients call it.

Read where AI runs

The AI tab, Where AI runs, is a matrix of your apps against the model providers their code names. A cell counts the agents and model calls in that app that reach the provider; an agent naming two models of one provider reaches it once. Under the matrix, What AI reaches lists every tool that reaches a table, an endpoint or a client, in the app that serves it. Tools reaching a column classified pii, confidential or secret come first. An app with no agents, tools or model calls is not a row.

Boundary rules count the calls

Boundary rules on the root board check the calls from Clients as well as the root's edges. A forbidden call is a crossing even when no one has drawn the edge. The rules run again each time an app's push lands.

See it on the root hub

The root hub shows the System aspects card by default. It counts boundary rules, event channels and dependencies, each with what needs attention: violated rules, event types whose copies disagree, and calls to a service no node matches.

When the card is wide enough, it draws the same calls and events as a matrix in place of the counts. Each row is a system, and it depends on every column it has a number in; the number counts its calls and event subscriptions to that system. A ringed cell is On a loop: systems that depend on each other, directly or through others, listed under the matrix. The matrix draws the 12 most connected systems and says how many it left out.

The root hub's System scorecard card carries the totals: Dependencies between systems, Loops between systems, Rules violated, Events that disagree and Calls nobody answers. Change Cards explains its other cells.

Ask about it in chat

In Chat, ProvenMap reads all three views with the get_system_view tool, and so does the workspace plugin. Either can raise an insight for contract drift, a call to an unknown service, or a call with no drawn edge. An agent with a read MCP token can use the same tool.

FAQ

Can I edit an event or a client on the root?

No. Change the code and run /aspects again in that app; add notes on the app's own board.

Do published boards show these views?

No. A published root board shows only the rows you select on it, such as its boundary rules.

What's next