GovStack 2.0.0 Core Specifications are live. Here’s the rollout and alignment plan.

Mar 10, 2026

Overview

GovStack 2.0.0 core specifications have been officially published at https://specs.govstack.global/architecture – which is a major milestone on the roadmap of GovStack. This work aligns with the GovSpecs 2.0 strategy, earlier published at https://govstack.global/news/govspecs-2-0-strategy-2025-2027-a-blueprint-for-future-ready-digital-public-services/ .

The update establishes a new structural foundation for our digital government architecture specifications. The 2.0.0 specification moves GovStack closer to an object-oriented specification model. Every Building Block now behaves like a class that inherits common technical rules – directly from the cross-functional requirements (CFR) layer. This means any system meeting a Building Block specification automatically meets our core architectural baseline.

It also serves the core value promised by GovStack: supporting digital government ecosystem interoperability – different blocks are able to understand each other better and collaborate as a result of these principles.

We are also enforcing a new strict compliance standard: solutions must satisfy 100% of “required” rules to achieve GovStack compliance and earn a GovMarket listing.

Broader Ecosystem Applications and Use of Specifications

The 2.0.0 specifications are primarily designed for the benefit of GovStack and GovStack country implementation and digital transformation projects and GovStack specification developers, however the valuable use of these specifications is wider. Here is how and where the new specifications can also be used:

Governments: National agencies use these specifications as an architectural baseline for procurement and national interoperability frameworks.
Donors: International development organizations mandate these specifications in funding conditions to set quality baselines.
Private Sector: Vendors use these open standards to build new software or update existing products or make them interoperable.
Software Repositories (inc. GovStacks’ own GovMarket): The specifications serve as the strict entry requirement for listing solutions.
Software Architects: Technical teams use the cross-functional requirements as an operational quality checklist and maturity assessment for system design.
Applied AI Projects: Development teams use the structured context, unique identifiers and requirements as contracts to provide strict guardrails for AI-assisted code generation and automated compliance verification.
Academia (inc. Govstacks’ own GovLearn): Universities and researchers use the versioned specifications as teaching material for software architecture and e-governance programs.

Actions for Specification Working Groups

To achieve cross-functional interoperability, all active working groups must align their feature and foundational specifications with the 2.0.0 core framework (govstack-cfr-2.0.0). Working group members and leads should familiarise themselves with the new core specification at https://specs.govstack.global/architecture.

Separate webinars will be held to introduce some of the more complex concepts, but these webinars will be primarily Q&A oriented. Separate meetings can be organized to support individual working groups, if required.

Specification Compliance Action Checklist

Validate compliance with https://specs.govstack.global/architecture/5-specification-framework – more notably the
following:

Standardise Identifiers: Update all specification naming conventions to the govstack-bb-[name] format and all requirements to the govstack-bb-[name]-fr and govstack-bb-[name]-cfr formats.
Validate Compliance: Detect conflicts with the govstack-cfr-* requirements, especially with the REQUIRED requirements. In case of issues, list them down and send feedback to your closest contact in the GovSpecs team (Ali González, Kristo Vaher, David Higgins).
Validate Scope of Requirements: Make sure that the specification is primarily Technical and Vendor Neutral. Legal and organisational aspects of digital services should be guides, not Building Block specification requirements.
Implement Semantic Versioning: Transition specification to a three-part major.minor.patch versioning system, where major increments signal breaking changes.
Implement new format of specification naming, identifying and classifications.
- Reclassify all existing requirements using the exact 2.0.0 keywords: REQUIRED, RECOMMENDED, DRAFT, DEPRECATED, or INAPPLICABLE.
- Assign mutability tags (IMMUTABLE, EXTENSIBLE, REPLACEABLE) to every requirement to establish clear rules for how local implementations can overlay or tighten constraints.
- Each requirement must now carry a verification classifier – either OBSERVABLE or AUDITABLE – defining exactly how compliance will be confirmed. Use OBSERVABLE for rules verifiable through external interaction (API calls, behavioral tests) and AUDITABLE for rules requiring inspection of architecture docs, source code or configuration.
Remove CFR Duplication: Ensure your specifications do not duplicate or conflict with requirements already defined in govstack-cfr. If still needed then consider extending or
replacing, if possible.
- Map Extensions Properly: cross-functional requirements, use explicit extension syntax (e.g., govstack-bb-wallet-cfr#req-1 extends govstack-cfr-data#req-3) to maintain machine-readable traceability.
Validate for AI-Readiness: Verify that your API contracts are machine-readable and
that event schemas use consistent life-event vocabularies.

Expected Timelines

Online Seminars – core specification update focused seminars and Q&A sessions will take place in March 2026.

Foundational Building Block compliance – critical foundational specifications (Digital Identity, Information Mediator, Workflow) are expected to be compliant by end of June 2026.

Feature Building Block compliance – other Building Blocks are expected to be compliant by
the end of 2026.

If achieving any of these goals is complex and there are issues with resourcing to have capacity to do the expected changes, please contact GovSpecs team (Ali González, Kristo Vaher, David Higgins). Separate projects may be organized to support the efforts.

Kristo Vaher
Chief Technology Officer