Scores, History & Reports: Making Governance Visible
Once every governed change flowed through one Branch/Merge spine, something became possible that wasn't before: measuring it. The visibility layer doesn't change how governance works — it makes what's already happening legible, so a reviewer sees risk instead of just a diff, and a lead sees the workspace's health instead of just a list of notifications.
Impact scored, not guessed
Every fan-out notification carries a 0–100 impact score and a low/medium/high/critical risk level, computed once at merge time from four signals: reach (how many services are affected), breaking-change detection (an API method or path-shape change, a delete, a tightened validation rule), secret or structural sensitivity, and a governance gap signal — whether anyone can even action each impact. The raw signals are stored alongside the blended score, so the weights can be tuned against real usage data later instead of being frozen guesses. Each impact row also renders a required-action hint — "re-sync your copy," "adopt or decline this column" — so an approver knows what saying yes actually does.
A history you can search, not reconstruct
Merged branches were always the permanent record of what changed. The audit trail records everything around that: branch created, submitted, decided, merged, reverted; every impact approved or rejected (and by whom, with what comment); every resync and override publish. It's append-only, filterable by service, actor, event type, and date, and free-text searchable — and it respects member visibility, so you only ever search history you're allowed to see.
The Change Review Center
Opening a branch now answers the reviewer's real questions before merge, not after: a per-domain summary of what's staged, an impact matrix previewing exactly who would be notified (and, post-merge, what each service actually did), a readiness score that docks points for unresolved conflicts, breaking changes, and pending impacts, and which other open branches touch the same entities — the ones that will conflict if this merges first. Reviewers can also leave comments, including a formal "request changes" signal, without turning the binary decision into a committee.
Rolled up: the Workspace Report
And when a merge turns out to be wrong, revert is a first-class governance action: it creates a normal draft branch with before/after swapped for every update-type change, going through the same submit → review → merge path as anything else. Structural creates and deletes are skipped and reported honestly rather than silently mishandled — undoing those is a decision, not a mechanical inversion.