Ontologies for Everyone

The next serious computer is not a chatbot. It is an owned object graph.

That sounds abstract until you ask what a person, family, school, firm, or city actually needs from AI. They do not only need answers. They need a computer that can maintain a world: people, documents, sources, decisions, obligations, permissions, evidence, drafts, corrections, versions, publications, and histories of why things changed.

Memory is not enough. A memory system remembers summaries of what happened. An object graph owns the objects themselves: the document, the source, the child’s assignment, the contract, the claim, the revision, the permission, the teacher note, the team memo, the customer request, the publication, the rollback point.

The difference matters because AI makes the old software categories too weak. A family does not need one more app. A firm does not need one more workspace. A school does not need one more dashboard. They need a substrate where their world can be represented without surrendering it to someone else’s platform.

Call it an ontology substrate.

Not ontology in the academic sense of arguing over perfect categories forever. Ontology in the operational sense: what objects exist here, who owns them, who may see them, what changed them, what they cite, what they imply, what may be published, and what must remain private.

Choir is an attempt to build that substrate.

The owned learning loop

A chatbot learns, if at all, by compressing interaction into memory. That is useful, but it is not ownership.

An owned learning loop needs more than memory. It needs:

• artifacts;
• versions;
• source records;
• corrections;
• evidence;
• permissions;
• private context;
• public projections;
• publication history;
• verifier records;
• rollback points;
• durable identities for things in the world.

A chatbot remembers by summarizing. An owned computer learns by changing its graph.

That is the core architectural claim. The productive unit is not the prompt. The productive unit is the persistent object and its edges: this draft cites this source; this child can use this capability; this employee published this memo upward; this team accepted this revision; this enterprise published this artifact outward; this public claim has this provenance; this route points to this immutable version.

The graph is not decoration. It is the system’s memory, policy, provenance, and publication surface in one substrate.

Why the object graph beats memory-over-exhaust

The AI industry keeps trying to solve continuity with larger context windows, longer chat histories, vector search, and summarization. Those are useful techniques, but they do not answer the ownership question.

A memory-over-exhaust system says: produce a lot of interaction exhaust, then ask another model to remember the important parts.

An object-graph system says: make the important parts first-class objects.

A school permission slip is not a memory. A contract clause is not a memory. A source citation is not a memory. A child’s boundary is not a memory. A customer’s inbound proposal is not a memory. A publication route is not a memory. A team-level decision is not a memory.

They are objects with identity, policy, provenance, and consequences.

That is why the object graph matters. It prevents life from dissolving into chat exhaust.

Transclusion is composition, not copying

The missing word is transclusion.

Transclusion is what turns separate private graphs into a composed institution without flattening them into one shared database. A team graph does not become powerful because everyone copies documents into a team folder. It becomes powerful because it can transclude the relevant objects, histories, sources, and revisions from its members' graphs under policy.

An enterprise graph is not a static warehouse of approved artifacts. It is a composition of user graphs, team graphs, department graphs, and platform graphs. Each lower-level graph keeps its own ownership boundary and history. The enterprise graph sees the selected transclusions: not merely one exported object, but the living versioned object as it has been made publishable at that boundary.

That means publication is not just “freeze a version and upload it.” A frozen version matters: it gives auditability, rollback, citation, and legal finality. But the point of transclusion is that the published object can carry its version history and update path. When the source graph advances through an approved revision, the higher-level graph can receive the update automatically, with provenance still attached, because the relationship is not a pasted copy. It is a maintained transclusion.

The receiving graph can still pin a version when it needs stability. A policy memo, contract, compliance artifact, school record, or public claim may need immutable citation. But pinning is a policy choice, not the essence of publication. The essence is governed composition: this higher-level graph includes that lower-level object, with this history, this policy, this update behavior, and this provenance.

That is how an enterprise keeps the provenance of work. The team does not merely know the latest approved answer. It can know how the answer got there: which employee graph proposed it, which team graph revised it, which source objects it cited, which reviews accepted it, which versions were superseded, which public artifact currently transcludes it, and which downstream objects update when it changes. When a published artifact is a transclusion rather than a pasted copy, approved updates can publish forward automatically while carrying the history that explains why the update is legitimate.

Without transclusion, the object graph becomes static knowledge management. With transclusion, it becomes living institutional memory.

Invalidation and recall

Live transclusion has a danger that static export does not have. A copied artifact goes stale. A transcluded artifact can fail live. If a lower graph is compromised, corrupted, or wrong, automatic propagation becomes a supply-chain attack inside the institution.

That is why update semantics need a twin: invalidation semantics.

A source can be retracted. A memo can depend on a false premise. A child’s publication can turn out to have crossed a boundary. A public claim can be wrong. In each case, the answer is not merely to publish a newer version and hope downstream readers notice. The graph needs a recall path.

Recall does not mean erasing history. It means publishing an invalidation object into the same graph relation that carried the original transclusion. The downstream graph should be able to know:

• which upstream object or version was invalidated;
• who invalidated it, under what authority, and why;
• which downstream objects transcluded, cited, summarized, or acted on it;
• whether those downstream objects should be blocked, marked stale, re-run, re-reviewed, or legally preserved;
• which external publications or agent-facing routes need correction notices;
• which humans or agents relied on the earlier version.

This is where provenance becomes more than prestige metadata. The point of provenance is the unhappy path. If the graph knows how a claim traveled, it can also know how a correction, retraction, or safety recall must travel.

So the publication gate has a twin. The gate decides what may move upward. The recall decides what must move back down, sideways, or outward when the upstream object loses validity.

A serious transclusion system therefore needs at least four propagation modes: update, pin, deprecate, and invalidate.

Update says: this source advanced through the relevant gate; downstream live transclusions may advance.

Pin says: this downstream object intentionally remains bound to an older version for citation, legal, or historical reasons.

Deprecate says: this object is superseded, but not false.

Invalidate says: this object should no longer be relied on without an explicit override.

That is the difference between a living institution and a rumor network with better software.

Palantir, context graphs, and the decision layer

This is also why Palantir matters as a precedent. Palantir understood early that enterprise AI is not primarily about a better chat interface. It is about an ontology: operational objects, permissions, workflows, decisions, and actions connected closely enough that software can reason over the institution. Palantir is the clearest public proof that large organizations will pay for an ontology layer when the stakes are high enough.

Jaya Gupta and Ashu Garg’s Foundation Capital essay, AI’s trillion-dollar opportunity: Context graphs, names the next version of the same problem. Their point is that enterprise agents do not merely need access to Salesforce, Workday, SAP, Zendesk, Slack, Pager​Duty, and policy documents. They need the decision traces those systems usually fail to capture: exceptions, approvals, precedents, conflict resolutions, agent runs, “why” links, and the cross-system context that made an action legitimate. They call the accumulated structure a context graph.

That is right, but it is still incomplete if the context graph becomes one more vendor-owned enterprise layer. The hard question is not only whether the firm can build a system of record for decisions. It is who owns that system, how it composes with user and team graphs, whether its objects can carry version history through publication, and whether provenance survives when artifacts update.

A context graph says: capture the decision trace.

A transclusive object graph says: capture the decision trace as a versioned object relation that can move through the institution without becoming detached from its source history.

That distinction is the difference between enterprise AI as another centralized control plane and enterprise AI as owned institutional capital.

Enterprises: user computers, team computers, firm computers

An enterprise should not be one giant shared chatbot.

A serious enterprise AI platform needs many computers at different scopes:

• one VM per employee;
• team-level VMs for shared projects;
• department-level VMs for recurring functions;
• enterprise-level VMs for firm-wide memory, policy, publication, governance, and external interface;
• special-purpose VMs for legal, finance, sales, research, compliance, support, recruiting, and operations.

Each VM owns its own object graph. An employee’s graph contains private drafts, notes, preferences, local workflows, source material, and agent runs. A team graph contains shared documents, decisions, task state, project memory, evidence, proposals, and accepted artifacts. The enterprise graph contains policy, official publications, customer-facing material, institutional memory, approved procedures, public claims, and governance records.

But the enterprise graph is not merely another graph above the others. It is the composition of them.

This is not a hierarchy of chat rooms. It is a hierarchy of owned ontologies connected by transclusion.

The employee can publish up to the team. The team can publish up to the enterprise. The enterprise can publish outward to the public or to partner/customer graphs. At each step, the receiving graph does not need to ingest the sender’s whole private state. It transcludes the selected object neighborhood: the object, its approved version history, its source edges, its review state, its provenance, and its update policy.

Publication is the key word, but publication should not be understood as static export. The employee does not dump a private computer into the team computer. The team does not dump its whole working graph into the enterprise graph. The enterprise does not expose its internal graph to the world. Each level publishes selected transclusions upward through gates.

Publish up, do not leak sideways

The right primitive is not sharing. Sharing is too vague. The right primitive is publication.

Publication means:

• choose an object or object neighborhood;
• declare whether the receiver gets a pinned version, a live transclusion, or both;
• carry the version history needed for provenance;
• attach policy;
• attach review or consent;
• preserve citations and transclusions;
• define update behavior;
• expose only the selected projection;
• keep private state private.

An employee publishes a memo upward to a team. The team receives a maintained artifact with provenance, not the employee’s whole context. A team publishes a product brief upward to the enterprise. The enterprise receives an approved transclusion, not every argument that happened inside the team. The enterprise publishes a public page, API response, agent-inbound description, support document, or research artifact outward. The world receives a route to a versioned object whose provenance and update history can be preserved without exposing the firm’s private graph.

This is how the object graph preserves alpha.

The private graph compounds. The higher-level graph composes selected histories. The public graph receives governed transclusions.

The difference is decisive. A copied artifact goes stale unless somebody republishes it manually. A transcluded artifact can update when its source graph advances through the relevant gate. The downstream object keeps the provenance because it did not lose the upstream history.

What the gate must verify

“Attach review or consent” is not a decorative checkbox. The gate is where private belief becomes shared state. It is where lies, slop, hallucinations, compromised agents, and adversarial inbound artifacts try to enter the composed graph.

A receiving graph should not trust a publication merely because the sender says it is publishable. The gate needs verifier records: structured evidence that the object passed the checks appropriate to its consequence.

For a low-stakes family note, that may mean explicit consent and a simple boundary check. For a school assignment, it may mean source requirements, plagiarism checks, teacher review, and parent-visible publication scope. For an enterprise policy, it may mean authority, legal review, source lineage, diff review, approval quorum, expiry date, and rollback plan. For public agentic inbound, it may mean schema validation, identity, rate limits, reputation, sandbox execution, provenance requirements, and refusal rules.

The membrane metaphor only works if the membrane rejects. A publication gate should be able to say no, ask for more evidence, route to human review, accept only a pinned version, accept the object but not its update stream, or accept the transclusion while marking its confidence and revocation conditions.

Verifier records are therefore first-class graph objects, not logs. They answer: who checked this, what was checked, against which policy, with which evidence, at which version, producing which permission.

Without that mechanism, publication turns the graph into a slop amplifier. With it, publication becomes the institution’s way of saying: this object is now allowed to matter here.

Enterprise-to-global publication

The global layer matters because agentic inbound is coming.

Today a public website is mostly a human-facing surface. Tomorrow it is also an agent-facing surface. Customers, suppliers, auditors, journalists, regulators, partners, and software agents will arrive asking:

• What do you sell?
• What changed?
• What is your policy?
• What is the latest version?
• What are the constraints?
• What can my agent do here?
• Which claims are official?
• Which objects can be cited?
• Which proposals can be submitted?
• Which workflows accept inbound artifacts?

A normal website is weak at this because it is page-shaped. An object graph can publish routes, artifacts, policies, source records, proposals, attestations, schemas, and capability boundaries.

An enterprise can therefore run its own Choir platform internally, then publish a selected enterprise graph outward. That public graph is not a marketing site. It is an institutional interface for humans and agents.

Agentic inbound requires this. If every inbound agent arrives through email or form-fill, the enterprise drowns. If inbound agents can target public graph objects, submit proposals, cite versions, follow policies, and receive capability-bounded replies, the enterprise has a real interface.

The enterprise graph becomes a membrane: porous enough to accept outside intelligence, structured enough not to dissolve.

Households need ontologies too

The same substrate matters at household scale.

A household is already an institution. It has bills, calendars, documents, medical records, school records, family photos, chores, shopping, subscriptions, legal obligations, insurance, travel, eldercare, childcare, dietary restrictions, values, budgets, devices, media, and private histories.

Today those objects are scattered across apps and platforms. The household has no owned ontology of itself.

That is why the consumer AI product is not just a better assistant. The real product is a household computer: a private graph that knows what the household is, what it owns, what it owes, what it believes, what it allows, what it wants to keep private, and what it is willing to publish or share.

For adults, that looks like a virtual family office. For children, it looks like bounded capability.

Thin graphs pool through transclusion

The obvious objection is volume. A household does not generate enough decisions to become Bridgewater. A single family’s judgment stream is too thin for the loop to compound at institutional scale.

Transclusion is the answer. Thin graphs do not need to become giant platforms individually. They can pool selected objects into shared graphs while keeping ownership intact. A household can publish a school artifact into a classroom graph, a medical experience into a patient community, a local hazard into a neighborhood graph, a purchasing pattern into a cooperative, or a civic complaint into a city service graph.

The shared graph gets volume. The household keeps its boundary.

That is the co-op structure AI needs. The lab’s scale advantage comes from centralizing everyone’s exhaust. A transclusive graph lets many small owners create shared judgment volume without surrendering their whole context. The shared graph learns from selected, policy-governed objects; the private graph retains the state that makes the household intelligible to itself.

That is how “ontologies for everyone” becomes more than a slogan. Individual graphs are thin. Composed graphs are thick. Transclusion is the mechanism that lets thickness emerge without ownership transfer.

Children: bounded capability without invasive surveillance

Children should not be given either an unbounded internet agent or a surveillance cage.

An object-graph household computer gives a better option.

A child can have a personal VM with capabilities appropriate to age, maturity, school context, and family values. The child’s computer can help with writing, research, scheduling, creative projects, coding, language learning, music, reading, and communication. But its capabilities are bounded by graph policy:

• which sources it can access;
• which contacts it can message;
• which purchases it can propose but not execute;
• which apps it can use;
• which hours or contexts change permissions;
• which topics require adult review;
• which publications go to family, class, school, or public;
• which private journals remain private;
• which safety events trigger escalation.

This is not screen-time control with AI glued on. It is capability design.

The parent does not need to watch every keystroke. The system can expose supervision at the right abstraction level:

• what capabilities were used;
• what objects were published or proposed;
• what sources were cited;
• what safety gates were hit;
• what spending or communication requests need review;
• what school artifacts were submitted;
• what the child chose to share.

That is non-invasive supervision: oversight of boundaries, publications, and exceptions rather than total surveillance of interior thought.

The child gets a real computer. The parent gets accountable capability boundaries.

Schools: student, classroom, school, district

Schools have the same multi-level ontology problem as enterprises, but with different stakes.

A student has a graph. A classroom has a graph. A teacher has a graph. A school has a graph. A district has a graph.

Student-level graphs can hold assignments, drafts, feedback, accommodations, sources, projects, reading history, portfolios, and personal learning context. Classroom graphs can hold shared materials, discussions, rubrics, group projects, teacher notes, and published class artifacts. School graphs can hold policies, calendars, safety procedures, parent communications, curriculum maps, and public pages.

The publication ladder matters:

• a student publishes an assignment to a teacher;
• a group publishes a project to a class;
• a class publishes selected work to the school;
• a school publishes public artifacts to families or the district;
• the district publishes policies and official records outward.

Again, the private graph does not leak. Publication gates carry selected transclusions upward, and recall paths carry invalidations back through the dependency graph when a published object should no longer be relied on.

That gives schools AI without turning education into surveillance. The institution can support students with bounded agents, evidence-rich feedback, source-aware writing, and parent-visible milestones while preserving zones of privacy and growth.

The general pattern

The pattern is the same everywhere:

private graph -> scoped transclusion -> higher-level composition -> public/global projection

Publication is the gate. Transclusion is the relation. Composition is the result.

For an enterprise:

employee VM -> team VM -> enterprise platform -> global graph

For a household:

child VM -> family graph -> school/family publication -> public projection if appropriate

For a school:

student graph -> classroom graph -> school graph -> district/public graph

For a city:

resident/service graphs -> agency graphs -> city graph -> public civic graph

For media:

reporter graph -> desk graph -> publication graph -> public article graph

This is why Choir is not only a writing tool, news tool, or agent runtime. Those are applications. The deeper substrate is graph-governed computation: private computers that can publish selected state into larger computers.

Ontologies for everyone

Large organizations already have ontologies, whether or not they call them that. They have CRMs, ERPs, HR systems, ticketing systems, document stores, permission systems, policy systems, compliance systems, analytics warehouses, and publishing systems. The problem is that these ontologies are fragmented and mostly not agent-native.

Ordinary people have ontologies too. A family has roles, permissions, obligations, histories, schedules, needs, exceptions, traditions, projects, and boundaries. A child has a developmental ontology. A classroom has one. A neighborhood has one. A small business has one.

AI makes those ontologies operational.

If the ontology is owned by a platform, the user rents intelligence inside someone else’s world model. If the ontology is owned by the user, household, school, or enterprise, AI becomes automatic capital: a machine that compounds around owned state.

That is the difference between an AI assistant and an automatic institution.

The automatic newspaper was only the first proof

The automatic newspaper is the easiest public proof because publication makes the graph visible. Sources become citations. Claims become artifacts. Revisions become history. Routes become public pages. Feedback becomes signal. Editorial stance becomes a machine.

But the same substrate applies elsewhere.

The household computer is an automatic family office. The school computer is an automatic learning institution. The enterprise computer is an automatic operating institution. The public graph is an automatic interface for humans and agents.

The common need is not “more AI.”

The common need is owned structure.

What exists, what is needed

This essay is not a claim that every one of these semantics is already complete in Choir. The audited voice matters most here because this is the essay that only an implementation can cash.

What exists now is the direction of travel: Choir’s current object-graph work is already about durable objects, edges, publication artifacts, source lineage, versions, policies, verifier records, and graph-native publication surfaces. The automatic newspaper is the visible proof because its public artifacts already make sources, claims, revisions, routes, and publication history inspectable.

What is still needed is the full discipline described above: transclusion as the default relation between user, team, enterprise, and public graphs; explicit update, pin, deprecate, and invalidate semantics; verifier records that gates can actually enforce; recall propagation through downstream dependencies; and operator surfaces that make those states visible instead of burying them in logs.

So read this as architecture, not marketing. The existing system proves the substrate is plausible. The remaining work is to make every important publication and transclusion auditable enough that the graph can say not only what it believes, but why it believes it, who allowed it to travel, and what happens when it must be corrected.

The architecture in one sentence

Choir is a system of private object graphs that learn locally, transclude upward, and publish selectively.

That sentence contains the whole politics of the architecture.

Private object graphs: ownership, context, boundaries, and compounding.

Learn locally: corrections and artifacts improve the computer without requiring surrender to a central model lab or SaaS memory layer.

Transclude upward: higher-level graphs compose lower-level graphs by maintaining governed relationships to selected objects and their histories.

Publish selectively: knowledge can travel upward and outward as governed artifacts rather than leaked exhaust.

That is the substrate families need. It is the substrate schools need. It is the substrate enterprises need. It is the substrate public AI needs if agentic inbound is going to become something better than spam with tools.

The future is not one global chatbot.

It is many owned computers, each with its own graph, publishing into larger graphs without surrendering the state that makes it intelligent.