content(positioning): speak the ontology below the hero — capability pages, home, glossary, llms.txt, the AI-native cluster

content/glossary/en/metadata-driven-development.ts

@@ -9,6 +9,7 @@ const term = {
   definition:
     'Metadata-driven development builds an application by declaring its objects, fields, permissions, workflows, actions, and APIs as typed metadata that a runtime executes directly, instead of writing the code that implements them — a distinction that becomes decisive once an AI agent is doing the writing, because the declaration is small enough for a human to review and the runtime, not the generated code, is what enforces the rules.',
   explanation: [
+    'A note on lineage: until October 2026 this was the term that defined the product on this site. The product is now defined by the executable business ontology — see the Ontology entry in this glossary, and the related terms below. Metadata-driven development remains the method by which that ontology is written: the definition is typed metadata, and when an AI agent writes it, the metadata is what a person reviews. The page stays because it is linked to and searched for; the definition below is unchanged.',
     'The idea is not new, and pretending otherwise is the fastest way to be misread. Enterprise platforms have been describing applications as declarations rather than code since the mid-2000s, and the vocabulary comes from that lineage: objects instead of tables, permission sets instead of authorization middleware, flows instead of job scripts. What that generation established is worth keeping — a field added to a definition appears in the API, the list view, the detail form, the export, and the permission model at once, because all of them are derived from the same declaration rather than kept in sync by hand.',
     'What has changed is who writes the declaration. When a human authored it through a point-and-click console, the payoff was speed and consistency, and the format could afford to be a proprietary XML dialect nobody read directly. When an AI agent authors it, the format itself becomes the constraint that decides whether the output is trustworthy: a complete business application expressed as metadata is a few thousand lines rather than a few hundred thousand, so an agent can hold the whole system in one context window instead of sampling a codebase it cannot see the edges of, and the human reviewing the change reads a diff of declarations — which fields moved, which permission changed, which step now requires approval — rather than auditing a generated controller, template, migration, and test.',
     'Stated bare, the term collapses into the low-code reading and loses the argument, so it is worth being precise about the difference. A drag-and-drop builder optimizes for a person who does not want to write code; metadata-driven development in this sense optimizes for a reviewer who did not write the code and must sign off on it anyway. Those produce different formats. The first can hide the definition behind a UI, because the UI is the interface. The second cannot: the definition has to be a readable, version-controlled, diffable file, because a diff is the review surface and an agent — not a form — is the thing writing it.',
@@ -20,6 +21,7 @@ const term = {
     'declarative application development',
   ],
   relatedTerms: [
+    'ontology',
     'application-metadata',
     'typed-metadata',
     'application-definition-vs-runtime',

content/glossary/en/ontology-projection.ts

@@ -0,0 +1,29 @@
+import type { GlossaryTerm } from '../../../src/glossary/types';
+
+const term = {
+  slug: 'ontology-projection',
+  term: 'Ontology projection',
+  title: 'Ontology Projection: Views, Dashboards, Apps, and Translations Derived from the Ontology',
+  description:
+    'An ontology projection is a view, dashboard, app, or translation derived from an executable business ontology — authored as metadata and validated by the same gate, but not part of the ontology, so the core changes and the projections follow.',
+  definition:
+    'An ontology projection is a view, dashboard, app, or translation derived from an executable business ontology — authored as metadata and validated by the same gate, but not part of the ontology itself, so that changing the core changes the projection while removing a projection leaves the business it showed unchanged.',
+  explanation: [
+    'The ontology is the definition of the business the runtime runs: objects and fields, relations, actions, permissions, flows, and agent and tool definitions. Everything a person looks at is a projection of it. A list view projects an object\'s fields and permissions onto a grid; a dashboard projects queries over objects onto charts; an app groups objects, views, and actions into a navigable product; a translation projects every label into a locale. The projection is real metadata — authored, typed, validated, and reviewed like the rest — but it describes how the business is shown, not what the business is.',
+    'The test for telling core from projection is what happens when you delete it. Remove a kanban view and the cases, their owners, and who may edit them are exactly as they were; remove the permission that scoped the kanban and the business has changed. That is why the distinction bounds what an agent must hold to reason about a business: the core, not every screen. It also decides what a reviewer reads: a diff that touches only projections changes presentation, and a diff that touches the core changes authority.',
+    'Two things are not projections, though they are often mistaken for them. Actions are part of the ontology: they define what may be done to a record and under which conditions, and an agent calls them as tools. Permissions are part of the ontology: a view is shaped by them; it does not define them. Code is not a projection either — hooks, action bodies, CEL expressions, and constrained JSX run inside the runtime, under the same permission and audit fence as everything derived from the ontology.',
+  ],
+  alsoKnownAs: ['projection', 'view projection', 'projection of the ontology'],
+  relatedTerms: [
+    'ontology',
+    'application-metadata',
+    'typed-metadata',
+    'definition-layer',
+    'reviewable-diff',
+    'object-type-and-action-type',
+  ],
+  articleSlugs: ['what-does-the-ontology-is-the-software-mean'],
+  pageSlugs: ['app-ui'],
+} satisfies GlossaryTerm;
+
+export default term;

content/glossary/en/ontology.ts

@@ -3,19 +3,20 @@ import type { GlossaryTerm } from '../../../src/glossary/types';
 const term = {
   slug: 'ontology',
   term: 'Ontology',
-  title: 'Ontology in Enterprise Software: Definition, and Who Owns Yours',
+  title: 'Ontology in Enterprise Software: The Executable Business Ontology, and Who Owns Yours',
   description:
-    'An ontology is a formal model of a business domain — its classes, properties, and relationships — expressed so software and AI agents can reason about the business instead of about raw tables.',
+    'An executable business ontology is the definition of a business that a runtime runs — objects and fields, relations, actions, permissions, flows, and agent and tool definitions — validated, not reasoned over.',
   definition:
-    'An ontology, in the enterprise sense, is a formal model of a business domain — the classes of things the business deals with, the properties that describe them, and the relationships that connect them — expressed in a machine-readable form so that software, and now AI agents, can reason about the business rather than about raw tables.',
+    'An ontology, in the sense ObjectStack uses, is an executable business ontology: the definition of a business — its objects and fields, relations, actions, permissions, flows, and agent and tool definitions — written as typed metadata that a runtime validates and then runs, so that software and AI agents operate the business through that one definition rather than through raw tables.',
   explanation: [
-    'The word comes from philosophy and arrives in enterprise software through knowledge engineering, but the working definition is narrow and useful: an ontology names the types (customer, work order, device), the properties each type carries, and the links between them, once, for the whole organization. That is what separates it from a database schema. A schema describes how one application stores its rows; an ontology describes what the business means by "customer" in a way that a dozen systems, a reporting tool, and a model can all resolve the same way. Palantir Foundry is what most people picture in 2026, and its modelling quality is genuinely high; Microsoft Fabric IQ and Google\'s enterprise knowledge graph are moving into the same layer.',
+    'The ontology is the software. In ObjectStack the ontology is not a layer inside a hosted platform: it is the application\'s own definition — objects and fields, relations, actions, permissions, flows, and agent and tool definitions — and the runtime runs it, deriving the database, the REST API, the screens, and the MCP tools from it and enforcing permissions and audit on every call. Four boundaries come with the word. It is executable, not a knowledge-representation ontology: no inheritance, no axioms, no reasoner — the definition is validated, then run. It is not a semantic layer over your existing systems: it is the system, and federating an external datasource is read-only by default and early. Views, dashboards, apps, and translations are projections of the ontology, not part of it. And code does not disappear: it moves into the runtime, as hooks, action bodies, CEL, and constrained JSX.',
+    'The word comes from philosophy and arrives in enterprise software through knowledge engineering, where it means a formal model of a domain — its classes, properties, and relationships — that software can reason about. That working sense is narrow and useful: an ontology names the types (customer, work order, device), the properties each type carries, and the links between them, once, for the whole organization, which is what separates it from a database schema. A schema describes how one application stores its rows; an ontology describes what the business means by "customer" in a way that a dozen systems, a reporting tool, and a model can all resolve the same way. Palantir Foundry is what most people picture in 2026, and its modelling quality is genuinely high; Microsoft Fabric IQ and Google\'s enterprise knowledge graph are moving into the same layer.',
     'Most ontology work stops one step short of where the risk begins. A retrieval-grade ontology is a read model: it makes an agent articulate about the business and says nothing about what happens when the agent has to change something. The capability that completes it is the declared, permission-checked write operation — the action — together with the permission and audit rules attached to the same definition. Palantir deserves credit for funnelling writes through governed actions for years; the open question was never whether that design is right.',
-    'The open question is who holds the file. In ObjectStack the ontology is not a layer inside a hosted platform: it is the application\'s own definition — its objects and fields, relations, actions, permissions, flows, and agent and tool definitions — and the runtime runs it. That definition is your business ontology: open, versioned, and yours, in your own repository, not code scattered across a framework and not a graph held inside a vendor\'s system. Views, dashboards, apps, and translations are projections of it, not part of it; code does not disappear, it moves into the runtime as hooks, action bodies, CEL, and constrained JSX. A definition you can read, diff, and move to another host is a different asset from an equally good definition that lives inside a vendor\'s engine and migrates by rebuild. The slogan this reduces to is the one the ObjectStack README opens with: The ontology is the software.',
-    'The boundary matters as much as the claim. ObjectStack\'s ontology is executable, not a knowledge-representation ontology: no inheritance, no axioms, no reasoner — it is validated, then run. It is not a semantic layer over your existing systems either; federating an external datasource is read-only by default and early. And an ontology does not make an AI agent correct: modelling a business well remains slow, contested, human work that no format shortcuts. What the format decides is narrower — whether the result is small enough for an agent to hold whole, strict enough to reject the agent\'s mistakes at authoring time, and portable enough to survive the platform it was first written on.',
+    'The open question is who holds the file. In ObjectStack the definition is your business ontology: open, versioned, and yours, in your own repository, not code scattered across a framework and not a graph held inside a vendor\'s system. A definition you can read, diff, and move to another host is a different asset from an equally good definition that lives inside a vendor\'s engine and migrates by rebuild. An ontology does not make an AI agent correct: modelling a business well remains slow, contested, human work that no format shortcuts. What the format decides is narrower — whether the result is small enough for an agent to hold whole, strict enough to reject the agent\'s mistakes at authoring time, and portable enough to survive the platform it was first written on.',
   ],
-  alsoKnownAs: ['enterprise ontology', 'business ontology', 'domain ontology'],
+  alsoKnownAs: ['executable business ontology', 'business ontology', 'enterprise ontology', 'domain ontology'],
   relatedTerms: [
+    'ontology-projection',
     'semantic-layer',
     'knowledge-graph',
     'object-type-and-action-type',
@@ -25,13 +26,14 @@ const term = {
     'governed-runtime',
   ],
   articleSlugs: [
+    'what-does-the-ontology-is-the-software-mean',
     'ai-ontology-open-protocol',
     'enterprise-ontology-race-open-vs-closed',
     'ontology-vs-semantic-layer-vs-knowledge-graph',
     'enterprise-ontology-platform-comparison',
     'objectos-action-tools',
   ],
-  pageSlugs: ['data-modeling', 'platform', 'ai'],
+  pageSlugs: ['ontology', 'compare', 'data-modeling', 'app-ui', 'permissions', 'mcp', 'agent-developer', 'platform', 'ai'],
 } satisfies GlossaryTerm;
 
 export default term;

content/glossary/zh-Hans/metadata-driven-development.ts

@@ -9,13 +9,15 @@ const term = {
   definition:
     '元数据驱动开发把一个应用的对象、字段、权限、流程、动作和 API 声明为类型化元数据、交由运行时直接执行，而不是去写实现这些东西的代码——当作者变成 AI Agent 之后，这个区别开始起决定作用：声明足够小，人能真正读完并签字，而且真正在执行规则的是运行时，不是生成出来的那堆代码。',
   explanation: [
+    '沿革说明：在 2026 年 10 月之前，本站用这个词来定义产品。现在定义产品的是可执行的业务本体——见本术语表的「本体（Ontology）」词条，以及下方的相关术语。元数据驱动开发仍然是写出那份本体的方法：定义是类型化元数据，而当作者是 AI Agent 时，人审阅的正是这份元数据。这一页保留下来，是因为它已有外部链接和搜索流量；下面的定义未变。',
     '这个想法并不新，装作它很新是最快被误读的方式。企业级平台从 2000 年代中期就开始用「声明而非代码」来描述应用，今天这套词汇正是从那条脉络来的：用对象而不是表，用权限集而不是鉴权中间件，用流程而不是定时脚本。那一代人立住的东西值得保留——在定义里加一个字段，API、列表视图、详情表单、导出和权限模型会同时出现它，因为这些都是从同一条声明推导出来的，而不是靠人手工保持一致。',
     '真正变了的，是谁在写这份声明。当声明由人在可视化控制台里点出来时，收益是速度和一致性，格式本身可以是一种没人直接阅读的私有 XML 方言。当声明由 AI Agent 编写时，格式本身就变成了决定产出可不可信的约束：一个完整业务应用用元数据表达是几千行而不是几十万行，Agent 可以在一个上下文窗口里装下整个系统，而不是对着一个看不到边界的代码库抽样阅读；而审阅这次改动的人读到的是一份声明的 diff——哪个字段动了、哪条权限变了、哪一步现在需要审批——而不是去审计生成出来的控制器、模板、迁移脚本和测试。',
     '这个词一旦裸着说出来，就会塌回低代码的那种读法，并且直接输掉论证，所以差别值得说清楚。拖拽式搭建器优化的是「不想写代码的人」；这里说的元数据驱动开发优化的是「不是我写的、但要我签字的审阅者」。这两件事会长出不同的格式。前者可以把定义藏在界面背后，因为界面就是入口。后者不行：定义必须是一份可读、进版本库、能 diff 的文件——因为 diff 就是审阅面，而写它的是 Agent，不是一张表单。',
     '它并不适合所有工作，说明这一点不是自谦。本质是算法的问题——定价优化、路径规划、解析器——不会因为被「声明」出来就变小或变安全；它们该被写成代码，然后由定义去调用。这套方法诚实的失败形态是表达力天花板：当声明面表达不了某个需求时，团队就会去找逃生舱口，而逃生舱口的代码一多，系统就退回原点——逻辑落在了运行时管不到、审阅者也看不见的地方。',
   ],
   alsoKnownAs: ['元数据驱动的应用开发', '元数据驱动架构', '声明式应用开发'],
   relatedTerms: [
+    'ontology',
     'application-metadata',
     'typed-metadata',
     'application-definition-vs-runtime',