Architecture governance creates a surprising amount of evidence: standards are evaluated, findings are raised, developers remediate code, exceptions and approvals may be recorded, ADRs govern decisions, and pull requests are reviewed again.
Individually, each of those events is useful.
Together, they tell a much more important story:
Why was this software considered architecturally acceptable?
In the previous article, From Violation to Fix — AI Guidance and Recommended Code, I focused on the developer experience:
That is where governance becomes actionable.
But once the implementation is fixed, another responsibility appears.
The organization must be able to preserve and explain what happened.
That is the role of ArkSentinel AI's Compliance & Evidence Reports.
The problem with a green check
A green GitHub check is very useful during a pull request.
It answers an immediate delivery question:
Can this change proceed?
But imagine looking at the same change six months later.
Someone asks:
Why did this implementation pass?
Which standards were evaluated?
Which versions of those standards applied at the time?
Were there initially violations?
Were they corrected?
Was an exception involved?
Was there an architecture decision governing this code?
Who approved the final result?
What evidence demonstrated that the implementation became compliant?
A simple green check cannot answer those questions.
And in many organizations, reconstructing the answer means searching across GitHub, architecture documents, ticketing systems, emails, spreadsheets and people's memory.
That is not durable governance.
I wanted ArkSentinel to treat the evidence of the decision as a first-class product capability.
From governance activity to governance evidence
Throughout this series, governance has appeared as a workflow: pull requests are evaluated against standards, findings are generated, exceptions and ADRs are governed, and developers receive guidance. Each step creates data. Compliance & Evidence Reports turn those records into evidence that can be scoped by portfolio, repository, team, domain and reporting period, so each audience can examine the same history at the right level.
A real example: ADR-001
Consider the ADR scenario used earlier in this series:
ADR-001 — Use Event-Driven Integration for Payment Processing
The accepted architecture decision governs part of the implementation in `payments-api`.
A developer introduces a change that does not satisfy the required architecture behaviour.
The workflow proceeds like this:
Accepted ADR → violating PR → automatic GitHub webhook → ArkSentinel finding/check FAIL → developer fixes code → automatic re-review → ADR Validated → standards compliant → 100% compliance → human approval → GitHub check PASS → merge
At development time, the important outcome is that the problem was found and corrected.
For governance evidence, every stage matters: the governing ADR, the standards and exact versions, the original finding, implementation evidence, remediation, subsequent review, approval and final delivery outcome. A percentage such as 100% compliance describes the result; evidence explains it.
Reconstructing the exact policy basis
One of the reasons I invested in policy versioning earlier in ArkSentinel was precisely this problem.
Architecture policy changes.
Imagine a review performed under:
MSG-001 v2
Later, the organization publishes:
MSG-001 v3
If somebody examines that historical review after v3 becomes active, the historical evidence must not silently change.
The original decision was governed by v2.
That fact needs to remain true.
Historical architecture governance therefore requires a durable relationship between the review and its exact policy basis.
That allows a reviewer to answer:
“What rules actually applied when this decision was made?”
rather than:
“What rules happen to be active today?”
This becomes especially important when a report covers a longer period containing several versions of the same policy.
Evidence references and the evidence manifest
A report should also distinguish between a summary and the records that support the summary.
For that reason, the implemented reporting capability includes evidence references that point to the underlying governance evidence represented in the package.
An evidence manifest provides a clearer picture of the sources behind the report.
This is an important principle for me.
AI can summarize information.
Dashboards can visualize it.
Reports can aggregate it.
But when someone asks:
“What is this statement based on?”
the product should be able to lead them back toward the evidence.
That makes the report useful not only as a presentation artifact, but as an entry point into the governance history.
Compliance and audit readiness are not the same
While building this capability, another distinction became increasingly clear.
A system can be compliant and still have poor governance evidence.
Suppose a repository has no unresolved architecture violation.
That sounds good.
But perhaps an important approval was recorded without a meaningful rationale.
Perhaps an exception was approved without enough context.
Perhaps its expiry information is incomplete.
Perhaps an ADR exists, but its decision history does not provide enough information to explain how the architecture decision evolved.
Technically, the implementation may be compliant.
From an evidence perspective, the governance record may still be weak.
That is why ArkSentinel also evaluates audit readiness and exposes evidence gaps.
This distinction helps avoid a common trap.
Governance should not become an exercise in creating documents simply so that documents exist.
The objective is not administrative volume.
The objective is decision traceability.
Can somebody understand the policy basis?
Can they identify the finding?
Can they understand the exception and its rationale?
Can they see the approver?
Can they determine whether the exception expired?
Can they understand the relevant ADR?
Can they see what eventually happened to the software?
If important pieces are missing, the report should make that visible.
Exceptions need evidence too
Exceptions are especially important because legitimate deviations do occur. The evidence should preserve who requested the exception, why it was needed, its scope, who approved it, when it expires and what ultimately happened. Without those details, an exception can become an invisible permanent bypass; with them, it becomes a governed decision. The same principle applies to human approvals.
ADR evidence closes another gap
ADR Governance introduced another evidence source.
An architecture decision is not very valuable if it exists only as a document that nobody can connect to implementation.
ArkSentinel links architecture decisions to governance scope and can enforce ADR-related expectations during the pull-request workflow.
That means the evidence story can connect:
This is a much stronger representation of governance than simply attaching an ADR document to a repository.
The decision becomes part of the implementation history.
From individual evidence to enterprise reporting
Once governance evidence is captured consistently, we can move upward from individual reviews.
An executive or enterprise architecture view can ask different questions:
How does governance posture vary between repositories?
Which teams or domains are accumulating more architecture risk?
Where are findings recurring?
Where are exceptions common?
Is compliance improving over time?
What has changed since the previous reporting period?
ArkSentinel includes an Executive Governance Summary together with comparative governance posture views so that governance evidence can be interpreted beyond one pull request.
The reporting capability also includes weekly or monthly compliance trend information and a view of What Changed Since Last Snapshot.
I particularly like the last idea because a snapshot tells us where we are.
A comparison tells us where we are moving.
Suppose a repository is at 82% compliance today.
By itself, that number has limited meaning.
If the previous snapshot was 95%, something has deteriorated.
If the previous snapshot was 61%, the same 82% may represent meaningful improvement.
That context matters.
Reports as another view over the same governance system
Reports are another view over the same governance system, not a separate universe. Risk, drift and technical debt, cross-repository intelligence, AI economics, ADR governance and AI Architect each answer different questions; Compliance & Evidence Reports package the connected history so it can be examined, communicated and retained.
Different audiences, different questions
The same evidence must serve different audiences. Developers care about what to fix; architects about standards, ADRs and resolution; governance administrators about approvals and evidence gaps; engineering leaders and executives about posture and trend; auditors about whether a decision can be reconstructed. That is why the reporting capability combines detailed evidence with executive and comparative views.
Getting the evidence out of the platform
Evidence also needs to be portable.
ArkSentinel supports report output in HTML and JSON, together with a printable report experience that can be saved as PDF.
The JSON representation is useful when governance evidence needs to participate in other technical workflows.
The formatted report is useful when the information needs to be reviewed or shared by people.
The important point is that the governance history is not trapped behind one dashboard screen.
“Show me.”
For me, the purpose of this capability can be summarized in two words:
Show me.
If an organization says it follows architecture standards:
Show me which standards.
If it says architecture decisions are enforced:
Show me the ADR and the implementation evidence.
If a repository had violations:
Show me the findings.
If the team corrected them:
Show me the subsequent review.
If an exception was allowed:
Show me why, who approved it and when it expires.
If a human made an accountable architecture decision:
Show me that decision.
If the organization says the repository is compliant:
Show me the evidence behind that conclusion.
That is the difference between architecture governance as an aspiration and architecture governance as an observable system.
From proving decisions to improving decisions
Compliance & Evidence Reports complete an important part of the ArkSentinel story.
We started with individual architecture standards.
We applied those standards during pull requests.
We introduced governed exceptions.
We connected decisions through ADRs.
We gave developers AI assistance to resolve findings.
Now we can preserve and package the evidence produced by that entire process.
But evidence has another use.
Once enough governance history exists, we can stop asking only:
“Can we prove what happened?”
We can start asking:
“What should we learn from what happened?”
Which governance signals actually predict architecture risk?
Which standards create the most recurring problems?
Which repositories are improving?
Where are exceptions telling us something about the policy itself?
Where should architects invest their limited attention?
That takes us from reporting into decision support.
And that is the subject of the next article:
Article 14 — From Governance Data to Architecture Decisions.