While writing about why I put a book manuscript under version control, I realized I had only explained half of what made the experience important.
Version control mattered. The ability to preserve history, compare changes, freeze an approved state, separate review from correction, and recover an earlier version was enormously useful.
But that was not the real breakthrough.
The real breakthrough was discovering that modern AI systems can work with GitHub almost as naturally as experienced technical teams do.
I can ask an AI system to inspect a repository, determine the current state of the work, locate a specific artifact, compare two versions, trace a change through the commit history, identify which branch contains a review, or explain how a decision evolved. It can move through a project structure quickly, understand the relationships among files, and often reconstruct what is happening without requiring me to manually assemble a briefing package first.
That experience changed the way I think about project management.
I am not a software developer. I did not begin using GitHub because I wanted to imitate a development team or turn project work into code. I began using it because, after years of managing complex artifacts, GitHub simply felt right.
The repository provided something most project environments do not: a durable place where structure, state, history, evidence, and change could remain connected.
Then AI made that structure dramatically more useful.
ChatGPT could inspect the project and understand the current condition. Claude could work against the same repository and reach the same underlying artifacts. One system could help structure and govern the work, while another could execute, inspect, or independently review it. Both could enter the same environment and orient themselves quickly because the state of the work was preserved outside any single chat session.
That is more than version control.
It is the beginning of an AI-readable project operating environment.
And I think it has major implications for project managers.
The problem was never a shortage of project artifacts
Project management has never lacked documents.
We have schedules, charters, RAID logs, decision registers, change requests, financial forecasts, requirements, test plans, meeting minutes, status decks, executive summaries, benefits cases, issue logs, governance packs, and lessons-learned reports.
On large programs, there may be thousands of them.
Yet despite this abundance, project teams still struggle to answer basic questions quickly and confidently.
Which artifact is authoritative?
What changed since the last steering committee?
Which assumption supports the current forecast?
What evidence caused the status to move from green to amber?
Which decision authorized the revised baseline?
Was the risk actually resolved, or was it simply removed from the current report?
What did leadership know when it approved additional funding?
The answers usually exist somewhere, but “somewhere” is doing a great deal of work.
They may be scattered across email, shared drives, project-management tools, spreadsheets, chat histories, ticketing systems, meeting recordings, presentation decks, and the memories of people who may already have moved on.
The project has information.
What it lacks is coherent, inspectable state.
A repository gives the project a shape
One reason GitHub felt immediately useful to me was that it forced the work to have a visible structure.
The manuscript did not exist as one giant file called Final.docx. It existed as a repository with project controls, manuscript components, source digests, decision records, handoffs, review materials, external-review branches, product-strategy material, and publication records.
That structure mattered because it reflected the actual work.
The chapters were distinct components. The control records had a separate role. External reviews belonged in their own areas. Decisions could be preserved independently from the artifacts they governed. The history of the project could be inspected rather than reconstructed from filenames and memory.
The repository also contained the kinds of structures project managers already understand: an authoritative table of contents, an issue register, a chapter registry, planning memos, verification records, handoffs, and an artifact architecture.
Nothing about that is inherently limited to publishing.
A project repository could contain:
the current charter and funded thesis;
the approved baseline;
risks, assumptions, dependencies, and decisions;
architecture and requirements;
financial forecasts;
evidence supporting major claims;
test and acceptance records;
vendor commitments;
governance packages;
approved state transitions;
and the historical record of how each item changed.
The structure makes the project legible.
And once the project is legible to people, it becomes legible to AI.
AI can enter the repository and orient itself
This is the part I initially underestimated.
Most AI work begins with context assembly.
You gather documents, paste summaries into a prompt, explain what happened previously, upload the latest files, clarify which version is current, and hope the model has enough information to understand the situation correctly.
That approach works, but it is fragile. Every new conversation requires some reconstruction of the operating context.
A well-managed repository changes that.
The repository itself carries the structure and memory of the project.
An AI system can inspect the directory layout, read the control records, locate the current artifacts, review the commit history, compare branches, and identify the sequence of decisions that led to the present state.
It does not need me to remember every detail.
It can read the project.
That distinction is important.
I can ask ChatGPT to inspect the repository and explain the current publication state. I can ask Claude to work from the same source of record and perform a bounded execution task. I can place an independent review on a separate branch, preserve its findings, and then ask another system to reconcile the results.
The models are not relying exclusively on what one of them said in an earlier conversation.
They are grounding themselves in the same external project state.
That makes the repository a shared working memory across AI systems.
The state survives the conversation
AI conversations are powerful, but conversations are not durable project control.
A chat can contain excellent analysis, subtle reasoning, and important decisions, yet unless those outcomes are externalized, they remain trapped inside the interaction that produced them.
A repository allows the important state to survive the conversation.
The decision record remains after the chat ends.
The reviewed artifact remains exactly where it was.
The branch still shows what the reviewer examined.
The commit history still shows what changed.
The next AI system can enter the project without inheriting the first system’s entire conversation history.
This is crucial for multi-model work.
ChatGPT and Claude do not need identical memory if they can inspect the same governed evidence. Gemini does not need to trust ChatGPT’s summary of the manuscript if it can review the frozen manuscript itself.
The source of continuity moves outside the model.
That is a much safer architecture.
The AI becomes a capable participant in the project, but the project does not live inside the AI.
This is what project managers have been missing
Project managers spend an enormous amount of time reconstructing state for other people.
We prepare onboarding packs for new team members. We create executive summaries for sponsors. We produce handoff documents when responsibilities change. We explain the history behind a decision. We walk auditors through the evidence trail. We help vendors understand which baseline is current.
Every new participant requires a briefing because the project does not explain itself.
Now imagine a project environment where the structure, artifacts, decisions, evidence, and change history are organized well enough that an AI system can perform much of that orientation automatically.
A new project manager could ask:
Show me the current governed state of the project, the five most material changes since the previous baseline, the assumptions supporting the forecast, and the decisions that remain open.
An executive could ask:
Why is this program still green when the schedule has moved twice?
An auditor could ask:
What evidence was available when the steering committee approved the revised forecast?
A technical lead could ask:
Which requirements and decisions are affected by this failed integration test?
A project manager could ask:
Compare the approved state with the proposed recovery state and identify every artifact that would need to change.
Those questions are difficult today because the information is fragmented.
In an AI-readable repository, they become navigational questions.
The AI can follow the links.
The repository becomes a Project Brain
This brings me back to the Project Brain concept.
A Project Brain should not merely be a chatbot that knows something about the project. It should not depend on a collection of documents poured into a vector database and summarized on demand.
It should be a structured memory of the project’s state.
That memory should know:
what is currently approved;
what remains proposed;
what changed;
which evidence supports each material claim;
which assumptions remain active;
which decisions authorized the current condition;
which commitments depend on those decisions;
and which contradictions remain unresolved.
GitHub provides many of the mechanics required to support that memory: files, directories, commits, branches, tags, diffs, authorship, timestamps, review workflows, and recoverable history.
AI provides the ability to navigate and interpret the structure.
Together, they begin to resemble a practical Project Brain.
The repository provides the memory.
The AI provides the cognition.
Human governance provides authority.
That three-part relationship matters.
Without structured memory, AI is forced to reconstruct the project repeatedly.
Without AI, the repository may remain too technical or labor-intensive for many stakeholders.
Without human authority, the system can identify changes but cannot legitimately decide what the organization should do.
A project is not a folder full of files
The danger is treating GitHub as another document repository.
Simply moving project files into GitHub would not solve much. A pile of documents remains a pile of documents, regardless of where it is stored.
The value comes from treating the artifacts as linked claims about project reality.
A schedule claims that a sequence of work is feasible.
A forecast claims that a certain amount of money will be sufficient.
A risk record claims that an uncertain condition has a particular likelihood and consequence.
A status report claims that the project is in a particular condition.
A decision record claims that an authorized person accepted a course of action based on the information available.
Each claim should have visible relationships.
What evidence supports it?
Which assumptions does it depend on?
Which prior state did it replace?
What changed?
Who reviewed it?
Who approved it?
Which commitments depend on it?
What would invalidate it?
Once those relationships are explicit, AI can do something far more useful than summarize documents.
It can reason across the project.
It can identify that the forecast still assumes a delivery date the schedule no longer supports. It can detect that the status report describes a risk as unresolved while the decision record assumes it has been mitigated. It can show that a proposed scope change affects the benefits case even though the benefits case has not been updated.
That is where the environment becomes intelligent.
AI should inspect the state before it writes the report
Today, AI is often introduced into project management at the end of the process.
The project data already exists in fragmented systems, and the AI is asked to summarize it into a status update, meeting note, or executive presentation.
That is useful, but it preserves the old operating model.
The project remains fragmented. The AI simply writes a better report about the fragmentation.
A stronger model begins earlier.
Before generating the report, the AI should inspect the current governed state.
It should compare evidence with recorded claims. It should identify contradictions. It should determine whether the latest artifacts are aligned. It should show which assumptions have changed and which decisions may need to be revisited.
Only then should it generate the narrative.
The status report becomes an output of state inspection rather than a manually maintained reality of its own.
This changes the project manager’s question from:
Can AI write my status report?
to:
Can AI prove that the status report is supported by the current project state?
That is a much more consequential capability.
Multiple AI systems can work from the same truth
One of the most practical benefits I have experienced is the ability to move between AI systems without moving the entire project manually.
ChatGPT can inspect the repository and understand the control model.
Claude can enter the same project and work against the same artifacts.
Gemini can review a frozen candidate without depending on the development history inside another model.
Each AI may bring different strengths, but they are not starting from separate realities.
They are working from the same source of record.
That makes independent review possible in a way that ordinary chat-based workflows struggle to achieve.
Suppose one AI proposes a revision to a project forecast. Another AI can inspect the same evidence and challenge the proposal. A human can review both findings and approve the resulting state transition.
The disagreement becomes visible.
The project does not simply inherit whichever answer appeared last.
This matters because AI systems will disagree, just as experienced professionals do. The answer is not to pretend one model is always correct. The answer is to preserve the evidence, proposals, reviews, and decision boundary.
GitHub provides a natural environment for doing that.
The project manager becomes the steward of an AI-readable state
This environment changes the project manager’s role in a constructive way.
The project manager is no longer primarily the person who gathers updates and turns them into documents.
The project manager becomes the steward of an environment in which both people and AI can understand the project accurately.
That means designing the repository structure.
It means deciding which artifacts are authoritative.
It means ensuring that evidence is linked to claims.
It means separating proposed state from approved state.
It means preserving decisions and their supporting context.
It means making sure that AI-generated changes remain proposals until the proper authority accepts them.
It means watching for contradictions among operational, recorded, reported, and funded reality.
This is not administrative housekeeping.
It is information architecture, governance, and decision support.
The project manager becomes the person who ensures that the project remains intelligible.
That may become one of the profession’s most important responsibilities.
What a practical governed-state workflow could look like
Consider a vendor delay that threatens a major milestone.
The operational evidence enters the repository: a vendor notice, updated delivery estimate, dependency analysis, and revised technical outlook.
The AI inspects the current state and identifies the affected artifacts:
schedule;
risk;
forecast;
benefits timing;
resource plan;
contractual position;
and the prior steering decision.
It then prepares a proposed state transition.
The proposal explains what changed, which assumptions failed, what the consequences are, and which alternatives remain available.
One path preserves scope but moves the date.
Another protects the date by reducing scope.
A third requires additional funding.
A fourth pauses the work pending renegotiation.
The AI can draft the changes and compare the options, but it does not silently rewrite the approved project.
The proposed state remains distinct.
The project manager reviews the package.
The accountable decision authority approves one posture.
The repository records the decision, the accepted state, the changed artifacts, the evidence considered, and the condition that would trigger another review.
The next morning, ChatGPT, Claude, or another authorized AI can enter the repository and determine exactly where the project stands.
No one needs to re-explain the story.
The state explains itself.
This is more than “Git for project management”
I previously described this concept as Git for project reality.
I still think that phrase is useful, but it is incomplete.
The larger opportunity is not merely applying version control to project artifacts.
It is creating an environment where AI can natively work with governed project state.
The repository is not only the place where versions are stored. It is the place where AI can navigate the relationships among evidence, artifacts, history, decisions, and authority.
That suggests a broader idea:
The AI-Native Project Repository
An environment in which project evidence, artifacts, assumptions, decisions, commitments, and state transitions are structured so that both humans and AI systems can inspect and govern them directly.
Such an environment should allow anyone with appropriate authority to ask:
What is the current approved state?
What changed?
What evidence caused the change?
Which artifacts are now inconsistent?
Which decisions remain open?
What does the current forecast assume?
What alternatives were considered?
Who approved the current commitment?
What would require another decision?
Those questions should not require a week of document collection.
They should be answerable from the governed state.
GitHub is not perfect, but it proves the model
GitHub was designed for software, not project governance.
Its language, interfaces, and workflows will not suit every project manager or every organization. Some enterprises will require different security models, access controls, data structures, integrations, and user experiences.
But GitHub proves that the underlying architecture works.
A complex body of work can be broken into governed components.
Its history can be preserved.
AI can navigate it.
Multiple AI systems can work from the same source of record.
Proposed changes can remain separate from accepted changes.
Review can occur against a frozen state.
Decisions can be linked to the artifacts they govern.
The current condition can be reconstructed without relying entirely on human memory.
That is a powerful proof of concept.
The future platform may not look like GitHub.
But I suspect it will behave much more like GitHub than like the disconnected reporting environments most projects use today.
The bridge between The Sentient PMO and Forensic Capital Governance
I now see this as the operational bridge between my first and second books.
The Sentient PMO explored how AI could preserve evidence, context, decisions, and continuity across complex work.
Forensic Capital Governance asks whether the current evidence still supports continued commitment of capital.
An AI-readable governed repository connects the two.
The Sentient PMO can inspect the work, maintain continuity, detect changes, and surface contradictions.
The repository preserves the authoritative state, evidence, history, and proposed transitions.
Forensic Capital Governance determines what those changes mean for authority, exposure, and continued investment.
Together, they create something much more important than automated reporting.
They create an environment in which AI can help the organization understand what is true, while humans remain accountable for deciding what to do about it.
The future project environment should be able to explain itself
A project begins with a funded belief.
Leadership believes that a commitment of money, time, authority, and organizational attention will produce a desired outcome.
Execution then generates evidence about whether that belief remains valid.
The project environment should preserve that relationship.
It should know what the organization believed, what it committed, what the work has demonstrated, what changed, what state the project is now in, and which decision follows.
Most project environments cannot do that without substantial manual reconstruction.
A well-structured repository can.
An AI system can navigate it.
Multiple AI systems can inspect the same state.
And a project manager can govern the boundary between analysis and authority.
That is why GitHub felt right to me long before I could fully explain why.
It was not simply a better place to store project artifacts.
It was a place where the project could have memory, state, history, and structure—and where AI could natively understand all four.
Projects are not reports.
They are governed states.
And increasingly, those states need to be readable by machines as well as people.
This is Part 3 of Building an AI-Native Intellectual Enterprise, a series examining how multiple AI systems, version-controlled repositories, independent review, public writing, and human governance became part of one production system—and what that experience may teach us about the future of professional work.