No. 22 · Policy & People

Taking the Hill: Innovating on Procurement with AI Insights

Alberta will be the first government to release the entire digital capability map of government, built from the code, so industry can finally see the real shape of our estate and bid on opportunities with fidelity.

A critical step to fixing the technical estate of government is first addressing the broken procurement processes which inhibit sourcing the technologies and finding the partners we need to be successful. The best AI tools won't help if we can't buy them. Technology and Innovation staff and leadership often hear from many would-be vendors that the pathway to selling to government is just so difficult, so slow, and so confusing that it is often simply not worth the investment to even submit a bid. Small-to-medium-sized Canadian vendors specifically identify that they struggle to qualify in the face of steep requirements, especially for new and innovative products, and must take their products to foreign markets to win the first or even their tenth customer. Some of Canada's most successful companies do not even bother bidding on Canadian government procurements. From the outside, it appears that government procures the same standard set of products time and again.

As we dive into this paper, I wish to start with an introductory note. In any review of current process, a reasonable amount of critical self-reflection is helpful and valuable. However, such an analysis inherently runs the risk of sounding like a criticism of the people who have worked within this system for years or even decades. I will say clearly up front that I am deeply impressed by the professionalism and skill of our procurement team, our business partners, and the broader government supporting our procurement processes. Any failing in the system is my own. As Deputy Minister, I am fully accountable for any shortcomings in the organization, and work tirelessly to support our teams, to invest in our staff, and to build stronger processes. Growth requires self-reflection and being willing to recognize when there are new opportunities, and to have the courage to explore and try something new. I hope that the following proposals are seen as they are intended: as exciting new opportunities building upon all the decades of hard work of our team. Let's begin.


## §01 Key procurement challenges

There are several common complaints with respect to government procurement. The first critique centres around how requests for proposals and statements of work are scoped, which can often be seen as narrow, restrictive, or selective and which may result in the incumbent winning renewals. Practically, there is a lot of junk out there. Many businesses sell products that look good on paper but will fail to scale to the demands and complexity of government, and it is reasonable and legitimate to set a high bar to protect taxpayer dollars. Clear, tightly-scoped requirements in principle provide a high-pass filter to ensure that the buyer is not inundated with inferior quality content. 

Poor products are often paired with low-quality bid packages. It is easy for a vendor to bundle together every document, white paper, and brochure they've ever created and submit this corpus as evidence of meeting the procurement needs. This causes a significant burden on staff who work very hard to make things fair. When we receive a bid, we carry a legal obligation to review every single page of the package. Often the bids we receive run hundreds to thousands of pages long, have little to do with the actual requirement, but still require a full and detailed review. Large bid packages can extend the timelines for a procurement by months. As a defensive mechanism, procurements are written narrowly so as to typically keep the field to fewer than ten anticipated bidders. A procurement with hundreds of respondents is often seen as being too general, while those with one or two are seen as too restrictive. The format of the bid should never drive the outcome, but for practical reasons it can.


Further, vendors are frequently disqualified because they fail to meet one of the mandatory criteria. For bidders, it can be difficult to determine in advance whether their bid is fully compliant. A missing piece of evidence, or even a single omitted page or paragraph, can result in months of effort wasted, with bidders disqualified on a technicality and often left unaware as to why they never land the deal.  

"Procurement is the hill to die on in the battle to win the modernization of government." · Paper 22 · Taking the Hill

While every procurement must carry fair and transparent requirements, the reality is that narrow specification operates as a defensive mechanism. The result is a system which due to its complexity benefits a small number of companies who are highly proficient at writing the response in exactly the way the document wants to be read. That proficiency comes from experience, and the complex process may screen out as many as ninety-nine percent of all other businesses from doing business with government. 

OF BUSINESSES SCREENED OUT BEFORE A FAIR CONTEST BEGINS up to 99%. Narrow specification and high requirements act as a defensive filter against low-quality bids, and in doing so they quietly exclude the overwhelming majority of firms, including the innovators we most want to reach.


## §02 The evidence gap and technical debt

Procurement documents themselves significantly compress the reality of the challenge to fit within the format. 

Governments often struggle to clearly articulate the complexity of their operating environments. What stays hidden from most vendors is how large an impact technical debt and legacy code have on our decision-making. 


How business leads describe their objectives, and how those descriptions make their way into procurement 'speak', ties back to the compression problem paper documented earlier. The technical state or requirements of an application is often so complex that it prevents leaders at any level from describing their objectives sufficiently. Many of our systems carry little documentation internally and almost none externally. The incumbent holds an outsized advantage because they can bid with slim contingency margins: they already know the shape and the look of the code, even though that shape is written down nowhere. Many of the innovations we want depend on two to five legacy systems that need integration, and those systems are undocumented as well.

The typical government bid document falls short in sharing both depth and insight around technical debt and integration requirements, which leaves vendors unable to bid effectively. There are no mechanisms for vendors to test their bid in advance to ensure it is compliant. And the procurement requirements lack sufficient depth to enable an evidence-driven bid. This is a failing of the bid documents themselves, both the requirements out and the proposals which return. Much of the content which comes in via the proposal is an attestation from vendors rather than proof. Government provides insufficient source material, such as code, for a vendor to really demonstrate a sound and integrated product. Governments put out abstract requirements, vendors respond with abstract proposals. The ground truth is highly compacted.


Not all procurements describe real products which will work within the environment. Procurements can go out that describe things that cannot be achieved, written from the standpoint of an optimistic, all-encompassing wish list, or from a business owner who already holds a fixed, detailed image of what they want. They are describing a product they already know to exist. The buyer's preference is fair, but what is described is often a solution and not an outcome. Frequently, it precludes the opportunity for the vendor to introduce novel ways to solve the problem. The winner is the product the buyer already wanted but may result in the best outcome being missed. 


## §03 The compression problem and IT's role

In our efforts to support our business partners, IT struggles with this compression as well. Within Technology and Innovation, we also fall short of giving our ministries sufficient evidence to support our advice, because we often share tacit knowledge that has gone unvalidated. Within any large organization, there is a great deal of 'tribal knowledge' in circulation, a great many opinions on status and health, and a great many recommendations that are ungrounded or unanchored in reality. A game of 'broken telephone' runs between the technical front line, the management in IT, and to the business owners. Management often believes it is giving correct advice, and it has also suffered from the compression problem, so the recommendations that reach the business are frequently ones you could never audit back to a fact. Many government decisions are based on the high level detail and not the messier and more complex ground truth.

This includes the advice we give with respect to our costing and estimation. If we cannot see the ground truth of our technical domain, we necessarily struggle to estimate time, cost, and risk, and we lean on heuristics that are imprecise, inaccurate, or incomplete. That drives the business toward a vendor product, or away from one and toward a build, when either choice may have been inappropriate. The business is then left returning directly to the private sector, which is often able to sell a better vision than the public service can, because the public service lacks the engineering savvy, or at least the marketing team, to present it attractively and the evidence to demonstrate why one method is better than another. Often, the pitch ignores the messy realities of government and presents a highly compressed, polished vision. We must do more to present all parties, our business partner and our vendors, with the most comprehensive, evidence-based picture possible from the first meeting, and to drive toward a buy, build, or genuine alternative decision grounded in reality.


Decision material is frequently compressed down to a four-page memo or a ten-slide deck. An application with thousands of screens and workflows can never be represented faithfully that way.





## §04 The legacy complexity trap

It is almost never the case that we buy or build in a greenfield. Government has been around for more than a century across Canada, and Alberta is a hundred and twenty-one years old this year. We have layered on systems and processes that extend back before Confederation. The forms from that era are gone, but the processes remain. This drives an enormous amount of complexity which is not visible from outside of government.

A government operates on legislation, regulation, and policy set by elected officials. This is known and auditable, if dynamic and grounded in human language. However, greater invisible complexity emerges through implementation. The public service introduces numerous layers of additional complexity that map out the business processes, and those processes are codified into internal software code and process documentation. Once an application is written, often the only place those rules are maintained is the code itself. If you wanted to understand a mainframe system responsible for a social benefit program, you would need to extract out many of the real rules which sit codified inside the application which were accrued one release at a time over 40 or more years. Additional process information is contained in spreadsheets, training materials, and forms. No one artifact holds the business rules in their entirety. 


Government's own human knowledge often lags behind where the private sector is currently innovating. When we define a procurement, we tend to define the product retrospectively, describing what we already know, not where technology or innovation are heading. Matching the complexity of government with the dynamism of the private sector can be itself a challenging prospect.

THE COMPLEXITY LIES HIDDEN 10×. Regulations run to tens of pages. Code runs to millions of lines, because layers of low-level decisions made by frontline staff, business owners, and IT people become the shadow policy of what actually happens. Vendors routinely discover roughly ten times more specificity buried in the code than any procurement document described, driving cost and time overruns.

When you put out an RFP, what you describe is an approximation of the final product rather than the actual product itself. In nearly no scenario do we share the code, or a clear enough description, of the current state product to correctly inform the bidder. Procurement requirements are vague and over-compressed, and vendors have to guess to win the contract, and to implement change order language which accrues to their benefit. When the winning vendor gets in the door, they may find something like ten times more specificity buried in the code. In the pre-AI era, recovering this detail was an archaeological extraction. It would typically take consultants months or years to detangle and vet these rules with knowledgeable business owners. Policy is why we do things, but how we do it must be unearthed from the millions of lines of code itself.

But what if we gave the vendors insight into our technical estate? What if we could show them that level of granularity from the outset and to really explain what government does at a technical level?


## §05 Git Insights as the ground truth for procurement

Our proposed solution to addressing several of these problems builds directly on the processes introduced in the paper on Git Insights, the agentic tool that read the whole of Alberta's code estate and reported the ground truth of every repository. Since its creation, we constantly work to evolve that tool to drive ever greater insights and to assist in the kind of planning needed to fix these procurement problems. The latest version now extracts a large body of metadata from every repository across the estate, and that metadata becomes the backbone for the procurement solution this paper proposes. We are moving from understanding the shape of our code to using that understanding to change how we engage with industry. Detailed snapshots can be shared, along with the entire canvas of business capabilities representing hundreds of overlapping systems, as set out in Git Insights Ministry.

The extraction from Git Insights captures an accurate snapshot of the real complexity of government systems, mapping code into a robust set of distinct business capabilities, and extracting out the technical information into a robust catalogue. Code is reviewed by AI agents which identify screens, workflows, and key logic which would inform the rebuilding or replacement of each system or capability. Every observation is reconciled into a single canonical, whole-of-government map, deduplicated by name and function. The capabilities are augmented with health and risk scores, test coverage percentages, and rebuild estimates which can be refreshed frequently. Across thousands of repos and hundreds of millions of lines of code, we generate these insights using both script and AI model, so identical inputs produce a repeatable result which can be audited back to source.

By extracting this detailed metadata into a multi-dimensional matrix of insights, we are doing something which we believe has never been done before. We are giving industry and potential vendors a high-fidelity snapshot view into the shape of government systems and the challenges we face. This view lets vendors bid with unprecedented insight and confidence, and it opens the door to modernizing the entire procurement process through AI-assisted, fair, and transparent evaluation. Code remains the ground truth. The metadata is the faithful projection of how government really operates and where there is the most opportunity for innovation.


## §06 The open metadata release

This dataset will describe, with great fidelity, the work government does, while stopping short of releasing the entire code base itself. Our code, like all code, carries documented vulnerabilities as noted in the cybersecurity paper, so we cannot simply publish the code and let people bid on it openly, because that would hand attackers the insights they need to disrupt our systems and operations. Instead, what we can do is give industry something far more granular, and arguably far more useful, than we have historically shared while preserving confidentiality and security. This white paper introduces the first government release of a broad set of metadata that maps every repository, now more than four thousand of them, into a comprehensive business capability map. It describes the function of each repository, its health, its tech stack, and a large body of additional metadata, without ever naming the application.

The result is a complete view which abstracts hundreds of gigabytes of repositories, hundreds of millions of lines of code, into a clear stand-alone dataset. This dataset allows you to explore business capabilities, repos, and tech stacks, the core technologies that run these applications. Picture a three-dimensional view, released as an open dataset, that lets industry understand the full shape of government systems and the tens of thousands of screens and workflows they carry. This release removes the information asymmetry that has long favored incumbents, and it protects sensitive code and vulnerabilities at the same time. Each release of this data is a point-in-time snapshot, with future releases expected as our methods mature.

The estate, mapped and released 4,000+ applications. Every application mapped to its business capabilities, health, and technology, then de-identified and certified shareable. Across the estate this resolves to 2,182 capabilities organized into 40 domain clusters.

Taken together, these figures paint a fuller picture of what the scan found. The 4,041 applications resolve into 2,182 business capabilities across 40 product domains. Behind them sit more than seventy thousand screens and a similar number of workflows, hundreds of thousands of business rules and API endpoints, and nearly twenty-four thousand software dependencies. This first snapshot does not yet cover the whole of government. Several major commercial platforms, such as our SAP-based 1GX system, are absent from this release, and further work is underway to bring the full set of capabilities we intend to modernize into the map. Future releases will keep widening this landscape until it captures all of the digital activity across the Government of Alberta.

The capability map is the way in for vendors to bid on modernizing whole segments of government. The dataset organizes what government does into forty domain clusters, from Transportation and Roads through Financial Management to Justice and Courts, and within each cluster it lists the capabilities and the applications that deliver them. Repositories crosswalk to capabilities, and with this dataset it is the first time the functions of government have been drawn from the code up to the function, at this depth, and made open.

The release also carries a recommended disposition for every application, drawn from its health, its activity, and its complexity. The four dispositions map onto the four approaches to modernization set out in an earlier paper: maintain and monitor what is healthy, remediate in the AI Garage what is worth keeping and improving, retire and consolidate what is redundant, and rebuild in the AI Factory what needs to be replaced. Reading these across the estate lets procurement prioritize the domains where health runs low or a legacy tech stack demands rationalization, and it lets industry see, from the outset, which capabilities are open to consolidation and which are candidates for a clean rebuild.


## §07 How industry can bid with unprecedented fidelity

With this dataset in hand, industry can finally see the real shape of government systems and the tens of thousands of screens and workflows that sit behind them. Vendors can respond by supporting the modernization of an entire business capability, or several capabilities at once. They can calculate realistic costs by understanding exactly how many integrations will be needed, which tech stacks must be migrated, and how many screens and workflows must be ported. A serious bidder can use AI to analyze the data and generate a grounded proposal, in place of guessing at undocumented legacy systems and padding the price with contingency.

Screens and workflows now visible to bidders 75,582 / 73,516. The count of screens and workflows across the estate, enumerated for the first time. A vendor proposing to replace a capability can now see how much work actually sits behind it, rather than estimating blind.

This invites the whole vendor community to reset the procurement relationship with us. COTS and SaaS vendors can map their products directly against the capability matrix. Service providers and AI-native firms can propose agent orchestration that delivers fully government-owned capabilities. A vendor could look at the map, understand the domain space of what government does with its code, and propose to replace tens or even hundreds of repositories with an enterprise platform, with the integration count, the migration path, and the screen and workflow counts all grounded in the data. The barrier to entry collapses, because the information advantage that once belonged to the incumbent now belongs to anyone willing to read the map.


## §08 Structured bids, crosswalks, and the shared matrix

Alongside the dataset, we are releasing a CLAUDE.md file that gives every bidder the exact recipe for a compliant response. It tells them how to read the JSON, how to map their solution into the capability matrix, and what structured artifacts they must return. Each bid must include a machine-readable crosswalk file that links every page or section of the narrative back to the specific capability nodes, health scores, or repository metadata it claims to address. An AI reviewer can then shred the entire package and extract the structured fields for cost, capability coverage, evidence citations, local support capacity, and risk.

This shared multi-dimensional matrix lets the government procurement team instantly visualize who has bid where, where costs are concentrated, and what bid types are on offer, whether COTS, SaaS, open source, custom-built, or agentic. Alberta is completely transparent about what we are requesting, and industry can be completely transparent about what it is offering. If a vendor proposes a solution with ten screens to replace one that has a thousand, that mismatch becomes immediately visible, in place of being hidden inside glossy brochures or compressed abstracts. We are no longer daunted by the number of bids, because every proposal arrives structured, auditable, and comparable in the same framework. Procurement can see coverage across the whole estate, spot the gaps, and prioritize the domains where application health runs low or a tech stack like COBOL or unsupported Java demands rationalization.

"If a vendor proposes a solution with ten screens to replace one that has a thousand, that mismatch becomes immediately visible and worth a review." · Paper 22 · Taking the Hill


## §09 No slop, please

In making this process so transparent, so easy to understand, we also open up new challenges. In this era, anyone can point AI at the JSON data dump and generate a glossy, reasonable-looking proposal that carries little to no value against the real complexity of the work we are trying to do. We use AI ourselves, and we appreciate its power. We want the innovators and the disruptors to bid, and we expect every bid, and every product, to include AI. What we want to avoid is a flood of vibe-coded interfaces and unattached claims that simply sound good on paper, because that flood takes us straight back to the original problem: too many bids, and a legal obligation to read every page of each one. Because AI makes it easier to bid, we are raising our bar on the evidence needed to demonstrate that you hold the capability to meet our needs.

The onus will be on the vendors to prove that they have capacity to meet every single business capability they are addressing. This could be a working prototype slice, a harnessed agent workflow, or a reproducible build script that demonstrates real execution against the data. Industry must prove it has the capacity, and map every piece of evidence back to the business capability matrix, back to the tech stack, back to the APIs. 

The nature of what we are buying is also changing, and we are opening the door for builders to join us in pioneering the AI Factory and the next generation of AI-delivered products and solutions. In the AI era, we are less interested in another black-box COTS or SaaS product, because if a vendor can build it with agents, so can we. What we are looking for is partners who provide a roadmap for modernizing the length and breadth of our technology estate. And we are open to innovative ways to do this. Bidders can find and propose open-source code products, they can bring novel proprietary code where a component is genuinely one of a kind, and they can demonstrate how they will use agent orchestration, harnesses, skills, and standards to build to a Government of Alberta standard, described in the harness paper and the AI Factory papers. 

We will open-source this first dataset and the structured bid format at the Velocity Symposium on July 28th, 2026, our first industry day since the launch of the Velocity White Papers on July 6th. Industry will have two months to digest the information, ask questions, and build meaningful responses before demonstrating them at our Agency AI innovation series in October. These demonstrations are an opportunity for show-and-tell: a chance for industry to bring what it has built and show how it has tackled the problems the dataset reveals. Shortly after, the government will open the next tranches of procurement for these kinds of solutions, prioritized against what industry showcases.

Procurement we expect this model to enable $100–200M. The next one hundred to two hundred million dollars of procurement in this space is expected to follow this evidence and data-driven model, with a refined dataset released before that tranche opens. Industry has two months between the Symposium and Agency 2026 to build.


## §10 Procurement as the foundation for modernization

This approach is an important step on the Ministry's mission to make procurement easier, faster, and more transparent. Releasing the metadata and requiring structured, evidence-mapped bids lowers the barrier to entry while holding a high bar for proof. Industry gains a clear view of the real challenges and can propose novel solutions that fit our operating model, rather than pressing us to accept a pre-packaged product. AI-enabled bids and evaluations will make it easier for proponents to use AI to demonstrate how they meet government requirements and to de-risk their applications. AI also supports the evaluator, so procurement staff can analyze and compare hundreds of proposals which address a variety of challenges easily and rapidly.  Submitting a successful bid should take hours instead of weeks, with AI tools to support compliance and validation. Through this competitive, open process, Alberta gains new vendors, renewed goals with existing partners, and government-owned capabilities built through genuine partnership.

"Modernizing procurement is the necessary foundation for modernizing government itself." · Paper 22 · Taking the Hill

This is a new way of doing procurement, one that is fair, rapid, and rich enough in insight to let industry propose novel solutions and government move faster. By releasing this first-ever open-source dataset, we invite industry to work along the path laid down in these Velocity White Papers, and we offer a pathway to long-term partnership. We move away from the bid-by-bid, one-plank-at-a-time replacement model to addressing the challenges of government at scale and with speed. Through the Velocity Symposium and Agency 2026, we hope industry will join us to take on the most critical challenges we face.

Tags: procurement, open-data, git-insights, industry-partnership, modernization

Open the interactive version