No. 04 · Technical

Git Insights Ministry

From knowing the estate to rebuilding it: synthesizing thousands of findings into one modular, government-owned architecture.

Git Insights offered the first step, by analyzing each repository and each application and giving us actionable intelligence. Not all of the insights were welcome or easy to review. The estate needed remediation, and with those findings in hand we have and continue to fix the most critical issues. But knowing is only the first part. We cannot always right the ship of government one plank at a time. Sometimes we need a whole new vessel.


## §01 From knowing to rebuilding

Where Git Insights reads one repository at a time and reports its health, its sibling process Git Insights Ministry (GIM) reads an entire ministry of application code at once and synthesizes the findings into a plan. It looks for the patterns that only appear across a whole portfolio such as the same login component built forty times or the same report written in a dozen ways. From those patterns it proposes a modular, reusable, government-owned compute architecture to replace the sprawl.

Repositories read together, per ministry ~200. Some ministries are enabled by hundreds of applications and repositories. Git Insights Ministry pulls them all down and analyzes them as one body of work, which is what makes the patterns visible.


## §02 A deeper read

The analysis goes far deeper than a health score. GIM clones every repository and reverse-engineers each capability. Every screen, workflow, API integration and endpoint, database schema and table, business rule, and dependency is read and recorded. From that raw material, this tool builds a dossier for each system, detailed enough to rebuild these functions anew.


## §03 How Git Insights Ministry works

GIM runs in stages. Some are deterministic, analysis steps done by ordinary code that counts, clones, calculates, and cannot invent a result. Such scripts are fast and powerful but prone to false positives. The next steps are agentic, where AI is asked to apply judgment. The formats of its answers are strictly controlled and always tied back to evidence in the code. Every conclusion can be traced to the file it came from.

The consolidation plan is created in two steps. First the tool groups the findings from every repository into the real things the ministry does for people. Then it designs the modules that deliver them, keeping separate work in separate modules and pulling anything common into the shared platform, so it is built once rather than forty times.

We do not ask anyone to take this on trust. Every capability the tool names points back to the systems and the workflows it came from, so we can always trace a conclusion to real code. Costing for the replacement systems are based on real heuristics, such as the number of screens, endpoints, database tables, and workflows. Ordinary code works it out from a fixed set of rates, so we can defend it line by line. The models themselves run on Claude through Google Vertex, working in parallel, one repository or one module at a time.


## §04 The synthesis vision: a government rebuilt

From the raw reconstruction of every system, it clusters every functional piece into the set of business capabilities the ministry genuinely performs, then designs a target architecture that delivers those capabilities as clean modules, with zero redundancy and zero overlap. Hundreds of applications, each carrying its own login, its own file upload, its own reporting, collapse into a handful of modules where each capability is built once.

One ministry, after synthesis 185 → 16. In one instance, 185 applications collapsed into 16 distinct modules. The redundancy the tool measured across the portfolio is the redundancy it designs out of the rebuild.

Every new module is built on one modern stack. That matters. It means we are no longer locked into a vendor we cannot leave. Our attack surface is minimized. Each module is based on open-source technologies and expanded to meet our specific policies. The staff and agents which build these systems retain the knowledge to maintain them. 


## §05 Patterns of reuse across government

The most valuable patterns are the ones that repeat. Across ministries, the same capabilities appear again and again. Several of the modules from a single ministry, in this case payments, geospatial mapping, and contract management, are not unique at all. Rather than rebuild them inside every ministry, we are building them once, as shared services that any ministry can use.

By fully mapping the functions of government, we can build modules which can be reused across all Ministries. Alberta owns each module, and we collapse the complexity and attack surface of our infrastructure by more than ninety percent. Created by AI, following a clear standard, these modules are easy to maintain.

This is also where the economics come from. Because the modules are designed and built by AI under human direction, the work compresses purposefully. The entire software development lifecycle compresses. Building and testing automate heavily; the judgment calls on security, privacy, and what the public actually needs stay with people.


## §06 What the executive sees

GIM creates outputs a decision-maker can act on, not a pile of raw analysis. The dashboard presents the whole ministry as a single, evidence-backed picture, and the same source produces a plain-language executive report.

Git Insights Ministry is the bridge from knowing the estate to rebuilding it. It turns the ground truth of Git Insights into a defensible plan: a smaller, modular, government-owned architecture, with the common parts built once for everyone. The strategies for carrying out that rebuild, from patching in place to full reconstruction, are the subject of the next paper: **The Four Approaches to AI Modernization **.

Tags: git-insights, modernization, architecture, shared-services, agents

Open the interactive version