Four systems of record that had never been joined — and the risk they were hiding.

The situation

Application resilience was governed the way it is in most large enterprises: an annual assessment cycle in which application owners answered a long questionnaire about recovery objectives, disaster-recovery arrangements, backup posture and architectural separation. The answers were logged, findings raised, and the record aged for twelve months.

Nothing in the process compared those answers to reality. The organisation held an enormous amount of information capable of doing so — a configuration management database, an enterprise data warehouse containing host, storage, certificate and software-currency data, a resilience platform holding vendor records and business impact analyses, and a repository of solution architecture documents. None of it was joined, and none of it reached the assessment.

What we built

The first and largest piece of work was integration, and it was harder than it should have been. The service management platform’s REST API was unavailable under the organisation’s single sign-on posture, so we drove it through authenticated browser automation with saved session state — the same interface staff used, automated carefully and within policy. The resilience platform required riding its internal remote-procedure interface for the same reason. The warehouse connections were straightforward by comparison, though the tables were large, shared with production reporting, and load-dependent enough that query patterns had to be designed around them.

With the sources reachable, the reconciliation problem surfaced. Hardware inventory and cloud discovery each held partial, overlapping views of the same estate, using different naming conventions and different notions of what constituted a host. We built a unified host model that deduplicates across sources, badges each record with which systems saw it, and — importantly — flags rather than silently resolves the conflicts. Where two sources disagreed about an environment designation or a cluster membership, that disagreement was preserved as a finding rather than settled by whichever load ran last.

On top of that substrate we built the analysis. Each source is normalised into a labelled, provenance-tagged, budget-capped text block: what the infrastructure reports, what the organisation has declared, what the design documents describe, and what vendors have proven. A language model evaluates each applicable control against all layers at once and returns, per control, a verdict, the basis for that verdict, its reasoning and citations pointing at the specific facts it relied on.

The model does not calculate anything. Impact is derived in code from control criticality, exposure from the verdict and the confidence of its basis, and risk is the product of the two. Portfolio rollups, top risk drivers and coverage statistics are all ordinary arithmetic over those values, so the same evidence always produces the same number and any figure on screen can be traced to its inputs.

What it found

The first honest measurement was coverage, and it was uncomfortable. For a representative application, over half of the applicable controls had no evidence in either direction — neither proven nor disproven, simply unexamined. Under the previous process those controls had been recorded as satisfied.

It also found real, previously invisible violations. Cross-referencing software currency data against resilience claims surfaced applications running on operating systems and database hardware that had passed end-of-support years earlier, underneath records that described them as compliant. That finding had been sitting in the warehouse the entire time; nothing had ever asked the two systems the same question.

The vendor evidence result

The most instructive outcome came from adding a fourth evidence layer. The resilience platform held vendor records — audit reports, certifications, disaster-recovery test results — as attached documents that no analytical process had ever opened. We built extraction over them, prioritising documents whose titles suggested recovery testing, and fed the resulting text into the analysis as citable vendor evidence.

For one application, controls resting on attestation alone dropped from three to zero, evidenced controls rose from two to four, and measured risk fell by roughly a fifth — from 0.42 to 0.33. Several very-high-criticality disaster recovery controls moved from "declared" to "proven", each now citing a specific quarterly test report by name.

Nothing about the environment changed. The application was exactly as resilient the day before. What changed was what could be proven about it — and the organisation had held that proof, unread, the whole time. This is the single clearest argument for the approach: a great deal of enterprise risk is not real risk, it is unexamined evidence.

Beyond the analysis

The same substrate went on to support a portfolio heat map, a weekly executive report with week-over-week movement, per-assignee engagement tracking, and an agentic report builder in which a user describes the report they want in conversation, the system inspects real data through a constrained query interface, and a deterministic renderer produces the document. The model never writes executable code; it emits a structured specification that a fixed block library renders.

That reuse is the commercial argument for building the integration layer properly. The first question paid for the substrate. Every question after it has been comparatively cheap.