The Git Log Is the Corporate Record

In 1811, New York passed the first general incorporation statute, and with it came a requirement that persists to this day: the corporation must maintain its records. Minutes of meetings. Shareholder ledgers. Resolutions. Certificates. The corporate record book — traditionally a literal bound volume — is the canonical source of truth for what a corporation has done and who authorized it.

Two centuries later, most of these records live in Google Drive folders, DocuSign envelopes, and SaaS platforms that charge you monthly for the privilege of accessing your own governance history. The bound book became a PDF. The PDF became a database row. At each step, we gained convenience and lost something fundamental: provenance.

When a record lives in a database, you can see its current state. You might even see a changelog. But you cannot prove that the changelog itself wasn’t altered. You cannot verify that the sequence of events was recorded faithfully. You cannot demonstrate to a third party that this particular version of this particular document existed at this particular time and was authored by this particular person.

Git can.

Commits as corporate actions

A git commit is a snapshot of state with an immutable identity. It records what changed, who made the change, when it happened, and what came before. Each commit is cryptographically linked to its parent, forming a chain that cannot be reordered, altered, or selectively deleted without detection.

This is exactly what a corporate record is supposed to be.

When TheCorporation records a board resolution, it’s a commit. When equity is issued, that’s a commit. When an agent files a compliance document, when a founder vests shares, when the cap table changes — each action produces a commit with a message, a diff, and a signature.

The git log is the corporate minutes. Not a representation of the minutes, not a digitization of paper records — the log itself is the canonical record, written in the same medium that stores the data it describes.

What you get for free

Using git as the corporate record gives you properties that traditional recordkeeping systems spend millions trying to approximate:

Immutability. Once a commit is pushed, it cannot be altered without changing its hash and every subsequent hash. The record is tamper-evident by construction, not by policy.

Branching. Proposed corporate actions — a draft resolution, a pending equity grant — can live on a branch until approved, then merge into the canonical history. This isn’t a metaphor. It’s literally how the system works. A proposed action that gets rejected is simply a branch that never merges. It remains visible for audit purposes but never becomes part of the official record.

Diffing. You can see exactly what changed between any two points in your corporate history. What did the cap table look like before and after the Series A? git diff. What changed in the bylaws last quarter? git log --oneline bylaws/. These aren’t features we built on top of git. They’re git.

Signing. Git commits can be cryptographically signed. When a director approves a resolution, their signature is embedded in the commit itself. This is stronger than DocuSign — it binds the approval to the specific content that was approved, not just to the act of clicking a button.

Portability. Your corporate records are a directory on a filesystem. You can clone them. You can back them up. You can move them between providers, or host them yourself, or put them on a USB drive in a safe deposit box. You never depend on a vendor’s continued existence to access your own governance history.

The audit that audits itself

Every corporation dreads the audit. Whether it’s a tax audit, a due diligence review, or a compliance examination, the core activity is the same: someone asks “show me that you did what you said you did, when you said you did it, with the authorization you claim you had.”

In a traditional corporate records system, answering these questions requires assembling documents from multiple sources, cross-referencing dates, and hoping nothing was lost in a migration or a departed employee’s inbox.

In a git-backed corporation, the answer is the repository itself. The audit trail isn’t a report generated from data — it’s the data. The history is complete, ordered, signed, and self-consistent by construction.

When a regulator asks “who authorized this equity issuance?”, the answer is the commit signature. When an acquirer asks “what was the cap table on June 15th?”, the answer is git log --before="2026-06-15" cap-table/. When a tax authority asks “when was this filing submitted?”, the answer is the commit timestamp.

You don’t prepare for the audit. The audit is already done. It was done the moment the commit was signed.

From record-keeping to record-being

The traditional corporate record book is a passive artifact. Someone does something, then someone else writes it down. The action and the record are separate events, performed by separate people, often at separate times.

In a version-controlled corporation, the action is the record. There is no gap between doing and documenting, because the documentation is a structural property of the system. You cannot issue equity without creating a commit. You cannot pass a resolution without producing an auditable entry. The record isn’t kept — it simply is.

This is what it looks like when you treat corporate governance as infrastructure rather than paperwork. The record doesn’t describe what happened. The record is what happened.

Your corporation’s history shouldn’t be a story someone tells about the past. It should be a log that proves it.