From layers to a release
The same path as the live manager: layers, a package, Release with its labelled links, then its states.
The factory ontology
A software company, as a model.
One typed model of what a software company does, from planning a product to retiring it, written so that AI agents and people can work from the same picture.
- definitions in the four locked layers
- 9,034
- decisions, each with who decides
- 414
- automatic checks on every change
- 19
Numbers as of 16 October 2026, read from the ontology's source files.
The film
The ontology in three minutes.
Silent. How it is built, the manager, a year of sample data and the tool mappings.
The problem
Agents can write code. They cannot run a software company.
Not without a shared model of the company around the code: what a release is, who approves it, and which steps need a person.
No shared picture
Each tool has its own idea of a release, an incident or an approval.
Rules live in prose
Who decides, and when a person must agree, sits in wikis and in people's heads.
Nothing to check against
Without a model, nobody can test whether an agent did the right thing.
Pull requestMerge requestChange listDeployReleaseRolloutApprovalSign-offReviewIncidentOutagePage
The idea
Agents do about 90 percent of the work. People do about 10.
People give the intent and answer four kinds of question. Agents do the rest, and record why for every decision they take. Both read the same model.
People
Intent and the four stops
The ontology
One model, read by both
Agents
Plan and design
Agents
Build, review, merge
Agents
Release and run
The split
Agents, about 90%People, about 10%
A target, not a measurement. The sample company runs at 98.5 percent agents today, which is too high.
The four stops: the only times a person is asked
- Kill switchStop everything.
- A change that cannot be undoneIn production.
- More power for agentsOr a weaker control on them.
- A binding commitmentMoney, contracts, regulators.
The ontology
Six layers, each built on the one below.
The four core layers are locked and change only by proposal. Tools and company rules sit above them and never edit them.
Rules for a context
Company or country rules. They only make rules stricter.
11profilesTools and methods
One package per tool, cloud or method, mapped onto the core.
40 mapped 44 discovered
84packagesDepartments
40 packs, from billing and legal to incidents.
5,910definitionsSoftware engineering
Releases, code changes, deployments, incidents.
1,320definitionsAny company
People, organisations, agreements, money, risk.
1,569definitionsBuilding blocks
The kinds: object, link, action, decision, state machine, policy.
235definitions
How it is built and kept correct
Source
One YAML file per package, in git. The only thing anyone edits; everything else is generated.
19 checks
Automatic gates across files. Every state has a way out; every stop can be checked by a machine.
An independent reader
A fresh model reads only the generated documents and answers set questions. A separate model scores it.
Lock
Then the layer is locked. A breaking change fails unless the owner decides it.
The manager
One map you zoom.
Layer, then package, then type, then its states. Never more than a handful of things at once. The live manager is behind sign-in, so these are recordings and screenshots.
The ontology map
The home page: six layers and what builds on what.
Release states
Planned to live. Amber steps may need a person, with the condition printed beside them.
A decision, written down
Promote to production: what it aims at, what it must respect, and what could change the answer.
Who decides
The owner must always agree on 46, only under a stated condition on 149, never on 219.
The whole map
Everything at once, zoomed like a city. Search flies to any type.
Model checks
What the automatic gates found, layer by layer.
Screenshots taken on 15 October 2026. Counts inside them can trail the numbers on this page, which are read from the source files.
Proof
Tested three ways: by readers, by a sample company, by industry standards.
A fresh reader must understand it
An agent with no context reads only the generated documents and answers questions written beforehand. A separate agent scores the answers. A layer is locked only after it passes.
Pass mark 80 percent. When a question's expected answer was itself wrong and the reader followed the source, it counts as correct (layer 1: 1, layer 2: 2, rules: 2).
Animation from an earlier run. The numbers below are the latest.
Simulated, not a real company
Harbourline: a made-up company, run for a year
45 people and 216 agents over 12 months. Every record went through the model's own actions, state changes and links. When the model could not express something, the generator logged a gap.
- records
- 1,372,181
- events
- 265,165
- links
- 118,497
- releases
- 143
- deployments
- 844
- incidents
- 235
- times a person answered a stop
- 2,780
- blocking gaps
- 0
119 gaps were logged in the latest run (1 major, 118 minor), none blocking. A second, tiny company ran beside it, and the one deliberate attempt to link records across the two was refused. Volumes come from a random walk, not real rates, so treat them as a test, not a forecast.
8 industry standards fit the kernel
A slice of each standard's core model was written using only the building blocks and the enterprise core. Every probe is met natively. The first run found one gap, FHIR's choice of types, and the kernel gained one base type for it.
Any tool stack
Tools map onto the model. Then the map is tested.
The model never names a tool. Each tool, cloud or method gets a package built from its own published schema, mapping its words to the model's.
Pull request
GitHub
Merge request
GitLab
Code change
One term in the model
84
tool, cloud and method packages
- 40 mappedEvery row reviewed; an independent reviewer samples rows each round.
- 44 discoveredGenerated from the schema, not yet reviewed.
Read from the package registry of 2026-10-16.
The testing pyramid, cheapest first
A mapping climbs only when the tier below it passes.
- Planned
Capped sandbox
Create, check and delete in a real account with a spending cap.
- Planned
Real cloud, look-only
List and describe with a read-only identity; never change anything.
The real product, locally
Self-hosted products, a local Kubernetes cluster and a cloud emulator.
231 of 235checks passed, 0 failed, 4 unclear, 7 packagesOffline
Every mapping against the tool's published schema and real documents.
887 of 919checks passed, 7 failed, 25 unclear, 19 packages
Animation from an earlier run. The numbers beside it are the latest.
Honest status
What is real today, and what is not.
The model, the manager and the sample data are real. The agents that will run on the model, and the factory core around it, are specified or planned, not built.
Built
- Four core layers, frozen and locked
- 11 rule profiles
- The ontology manager (behind sign-in)
- A sample company, run for a year through the model
- 40 tool packages mapped and reviewed
- Tool tests offline and on real products run locally
In progress
- The other 44 tool packages
- A query service for agents: graph, meaning, rules and time (specified, not built)
- Look-only tests against real clouds
- Proposals from tool packages, waiting for review
Planned
- The decision engine and workflow engine
- The factory core, written in Go
- Agents doing real work on the model
- Tenants beyond our own
About
Built by Venkat.
Venkatesan Ramachandran designs and directs the factory: the research, the decisions and the reviews. Claude Code writes every line, under those decisions and the checks shown above.
LinkedIn link: to be added
CV link: to be added