Every Stakeholder Gets a Clone

When a new director joins a corporate board, they receive a board packet. It’s a PDF, usually assembled by counsel, containing the documents the outgoing board members thought the new director should see. Articles of incorporation. Current bylaws. Recent minutes. The cap table as of some recent date.

This is a summary of the corporate record, curated by someone else, frozen at a point in time, with no reliable way to verify completeness or accuracy. The new director is expected to govern from a snapshot.

In a version-controlled corporation, a new director receives a git clone URL.

What a clone contains

A git clone is not a copy of the current state. It’s a copy of the entire history. Every version of every file. Every commit message. Every signature. Every branch, including branches that were proposed and rejected. The complete, cryptographically linked chain of every corporate action from the moment of formation.

When a director clones the corporate repository, they receive:

The articles of incorporation as originally filed, plus every amendment, each as a separate commit signed by whoever authorized the change. The bylaws in their current form, with a complete diff history showing every modification. The cap table as a structured data file, with every issuance, transfer, and conversion recorded as an individually signed commit. Every board resolution, every written consent, every officer appointment. The agent configurations — which agents are authorized, what permissions they hold, what actions they’ve taken. Every compliance filing, every tax document, every contract.

The clone contains the records themselves, not a platform-generated summary.

The verification problem

Traditional corporate records have a verification problem. When an investor asks “is this really the current cap table?”, the honest answer is “this is what the platform says.” The investor must trust the platform. They must trust that no one with admin access modified a record. They must trust that the platform’s database wasn’t corrupted, migrated incorrectly, or selectively edited.

This isn’t paranoia. Cap table disputes are among the most common and most expensive corporate conflicts. They happen because records diverge from reality, and there’s no mechanism to detect the divergence until it matters.

Git eliminates this class of problem.

Every commit has a SHA-256 hash computed from its contents, its parent commit, its timestamp, and its author. Change any of these and the hash changes. Change a commit from three years ago, and every subsequent hash changes. The entire history is a Merkle tree — a data structure specifically designed to make tampering detectable.

When two stakeholders compare their clones, they don’t need to compare documents. They compare a single hash — the HEAD of the main branch. If the hashes match, the repositories are identical, including all history. If they don’t match, git can identify exactly which commit diverged and what changed.

This is mathematical verification rather than platform trust. The corporate record is either consistent across all clones or the inconsistency is identifiable.

The board as a peer network

In a centralized governance model, the board interacts with the corporate record through a platform. The platform mediates access. The platform controls permissions. The platform is the gatekeeper.

In a peer-to-peer model, the board is the network.

Each director holds a clone. When a resolution is proposed, it appears as a branch. Each director can review the proposed changes locally, on their own machine, at their own pace. Approval is a signed commit — a cryptographic attestation that this specific director, identified by their key, approved this specific change at this specific time.

The approval doesn’t flow through a platform. It flows through git. A signed commit can be created offline, transferred via email or USB drive if necessary, and verified by any party with the signer’s public key. The platform is a convenience for coordination, not a requirement for authorization.

This matters in adversarial situations. If the governance platform is compromised, shut down, or legally enjoined, the board can continue to operate. They have the records. They have their signing keys. They have each other’s public keys. The infrastructure for governance is fully distributed among the governors.

Selective access, complete integrity

Not every stakeholder needs to see everything. An observer on the cap table doesn’t need access to board minutes. A contractor doesn’t need to see the equity plan. P2P governance doesn’t mean everyone sees everything.

Git supports this through repository structure and access controls at the remote level. Different stakeholders can be granted access to different branches or subtrees. A stakeholder with limited access still gets a cryptographically complete copy of the portions they can see — the integrity guarantees hold regardless of the access scope.

But here’s what makes the P2P model different from centralized access control: the access restrictions are at the network level, not the data level. A director with full access holds a copy that is independently verifiable. They don’t need to trust the platform’s access control layer to know that what they’re seeing is authentic. The data itself carries its proof.

No single point of failure

In 2019, a cloud provider suffered a regional outage that took down several governance SaaS products simultaneously. For eighteen hours, hundreds of companies could not access their own corporate records. No cap tables. No bylaws. No minutes. No way to check who was authorized to do what.

That failure mode is much harder to reproduce in a peer-to-peer model.

If the coordination remote goes down, every stakeholder still has a complete copy. If a director’s machine fails, the repository exists on every other director’s machine, and on the remote, and on any backup that was ever cloned. The number of independent copies equals the number of stakeholders, plus backups.

The probability of total data loss in a P2P system approaches zero as the number of participants increases. In a centralized system, the probability of total access loss is the probability of a single platform going down — which is not zero, and has been observed repeatedly.

The default should be distributed

Corporate records are too important to depend on any single custodian. The traditional model — one law firm holds the minute book, one platform holds the cap table, one folder holds the contracts — creates fragmentation, vendor dependency, and single points of failure.

The peer-to-peer model — every authorized party holds a complete, verifiable, independently valid copy — is strictly better on every dimension that matters: availability, integrity, resilience, portability, and verifiability.

It took the software industry decades to move from centralized version control (CVS, Subversion) to distributed version control (Git). The benefits were so overwhelming that the transition, once started, was irreversible.

Corporate governance is starting the same transition. Every stakeholder gets a clone. The corporate record lives everywhere its governors do.

This is not an add-on feature. It is the storage model.