Governed version authority for software estates.

H33-GIT is a governed version authority layer over Git that binds every commit, build, artifact and runtime to one identity and lineage — and records whether that lineage is admitted to production.

Git already solved distribution and history. It answers what changed, reliably, at any scale you throw at it. The question it was never designed to answer is the one that decides whether a release is safe: what is this code, what depends on it, and is it allowed to exist here?

This is not a Git replacement

H33-GIT does not host repositories, does not re-implement version control, and does not ask a team to leave the tools they already use. It sits above them as an authority layer. Git and GitLab remain the record of change; H33-GIT becomes the record of admission — identity, lineage, ownership, dependencies, consumers, evidence, lifecycle state, and the boundary of what each of those may be used to claim.

The distinction matters because the two records fail differently. A history that is complete and correct can still describe an estate nobody can govern: hundreds of branches, duplicated implementations, abandoned code that still matters, generated code with unclear ownership, production binaries whose source is no longer identifiable. None of that is a defect in Git. It is the absence of a layer Git never claimed to provide.

The estate condition this addresses

Software estates pass a size beyond which they cannot be governed by reading them. The symptoms are consistent across organisations:

• hundreds or thousands of branches, with no ruling on which are alive
• duplicated implementations that may be copies, evolutions, or competitors
• abandoned code that still carries capability nothing else has
• AI-generated code with unclear ownership and unclear review
• hidden dependencies that surface only when something breaks
• production binaries no longer connected to identifiable source
• repositories holding several competing versions of the same truth
• migrations that were started, partially completed, and never closed
• deprecated systems still referenced by live consumers

Every one of these is an authority question wearing a storage question’s clothes. “Where is the code?” has an answer. “Which of these four implementations may a release depend on?” does not — unless something is recording it.

Every push becomes a governed event

In an ordinary workflow a push is a transport operation: a developer commits, the commit reaches a remote, and the remote accepts it because it is well-formed. H33-GIT keeps that path and adds a decision to the end of it.

The output is not a score and not a warning. It is a recorded decision with a reason attached, which is the difference between a system that advises and a system that governs. A refusal names what was missing. An UNKNOWN says the estate does not yet hold the facts required to rule — and says so rather than defaulting to yes.

A code library, so retrieval stops meaning re-reading everything

The common pattern for AI-assisted engineering today is to point a model at the repository and let it read. That works until the estate is large, and then it degrades in three ways at once: cost rises with every question, exposure rises with every file that leaves the boundary, and accuracy falls because the model reconstructs architecture from fragments rather than retrieving it.

H33-GIT maintains a governed index of the estate — a sitemap for code — so a question is answered from the index and only authorised context is retrieved:

The retrieval boundary is the same one H33-Key applies to secrets: the reference is shareable, the contents are not. An index can be broadly readable while the source it points at stays under authorisation.

Identity, bound end to end

H33-BIND is the identity spine. Each layer of the chain is bound to the one above it, so a production system can be asked a question it usually cannot answer:

“Show me the exact code, build, artifact and runtime instance exercising this authority” is a routine audit request and an unusually difficult one to satisfy. It is difficult because the chain is normally reconstructed after the fact from logs, naming conventions and recollection. Bound at the time of the push, it is a lookup.

Duplication is measured, not assumed

The instinct when an estate looks duplicated is to consolidate it. The instinct is often wrong, and consolidating on the wrong reading destroys capability that no one knew was there. H33-GIT treats duplication as a measurement rather than an impression, and the measurement asks five questions:

• Are these implementations identical?
• Are they evolutionary — one derived from the other?
• Are they competing — two answers to the same problem, both live?
• Does one contain capability the other does not?
• Who consumes each, and would consolidation break them?

More files is not more capability, and fewer files is not less risk. What has actually been found in estates of this kind is duplicate connectors, parallel implementations, renamed capabilities, superseded systems that still run, and apparent duplicates that turn out to differ in exactly the place that matters.

Canonicalisation has five outcomes, and one of them is UNKNOWN

The most common failure in estate consolidation is a single assumption: the newest branch is the correct branch. Recency is a timestamp, not an authority. H33-GIT evaluates commit lineage, capability, consumers, production usage, evidence and ownership, and returns one of five rulings.

Not every branch should merge, and not every old branch should die. UNKNOWN exists because the alternative — a system that always produces a ruling — produces its most confident answers exactly where it has the least evidence.

What an AI agent may and may not do here

AI coding agents create a governance problem before they create a security one: they generate code faster than the people responsible for it can understand it. The answer is not to exclude them — they are genuinely good at the discovery work — but to bound what their output is allowed to become.

The boundary is the same one Agent-008 applies to autonomous action generally: proposing is not authorising, and an agent that resolves ambiguity by inventing an answer has stopped being useful precisely when the question got hard.

Proof artifacts have lineage too

The same failure that produces unmanageable branches produces unmanageable evidence. Attestations, replay records, adversarial test results and client attestations accumulate, and without a governed discovery layer they become the evidence equivalent of abandoned branches: real, valuable, and impossible to find or trust on demand.

H33-GIT governs that lineage on the same model. The two halves answer different questions and are designed to compose:

Bound together, the chain is searchable from either end. An auditor who starts at a proof can reach the exact artifact that produced it; an engineer who starts at an artifact can reach every proof it is cited in. Neither direction requires trusting a summary.

What an evidence query looks like

“Show me every adversarial test against this customer involving this model during the third quarter” should not be answered by searching source code. It is a query against the evidence index:

The last field is not decoration. A proof record carries what it may not be used to assert — that a passing red-team result does not prove all attacks are prevented, and does not authorise a production deployment. Recording the boundary beside the evidence is what stops a narrow result being cited as a broad one.

Discovery without exposure

An estate that produces evidence continuously produces a great deal of it, and no audit process survives an instruction to download all of it. The index is therefore designed to expose metadata, classification, authority, integrity and availability — while the proof itself remains behind authorisation. Finding that a proof exists, and being permitted to read it, are two different grants.

Recovery, and code as an enterprise asset

If a hosting provider became unavailable tomorrow, most organisations could eventually recover their files. Far fewer could recover the answer to what mattered, what connected to what, and what was safe to restore. H33-GIT keeps that portable by design: metadata that travels, cryptographic identity that verifies without the original host, a dependency map, and recorded recovery paths. It is the same reasoning H33-Recovery applies after compromise — restoring files is the easy half, and deciding what may be trusted again is the half that needs evidence.

Every governed artifact can inherit post-quantum identity and signatures on the same substrate the rest of the estate uses, so supply-chain integrity survives the migration rather than being rebuilt after it.

The control model — five coordinates, never collapsed

Every node in the graph carries five coordinates, and the discipline is that they are not interchangeable:

The last row does the work the other four cannot. Without it, an estate quietly upgrades its own facts:

What each layer answers

None of the rows above is replaced by the one below it. An estate needs all of them, and the last one is the one that is usually missing.

Where H33-GIT stands today

The architecture, the boundaries and the control model are decided, and this page states them. What does not yet exist is a published example: a real change carried through identity capture, binding, consumer analysis and an admission decision, captured as evidence, and replayed by somebody who did not produce it. Until that exists, H33-GIT composes components that carry their own proof surfaces — and composing proven parts is not itself a proof.

That first governed push is what this product publishes next, and it will be checkable with the same offline verifier the rest of the estate uses. We would rather say that here than imply otherwise.

H33-GIT is the version authority layer of the H33 platform. It composes H33-BIND for identity binding, H33-74 and H33-Replay for evidence and replay, Agent-008 for agent governance, and H33-Root for authority. Composition is not inheritance: each of those carries its own evidence position, and H33-GIT does not borrow it.