Building Knowledge Infrastructure for an AI-Ready Organization
Why Git, CI/CD, provenance, connectors, and AI-ready knowledge architecture may matter more than choosing the right chatbot
Executive Summary
Organizations are moving quickly to adopt artificial intelligence, but the durable investment may not be the AI assistant itself. The more important asset is the knowledge underneath it: research, policies, standards, procedures, decisions, institutional memory, technical documentation, data, and the relationships among them. The central challenge is therefore not simply choosing between Copilot, ChatGPT, Claude, Gemini, or another platform. It is creating trustworthy organizational knowledge that authorized people and machines can find, interpret, and reuse.
This article proposes treating knowledge as infrastructure. Git and GitHub provide useful mechanisms for version history, review, and controlled change. CI/CD practices can be adapted into a “Knowledge CI/CD” lifecycle in which automated checks validate structure while people remain responsible for evidence, meaning, approval, and judgment. Provenance helps distinguish sourced evidence from synthesis, interpretation, hypothesis, and application. Identity and permissions determine who is allowed to retrieve what. Connectors, APIs, and emerging approaches such as Model Context Protocol provide interfaces through which multiple authorized AI systems can interact with governed knowledge.
The practical implication is straightforward: do not organize organizational knowledge around a single AI product. Build and maintain an authoritative knowledge layer, then allow authorized search systems, applications, agents, and AI platforms to use it. For school districts, engineering firms, public agencies, regional collaboratives, and other knowledge-intensive organizations, that turns AI readiness from a software purchasing decision into an information architecture, governance, and organizational capacity challenge.
The Repository Is Becoming More Than a Place for Code
Most people still think of GitHub primarily as a software-development platform. That remains its foundation, but repositories can also hold README files, Markdown documentation, architectural notes, technical standards, research material, methodologies, contribution guidelines, and other forms of institutional knowledge.
That matters because repositories can increasingly serve as sources for AI systems. Microsoft’s GitHub Cloud Knowledge connector, for example, provides a way for repository documentation to become discoverable through Microsoft 365 Copilot and Microsoft Search experiences.
The repository can therefore occupy a different position within organizational information architecture:
Research
│
├── Evidence
├── Documentation
├── Frameworks
├── Methods
├── Decisions
└── Institutional knowledge
│
↓
Governed knowledge layer
│
↓
AI access layer
That is fundamentally different from accumulating documents in folders and pointing an AI assistant at them. The repository becomes an intentionally maintained layer between what the organization produces and what its people and machines consume.
Git Gives Knowledge Something AI Desperately Needs: History
Knowledge changes. A technical recommendation written several years ago may no longer be appropriate today. Research conclusions can change when better evidence becomes available. Policies are revised. Technical standards mature. Frameworks evolve. One document may be exploratory while another has undergone formal review.
Making material accessible to AI does not solve these problems. If anything, AI makes managing them more important because retrieval can make old or contradictory information easier to surface.
Git introduces mechanisms that are useful beyond software development: version history, authorship, commits, branches, pull requests, reviews, releases, and identifiable current versions. These mechanisms do not tell us whether a proposition is true, but they can establish what changed, when it changed, who proposed the change, and which version an organization currently recognizes.
The question therefore changes from simply asking whether AI can find a document to asking:
Can AI find the right version of the right knowledge, with enough context to understand what that knowledge represents?
That is a much higher standard.
CI/CD Is Not Just for Software
This leads to an opportunity that deserves more attention. What if we treated important organizational knowledge with some of the lifecycle discipline already applied to production software?
In software engineering, continuous integration, or CI, establishes processes for frequently integrating changes and testing them. Continuous delivery or deployment, or CD, establishes processes for moving validated changes toward production or publication.
The same basic pattern can be adapted to organizational knowledge:
Author proposes knowledge
↓
Repository branch
↓
Automated validation
↓
Human review
↓
Approval
↓
Merge into authoritative branch
↓
Publication
↓
AI indexing
↓
Monitoring and revision
I call this Knowledge CI/CD. I use the term as a conceptual application of established software-development practices to knowledge governance, rather than as a formal GitHub or Microsoft product.
The important distinction is that automation should not be expected to determine whether organizational knowledge is intellectually, scientifically, professionally, or legally correct. Automation can validate structure. People must validate meaning.
Machines validate structure. People validate meaning.
That principle provides an important boundary for using AI and automation responsibly.
What Would a Knowledge CI Pipeline Check?
A knowledge CI pipeline does not have to begin with sophisticated artificial intelligence. In fact, many of its most useful checks can be relatively mundane.
An organization could validate whether documents meet Markdown conventions, contain required metadata, follow filename conventions, reference existing internal resources, include ownership information, identify their classification, and meet repository-specific formatting rules. A workflow might also flag material requiring review because its review date has passed.
Conceptually, that process might look like:
Proposed change
↓
Markdown validation
↓
Required metadata
↓
Internal-reference checks
↓
Document classification
↓
Provenance fields
↓
Human subject-matter review
↓
Approval
These checks do not determine whether an author’s reasoning is correct. Instead, they establish an orderly environment in which responsible people can make that determination.
Provenance Becomes Part of the Pipeline
I have increasingly found it useful in my own research and writing to distinguish evidence, synthesis, interpretation, hypothesis, and application. An AI-ready knowledge environment makes those distinctions even more valuable.
Consider the difference between saying that research demonstrates a causal relationship and saying that I suspect such a relationship may exist but believe it still needs testing. A retrieval system might find both statements because they contain similar terminology. Epistemically, however, they carry very different weight.
An organizational research document could therefore carry metadata such as:
---
title: "Rural AI Readiness Field Note"
author: "Jason F. Kronemeyer"
status: "reviewed"
version: "1.3"
knowledge_type: "research-note"
visibility: "public"
last_reviewed: "2026-10-18"
provenance:
- sourced-evidence
- author-synthesis
---
This particular metadata structure is my proposed model rather than a GitHub or Microsoft requirement. Its purpose is to demonstrate that knowledge can contain information about itself.
Within the document, the organization can make additional distinctions. Evidence describes what a source establishes. Synthesis connects evidence from multiple sources. Interpretation explains what an author thinks the evidence means. Hypothesis identifies an idea still requiring investigation. Application explores what the knowledge could mean for an actual decision or problem.
A CI process might verify that required provenance fields are present. A human reviewer still determines whether those designations are appropriate.
Practical Example: A School District
Consider a school district. Over decades, the district may accumulate board policies, technology standards, cybersecurity procedures, curriculum frameworks, facilities plans, network diagrams, grant applications, strategic plans, professional-learning resources, vendor documentation, research, and considerable institutional memory.
These materials do not necessarily belong in a single repository. A district could instead identify an intentionally maintained body of knowledge suited to version-controlled governance.
district-knowledge/
│
├── technology/
│ ├── architecture/
│ ├── standards/
│ └── procedures/
│
├── facilities/
│ ├── standards/
│ └── planning/
│
├── education/
│ ├── frameworks/
│ └── instructional-technology/
│
└── governance/
├── ai/
└── data/
Suppose the technology department changes its network architecture standard. Instead of silently replacing a file, someone proposes a documented change. Automated checks validate required structural elements. Appropriate professionals evaluate the technical substance. The change is approved and merged, and the maintained version becomes the authoritative source made available to approved downstream systems.
AI readiness in this model comes not from buying more AI, but from improving the quality and governance of the knowledge AI encounters.
Practical Example: An Architecture or Engineering Firm
An architecture, engineering, or construction organization may hold design standards, specifications, commissioning guidance, technical details, manufacturer documentation, lessons learned, project templates, fiber standards, Power over Ethernet guidance, DC power guidance, and emerging Fault-Managed Power Systems practices.
Imagine an engineer asking an AI system:
What is our current guidance for integrating Fault-Managed Power Systems into intelligent-building designs?
If the organization’s information environment contains several generations of that guidance, retrieval alone does not solve the problem. The AI still needs an authoritative source.
A governed lifecycle could establish:
Draft guidance
↓
Technical review
↓
Discipline review
↓
Standards review
↓
Document validation
↓
Approved release
↓
Knowledge repository
↓
Authorized AI access
The business value is therefore not merely that AI can retrieve technical knowledge. It is that the organization knows which knowledge AI should retrieve.
Practical Example: A Rural Community or Regional Collaborative
The same principles can work outside conventional corporate environments.
A regional collaborative may work simultaneously across broadband, energy, education, workforce, transportation, housing, healthcare, agriculture, government, and economic development. Institutional structures and funding programs encourage those subjects to become separate silos even though communities experience them as interconnected systems.
A regional repository might maintain selected reusable knowledge:
/community
demographics.md
/broadband
infrastructure.md
adoption.md
affordability.md
/education
connectivity.md
workforce.md
/energy
distributed-energy.md
/economic-development
workforce-data.md
/research
bibliographies/
methods/
evidence/
When an important broadband dataset changes, for example, the relevant research note can be reviewed and revised instead of allowing an outdated conclusion to remain embedded indefinitely in an old report.
The goal is not to let an AI decide what a community should do. It is to give people better access to their own history, evidence, research, relationships, and institutional knowledge so they can make better decisions themselves.
Practical Example: A Public Agency
A public agency administering broadband, infrastructure, education, workforce, or economic-development programs faces another challenge: documents may have different levels of authority.
Relevant information might include legislation, administrative rules, formal policies, program guidance, technical assistance, public documentation, internal procedures, and staff interpretation. A search system may retrieve text from several of them even though they should not necessarily carry equal authority.
An organization can make these relationships explicit:
Law
↓
Regulation
↓
Official policy
↓
Program guidance
↓
Technical guidance
↓
Internal procedure
↓
Interpretation
That diagram is illustrative rather than a universal legal hierarchy. The actual relationships must reflect the applicable law and governance model.
The underlying principle is broadly applicable: an AI system should not be expected to infer institutional authority merely because several documents happen to contain similar words.
Continuous Delivery Makes Knowledge Operational
One of the more powerful ideas in this architecture comes from the delivery side of CI/CD. Once knowledge has been appropriately reviewed, the same authoritative source can potentially support multiple approved destinations.
AUTHORITATIVE REPOSITORY
│
Approved change
│
┌───────────┼───────────┐
↓ ↓ ↓
Website Search AI
│ │ │
└───────────┼───────────┘
↓
People
This creates the possibility of author once, govern once, deliver appropriately.
A reviewed technical note might support a public documentation site. The same maintained content might become discoverable through organizational search. An approved connector might make appropriate material accessible to an AI assistant. A future presentation or briefing can draw its foundational claims from the same maintained source.
For sensitive or high-consequence environments, I would generally favor controlled delivery with explicit approval gates rather than assuming that every accepted repository change should automatically become public or AI-accessible.
Don’t Build the Knowledge Base for One AI
This is where architecture becomes more important than product selection.
An organization might connect part of its knowledge environment to Microsoft 365 Copilot today and use another assistant for a different task tomorrow. New models, agents, search systems, and interfaces will continue to appear.
The durable architecture therefore should not be:
Organization → Copilot
It should be closer to:
PEOPLE
│
Review
│
↓
KNOWLEDGE LAYER
│
Versioning
│
Knowledge CI/CD
│
Approved knowledge
│
┌────────────┼────────────┐
↓ ↓ ↓
Search Connectors APIs
│
↓
MCP
│
AI ACCESS LAYER
│
┌──────────┼──────────┐
↓ ↓ ↓
Copilot Other AI Agents
The governed knowledge is the durable asset. AI applications become consumers of that asset.
This distinction matters because switching AI systems should not require rebuilding everything the organization knows.
The Repository Doesn’t Have to Contain Everything
A mature knowledge architecture should not replace one information silo with another.
Organizations already have appropriate systems for different forms of information. Version-controlled research may belong in GitHub. Working documents may remain in Microsoft 365. Structured data may reside in databases or data platforms. Transactional systems may remain systems of record. Public research may come from government datasets, standards organizations, universities, and scholarly publications.
The goal is therefore not necessarily centralization. It is controlled discoverability across authoritative systems.
GitHub
Research • Frameworks • Documentation
│
│
Microsoft 365 ───┼─── Data platforms
Documents │ Structured data
Collaboration │ Analytics
│ Knowledge graphs
│
External sources ┘
Research • Standards • Public data
│
↓
Knowledge access layer
│
Search • AI • Agents
This begins to resemble a knowledge fabric rather than a conventional document repository.
MCP Adds Another Interoperability Layer
Model Context Protocol, or MCP, adds another emerging dimension to this architecture. At a high level, MCP is intended to provide a standardized way for AI applications to interact with external context and capabilities.
Its strategic importance is not simply another acronym or protocol. It represents movement toward separating the AI interface from the systems containing knowledge and tools.
Conceptually:
KNOWLEDGE AND SYSTEMS
GitHub ─ Databases ─ Data lakes ─ Applications
│ │ │ │
└──────────┴─────┬─────┴────────────┘
│
APIs / Connectors / MCP
│
AI applications
That separation is important. The knowledge does not have to live inside the chatbot. Instead, an authorized AI system receives governed access to knowledge maintained in appropriate systems.
Permissions Matter as Much as Retrieval
Making organizational knowledge discoverable immediately raises another question:
Discoverable by whom?
Knowledge architecture and identity architecture become inseparable once AI enters an organizational environment.
Identity
↓
Authentication
↓
Authorization
↓
Knowledge permissions
↓
Retrieval
↓
AI reasoning
↓
Response
A sophisticated language model cannot compensate for poorly designed access controls, nor should it.
A superintendent, engineer, contractor, board member, researcher, student, and member of the public should not necessarily receive access to the same organizational information.
Before asking whether AI can retrieve something, organizations should therefore ask whether a particular person should be authorized to retrieve it.
Retrieval Is Not the Same as Knowledge
Connecting AI to more documents does not automatically make an organization smarter.
If five contradictory versions of a policy exist, AI may simply become better at finding five contradictory policies. If technical documentation is obsolete, AI gains faster access to obsolete information. If an organization cannot distinguish research evidence from someone’s interpretation, retrieval does not resolve the ambiguity.
Knowledge CI/CD addresses part of this problem by establishing a lifecycle around changes. It does not eliminate the requirement for human judgment.
The equation is not:
More data + AI = knowledge
A more realistic model is:
Information
+
Structure
+
Context
+
Provenance
+
Version control
+
Validation
+
Governance
+
Permissions
+
Human judgment
↓
Usable organizational knowledge
AI can then make that knowledge easier to discover, interrogate, connect, and apply.
A Practical Implementation Roadmap
Organizations do not need to begin by connecting every system to AI. I would recommend starting with a deliberately constrained knowledge domain and using the implementation to develop governance practices before expanding.
Phase 1: Identify Authoritative Knowledge
Choose one manageable body of knowledge, such as technology standards, architecture documentation, research publications, technical procedures, or AI governance guidance.
For that domain, establish what is authoritative, who owns it, who can change it, who approves changes, who should be able to retrieve it, and how frequently it should be reviewed.
The objective is to understand the knowledge lifecycle before introducing AI into it.
Phase 2: Establish the Repository Model
Develop an information architecture that reflects how knowledge is actually created and used.
knowledge/
│
├── research/
│ ├── evidence/
│ └── bibliographies/
│
├── standards/
├── frameworks/
├── procedures/
├── architecture/
└── decisions/
Establish conventions for filenames, metadata, ownership, provenance, classification, review status, and relationships to primary sources.
Phase 3: Establish the Git Workflow
Move significant changes through a deliberate lifecycle.
Issue
↓
Branch
↓
Edit
↓
Pull request
↓
Review
↓
Approval
↓
Merge
Different knowledge categories can require different reviewers. A technical standard might require an engineering reviewer, while research claims might require methodological or editorial review.
Phase 4: Add Knowledge CI
Start with simple automated validation. Determine whether files conform to repository standards, whether required metadata is present, whether internal references resolve, and whether structural requirements have been met.
Do not attempt to automate epistemic judgment.
A machine can determine whether a source field exists. It cannot substitute for a qualified reviewer deciding whether that source really supports the claim being made.
Phase 5: Add Knowledge CD
After approval, deliver suitable content to approved destinations.
APPROVED KNOWLEDGE
│
┌──────────┼──────────┐
↓ ↓ ↓
Website Search AI access
Not everything should necessarily go everywhere. Classification, audience, authority, and permissions should determine where material is distributed.
Phase 6: Connect Search and AI
Only after establishing a reasonably governed source environment should the organization connect AI retrieval.
Begin with a limited collection and test real questions against it. Evaluate whether the AI finds the authoritative source, uses the correct version, preserves attribution, respects permissions, and avoids superseded material.
The testing process should include human evaluation because these are not merely technical acceptance criteria. They are questions of meaning, provenance, and organizational trust.
Phase 7: Expand to Multiple AI Consumers
Once the underlying architecture works, the organization can evaluate additional AI applications, connectors, APIs, and interoperability mechanisms such as MCP.
The architecture then becomes:
GOVERNED KNOWLEDGE
│
APIs / Connectors / MCP
│
┌───────┼───────┐
↓ ↓ ↓
Search AI Agents
The organization does not rebuild its knowledge every time a new AI product arrives. It gives appropriately authorized systems controlled access to knowledge that already has governance, ownership, history, and provenance.
From DIKW to CI/CD to AI
This architecture adds an interesting dimension to the familiar Data-Information-Knowledge-Wisdom model.
We often portray DIKW as a one-way progression:
DATA
↓
INFORMATION
↓
KNOWLEDGE
↓
UNDERSTANDING
↓
DECISION
But organizational knowledge is not static. Decisions lead to implementation. Implementation creates observations. Observations produce new data and evidence. New evidence should sometimes cause existing knowledge to be reconsidered.
A more useful representation may therefore be cyclical:
Data
↓
Information
↓
Knowledge
↓
Application
↓
Observation
↓
New evidence
↓
Revision
↓
Review
↓
Updated knowledge
└───────────────→
CI/CD starts to make conceptual sense within this cycle. It provides some of the machinery through which revised knowledge can move through a managed process of validation, review, approval, and delivery.
AI becomes another interface into that knowledge cycle, not its owner.
A New Kind of Infrastructure
We routinely recognize roads, fiber networks, electrical systems, water systems, schools, data centers, and cloud platforms as infrastructure. I think we should begin treating knowledge infrastructure with some of the same seriousness.
Knowledge infrastructure has architecture. It requires maintenance. It has security boundaries. It needs interoperability. It accumulates technical debt. It requires stewardship. Important changes need review. Obsolete components should be retired. And many different applications can be built upon it.
The analogy to software infrastructure is useful:
| Software Infrastructure | Knowledge Infrastructure |
|---|---|
| Source code | Research and documentation |
| Git | Knowledge history |
| Pull request | Proposed knowledge change |
| Automated tests | Structural validation |
| Code review | Expert or peer review |
| CI | Knowledge validation |
| Release | Approved knowledge |
| CD | Publication and distribution |
| API | Machine-accessible interface |
| Connector/MCP | AI access mechanism |
| Monitoring | Knowledge-health review |
This is my proposed analogy rather than a formal industry model. Its value is in showing that organizational knowledge need not remain a loose collection of files. It can be managed as a living system.
Build the Knowledge Layer First
My emerging principle is simple:
Do not build an organization’s knowledge around an AI product. Build trustworthy knowledge infrastructure that authorized AI systems can use.
I would add a second principle:
Do not treat organizational knowledge as a finished collection of files. Treat it as a maintained system with a lifecycle.
Together, those principles produce a different architecture for organizational AI:
PEOPLE
│
Create / observe
│
↓
KNOWLEDGE
│
Git / versioning
│
Knowledge CI
│
┌──────────┴──────────┐
↓ ↓
Automated validation Human review
│ │
└──────────┬──────────┘
↓
Approved knowledge
│
Knowledge CD
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Website Search AI access
│
Connectors / APIs / MCP
│
┌────────────┼────────────┐
↓ ↓ ↓
Copilot Other AI Agents
│ │ │
└────────────┼────────────┘
│
PEOPLE
│
Judgment / action
│
New evidence
│
└──→ Knowledge
Notice where people sit in the architecture: at the beginning, at critical review points, and at the end.
That is intentional.
Conclusion: AI Readiness Is Knowledge Readiness
The rush toward organizational AI can make the problem appear to be primarily about selecting platforms, licensing assistants, or building agents. Those decisions matter, but they sit on top of a more fundamental challenge. An AI system cannot retrieve trustworthy organizational knowledge unless the organization first does the work of making that knowledge trustworthy, identifiable, governed, accessible, and current.
That is why Git, CI/CD, provenance, identity, knowledge graphs, connectors, APIs, and emerging interoperability mechanisms such as MCP belong in the same conversation. Together, they suggest an architecture in which organizational knowledge has ownership, history, review, permissions, and a lifecycle. AI then becomes one of several authorized ways of interacting with that knowledge rather than the place where organizational knowledge itself resides.
For a school district, this could help preserve technical and institutional knowledge across leadership transitions. For an engineering firm, it could make current standards easier to maintain and discover. For a public agency, it could help distinguish authoritative guidance from interpretation. For a regional collaborative, it could make evidence across broadband, education, workforce, agriculture, energy, and economic development more legible across institutional boundaries.
Most importantly, people remain responsible for judgment. We produce evidence, establish provenance, evaluate meaning, authorize access, approve changes, and decide what action to take. Automation helps validate and distribute knowledge. AI helps retrieve and connect it. Neither removes the responsibility of people to decide what that knowledge means.
AI readiness is therefore, in a very real sense, knowledge readiness.
The organizations best positioned for the next generation of AI may not simply be the ones that purchase the most capable models. They may be the organizations that know what they know, know where that knowledge came from, know who should have access to it, know when it changed, and have built the infrastructure necessary to keep it trustworthy.
That is why I believe knowledge infrastructure deserves to be treated as infrastructure in its own right. And building it may prove to be one of the most consequential technology, governance, and organizational-capacity challenges of the AI era.
Further Reading
- GitHub. “Continuous Integration.” GitHub Docs.
- GitHub. “Continuous Deployment.” GitHub Docs.
- Microsoft. “GitHub Cloud Knowledge Connector Overview.” Microsoft Learn.
- Microsoft. “Deploy the GitHub Cloud Knowledge Connector.” Microsoft Learn.
- Microsoft. “Set Up the GitHub Service for GitHub Cloud Knowledge Connector Ingestion.” Microsoft Learn.
- Model Context Protocol. “Architecture Overview.” Model Context Protocol.
- Microsoft. “Model Context Protocol.” The Source.