Reporting

How our findings are written

Three of our offerings end in a written report: the implementation review, the incident review, and any implementation engagement. All of them are written to one standard, and the standard is the same discipline the framework enforces on agents. A report is an evidence artifact. It has to survive examination by someone trying to break it.

Rule 1

What was examined, and what was not

Every report opens with its scope and its blind spots. Which repositories, which CI/CD checks, which pull request history, which agent logs we read, and which we did not. A review that does not state its limits is a claim, not a review.

Rule 2

Findings, not blessings

A finding says what is there, what is worth examining, and what we would change. It never says a system is compliant, safe, or adequate. Final validation stays with the team that owns production. We do not certify code; we help you build the structure that lets your team validate it.

Rule 3

Every figure carries its computation method and source

If a number cannot be recomputed from what the report cites, it is not in the report. Drift figures, merge rates, check pass rates, time to review: each one names where it came from and how it was calculated.

Rule 4

The bar is fixed before the read

What we are checking for is written down before we open your repository. The person who sets the bar does not conduct the read. It is how a testing lab stays honest, and it is why our findings do not drift toward what the client hoped to hear.

Contents

What a review report contains

Scope: what was examined, what was not, and why
The bar: what we were checking for, as written before the read
Findings: what is present, what is thin, what would change
Traceability: for each finding, the file, the check, or the log entry that supports it
Limits: what this review cannot tell you
Recommended changes, in the order we would make them

What we read

Ground truth, not the summary

An agent's description of what it did is not evidence that it did it. So a review does not start from the pull request description or the agent's run summary. It starts from the pipeline itself:

The repository and its history: what actually changed, and when
CI/CD signals: which checks ran, which passed, which were skipped or weakened
Pull request and merge records: who approved what, and whether anyone read it
Agent logs and session records: which agent acted, under whose authorization
Tests: what they assert, and whether they still assert it

Sector Challenges

Where This Applies

The sectors where this discipline is most often needed, and what we examine in each. These describe the problems we see, not claimed results. Every engagement is scoped and evidenced on its own terms.

Healthcare

Challenge: PHI risk, vendor sprawl, unclear AI triage rules.
What we examine: where protected data enters and leaves each AI pipeline, which vendors touch it, and where a clinician must remain in the loop.

Financial Services

Challenge: Machine learning model approval bottlenecks; audit gaps.
What we examine: how machine learning models are approved, evaluated, and retired, and whether the record of each decision would survive an audit.

Manufacturing

Challenge: Quality drift in predictive maintenance.
What we examine: data lineage from sensor to machine learning model, how drift is detected, and who acts when a prediction stops matching the floor.

Public Sector

Challenge: Residency and procurement risk.
What we examine: where data is allowed to live, which architecture options keep it there, and what controls a vendor contract must carry.

Real Estate / MLS

Challenge: Fragmented MLS schemas; privacy constraints.
What we examine: schema reconciliation, which fields carry personal data, and how analytics can run without exposing them.

Media & Entertainment

Challenge: IP leakage and shadow IT.
What we examine: where creative assets meet generative tools, which tools staff actually use, and what controls hold without slowing the work.

Which report fits

Three ways to get one

Implementation review

You built the framework from the workshop and template pack. We read what you built and say where it is thin. Written findings, follow-up call.

See the offering

Incident review

An agent pushed something bad, or claimed work it did not do. We reconstruct what happened from the repository, the CI/CD record, and the agent logs, and write down what the record supports and what it does not.