Team Architecture

The Team Architecture screen maps your codebase to your team topology — making Conway’s Law effects measurable rather than theoretical. It answers the structural questions that matter before and after a reorganisation: where ownership is contested, where coordination overhead accumulates, how team boundaries have shifted over time, and whether a restructuring actually reduced cross-team coupling.

All metrics derive exclusively from Git commit history. No integrations, no survey data, no manual input beyond the team configuration in config.yaml.

The screen is split into two tabs. The three KPI cards at the top are always visible regardless of which tab is active.

KPI Cards

Three summary numbers shown above both tabs.

Card	What it Measures	Colour
Cross-Team Coupling Pairs	Number of module pairs owned by different teams that change together. Each pair is a potential coordination hotspot.	Amber when > 0
Coordination Events	Total commits that touched modules from more than one team. Accumulated coordination overhead visible in the commit history.	Neutral
Contested Modules	Modules with meaningful contribution from more than one team. Prime candidates for ownership clarification or service boundary redesign.	Amber when > 0

Tab 1 — Team Topology

Current-state analysis of team ownership and coupling.

Team Health Table

Each team’s top three modules by commit volume, with an ownership status badge.

Status badges:

Focused — the team’s commit activity is concentrated in its assigned modules.
No redundancy — one team dominates with > 90 % of commits; no meaningful secondary contributor.
Spread thin — the top two teams together cover less than 50 % of commits in the team’s primary module; activity is fragmented.
Unassigned activity — more than 30 % of commits in the team’s modules come from developers not assigned to any team.

Note

The status badge measures how concentrated this team’s work is — not whether other teams also work in the same modules. A team can be Focused while still appearing in the Module Ownership Heatmap as a secondary contributor elsewhere.

Module Ownership Heatmap

A module × team matrix showing each team’s commit share per module.

Colour coding:

Green — dominant owner: > 50 % of commits
Yellow — significant contributor: > 20 % of commits
Grey — present: ≤ 20 % of commits
— — no contribution in the selected period

Contested modules — those where multiple teams contribute meaningfully — appear at the top of the list.

Team Coordination Matrix

Cross-team co-change events per team pair. Each cell shows the number of commits that touched modules owned by both teams in the same commit. Higher values indicate accumulated coordination overhead that is already embedded in your Git history.

Teams with no cross-team coupling share show 0 or —.

Tab 2 — Drift & Reorg

Temporal analysis of how team ownership has shifted and whether interventions have had measurable effect.

Ownership Drift Timeline

A stacked area chart showing each team’s share of commits per module across quarterly time buckets. Only modules with a meaningful ownership shift (≥ 10 % change in the leading team’s ratio across buckets) are included — these are the modules where responsibility has visibly moved between teams.

Use the Module dropdown to switch between affected modules. The chart renders:

A single full-width stacked area when one module is selected.
A summary view when no module is selected (all modules combined).

Tip

A module where one team’s ratio rises sharply while another’s drops is the earliest signal of an informal ownership transfer — one that may not yet be reflected in your team configuration or org chart.

Reorg Validator

The Reorg Validator answers the question: did the reorganisation actually work?

Enter the date on which a team restructuring took effect. Calyntro fires four parallel queries against the existing coupling and alignment endpoints — two covering the period before the date, two covering the period after — and presents a before/after comparison for three metrics:

Metric	What it measures
Cross-Team Coupling Pairs	Number of module pairs owned by different teams that changed together. A decrease indicates the restructuring aligned team boundaries more closely with actual co-change patterns.
Coordination Events	Total commits touching modules from more than one team. A decrease indicates reduced accumulated coordination overhead.
Contested Modules	Modules with meaningful contribution from more than one team. A decrease indicates clearer ownership after the restructuring.

Delta indicators are colour-coded: green for improvement (values decreasing), red for regression (values increasing).

Note

The Reorg Validator uses no new backend endpoint. It re-uses the existing POST /v1/analysis/coupling/modules and POST /v1/analysis/alignment/modules endpoints with date-bounded requests. The “before” window covers all commits up to the entered date; the “after” window covers all commits from that date onward.

API Endpoints

Endpoint	Widget
`POST /v1/analysis/alignment/modules`	Team Health Table, Module Ownership Heatmap, Contested Modules KPI, Reorg Validator (alignment)
`POST /v1/analysis/alignment/teams`	Team Health Table (team-centric view)
`POST /v1/analysis/coupling/modules`	Team Coordination Matrix, Cross-Team Coupling Pairs KPI, Coordination Events KPI, Reorg Validator (coupling)
`POST /v1/analysis/alignment/drift`	Ownership Drift Timeline

For full request/response documentation see the API Reference under Team & Knowledge.

When to Use This Screen

Before a reorganisation: Use Tab 1 (Team Topology) to identify which modules are currently contested, which team pairs generate the most coordination overhead, and where ownership is ambiguous. This is the evidence base for designing new team boundaries — not gut feel or org-chart proximity.
During an ongoing transformation: Use the Ownership Drift Timeline (Tab 2) to track whether team boundaries are stabilising or continuing to drift. A module where the stacked areas converge toward one dominant team is stabilising; a module where they fragment further is a signal to intervene.
After a reorganisation: Use the Reorg Validator (Tab 2) to measure the outcome quantitatively. If Cross-Team Coupling Pairs and Coordination Events decreased, the restructuring reduced architectural friction. If they increased or held flat, the new boundaries may not match the actual co-change structure of the codebase.