Civic Ledger: GovTech Landscape Analysis

The Civic Ledger: A Comprehensive Landscape Analysis of Distributed Version Control, Reputation Economies, and Federated Operations in the Public Sector

1. Introduction: The Architectural Imperative for a Civic Ledger

The public sector currently operates on a bifurcated infrastructure. On one side, the "software" of government—its digital services, websites, and data pipelines—has increasingly adopted modern DevOps methodologies, utilizing version control systems like Git, continuous integration, and agile collaboration. On the other side, the "firmware" of government—the laws, civil engineering blueprints, standard operating procedures (SOPs), and procurement policies—remains trapped in a "waterfall" era of static documents, binary files, and siloed knowledge management. This report analyzes the viability of "The Civic Ledger," a proposed architectural paradigm that seeks to bridge this divide by applying the principles of distributed version control, InnerSource, and reputation economies to the operational machinery of the state.

The hypothesis of The Civic Ledger is that the mechanisms which allowed the open-source software movement to scale—specifically the ability to "fork" (copy and adapt), "merge" (integrate changes), and "blame" (audit history)—can be transposed onto non-software assets. If a city’s zoning code were a Git repository, neighboring municipalities could fork it, adapt it to their local context, and even submit "pull requests" to improve the upstream standard. If a bridge design were an object-based stream rather than a static PDF, engineers could collaborate concurrently without file-locking conflicts. If civil servants operated within a reputation economy similar to Stack Overflow, tacit institutional knowledge could be captured and valued before it is lost to the "Silver Tsunami" of retiring workforce.

This deep landscape analysis validates the Civic Ledger concept by investigating four specific research vectors: Git for "Physical" Public Works, the "No-Code" Interface for Civil Servants, the "Status Economy" in Government, and the "Federation" Model of Cross-Agency Collaboration. The findings indicate that while the holistic platform does not yet exist, the component technologies have been successfully deployed in isolation across high-maturity sectors of the government, ranging from the Intelligence Community’s classified knowledge markets to the District of Columbia’s version-controlled legal code.

2. Vector 1: Git for "Physical" Public Works

The application of Git-based version control to the built environment—civil engineering, architecture, and hardware design—represents the most technically complex vector of The Civic Ledger. The primary barrier has historically been the binary nature of Computer-Aided Design (CAD) files (e.g., .dwg, .rvt), which do not lend themselves to the line-by-line difference tracking ("diffing") that makes Git powerful for text-based code. However, a profound shift from file-centric management to object-centric data streams is currently dismantling this barrier, validated by major public infrastructure projects in the UK and US.

2.1 The Transition from Files to Object Streams in BIM

Traditional Product Data Management (PDM) in the public sector relies on a check-in/check-out workflow. A government engineer working on a water treatment plant must "lock" a massive binary file to prevent conflicting edits, effectively serializing work and creating bottlenecks. The Civic Ledger envisions a parallel workflow where multiple engineers work on different branches of the same physical asset simultaneously.

Speckle has emerged as the definitive open-source architectural validator for this concept. Rather than attempting to version control massive binary files, Speckle acts as an interoperability layer that decomposes Building Information Models (BIM) into granular "objects"—walls, beams, sensors—stored as JSON-like structures in a database. This allows for a Git-like workflow where specific elements of a building can be branched, modified, and merged without locking the entire model.

Case Study: High Speed 2 (HS2) Railway, UK The validation of this object-based approach is found in the High Speed 2 (HS2) project, one of the largest infrastructure initiatives in Europe. Engineering firms Arup and Mott MacDonald utilized Speckle to manage the complex data exchanges required for the project’s design. Specifically, the design of the "Interchange Station" required the seamless flow of information between architectural teams (defining the massing), structural teams (defining the primary portal frames), and façade teams (rationalizing the geometry). In a traditional workflow, these teams would be forced to exchange static IFC files or PDFs, resulting in version mismatch and data loss. By using an object-based data hub, the teams could stream geometry and metadata between different software environments (Rhino, Grasshopper, Revit) while maintaining a "single source of truth." This effectively functioned as a "Civic Ledger" for the station’s physical design, proving that complex public infrastructure can be managed as a distributed, version-controlled repository rather than a static archive.

Case Study: The National Digital Twin, UK Further validating the "Federation" aspect of the Civic Ledger, the UK’s National Digital Twin programme—supported by the Centre for Digital Built Britain—envisions an ecosystem of connected digital twins. This moves beyond the project level to the national level, where data from transport, energy, and water networks can be federated. Speckle’s role as an "open data layer" positions it as a foundational technology for this vision, allowing government entities to query and utilize data from across the built environment without needing to own the proprietary software used to create it.

2.2 Cloud-Native CAD and Compliance-Driven Versioning

While Speckle connects disparate desktop tools, Onshape Government represents a "clean slate" approach where the entire CAD platform is moved to the cloud, enabling inherent version control. Built on AWS GovCloud to meet US defense compliance standards (ITAR/EAR), Onshape provides a real-time, database-driven environment for mechanical design.

The critical innovation here for The Civic Ledger is the "Visual Diff." In software, a Git diff shows added/removed lines of text. In Onshape, the system creates a visual overlay of the 3D part, highlighting exactly what geometry was altered between versions.

Operational Impact: For government procurement officers and auditors, this is transformative. Instead of relying on a contractor’s summary of changes, a government engineer can view an immutable, cryptographic log of every geometric edit. This "audit trail" is a core requirement of The Civic Ledger, turning the design process into a transparent, accountable record.

Defense Sector Adoption: The deployment of Onshape Government signifies that the security concerns often cited as barriers to distributed version control are solvable. By centralizing the data in a FedRAMP-compliant cloud (rather than scattering files on local hard drives), the "Git" model actually enhances security posture compared to traditional methods.

2.3 Git for Hardware and Electronics

Modern public infrastructure is increasingly "smart," relying on custom Printed Circuit Boards (PCBs) and IoT controllers for traffic signaling, water metering, and environmental sensing. This hardware layer must also be versioned.

AllSpice.io: This platform serves as a "GitHub for Hardware," connecting native engineering design tools (like Altium or KiCAD) to a Git backend. It allows government hardware engineers to perform visual diffs on schematics, automating the review process for complex electronics. This is crucial for maintaining the long-term lifecycle of public infrastructure electronics, which often outlive the original design teams.

Bild: Similarly, Bild addresses the collaboration gap in hardware engineering, offering cloud-based data management that focuses on the version control pain points specific to physical product design.

2.4 The Legacy Data Challenge: NIST Repository

A significant hurdle for The Civic Ledger is the inertia of legacy data. The NIST Engineering Design Model Repository represents an early federal attempt to address this by hosting industry-relevant CAD models on GitHub. While primarily a static archive for research and validation, its existence on GitHub signals a recognition by federal standards bodies that Git is a viable transport mechanism for engineering artifacts. It serves as a precedent for the "Repository" aspect of the Civic Ledger, even if it lacks the active "Collaboration" layer of Speckle or Onshape.

3. Vector 2: The "No-Code" Git Interface for Government

The underlying engine of The Civic Ledger is Git, but its interface cannot be the command line. The average policy analyst, city clerk, or urban planner does not possess the technical literacy to execute git commit or git merge. To operationalize this system, a robust "No-Code" abstraction layer is required—a "GUI for Government" that wraps the power of version control in familiar user experiences.

3.1 Cloud.gov Pages: The Federal Web Publishing Standard

The most mature example of this abstraction is Cloud.gov Pages (formerly Federalist), developed by the GSA’s 18F team. This platform powers extensive portions of the federal web presence and serves as a direct architectural blueprint for The Civic Ledger.

Architecture: The system decouples content from code. Website content is stored as Markdown files within a GitHub repository, while the site generation logic (Jekyll/Hugo) is handled by the platform.

The Decap CMS Wrapper: To the end-user—a communications officer at the EPA or a policy writer at the GSA—the interface is Decap CMS (formerly Netlify CMS). This is a React-based single-page application that looks like a standard WYSIWYG editor (similar to WordPress). When the user clicks "Publish," the CMS translates that action into a Git commit, pushing the change to the underlying repository.

Significance: This successfully hides the complexity of the Git flow (branching, merging, pull requests) while retaining all its benefits: immutable history, easy rollback, and distributed collaboration. It proves that non-technical civil servants can actively participate in a Git-based ecosystem if the interface is properly scoped.

3.2 Open Law Library: "Law as Code"

While Cloud.gov Pages manages web content, the Open Law Library (OLL) applies these principles to the very source code of government: legislation. OLL represents the most sophisticated execution of the "Civic Ledger" vision currently in production.

The "Drafting" Interface: OLL recognizes that legislators live in Microsoft Word. Rather than forcing them to use a code editor, OLL provides a Word plugin called Open Law Draft. This plugin acts as the "No-Code" bridge, allowing drafters to work in their native environment while the system automatically structures the document into XML and manages the version control in the background.

Automated Codification: In traditional governance, passing a law and updating the official legal code are disjointed processes that can take months. OLL’s platform utilizes a Git-based backend to "auto-update the legal code" as soon as laws are effective. This is essentially Continuous Integration/Continuous Deployment (CI/CD) applied to the law.

Cryptographic Verification: The implementation of the Archive Framework (TAF) in Maryland’s Code of Maryland Regulations (COMAR) project adds a layer of cryptographic security. TAF ensures that the legal code served to the public is authentic and has not been tampered with, using hashing principles identical to those that secure a Git blockchain. This addresses the "Trust" requirement of the Civic Ledger.

3.3 Git-Backed Wikis and "Local-First" Knowledge

For internal knowledge management and Standard Operating Procedures (SOPs), a lighter-weight abstraction is emerging through Git-backed wikis and tools like Obsidian.

Waliki and Wiki.js: These platforms explicitly market themselves as Git-backed wikis. Waliki focuses on intelligent merge conflict resolution, a critical feature for collaborative documentation where two civil servants might edit the same SOP simultaneously.

Obsidian in Government: Anecdotal evidence suggests that government statisticians and administrators are adopting Obsidian for personal and team knowledge management. Obsidian operates on local Markdown files that can be synced via Git. This "Local-First" architecture offers resilience and ownership that cloud-only SaaS platforms cannot match, aligning with the data sovereignty needs of public agencies. It represents a "bottom-up" adoption of Civic Ledger principles, driven by user needs rather than top-down IT mandates.

4. Vector 3: The "Status Economy" in Civil Service

The "Civic Ledger" relies on InnerSource methodologies to drive collaboration. In the private sector, InnerSource is fueled by a "Status Economy"—developers contribute to open-source projects to gain "stars," reputation points, and peer recognition. Transplanting this economy into the civil service—defined by rigid pay scales, hierarchical chains of command, and risk aversion—presents the most significant cultural challenge.

4.1 The Cautionary Tale of A-Space

The most prominent experiment in government-internal reputation economies is the Intelligence Community’s A-Space (Analytic Space), launched in 2008.

The Vision: A-Space was designed as a "social network for spies," a common workspace for analysts across 16 different intelligence agencies. It utilized web 2.0 tools to allow analysts to share hypotheses, tag data, and build reputations based on the quality of their insights rather than their rank.

The Success: It was wildly popular among the workforce, named one of Time Magazine’s best inventions of 2008. It proved that the demand for cross-agency collaboration and peer recognition exists deeply within the civil service.

The Failure Mode: The project was ultimately strangled by the security bureaucracy. It was described by Michael Wertheimer, a senior intelligence official, as a "counter-intelligence nightmare". The fundamental mechanic of a reputation economy—openness and visibility—clashed with the fundamental mechanic of intelligence—compartmentalization (Need to Know). A single "bad apple" could theoretically scrape the aggregated insights of the entire community.

Insight: This failure dictates that The Civic Ledger’s reputation system must be scoped. A global leaderboard is a security risk; a "Water Treatment Engineering" leaderboard, visible only to cleared engineers, is a value-add.

4.2 Stack Overflow for Teams: Privatizing the Status Economy

Where A-Space faltered, Stack Overflow for Teams has found a foothold. The Department of Defense (DoD) and other agencies have adopted this platform to create secure, internal knowledge markets.

Mechanism: It utilizes the familiar mechanics of the public Stack Overflow—upvotes, accepted answers, badges—to incentivize knowledge sharing.

The "Brain Drain" Defense: The primary driver for adoption is the "Silver Tsunami." As senior civil servants retire, they take decades of tacit knowledge with them. Stack Overflow for Teams gamifies the extraction of this knowledge, effectively capturing it in a searchable, versioned ledger before the employee departs.

4.3 Gamification of Training and Competitions

Gamification has established a stable beachhead in government training (LMS) and innovation challenges.

Digital Badging: The US Air Force and NASA utilize the Open Badges standard to verify and display technical skills. These badges are not just "stickers"; they are portable, metadata-rich credentials that persist across an employee's career. This creates a "Ledger of Competence" that is independent of specific job titles.

Challenge.gov: This platform operationalizes gamification for public problem-solving. By hosting prize competitions, it creates a "Leaderboard" for innovation. The Civic Ledger could internalize this model, allowing agencies to post "Internal Challenges" (e.g., "Refactor this procurement workflow") and reward successful teams with reputation points or badges visible on their internal profiles.

LMS Integration: Platforms like Tovuti LMS and Centrical are used to gamify the learning of dry Standard Operating Procedures. Features like progress bars, leaderboards, and "missions" transform compliance training into a competitive activity, increasing engagement and retention.

4.4 The "Intellipedia" Stagnation

Intellipedia, the classified wiki of the intelligence community, offers another critical lesson. While initially successful, it suffered from stagnation because contribution was viewed as "extra work" rather than part of the workflow. Furthermore, analysts were risk-averse; putting one's name on a wiki edit that might later be proven wrong carried professional risk without clear professional reward.

Implication: For The Civic Ledger to succeed, contribution must be implicit in the work (e.g., the Git commit is the contribution), not an explicit, separate act of documentation. The reputation must be derived from the work itself, not from "wiki gardening."

5. Vector 4: The "Federation" Model

The ultimate ambition of The Civic Ledger is to move from "Shared Services" (centralized) to "Federated Commons" (decentralized). This implies a system where City A can "fork" a project from City B, adapt it to local needs, and potentially merge updates back upstream. This requires a robust architecture of standardization and governance.

5.1 The Foundation for Public Code

The Foundation for Public Code , based in the Netherlands, is the primary architect of this federation model. They maintain the Standard for Public Code, a set of criteria designed to ensure that software codebases are reusable, portable, and governable by public organizations.

Policy Bundling: Crucially, the Standard mandates that "policy and source code" be bundled together. You cannot fork the software without also forking the policy logic that governs it. This validates the Civic Ledger's holistic approach: the artifact is not just the code, but the governance of the code.

Stewardship: The Foundation acts as a "Steward" for these codebases (e.g., Signald, Openzaak), facilitating the community governance required to keep a federated project healthy.

5.2 The "Forking" of Law and Data

Open Law Library: OLL enables the federation of legal codes. Because the laws are stored as structured XML, a new municipality can technically "fork" the traffic ordinance of a model city, apply local parameter changes (e.g., speed limits), and deploy it. This transforms legislation from a creative writing exercise into a configuration management task.

Standardized Zoning: Projects like ZoneBuilder and the National Zoning Atlas are attempting to standardize zoning codes into machine-readable formats (GeoJSON) on GitHub. This standardization is the prerequisite for federation. You cannot "fork" a PDF, but you can fork a GeoJSON dataset. If City A’s zoning code is a standardized dataset, City B can fork it and adjust parameters (setbacks, FAR) while maintaining the same underlying data structure.

5.3 Federated Data Standards: SharedStreets & MDS

The transportation sector has pioneered data federation through SharedStreets and the Open Mobility Foundation (OMF).

Mobility Data Specification (MDS): Originally developed by the City of Los Angeles to manage e-scooters, MDS was released as an open-source standard on GitHub. It was subsequently "forked" and adopted by dozens of cities worldwide. This represents a successful "Policy Fork": the technical implementation of a regulation (API specifications for scooter data) was replicated across jurisdictions via Git.

SharedStreets: Provides the "Rosetta Stone" for street data, a stable ID system that allows different cities and companies to refer to the same physical street segments. This shared reference system is essential infrastructure; without it, a "pothole repair policy" cannot be federated because "Main Street" means something different in every town.

5.4 The X-Road Trust Model

For cross-agency data exchange, X-Road (developed by Estonia and adopted by Finland, Iceland, and others) is the gold standard. Unlike a centralized data lake, X-Road is a peer-to-peer exchange layer. It allows agencies to retain sovereignty over their data while exposing secure endpoints to other agencies. This "Federated Trust" model is critical for the Civic Ledger: it allows agencies to collaborate without surrendering control, solving the political friction of centralization.

6. Market Landscape Analysis

6.1 Direct Competitors

These entities are currently building the core components of the Civic Ledger and operating with its specific philosophy.

Open Law Library: Domain: Law/Policy. The market leader in "Git for Legislation." They have proven the model with DC and Maryland, automating the codification process and treating law as structured code.

Speckle: Domain: Physical/BIM. The only open-source, object-based data hub that explicitly enables "Git for Construction." Its adoption by Arup and HS2 validates the model for massive infrastructure.

Foundation for Public Code: Domain: Governance. The steward of the "Federation" model. They provide the necessary bureaucratic protocols to make "forking" a reality in the public sector.

6.2 Partial Matches

These platforms provide critical functionality but lack the holistic "Civic Ledger" vision or openness.

Onshape Government: Domain: CAD. Provides perfect version control for mechanical design but is proprietary and siloed to the defense/hardware niche.

Stack Overflow for Teams: Domain: Knowledge. Delivers the "Status Economy" and gamification but remains disconnected from the actual operational artifacts (blueprints/laws).

Cloud.gov Pages: Domain: Web. Solves the "No-Code" interface problem for web content but does not yet extend to complex operational logic or physical assets.

Accela / Tyler Technologies: The legacy incumbents. They hold the data (permits, licensing) but trap it in centralized, proprietary silos that are the antithesis of the "Fork/Merge" federation model.

6.3 Failed Attempts

A-Space: Reason for Failure: Security vs. Openness conflict. Lesson: The Civic Ledger must have robust, object-level access controls (like Speckle’s streams) to survive security reviews. A global reputation system is a vulnerability.

Diplopedia: Reason for Stagnation: Workflow Isolation. Lesson: Documentation must be a byproduct of work (e.g., a commit message), not an extra task that civil servants must remember to do.

Code.gov: Reason for Failure: Lack of Stewardship. Lesson: A registry of code is useless without a governance model to support reuse. "Forking" requires a community manager (Foundation for Public Code) to be successful.

6.4 The "Blue Ocean" Opportunity

The research identifies a massive, unaddressed gap: the Orchestration Layer.

Currently, a city's Law (Zoning Code) lives in one silo (e.g., Open Law Library or a PDF on a server). Its Design (CAD/GIS) lives in another (Speckle or a secure drive). Its Operations (SOPs) live in a third (SharePoint or a Wiki). There is no platform that links a "Pull Request" on a Zoning Ordinance to a "Branch" in the City Planning Model and an update to the "Permitting Workflow."

The Blue Ocean Strategy:

The "Omni-Repo": A system that federates the relationships between Policy, Physical Assets, and SOPs. If the City Council changes the setback requirement in the Zoning Code (OLL), the system should automatically flag the "Standard Street Section" blueprint (Speckle) as "Non-Compliant/Outdated."

Visual Git for Bureaucracy: Expanding the "No-Code" interface beyond websites (Cloud.gov Pages) to include visual diffs for Policy and Blueprints in a single dashboard.

The Forkable City Stack: A marketplace where a new municipality can "fork" a complete operational stack—Zoning Code + CAD Standards + Maintenance SOPs—as a single, bundled distribution, vetted by the Foundation for Public Code.

7. Conclusion

The "Civic Ledger" is not a futuristic fantasy; it is a compilation of existing, validated technologies currently operating in silos. Git has successfully bridged the gap to physical engineering (Speckle) and law (Open Law Library). InnerSource models are active within the highest security environments (DoD/Stack Overflow). Federation protocols (X-Road) prove that decentralized government collaboration is possible.

The barrier to realization is not technological; it is architectural and cultural. The "Counter-Intelligence Nightmare" of A-Space warns us that reputation economies must be carefully scoped. The success of OLL warns us that the interface must meet the user where they are (e.g., inside Microsoft Word).

Recommendation: The Civic Ledger should not attempt to rebuild the underlying version control systems (Git is sufficient). Instead, the opportunity lies in building the Orchestration Layer: the "No-Code" interface that allows a City Manager to "merge" a policy update from a neighboring city, automatically triggering a "diff" check against their local engineering standards. The value lies not in the storage of data, but in the reduction of friction between the legal, physical, and operational definitions of public infrastructure.

The path forward is a pilot program that links Open Law Library (Policy) and Speckle (Physical). A project that connects a version-controlled zoning ordinance directly to a version-controlled urban model would serve as the Minimum Viable Product (MVP) for the Civic Ledger, proving that the state can indeed be managed as a repository.

Data Synthesis & Citations

Speckle (Vector 1):

Onshape (Vector 1):

AllSpice/Bild (Vector 1):

Open Law Library (Vector 2/4):

Cloud.gov Pages (Vector 2):

A-Space (Vector 3):

Foundation for Public Code (Vector 4):

Digital Public Goods Alliance (Vector 4):

SharedStreets/MDS (Vector 4):

Works cited

1. Speckle: the open-source cloud data platform - AEC Magazine, https://aecmag.com/data-management/speckle-the-open-source-cloud-data-platform/ 2. HS2 Interchange Station – Innovative Roof Design: An exemplary project on Integrated Design Team collaboration and the use of advanced Digital Workflows, https://learninglegacy.hs2.org.uk/document/hs2-interchange-station-an-exemplar-project-on-integrated-design-team-collaboration-and-the-use-of-innovative-software-workflows/ 3. State of AI for Earth Observation - Cloudfront.net, https://d11avd6t8zdcx0.cloudfront.net/uploads/2022/09/State-of-AI-for-Earth-Observation.pdf 4. Digital Construction Ecosystem → Term - Fashion → Sustainability Directory, https://fashion.sustainability-directory.com/term/digital-construction-ecosystem/ 5. Cloud-Native CAD & PDM Solution for U.S. Federal ... - Onshape, https://www.onshape.com/en/blog/cloud-native-cad-pdm-solution-federal-government 6. AllSpice.io, hardware development platform, raises $15m Series A round to launch AI Agent and scale new enterprise functionality for electrical engineering teams - PR Newswire, https://www.prnewswire.com/news-releases/allspiceio-hardware-development-platform-raises-15m-series-a-round-to-launch-ai-agent-and-scale-new-enterprise-functionality-for-electrical-engineering-teams-302489862.html 7. Bild Terms of Service, https://www.getbild.com/terms-of-service 8. Startup Stories: Streamlining Workflow for Engineers | Yale School of Management, https://som.yale.edu/story/2024/startup-stories-streamlining-workflow-engineers 9. The NIST Engineering Design Model Repository provides a public-domain collection of industry-relevant CAD models. - GitHub, https://github.com/usnistgov/engineering-design-models 10. cloud-gov/pages-uswds-gatsby - GitHub, https://github.com/cloud-gov/pages-uswds-gatsby 11. decaporg/decap-cms: A Git-based CMS for Static Site Generators - GitHub, https://github.com/decaporg/decap-cms 12. Access and Permissions | Cloud.gov Docs, https://docs.cloud.gov/pages/using-pages/permissions/ 13. Getting started with Decap CMS - Cloud.gov Docs, https://docs.cloud.gov/pages/using-pages/getting-started-with-netlify-cms/ 14. Maryland Adopts Technology That Protects Laws Against Cyberattacks; UW Law's BJ Ard a Key Contributor | University of Wisconsin Law School, https://law.wisc.edu/newsletter/article.php?iArticleID=10323 15. Open Law Platform — Open Law Library, https://www.openlawlib.org/platform/ 16. Open Law Library, https://www.openlawlib.org/ 17. mgaitan/waliki: A wiki engine powered by Django and Git - GitHub, https://github.com/mgaitan/waliki 18. Obsidian Notes - VA.gov, https://www.oit.va.gov/services/trm/ToolPage.aspx?tid=16483 19. Does anyone use Obsidian to manage their business : r/ObsidianMD - Reddit, https://www.reddit.com/r/ObsidianMD/comments/1gav339/does_anyone_use_obsidian_to_manage_their_business/ 20. A-Space - Wikipedia, https://en.wikipedia.org/wiki/A-Space 21. DevSecOps for the Public Sector - GitKraken, https://www.gitkraken.com/blog/devsecops-public-sector 22. Government Agency Software Development Solutions | GitHub, https://github.com/solutions/industry/government 23. HQ AETC/A3BD Digital Badging Handbook, https://www.aetc.af.mil/Portals/88/images/ForceDevelopment/Digital%20Credentials%20Pages/Digital%20Badging%20Handbook_20230613.pdf?ver=UBti9OFZNyFplarYSIt-Tg%3D%3D 24. Proposal 12 for ICANN: Enhance Learning by Encouraging Games | THE GOVLAB BLOG, https://thegovlab.org/proposal-12-for-icann-enhance-learning-by-encouraging-games/ 25. Train State, Local, and Education (SLED) Gov Entities on One Platform - Tovuti LMS, https://www.tovutilms.com/state-local-education-lms 26. 5 Companies Using Gamification to Boost Business Results - Cornerstone OnDemand, https://www.cornerstoneondemand.com/resources/article/5-companies-using-gamification-boost-business-results/ 27. Intellipedia - Wikipedia, https://en.wikipedia.org/wiki/Intellipedia 28. Web 2.0 in Government: Why and How? - JRC Publications Repository, https://publications.jrc.ec.europa.eu/repository/bitstream/JRC45269/jrc45269.pdf 29. Foundation for Public Code - Idealist, https://www.idealist.org/en/nonprofit/6f78a8b99aa64891a89dc1fb348f073a-foundation-for-public-code-amsterdam 30. Bundle policy and source code - Standard for Public Code, https://standard.publiccode.net/criteria/bundle-policy-and-source-code.html 31. Codebase stewardship, About the Foundation for Public Code, https://about.publiccode.net/activities/codebase-stewardship/ 32. Foreseeing the Impact of Transformational Technologies on Land Use and Transportation - MS2, https://www.ms2soft.com/media/1613/nchrb_report_924_ms2.pdf 33. zonebuilders/zonebuilder: Divide geographic space into discrete chunks - GitHub, https://github.com/zonebuilders/zonebuilder 34. MAPC/zoning-atlas - GitHub, https://github.com/MAPC/zoning-atlas 35. Public sentiment analysis and its explanatory power | Arup, https://www.arup.com/globalassets/downloads/insights/p/public-sentiment-analysis-and-its-exploratory-power/public-sentiment-analysis-and-its-exploratory-power.pdf 36. X-Road Trust Federation for Cross-border Data Exchange - Observatory of Public Sector Innovation, https://oecd-opsi.org/innovations/x-road-trust-federation-for-cross-border-data-exchange/ 37. togaf - Case Study on Enterprise Architecture - Stack Overflow, https://stackoverflow.com/questions/32294735/case-study-on-enterprise-architecture 38. Embassy Islamabad and Constituent Posts, Pakistan (ISP-I-10-64) - Office of Inspector General, https://www.stateoig.gov/uploads/report/report_pdf_file/isp-i-10-64_1.pdf 39. Weather.gov 2.0 - Hacker News, https://news.ycombinator.com/item?id=39571308 40. Speckle - GitHub, https://github.com/specklesystems 41. Guidance for government open source collaboration, Standard for Public Code - The Foundation for Public Code, https://standard.publiccode.net/ 42. Standard for Public Code | Interoperable Europe Portal - European Union, https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/standard-public-code 43. Digital Public Infrastructure - United Nations Development Programme, https://www.undp.org/sites/g/files/zskgke326/files/2023-08/undp-g20-accelerating-the_sdgs-through-digital-public-infrastructure.pdf