Governance Is the Product

The harness — the agentic work environment connecting a model to context, tools, action, feedback, permissions, and human control — is becoming the interface to product work rather than a coding assistant bolted to its edge. That shift is real and it is not the problem. The problem is that a capable interface does not create a capable organization around itself. Context stays scattered, authority stays unbound, evidence detaches from the decisions it should support, and continuity resets every time a session ends. Activity grows. Capability does not compound.

Team Foundry is the connected system around the harness. It holds five properties: work is durable, context stays connected, accepted state coordinates teams, authority and evidence stay governed, and feedback adapts the system. Those five properties are a contract, not a feature list — they describe what any implementation must satisfy, independent of what stores the data.

The implementation satisfies that contract through two layers with an explicit, committed boundary between them. A skills layer carries judgment: a router resolves intent, and per-domain route files own workflow sequencing. A programmatic layer carries mechanics: a single command surface, schema validation, and gates that cannot be reasoned with. The division is not a diagram — it is a committed record that assigns each category of behaviour to code, to a skill, or to both, and it can be read line by line.

Inside that boundary the governance is structural. The skills layer states human authority as operating instructions in reviewable text — prefer a human gate over inferred authority — while the programmatic layer makes some outcomes impossible rather than discouraged.

Git is the substrate underneath, chosen because its semantics were already legible to a harness: inspect, diff, attribute, isolate, review, recover. Every Foundry operation translates to a Git mechanism — a Session is a branch-backed envelope, publication is a reviewable pull request into a human-governed main branch. This paper argues that the translation runs one way only.

The honest limits are set out under Challenges. The most important one to state up front: this is an argument about which semantics are essential, not a claim that Foundry runs on anything other than Git today. The records are plain, readable files that do not need Git to carry their meaning — but nothing has been moved off it yet.

This document uses five terms precisely.

Harness. An agentic work environment that connects a model to context, tools, action, feedback, permissions, and human control. ChatGPT and Claude are harnesses; so are Codex and Claude Code. They are examples of the category, not its definition or its boundary. The coding-focused ones came out of engineering and their vocabulary still shows it, but nothing in the definition is specific to code — and the general-purpose ones are already how much of an organization works, with no engineer involved. Nothing in this paper depends on which harness is in use, and Foundry has been operated through more than one.

Substrate. Whatever actually stores and versions durable state. Today that is Git and a filesystem. The distinction between the substrate and the system is the subject of the Substrate section and the reason this paper exists.

Session. A bounded work envelope owned by one person, inside which work happens and from which durable records are produced. It is the unit of attribution and continuity, not a chat transcript.

Primitive. A domain concept that Foundry models as a first-class record with a predictable address, a typed contract, a command surface, and an owning skill. Sessions, Tasks, Artifacts, Delivery Runs, Repos, Standups, and Meetings are a few of them; The Primitive reference section lists every one.

Invariant. A governance semantic that must hold in any implementation of Foundry, regardless of substrate. The Substrate section names six and argues they are the actual product.

One scope exclusion: this is not an operating manual. Where mechanics matter, this document shows the smallest example that makes the mechanism checkable.

The interface shift

The harness is no longer only a coding copilot — and the people using one are no longer only engineers. Engineering adopted these environments first, which is why they are still described in engineering language, but adoption did not stop at engineering. Strategy, design, marketing, operations, and sales increasingly do their actual work inside the same kind of agentic environment: researching, reasoning, drafting, planning, deciding, and coordinating.

Across the product lifecycle — research, reasoning, planning, coordination, creation, review, execution — only the last three were ever copilot territory. The first four are where the interface has quietly expanded, and they were never engineering’s alone. One interface now crosses the whole lifecycle and much of the organization. That is the shift, and it is genuinely useful.

The missing organizational layer

A cross-lifecycle interface does not automatically create a cross-lifecycle system. The interface crosses the lifecycle; the organization still resets around it.

Watch what a capable harness session actually has to do before it can help. It reconstructs the company from scratch: which project this is, who decided what and when, what was tried, what the constraints are, who can approve. Four things are missing every time:

• Context is scattered across conversations, tools, and people’s memory.
• Authority is unbound — nothing structural distinguishes a proposal from a decision, or a contributor from an approver.
• Evidence is detached from the decisions it should support.
• Continuity resets when the session ends.

The result is the specific failure this paper addresses. Activity grows — visibly, impressively. Capability does not compound.

What is actually missing

The missing layer is not a better model, a longer context window, or a more capable harness. All three are improving without closing this gap. What is missing is a connected system around the harness that holds four things together: connected context, authority bound to work through identity, roles, and human gates, evidence carrying receipts, and continuity that survives people, tools, and sessions.

That system is what Foundry is.

Product development is a learning loop

Foundry’s operating engine is three moves:

• Produce — create durable, connected work.
• Consume — understand, review, decide, and act on it with context intact.
• Evolve — return outcomes as better context and better operating rules.

The harness facilitates the loop; it does not own it. The loop closes: Evolve feeds Produce, and the next piece of work starts from more than the last one did.

One loop, three operating planes

The same engine runs across three planes, each producing durable work, consuming shared context, and evolving from feedback. The third — the AI SDLC — is followed all the way down in its own section.

Feedback from every plane improves three things in turn: better context, better practice, better governance. The third is the one most systems omit — the operating rules themselves are outputs of the loop, not fixed configuration.

Natural language is the interface

People should not have to operate that model directly. They speak ordinary product language; the harness translates it into governed, inspectable actions.

The left column is the entire user interface. The right column is what must remain true regardless of phrasing.

Five properties

Whatever sits underneath, every Foundry must remain five things.

1. Durable — work survives the harness interaction. Sessions, Scratchpads, Artifacts, and outcomes become durable team state.
2. Connected — context stays connected. Relationships and provenance keep meaning attached across the system.
3. Coordinated — accepted state drives team action. Task Boards, Standups, Meetings, and Digests update the same accepted work.
4. Governed — authority and evidence stay bound to action. Identity, roles, gates, and receipts keep human decisions inspectable.
5. Adaptive — feedback changes the system. Outcomes improve context, practice, skills, and governance.

The five properties above are deliberately stated without reference to files, paths, commits, or repositories. That is the argument of this section.

They form a substrate-independent contract. Each one is a claim about relationships that must hold, not about a storage mechanism:

• Durable requires that work outlive the interaction that produced it — it says nothing about where it is written.
• Connected requires that relationships between records be explicit and traversable — not that they be filesystem links.
• Coordinated requires a single accepted state that team rituals read from and write to — not a particular database.
• Governed requires that identity, authority, and evidence be bound to actions such that a human decision is distinguishable from an agent proposal — not a specific permission system.
• Adaptive requires that outcomes feed back into context and rules — not a particular feedback pipeline.

This matters for a specific reason. A system whose value proposition is inseparable from its storage engine is a storage product with workflow features. A system whose value proposition is a set of relationship guarantees can outlive its first implementation — and can be evaluated on whether those guarantees actually hold rather than on whether you like its file layout.

The contract is also what makes the system falsifiable. Each property implies a test. Can work be found and used after the session that produced it closed? Can you trace a decision to the evidence that supported it and the person who made it? Can two people coordinate from the same accepted state without reconciling by hand? Can an agent’s proposal be distinguished, structurally, from a human’s acceptance? Did the operating rules change in response to what happened? Those are answerable questions, and the Evidence section answers them with field evidence rather than assertion.

Everything from here is implementation. The next section shows the mechanism; the one after separates what is essential from what is merely Git-shaped.

Two layers, with a committed boundary

Foundry is implemented as two layers with different competencies and an explicit contract between them.

The skills layer carries judgment. A router resolves natural-language intent to a domain, and a route file for each domain owns workflow sequencing, composition across domains, and the questions that must go to a human. This layer is instruction text, which means it is reviewable, diffable, and version-controlled like any other source — not a model improvising.

The programmatic layer carries mechanics. Commands perform exact lifecycle operations; JSON Schema validation enforces record structure; gates refuse to proceed when preconditions fail. This layer cannot be reasoned with, which is the point. When a rule must hold regardless of how persuasively it is questioned, it belongs here.

The two layers are comparable in deliberateness but not in size. Judgment is compact because it is instruction, not procedure. Mechanics are large because exactness is expensive — and that expense is what earns the deterministic layer the right to be the thing that refuses.

The claim that these two layers have a real division of labor is the kind of claim a reader should distrust on sight, because it is easy to assert and usually decorative. So Foundry commits the division to a record in the repository. It is reproduced here in full:

Read the right-hand column and a pattern appears. Some behaviours are pure mechanics, such as rebasing a workspace. Some are pure judgment, such as constructing a prompt. Most are joint, and the phrasing is precise about how: code owns the contract, the skill owns its interpretation. Session lifecycle is owned by code with interpretation by the sessions skill — the command decides what a valid session transition is; the skill decides when and why to make one, and when to ask a person instead.

Two things are true of this record at once, and the second is easy to miss. It genuinely fixes the foundational split — and it covers roughly half the system. Twelve domains added since it was written, QA, releases, task boards, standups, and meetings among them, appear nowhere in it. So it is evidence that the boundary is real and deliberate. It is not evidence that the boundary has been maintained everywhere, and this paper does not present it as such.

What the skills layer actually says

A reader may reasonably suspect that “the skills layer carries judgment” means the model is left to improvise inside a directory that looks organized. The route files answer that directly, because they are ordinary reviewable text and can be quoted. Human authority is not described in them as a principle. It is written as operating instructions, in the ordinary domains as much as the governed ones — running a standup, publishing an artifact, writing a task:

Keep the ceremony human-led. Act as scribe and context assistant; the facilitator owns interpretation and completion. Standups route file

Human approval controls review and publication state. Do not infer publication from polish alone. Artifacts route file

The session owner is write authority; an assignee is a task field and does not authorize the write. Task boards route file

A conflict is an inspectable stopped state, not a silent rollback. Sessions route file

If observations disagree, keep source records unchanged, emit a diagnostic and deterministic decision trace, and prefer a human gate over inferred authority. Delivery route file

Three things follow from this being text rather than code.

First, it is reviewable. A governance change arrives as a diff on a Markdown file that a human reads and accepts, through the same publication path as any other change. There is no hidden prompt and no configuration surface that alters authority without review.

Second, it is specific about the direction of doubt. Each directive resolves uncertainty toward the human — prefer a gate, stop and report, do not infer. A system that intended the opposite would be equally easy to write here, which is precisely why the actual text is evidence rather than decoration.

Third, it is not self-enforcing, and the Challenges section says so. Instruction text is followed by a model; it does not compile. The parts that must hold unconditionally are therefore placed in the layer that cannot be persuaded.

What the programmatic layer refuses

The deterministic layer’s job is to make some outcomes impossible rather than discouraged. Three mechanisms do that work.

Gates. Preconditions are checked and reported by name before anything proceeds. The workbench run described below reported four passing gates — active session, actor identity, repository resolution, toolchain — and, on an earlier attempt, refused to start at all because no session was active. A workbench cannot exist outside a work envelope, and no amount of context changes that.

Schema validation. Fifty JSON Schema documents define what a record may be, thirty-six of them for governed delivery alone — covering role proposals, go-ahead decisions, gates, claims, decision traces, human review briefs, feedback cursors, and reconcile receipts. A record that does not validate does not get written. This is what makes evidence-bound decisions a structural property rather than a habit: the decision record has a required shape that includes what it was bound to.

Bound authorization. An approval is tied to the exact state it was granted against. If anything material changes after a person says yes, the approval expires and the work returns for review rather than proceeding on consent given for something else.

Anatomy of one primitive

Take Sessions — the primitive underneath everything else, and the one this document was itself written inside. A Session has four faces:

Each face is separately inspectable, and that is the property that makes the system auditable. You can read the route file to see what judgment was supposed to happen. You can run the command to see what mechanically occurs. You can open the record to see what actually resulted, attributed to a person and a time. When those three disagree, the disagreement is visible rather than buried in a transcript.

The catalogue

The same anatomy repeats across the domain model. Counting the domains by which layer owns them shows the split is drawn by need rather than convention.

The uniformity is the argument: this is the same shape roughly two dozen times, not two dozen features. A new domain is a route file plus a command surface plus a typed record — not a new architecture.

The asymmetry is the more interesting evidence. A clean one-to-one mapping between skills and commands would be consistent with cosmetic mirroring — a directory structure that looks governed. Instead the split tracks whether a domain actually needs judgment, mechanics, or both. design, prompting, training, and conversation are pure judgment with no deterministic state machine, because there is no exact lifecycle to enforce. whoami and update-workspace are pure mechanics with no judgment, because there is nothing to decide. That distribution is what a real ownership boundary looks like when it is drawn by need rather than by convention.

Predictable paths and typed records as the first context engine

Foundry’s first context engine was not a vector store. It was the combination of two properties. The first is predictable addressing: every record lives at an address that encodes who owns it and which domain it belongs to. A session is addressed by person and date; a task board by project and board; an artifact by project and artifact; a delivery by its run identifier. Nothing has to be searched for to be found.

The second is typed record contracts, where the structure encodes meaning and links. A session record declares its actor, its status, and the artifacts it produced. A task declares its status, its assignee, and the repositories it touches. An artifact manifest declares its owner and the tasks and sessions it came from. Each contract names its own relationships.

Known address plus known contract plus explicit references plus history gives a harness enough to locate the right state, interpret its contract, relate it to linked work, and act with provenance — reading with receipts rather than retrieving plausible-looking text.

This ordering is a deliberate architectural choice with a consequence worth stating: vector retrieval remains a rebuildable projection, never foundational. An index can be deleted and regenerated because the records are the truth. A system whose canonical knowledge lives in embeddings has no such recovery path, and no way to attribute a claim to a decision.

One traced example

This paper’s own production is a usable trace, because the work happened inside the system it describes.

A person said “let’s work on the Thoughtful Robots website.” The router resolved Foundry domain work and loaded the sessions and codebench route files. A gate refused to proceed — the workbench reported no active session, because it requires a work envelope to belong to. Starting a session created that envelope. The workbench then resolved the project’s verified Repo, cloned it to a session-scoped path on a session-named branch, rendered local config from a reviewed target contract, and allocated a port.

Two failures in that sequence are worth reporting, because they show the gates working rather than the happy path. The first: the reviewed target contract could not be validated, so the bench silently degraded to clone-only mode with no services. The cause was that the repository’s own dependencies were not installed — schema validation could not load. The second: the toolchain manager refused an untrusted configuration, and the bench reported a blocked repository with a named remedy rather than proceeding with an unverified toolchain.

Both are minor operational friction. Both are also the mechanism behaving correctly: an unverifiable contract produced reduced capability rather than assumed capability, and an untrusted toolchain produced a blocker with a remedy rather than a silent execution.

Why Git was the fastest credible governance kernel

Git was chosen not because all product work is code, but because its semantics were already legible to a harness, and because it supplied a governance kernel that would otherwise have had to be built. Five properties made it the fastest credible choice:

• Harness-legible — inspect, diff, test
• Attributable — history and provenance for free
• Isolated — bounded workspaces
• Reviewable — a native distinction between proposal and acceptance
• Recoverable — reconcile and revert

Every Foundry operation translates to one of its mechanisms:

The fourth row is the one that matters most. Human publication authority is not a policy sentence in a document that an agent is asked to respect — it is a protected branch. The agent’s authority stops at proposing.

The claim

A reader evaluating this architecture should ask whether the design is a governance model or a Git workflow with vocabulary on top. The claim is precise:

The substrate is replaceable. Candidates that could serve: an event log, a transactional database, an object store, a policy engine, a search or graph system. Each would demand real engineering, and the Challenges section is honest about how much.

The invariants are not replaceable. Six semantics must survive any substrate change:

1. Attributable revisions — every change traces to a person and a time
2. Bounded work envelopes — work happens somewhere with an owner and edges
3. Inspectable proposals — a proposed change is reviewable before it counts
4. Evidence-bound decisions — decisions carry the evidence that supported them
5. Human publication authority — people decide what becomes accepted state
6. Reconciliation and recovery — divergence resolves explicitly, and mistakes are recoverable

Each Git mechanism above maps to a governance semantic it currently supplies, and that mapping is the specification for any replacement: a different store is not enough, because the governance semantics are the product.

What a replacement must preserve

Stated as a mapping, the specification is concrete. Each mechanism on the left is a Git feature; each entry on the right is the governance semantic it currently supplies. A different store must supply the right-hand column, whatever it calls the left.

The emphasised row is the authority boundary, and it is the one a replacement is most likely to get wrong. Supply the other seven without it and you have built a well-audited system that can still publish without asking anyone.

What follows from this

First, the version of this argument that fails is the one that treats a data-store swap as the goal. Moving Foundry to Postgres while dropping the distinction between a proposal and an acceptance would produce something that stores the same records and is not a Foundry. Governance-light is the failure mode, not Git-dependence.

Second, and more useful in practice: Git can remain the code-delivery substrate without remaining the central product-work substrate. These are separable decisions. An organization that wants governed product work in a transactional system with policy-aware reads, while its engineers keep shipping code through pull requests, is describing a coherent target — not a contradiction.

Everything so far applies across an organization. This section takes one function and follows it all the way down, because engineering is where the stakes are highest and the existing controls are most explicit — which makes it the clearest test of whether the governance model actually holds.

The software development lifecycle was designed around human authorship. Every control in it — code review, branch protection, CI, sign-off, audit — assumes a person wrote the change and another person can ask them why. Introduce agents that write substantial code and those assumptions quietly stop holding, usually before anyone notices.

What breaks first

Three things fail in a predictable order, and none of them are about code quality.

• Intent detaches from the change. A pull request arrives with a plausible diff and no durable record of what it was supposed to do, what was ruled out, or which constraints were known at the time. Review becomes archaeology.
• Review capacity becomes the bottleneck. Agents generate changes faster than people can meaningfully review them. The organisation either slows to its review capacity or starts approving work nobody actually read — and the second failure is invisible until something breaks.
• Accountability blurs. When a change is part-human and part-agent, “who approved this” stops having a clean answer, which is exactly the question an incident review, an auditor, or a regulator will ask.

Foundry treats these as governance problems rather than tooling problems, and answers each one structurally.

Work is bound to intent before any code exists

A delivery does not begin with a prompt. It begins with a task that already carries acceptance criteria, and it freezes a baseline: the exact source commit, the accepted base it was taken from, the task revision, and the session that planned it. Everything the run later produces is bound to that frozen starting point.

This inverts the usual failure. Rather than reconstructing intent from a diff after the fact, the intent is a record that existed first — and if the task changes underneath the run, the binding is invalidated rather than silently carried forward.

Steered work happens in a workbench

Not all agent-assisted engineering should be unattended, and most of it is not. When a person is driving, Foundry opens a workbench: the project’s verified repositories cloned into a session-scoped workspace on a session-named branch, services running locally, and configuration rendered from a reviewed contract rather than copied from somebody’s machine.

Two constraints keep it inside the governance model. Scope stays within one project’s verified repositories, so a workbench cannot reach a repository the project never registered. And its publication authority stops at a draft pull request — approval, readiness, and merging stay human acts.

Verification is deliberately scoped too. A workbench runs the focused checks that map to what actually changed and refuses to expand an uncertain mapping into a full suite. Full verification belongs to CI, release, or publication — not to somebody’s inner loop, where a green run would mean less than it appears to.

Separated roles, not one autonomous agent

The unit of execution is not an agent with a task. It is a case with roles, and the constraints between them are what make the output reviewable at speed.

Underneath the table are three separations, and they are enforced rather than encouraged:

• Proposal is separate from authorization. The role that proposes a piece of work is never the role that approves it.
• Execution is separate from publication. The role that makes a change does not commit or publish it.
• Assessment is separate from acceptance. Criteria are frozen before the evidence arrives, so they cannot be reshaped to fit what was built.

The Verifier constraint is the one engineering leaders tend to recognise fastest. Acceptance criteria are frozen before the evidence arrives, so an assessment cannot be quietly reshaped to fit what was actually built. That is the difference between verification and rationalisation.

The agent’s authority stops at a draft pull request

Changes land in the target repository as ordinary branches and draft pull requests. Nothing merges itself. This matters more for adoption than it first appears: the existing SDLC keeps working unchanged. Branch protection still applies. CI still runs. Reviewers still review. Codeowners still gate. Foundry adds a governed lane into the review process rather than a parallel one around it.

Target repositories also keep their own conventions. A role is required to follow the repository’s existing instructions and patterns and to surface conflicts in its proposal, rather than importing a parallel convention system from Foundry. The repository stays the authority on how its code is written.

Evidence travels with the change

A reviewer opening one of these pull requests does not start from the diff. The run carries the frozen criteria and which of them were satisfied, the proposal that was authorized and the decision that authorized it, execution events and diagnostics, verification results with the tests that produced them, and every human gate with the person accountable for it.

This is the direct answer to the review-capacity problem. Review does not get faster by reading diffs faster; it gets faster when the reviewer can see what was intended, what was checked, and what remains uncertain — and can spend their attention on the judgment rather than the reconstruction.

Quality is recorded, never assumed

QA has three record types with deliberately different jobs. A Checklist says what may be verified. A Finding records what was actually observed. A Report is an optional fixed-scope sign-off, binding an exact set of checklist items to an exact set of builds.

The governance is visible in what the system refuses to assume on your behalf:

Treat every selected target/Item pair without an Assessment as not-tested; never infer pass. QA route file

A finding opens as a draft the moment an issue might exist, and stays non-actionable until a person completes it with an expected result, an actual result, and at least one inspectable piece of evidence. Findings bind to the build they were observed on and, once fixed, to the release that shipped the fix — so “fixed” is a statement about a specific build rather than a status change on a card.

A regression is a new finding pointing back at the closed one, never a reopened record. The original stays terminal against the release that closed it, which keeps the history of what shipped when inspectable rather than overwritten.

Feedback after completion is governed, not silent

Review comments arriving after a run completes do not reopen it invisibly. Re-entry is explicit: only feedback newer than the recorded cursor is picked up, it advances a numbered iteration, and free-text feedback is classified into a recorded steering decision rather than acted on directly. If the correction requires changing the frozen baseline, that needs a named human gate — a scope change cannot enter through a comment.

Attended and unattended work have different rules

The two modes above are kept deliberately distinct. Governed delivery runs are designed for low-attention work — the overnight or weekend kind — and starting one requires explicit confirmation every time. The system will not infer that a person has stepped away, or that now is a suitable moment to proceed unattended.

The distinction matters because the failure modes differ. Attended work fails visibly and a person corrects it. Unattended work fails quietly, which is why it carries the heavier governance: bound authorizations, independent verification, and a human completion gate.

Shipping stays an operator’s act

The lifecycle does not end at a merged pull request. A Release records the intent to ship an exact set of commits through a command the project itself declares, and every attempt made at it — each with its own actor, outcome, and log. A failed attempt stays visible rather than disappearing; it does not end the Release and does not consume a release number.

Two constraints matter here more than the mechanics. Foundry never holds deploy credentials, and it never infers that a release happened — it records what the command returned, or what a human ran and reported. And because a Release captures the exact commit of every linked repository at the moment it was cut, QA findings, retests, and reports bind to a specific build rather than to a moving branch. “Fixed in production” becomes a checkable statement.

What this looks like in practice

Four governed runs across three codebases produced pull requests in the normal way — one restoring a broken dependency and lint pipeline, one shipping a change across two repositories, one rebuilt after a sponsor rejected a technically valid implementation, and one correcting a backend defect with focused tests.

What was tested, and how

Foundry’s first product team was Foundry itself. The system was not finished and then tested; it was used to build itself while real client projects exposed what it needed to become. Foundation work — identity, projects, sessions, standups — took the first few days. After that, primitives were added in response to work rather than in anticipation of it: views and self-hosting, then a harness-mediated interface, then scheduled digests, and finally governed delivery, which arrived only days before the evidence boundary.

The system did not stop there. In the weeks after that boundary it gained steered workbenches, the whole QA model, releases, and the conversation and thread-starter layers — five further domains, all of which this paper has been describing.

At Thoughtful Robots this is not a pilot running on one team. Every member of the company works in it, in and out, every day — engineering, design, strategy, and client delivery alike. Sessions, standups, task boards, artifacts, QA, and delivery all run through the same system, which is why the evidence below covers artifact-heavy discovery and design-led client work as readily as it covers code.

This section is where the paper’s other claims should be tested, so it is specific rather than gestural.

Git coupling is real, and porting is engineering work

The system exposes no interface layer for its substrate. There is no provider abstraction, no adapter boundary, nothing a different store could be plugged into. At the code layer there is no substrate pluggability at all — and the coupling is not theoretical. Git is invoked directly throughout the codebase: session lifecycle, delivery execution, QA evidence, and workbench setup all reach for it by name. What started as a deliberate choice of substrate has become a real dependency on that substrate.

What remains true, and is the actual basis for the claim made earlier, is narrower. The domain record layer does not depend on Git to mean anything. Sessions, tasks, artifacts, and delivery records are plain, readable files that carry their own structure and their own links; Git is additive on top of them — versioning, attribution, review, recovery — and it enters through workflow commands rather than through the layer that interprets records. Record interpretation and Git invocation are separate concerns that currently sit side by side in the same modules, which is honest about both the separation and its incompleteness.

So the accurate statement is this: the data model is substrate-agnostic in shape, the invariants are named, and porting would be a real engineering project rather than a configuration change. Anyone evaluating the portability argument should treat it as a specification for work not yet done.

Identity and authorization

The same missing interface appears in identity, and it bites sooner. A Foundry person is a GitHub-backed profile, keyed by GitHub handle, and the current operator is resolved from an authenticated GitHub CLI or Git configuration. Authorization leans on GitHub as well: repository access decides who may act on a codebase, and branch protection is what actually enforces that publication takes a human.

That was a sound choice while the team using it was engineering-shaped. It is a bottleneck now that it is not. Someone in strategy or operations who works through the system every day still needs a GitHub account in order to exist in it at all — which sits awkwardly against the claim that this is a system for a whole organization.

And there is no pluggable interface layer for identity or authorization across the primitives. No provider boundary a corporate directory could sit behind. No policy layer that can express who may read which project, approve which gate, or publish which record. Authority is expressed per primitive, inside each domain’s own contract, rather than through one model that could be administered centrally or swapped out.

An enterprise deployment would need both: identity drawn from whatever directory the organization already runs, and an authorization model that scopes reads and approvals by domain rather than by repository access. Neither exists today. Both are the same shape of gap as the substrate one above — the semantics are worked out, the interface that would make them replaceable is not.

The gaps above define most of what follows. The order below is roughly the order in which these would have to close for this to be deployable inside a large organization.

Make the substrate replaceable in code, not only in principle

The invariant list in the Substrate section is a specification waiting for an implementation. The work is a provider boundary — one interface through which records are read, written, versioned, attributed, and reconciled — and then a second implementation behind it, because a boundary with only one implementation has never actually been tested. The honest proof is a Foundry running on something that is not Git while every invariant still holds.

Identity and authorization as interfaces

Identity should come from whatever directory an organization already runs, which means a provider boundary rather than a GitHub handle serving as a primary key. Authorization needs a model of its own: who may read which project, approve which gate, publish which record — expressed once and administered centrally, rather than stated per primitive and inherited from repository access.

Confidentiality at organizational scale

The small-team default — everything legible inside the Foundry — produced real leverage and does not transfer. A larger organization needs domain boundaries and policy-aware reads, selective disclosure that keeps provenance visible, authority-scoped synthesis, and audit that does not leak the context it is auditing. This is the read-side counterpart to authorization, and it is the largest single piece of work between here and enterprise adoption.

Measure the leverage

The evidence establishes viability, not advantage. The open question is whether governed human–agent work measurably outperforms the ungoverned kind — and answering it honestly requires a baseline, a comparison, and a willingness to publish a negative result.

Lower the cost of living in it

Clearer operator messages, less setup friction, design-native participation, and richer retrieval over the same records — so that governance is ambient rather than something people work around. Durable underneath, lightweight in use.

The harness became the interface to product work without bringing an organization with it. Foundry is the connected system that closes that gap, and its contract is five properties — durable, connected, coordinated, governed, adaptive — stated without reference to any storage mechanism.

Those properties are implemented by two layers with a committed boundary: skills carry judgment, code carries mechanics, and a committed record states which owns what, line by line, for anyone who wants to check. The domain model repeats one shape across roughly two dozen primitives, each with a spoken intent, an owning skill, a command surface, and a typed record at a predictable address. Predictable addressing and typed contracts — not embeddings — are the foundation, which is why every retrieval layer above them stays rebuildable.

Git supplies the substrate because its semantics were already legible to a harness and it delivered a governance kernel for free: attribution, isolation, the distinction between proposal and acceptance, and recovery. The evidence that this holds up is a system used to build itself, worked in daily by every member of the company across engineering, design, strategy, and client delivery, and carrying governed deliveries — including one where a technically valid build was correctly overruled by its human sponsor. That is evidence of viability and breadth, not of measured advantage, and this paper does not pretend otherwise.

Which returns to the claim this document is named for. Git is this system’s first substrate, not its definition. The invariants — attributable revisions, bounded envelopes, inspectable proposals, evidence-bound decisions, human publication authority, reconciliation and recovery — are what must survive any move, and they are named precisely enough to serve as a specification for a replacement. There is no adapter today and porting would be real work; the Challenges section says so plainly.

Every primitive Foundry models today. Each has a predictable address, a typed contract, and an owning skill, a command surface, or both. A handful of record types fall outside that line — client organizations and proposals live in one project’s own conventions, validated by the checker but with no skill or command of their own — and they are deliberately not listed as primitives here.

Identity and structure

Work envelopes

Execution context

Coordination

Governed delivery

Quality

Outputs