A single business rule rarely lives in one place. The code enforces it, a spreadsheet or admin screen lists who it applies to, and a policy document explains why it exists. Today those are separate files, owned by different people, kept in sync by hand. This post asks what would change if they were one thing. It starts with a small example.
Picture a future version of your development tool. Your team builds a collaboration app, and you are changing who can invite guests into a workspace. You ask the tool to show that rule in TypeScript. A security reviewer asks the same tool for a permissions matrix. The team lead opens the access policy that explains who gets access and why.
The three of you are working on one proposed change. You tighten a condition in the TypeScript. The security reviewer flips a cell in the matrix. The team lead comments on a paragraph of the policy. The tool recognizes that all three contributions touch the same rule, flags that your condition and the reviewer’s cell now disagree, and lists what has to be verified before anyone can accept the change.
None of those three views is the source. Underneath them sits a representation written for machines rather than people, and every human-readable language is rendered from it on demand.
In Designing Version Control for the AI SDLC, I proposed a repository that connects intent, context, implementation, verification, and review, with source code still at the center. This post asks what happens if source code becomes one of the views. It is a design hypothesis, and the idea has a long history of failing in instructive ways, which I get to below.
One rule, four ways
Today the path is intent → source code → execution, and adding an agent leaves it intact: the agent writes the source. The alternative is intent → versioned semantic model → validated implementation → execution, where the semantic model is a structured record of rules, interfaces, and dependencies, and human-readable views are rendered from it at every step.
For the guest-invitation rule, the underlying object might look like this. The notation is made up; what matters is what it keeps together.
rule workspace.invite-guest (rev 41)
actor role in [owner]
action invite(guest) on workspace
expiry UNRESOLVED (open question)
source policy/access 3.2 (rev 38)
checks tests/invite-guest/* (pass)From that object, a tool could render an executable view:
// Rendered from workspace.invite-guest, rev 41. Executable.
export function canInviteGuest(actor: Member, workspace: Workspace): boolean {
return actor.workspaceId === workspace.id && actor.role === 'owner';
}A permissions matrix for the security reviewer:
| Role | Can invite guests |
|---|---|
| Owner | Yes |
| Member | No |
| Guest | No |
And a policy sentence for the team lead:
Workspace owners may invite guests. How long guest access lasts has not yet been decided.
Two things separate this from a codebase with good documentation. The views cannot drift apart silently, because each is generated from, and labeled with, the same revision. And the open question about expiry lives inside the rule, where most repositories would leave it in a chat thread.
This goes further than designing a programming language for agents. Such a language could still have readable source files and a compiler. A canonical representation underneath code, prose, and diagrams changes what the repository treats as the source. Progress on agent-friendly languages makes that worth exploring without showing that it works.
It is also unlikely to be one format. Fast execution, compact storage, model processing, verification, and human review pull in different directions, so a family of representations connected by explicit transformations is more plausible than one universal syntax.
Code becomes an interface
Different questions call for different views:
| Human question | Useful view |
|---|---|
| How is access checked? | Executable logic in a supported programming language |
| Who can view or edit a workspace? | Permissions matrix with exceptions |
| Where does workspace data travel? | Data-flow diagram with trust boundaries |
| How do people request access? | Access policy and an approval procedure |
| What changed since approval? | Rule changes, affected artifacts, and verification evidence |
Python, TypeScript, SQL, English, and diagrams would still matter, as interfaces rather than storage. Collaboration would feel familiar from Google Docs (coauthoring, comments, suggested edits, history), except that it carries across representations. A comment on the policy sentence above would stay attached to workspace.invite-guest when an engineer opens it as TypeScript. An agent could propose matching updates to the tests and the policy in the same change, with attribution showing who requested, generated, edited, and approved each part.
Certifying what nobody reads
Changing the system is only half of what people do with views. The other half is vouching for it. A security lead signs off on who can access customer data. An auditor collects evidence for a compliance report. A privacy reviewer confirms where personal data travels. A regulator may ask to see how a rule is enforced.
In a codebase, those people can at least in principle read the thing that runs. If the canonical form is written for machines, they cannot. The projection becomes the only way a human can certify the system, so every signature lands on a view while the model underneath is what executes.
Without discipline, that produces a system that explains itself convincingly while showing something other than what will run, and then collects signatures on the explanation. A view someone certifies needs at least four properties:
- Bound to a revision. The sign-off attaches to a specific revision of the model and a specific version of the renderer. Any later change to either marks the certification as stale instead of silently carrying it forward.
- Rendered, not written. The certified matrix comes from a deterministic, tested transformation, so re-rendering the same revision produces the same view. A language model can write an explanation next to it, but the explanation is commentary and nobody signs it.
- Honest about coverage. A TypeScript rendering may be executable or merely illustrative. The matrix above says who can invite guests and nothing about how long they stay. Each view states what it covers and omits, and unresolved questions appear in it instead of disappearing.
- Checkable by someone else. An auditor should be able to re-render the view from the same revision with an independent tool, and run the checks derived from it against the implementation. Evidence that the implementation matches the certified behavior has to exist outside the view itself.
Not everything should be rendered, though. The access policy is both a rule and a document: section 3.2 can be structured and feed the matrix, but the surrounding prose, which a lawyer may have approved word by word, has to stay authoritative in its original form. The same holds for reports and architecture decisions, where reproducing the facts does not reproduce the author’s meaning. The repository needs room for approved wording and unformalized information next to the structured model, and every generated view must respect access to the objects it draws on.
This is also where a machine-first representation could beat source code. Today an audit often rests on policy documents, configuration exports, and sampled evidence, with the code itself rarely read in full. If the policy, the matrix, and the implementation are renderings of one revision, the certification can cover the thing that actually runs.
Editing the view is the hard part
The appealing loop is short:
Artifact → human-readable view → human edit → proposed artifact change → validation.
Suppose the team lead edits the policy sentence from “Workspace owners may invite guests” to “Team members may invite guests.” What should change in the rule’s actor line?
- Does “team members” include contractors, if the system gives them the member role?
- Can guests invite other guests?
- Does a guest lose access when the person who invited them leaves?
A tool that quietly picks an answer turns an ambiguous sentence into an apparently precise business rule. It should record the edit, propose an interpretation, and keep the questions open, next to the expiry question, until someone with authority answers them.
Structured views help: a matrix cell maps cleanly onto the actor list, a rewritten paragraph does not. Edits with a defined mapping can apply directly; everything else becomes a proposal, with the original edit kept. Concurrency adds a second layer. When the matrix and the TypeScript are edited at once, the tool reconciles both against the underlying rule, including edits that look unrelated on screen but contradict each other, and a view rendered from an older revision says so before accepting an edit.
workspace.invite-guestThe rule as the underlying, versioned object.- TypeScript
- Permissions matrix
- Policy sentence
- Defined mappingApplies directlyA matrix cell maps cleanly onto the
actorlist. - No defined mappingBecomes a proposalA rewritten paragraph gets a proposed interpretation, and its questions stay open until someone with authority answers them.
Concurrent editsReconciled against the underlying rule. A view rendered from an older revision says so before accepting an edit.
Three properties seem essential:
- Opening and saving an unchanged view preserves the artifact’s meaning.
- An accepted edit identifies the objects it changes and leaves unrelated information intact.
- Ambiguous edits and conflicting concurrent changes stay visible until someone resolves them.
“Bidirectional compilation” is a fair name for the ambition. The name does not make arbitrary translations reversible.
This has been tried before
A canonical model with editable projections is an old idea, and its history is mostly about the editing problem above.
| Precedent | The idea | What happened |
|---|---|---|
| Round-trip engineering | UML tools around 2000 generated code from models and tried to sync hand edits back. | Edits the model could not express were fenced off or lost, and in many teams the diagrams stopped being updated. |
| Intentional programming | Charles Simonyi spent two decades, at Microsoft and then Intentional Software, on storing programs as trees of intent projected into whatever notation suited the reader. | Microsoft acquired the company in 2017; the approach never went mainstream. |
| Projectional editors | JetBrains MPS lets developers edit the syntax tree directly through projected notations. | It works, mostly for domain-specific languages, though editing a tree feels unlike typing text. |
| Content-addressed code | Unison stores definitions as hashed syntax trees, with names as metadata. | A non-file canonical form that works, within one language. |
| The view update problem | Database research in the early 1980s showed that updating tables through a view is ambiguous whenever the view discards information. | Later work on bidirectional transformations (lenses) described when a round trip is well behaved. An English summary of a rule is exactly such a view. |
What has changed: every earlier system needed a hand-written mapping from each view back to the model, and edits outside it were rejected or lost. A language model can read an arbitrary edit and propose what it means, which makes the loop usable for prose and diagrams for the first time.
It also moves the failure. The old systems could not express some edits. A model-backed system will express nearly every edit, confidently, sometimes wrongly. That is why the three properties above, and the insistence on keeping interpretations as reviewable proposals, carry most of the design.
| Earlier systems | A model-backed system | |
|---|---|---|
| Mapping from a view to the model | Hand-written for each view | A language model reads an arbitrary edit and proposes what it means |
| Edits outside the mapping | Rejected or lost | Expressed, so the loop becomes usable for prose and diagrams |
| How it fails | Could not express some edits | Expresses nearly every edit, confidently, sometimes wrongly |
Version control, and the task with it
Git is a reasonable foundation. It already models history as snapshots of a filesystem rather than a list of per-file changes. Built on it, an artifact repository would give rules, documents, tasks, and verification records stable identities and explicit links, with ordinary file diffs still available underneath. I sketched that object model in the earlier post; three things change when code is one view among several.
Conflicts can span representations. One branch lets guests in immediately. Another adds an administrator approval step in the service. The text merges cleanly, yet the behavior and the policy now disagree. Because the policy is a versioned object in the same merge, a tool can flag that when the relationship is modeled. It cannot promise to find every semantic conflict, and passing tests are evidence only for the cases they test.
Approval is part of history. A commit would keep the object revisions, the discussion that resolved disagreements, the evidence, and the sign-off on that exact change. Regenerating an explanation later with a different model must not rewrite what someone approved. A shared working revision, where people and agents explore alternatives, stays separate from the accepted revision that reaches production: editing a spreadsheet cell never changes behavior on its own.
The task becomes an object too. The AI-Executable Ticket argued that explicit intent, scope, and validation make work easier to delegate. Here a task, such as “Enable external collaborators with administrator approval”, would be a versioned object linked to the exact revisions it depends on, with a board or backlog as one more view of it. That buys three things:
- Stale context is visible. The task points at revision 38 of the access policy, so when the policy moves on mid-work the repository notices, and nobody silently applies a new interpretation to work already approved.
- Authority stays explicit. Delegating implementation to an agent does not delegate the right to change constraints or approve a release, and changing the intended outcome creates a new revision, so old evidence cannot quietly count toward the new goal.
- “Done” gets precise. Generated, verified, approved, released, and observed to achieve the intended result are five different claims. The task records which one was accepted, and on what evidence.
What exists today
As of September 2026, several projects cover parts of this. The table draws on their own recent announcements and reports, not on hands-on evaluation, and reading them as steps toward this repository is my inference.
| Project | What it contributes | Not shown by the cited source |
|---|---|---|
| Kiro (May 12, 2026) | Spec-driven workflow; requirements analysis that combines LLMs and automated reasoning to find ambiguity | Lossless editing between a specification and arbitrary code |
| Entire (April 6, 2026) | Checkpoints: a versioned unit linking code to the agent context that produced it | A behavioral model spanning documents and code |
| Claude Artifacts (June 18, 2026) | Shareable pages with version history and view, comment, and edit permissions | Semantic consistency across code, spreadsheets, and prose |
| AILANG (June 2, 2026) | A language for AI authorship: explicit effects, structured errors, SMT-checked contracts | Independent evidence; its gains over Python come from the project’s own benchmark |
| Vero (September 2026) | Agents writing code and proofs across Lean 4 repositories; 27 of 43 instances fully solved | Whether the specification captures what a person meant |
Each covers a piece. None of the sources describes a system that combines them.
So who is the language for?
The canonical form would be for machines. Most people would never read it directly, much as few engineers ever open a Git object file.
Everything a person decides or certifies would still happen in a human language: the TypeScript a reviewer challenges, the matrix a security lead signs off, the policy sentence a lawyer approves, the evidence an auditor accepts. Those stop being the storage and become the only places where human judgment can reach the system.
Whether that works depends on two things nobody has shown. A view has to be faithful enough to sign, so that certifying the matrix means certifying what runs. And an edit in a human view has to come back into the model with its meaning intact, or as an open question when it cannot. Until a tool does both, source code stays the source.