Last updated September 27, 2026
Aspects Across Systems
The root board's Aspects screen shows what passes between your apps: the events they exchange and the calls they make to each other. You use it to answer "who breaks if this changes" across repos, not one repo at a time.
Nothing here is drawn or stored on the root. Each view is built from the aspects every app already holds, each time you open it, so it's never out of date with the apps.
Before you start
Each app needs the aspects the views read:
Run them in each app's repo with the code plugin. The root needs a node for each app: an app board sits under the root node whose layer it is, and that node is the app on these views.
Read the events between systems
Open Aspects on the root board and choose Events.
Every app's channels with the same broker and name fold into one table. Each row is an event type; each column is a system. A cell says what that system does with the event:
Choose a row to open the event type. The panel lists who publishes it and who subscribes, and Open in its app takes you to each app's own channel.
When copies disagree
Many codebases copy an event's definition into every service that uses it. When a subscriber's copy reads a field no publisher sends, or reads it as another type, its cell gets an orange ring and the panel shows Copies disagree:
web-shop reads orderstatus as string; the publisher sends orderstatus.
A subscriber that reads fewer fields than the publisher sends is fine and isn't flagged. When no system on the board publishes the event, only type disagreements between the copies are shown, because there's no way to say which copy is right. An event whose schema is opaque to ProvenMap, such as an Avro blob, is never compared.
Read who calls whom
Open Aspects on the root board and choose Clients.
Each app's clients fold onto the node their target names. A row is one system's dependencies; a column is everyone who calls that system. A cell shows the protocol and how many calls the code names.
A client's target is matched to a root node by name, so http://catalog-api, catalog-api and CatalogApi all find the node catalog-api. A name no node answers to gets its own column in italics. Choose that cell and the 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. Calls lists each call the code names. When the other app has adopted its api.surface, each call links to the endpoint it reaches. Choose endpoint to open it there. Clients in the code opens each client on its own app board.
The same fold works from the other side. When you open an app board from the root, each endpoint on its Endpoints tab shows Called by: the other apps whose clients call that endpoint. Choose one to open the calling client in its app.
Boundary rules count the calls
Boundary rules on the root board are checked against two kinds of evidence: the root board's edges, and the calls from Clients. A call a rule forbids is a crossing even when no one has drawn the edge. The rules are checked again each time an app's push lands, so a new call shows up without anyone touching the root.
See it on the root hub
The System aspects card counts the boundary rules, event channels and dependencies between the systems. Each count comes with the part that needs a look: violated rules, event types whose copies disagree, and calls to a service no node answers to. It's hidden by default; add it from the root hub's Add widget palette.
Ask about it in chat
Chat and the architect plugin read both views with the get_system_view tool. They can raise an insight for contract drift, a call to an unknown service, or a call with no drawn edge. An external agent with a read MCP token can use the same tool.
FAQ
Can I edit an event or a client on the root?
No. The root shows what the apps hold. Change the code and run /adopt again in that app; notes on a row are added on the app's own board.
Do published boards show these views?
No. The views fold every app's aspects, whatever you selected to publish, so publishing them would show rows you didn't pick. A published root board shows only the rows you select on it, such as its boundary rules.