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

[objectstack-fleet]

Fixes #233

What changed

The card's four sections, in the route it suggests (§3 definitions → §1 capability pages → §4 cluster → §2 home and chrome). en and zh-Hans are authored; zh-Hant is derived at render time — the glossary, marketing-page, home and cluster registries all run s2t on the zh-Hans copy, and gen:zh-hant writes blog posts only — so this PR adds no generated file (none to hand-edit, none to regenerate; the tree is clean after pnpm build).

§3 Definitions

• content/glossary/{en,zh-Hans}/ontology.ts: title, description and definition lead with the executable business ontology; the first explanation paragraph opens with T1 and carries the four boundaries (no inheritance, axioms or reasoner; not the semantic layer; views, dashboards, apps and translations are projections; code moves into the runtime); the knowledge-engineering lineage becomes the second paragraph; the third is unchanged; the fourth keeps the ownership argument. alsoKnownAs gains "executable business ontology", relatedTerms gains ontology-projection, articleSlugs gains the definitional post, pageSlugs lists the capability pages that now name the ontology.
• New term content/glossary/{en,zh-Hans}/ontology-projection.ts. Measured before adding: terms are discovered by the eager glob in src/glossary/registry.ts, keyed on slug = filename — no registry edit; content:lint now checks 46 terms (44 on base). Its one cited article is the definitional post, which is the only post using "projection" in this sense (the MCP post's "projection" is the tool-surface sense).
• content/glossary/{en,zh-Hans}/metadata-driven-development.ts (ruled): page and URL kept; a lineage note is the first explanation paragraph and points at the Ontology entry; ontology is added first in relatedTerms so the cross-link card renders (explanation paragraphs render as plain text in GlossaryTermPage.astro, so the pointer is by name plus the related-terms link). Definition and the four original paragraphs unchanged.
• src/pages/llms.txt.ts Core Definitions (ruled): "Metadata driven development with an AI as the author" is replaced by "Executable business ontology"; the list stays at three. The "Open business ontology" entry keeps the ownership claim and hands the four boundaries to the new entry (its last sentence moved, not lost).

§1 Capability pages (en + zh-Hans)

Each page names the ontology where it already proves the promise; where a promise is quoted it is positioning.ts wording (p.t3[1], p.t3[2]), never a paraphrase.

• mcp.ts — Agent-operable: the lead and the "What the AI gets" copy; the tools derive from the ontology.
• data-modeling.ts — the core: the lead ("those objects, their fields, and the relations between them are the core of your business ontology"), the artifact eyebrow, the modeling-section copy.
• app-ui.ts — projections: the lead, the artifact title, the first section's eyebrow and copy ("change the objects and the screens follow; remove a screen and the business it showed is unchanged"). The old artifact title said the view "is part of the reviewable definition", which the projection boundary contradicts; it now says projection — and still a reviewable diff.
• permissions.ts — the shared fence: the lead and the AI-safety copy.
• agent-developer.ts — AI-writable: the lead names the ontology and quotes p.t3[1]; workflow step 2 becomes "Write the ontology" and names core versus projections.

§4 The ai-native-app-platform cluster

• src/lib/clusters.ts: slug and URL unchanged, no redirect. The title is the query plus the answer; shortTitle — the home strip and the footer label in every locale — is "Executable business ontology"; lead, definition, whyNow, capabilities (the four promises in README order), useCases and the three FAQs are rewritten; articleSlugs gains the definitional post. clusters.ts is loaded by content:lint under plain Node and may hold type imports only, so it cannot read positioning.ts; it states the framing in prose and does not restate T1–T4 or the descriptor.
• src/lib/cluster-i18n.ts: the cluster's name in the six template locales (ko keeps a final consonant so the templates' 이/은 particles stay right); the zh-Hans template's description, lead, definition and low-code FAQ answer re-derived. The template is one body per locale shared by all five clusters (noindexed, canonical to en), so those four zh-Hans/zh-Hant sentences change on the other four cluster pages too. The ja/de/es/fr/ko templates are untouched: their sentences carry no "AI-native" and are outside the authored locales.

§2 Home below the fold and site chrome

• src/lib/home.ts: imageNoteTitle is now t2Lead(positioning[locale].t2) — T2's first sentence, "One executable business ontology" / 「一份可执行的业务本体」 and the five other locales' equivalents — in all seven authored locales (zh-Hant derived), so it cannot drift from the canonical line; capabilities[2] title ("Write the ontology, not app code") with the en and zh-Hans copy, title only in ja/de/es/fr/ko; insightsTitle ("Practical thinking on AI-written software"), which also titles the blog index through src/pages/[lang]/blog/index.astro. The three strings are the whole of this file's change.
• src/lib/terms.ts: zh-Hans topic/role descriptions re-derived; ja/de/es/fr/ko aligned with the en wording already on main ("executable business ontologies", "AI-written business applications"); the hand-kept zh-Hant block is removed and zh-Hant is derived by s2t from zh-Hans — what the file's own header promised ("never hand-maintain a third copy"). Verified in dist/zh-Hant/blog/topics/*.

Measurements (origin/main 6ada491 → this branch 42648e1)

reading	before	after
ontolog per en page: mcp / data-modeling / app-ui / permissions / agent-developer (positive control: forward-deployed-engineers)	0 / 0 / 0 / 0 / 0 (11)	2 / 3 / 4 / 1 / 3 (11)
src/lib/home.ts: the three strings; lines with "AI-native"	3; 7	0; 0
src/lib/terms.ts: lines with "AI-native" or a locale form	14	0
content/glossary/en/ontology.ts:6-8 leads with the generic knowledge-engineering definition	yes	no — the executable business ontology
src/pages/llms.txt.ts Core Definitions: the MDD entry / "Executable business ontology"	1 / 0	0 / 1
src/lib/clusters.ts: "AI-native" / "low-code", case-insensitive	15 / 7	9 / 7 — the 9 are the slug, the title, the description, the lead, one FAQ question, and the article slug low-code-vs-ai-native-app-platform in four clusters' lists
src/lib/cluster-i18n.ts: "AI-native" / "low-code", case-insensitive (the card read 7 / 8; I read 7 / 6 in Latin spelling, 12 with the CJK forms)	7 / 6	1 (the map key, i.e. the slug) / 6

Before → after

Every changed sentence, by file and current line; "−" is origin/main 6ada491, "+" is this branch. Angle brackets in two TypeScript generics are respelled as ‹ › so the GitHub sanitizer leaves them alone.

content/pages/en/mcp.ts

:15
· 1 sentence unchanged
− The ObjectStack runtime generates governed tools from metadata instead: whatever your model — Claude, Cursor, or something fully local — it works through the same permissions, approvals, and audit as your people.

• ObjectStack generates governed tools from the ontology instead — ${p.t3[2]} is one of its four promises: the objects your definition declares and the actions it exposes become MCP tools, called under the signed-in user’s own permissions, approvals, and audit, whatever your model — Claude, Cursor, or something fully local.
  · 1 sentence unchanged

:49
− Because tools derive from the same metadata that defines the application, the AI sees real objects, real relationships, and real actions — not a raw database dump.

• Because the tools derive from the ontology that defines the application, the AI sees real objects, real relationships, and real actions — not a raw database dump.

content/pages/en/data-modeling.ts

:12
· 1 sentence unchanged
− On the open-source ObjectStack runtime that is one compact object definition — tables, migrations, the query engine, and REST endpoints are supplied by the runtime.

• Those objects, their fields, and the relations between them are the core of your business ontology, and on the open-source ObjectStack runtime that core is one compact definition — tables, migrations, the query engine, and REST endpoints are supplied by the runtime.
  · 1 sentence unchanged

:21
− eyebrow: 'The model is the source',

• eyebrow: 'The ontology is the source',

:62
− Definitions stay close to how the business talks: customers, plans, renewals.

• The ontology stays close to how the business talks: customers, plans, renewals.
  · 1 sentence unchanged

content/pages/en/app-ui.ts

:12
· 1 sentence unchanged
− On the open-source ObjectStack runtime that is one view definition — rendered per user, live as records change, and adjustable in the view designer without touching a file.

• On the open-source ObjectStack runtime that is one view definition — a projection of the ontology, not part of it — rendered per user, live as records change, and adjustable in the view designer without touching a file.
  · 1 sentence unchanged

:22
− title: 'The view is part of the reviewable definition.',

• title: 'The view is a projection of the ontology — and still a reviewable diff.',

:61
− eyebrow: 'Rendered from metadata', ⏎ title: 'The workbench, surface by surface', ⏎ copy: ⏎ 'Typed fields carry their own widgets and formatting, so generated screens look and behave consistently without a design-system project.',

• eyebrow: 'Projections of the ontology', ⏎ title: 'The workbench, surface by surface', ⏎ copy: ⏎ 'Views, dashboards, apps, and translations are projections of the ontology, not part of it: change the objects and the screens follow; remove a screen and the business it showed is unchanged. Typed fields carry their own widgets and formatting, so the projections look and behave consistently without a design-system project.',

content/pages/en/permissions.ts

:12
· 1 sentence unchanged
− On the ObjectStack runtime that boundary is one reviewable definition — enforced on every query, API call, and AI tool call, whether the agent is your own over MCP or ObjectOS’s in-app AI.

• On the ObjectStack runtime that boundary is part of the ontology itself — permissions are declared beside the objects they protect, not in a second policy system — and it is the one fence people and agents share: enforced on every query, API call, and AI tool call, whether the agent is your own over MCP or ObjectOS’s in-app AI.

:111
· 1 sentence unchanged
− The ObjectStack runtime never does: every agent action runs as the signed-in user who asked for it.

• The ObjectStack runtime never does: every agent action runs as the signed-in user who asked for it, inside the same fence as that user.

content/pages/en/agent-developer.ts

:15
− ${p.t2} The agent is the writer and you are the reviewer: the scaffolder writes an AGENTS.md so the agent starts with the protocol’s rules loaded, Strict TypeScript, Zod schemas, and os validate reject invalid output before it reaches the runtime, and the whole app stays small enough for AI to hold whole.

• ${p.t2} The ontology is what the agent writes — ${p.t3[1]}, in the README’s four promises — and you are the reviewer: the scaffolder writes an AGENTS.md so the agent starts with the protocol’s rules loaded, Strict TypeScript, Zod schemas, and os validate reject invalid output before it reaches the runtime, and the whole app stays small enough for AI to hold whole.

:54
· 1 sentence unchanged
− Generate metadata', ⏎ body: 'The agent edits object, view, workflow, action, dashboard, translation, and tool definitions as Strict TypeScript rather than generating app glue code.',

• Write the ontology', ⏎ body: 'The agent edits the ontology — objects and fields, relations, actions, permissions, flows, and tool definitions — and its projections — views, dashboards, translations — as Strict TypeScript rather than generating app glue code.',

content/pages/zh-Hans/mcp.ts

:15
· 1 sentence unchanged
− ObjectStack 运行时则直接从元数据生成受治理工具：无论你的模型是 Claude、Cursor 还是完全本地的模型，它都走和员工一样的权限、审批与审计。

• ObjectStack 则直接从本体生成受治理工具——${p.t3[2]}是它的四个承诺之一：你的定义声明的对象、它暴露的动作成为 MCP 工具，以登录用户自己的权限、审批与审计被调用，无论你的模型是 Claude、Cursor 还是完全本地的模型。
  · 1 sentence unchanged

:49
− 因为工具派生自定义应用的同一份元数据，AI 看到的是真实的对象、真实的关系、真实的动作——而不是一堆裸数据库表。

• 因为工具派生自定义这个应用的那份本体，AI 看到的是真实的对象、真实的关系、真实的动作——而不是一堆裸数据库表。

content/pages/zh-Hans/data-modeling.ts

:12
· 1 sentence unchanged
− 在开源 ObjectStack 运行时上，这就是一份紧凑的对象定义——表、迁移、查询引擎和 REST 端点由运行时供给；你的 Agent 能写它，你的团队能在对象设计器里逐字段微调它，而在 ObjectOS 上，产品内 AI Builder 能从一句描述起草出同样的对象与字段。

• 这些对象、它们的字段，以及它们之间的关系，就是你的业务本体的核心；在开源 ObjectStack 运行时上，这个核心就是一份紧凑的定义——表、迁移、查询引擎和 REST 端点由运行时供给；你的 Agent 能写它，你的团队能在对象设计器里逐字段微调它，而在 ObjectOS 上，产品内 AI Builder 能从一句描述起草出同样的对象与字段。

:21
− eyebrow: '模型即源码',

• eyebrow: '本体即源码',

:62
− 定义贴着业务的说法走：客户、套餐、续约。没有 ORM 类，没有散落各处的 schema 文件——下面每一步都停留在同一份定义里。

• 本体贴着业务的说法走：客户、套餐、续约。没有 ORM 类，没有散落各处的 schema 文件——下面每一步都停留在同一份定义里。

content/pages/zh-Hans/app-ui.ts

:12
· 1 sentence unchanged
− 在开源 ObjectStack 运行时上这是一份视图定义——按用户渲染、随记录实时变化，还能在视图设计器里调整，不碰一个文件。

• 在开源 ObjectStack 运行时上这是一份视图定义——本体的投影，而不是本体的一部分——按用户渲染、随记录实时变化，还能在视图设计器里调整，不碰一个文件。
  · 1 sentence unchanged

:22
− title: '视图是可审阅定义的一部分。',

• title: '视图是本体的投影——同时仍是一份可审阅的 diff。',

:61
− eyebrow: '从元数据渲染', ⏎ title: '把工作台一个面一个面看过去', ⏎ copy: ⏎ '类型化字段自带控件与格式，生成的界面外观行为天然一致——不需要先做一个设计系统项目。',

• eyebrow: '本体的投影', ⏎ title: '把工作台一个面一个面看过去', ⏎ copy: ⏎ '视图、仪表盘、应用和翻译是本体的投影，不是本体的一部分：改对象，界面跟着变；删掉一个界面，它所展示的业务原封不动。类型化字段自带控件与格式，投影出来的界面外观行为天然一致——不需要先做一个设计系统项目。',

content/pages/zh-Hans/permissions.ts

:12
· 1 sentence unchanged
− 在 ObjectStack 运行时上，这套边界是一份可审阅的定义——在每一次查询、API 调用和 AI 工具调用上强制执行，无论 Agent 是你自己经 MCP 接入的，还是 ObjectOS 的产品内 AI。

• 在 ObjectStack 运行时上，这套边界就是本体的一部分——权限声明在它所保护的对象旁边，而不是另一套策略系统——也是人和 Agent 共用的同一道围栏：在每一次查询、API 调用和 AI 工具调用上强制执行，无论 Agent 是你自己经 MCP 接入的，还是 ObjectOS 的产品内 AI。

:111
− 失去 AI 控制最快的方式就是给它超级用户权限。ObjectStack 运行时从不这么做：每个 Agent 动作都以发起它的登录用户身份执行。

• 失去 AI 控制最快的方式就是给它超级用户权限。ObjectStack 运行时从不这么做：每个 Agent 动作都以发起它的登录用户身份执行，待在和这个用户同一道围栏里。

content/pages/zh-Hans/agent-developer.ts

:15
− ${p.t2}Agent 是作者，你是审阅者：脚手架写入 AGENTS.md，让 Agent 一开始就带着协议规则；Strict TypeScript、Zod schema 与 os validate 会在无效输出进入运行时前将其拒掉；整个应用小到 AI 能整体装下。

• ${p.t2}Agent 写的就是本体——四个承诺里的「${p.t3[1]}」——你是审阅者：脚手架写入 AGENTS.md，让 Agent 一开始就带着协议规则；Strict TypeScript、Zod schema 与 os validate 会在无效输出进入运行时前将其拒掉；整个应用小到 AI 能整体装下。

:54
− title: '2. 生成元数据', ⏎ body: 'Agent 以 Strict TypeScript 编辑对象、视图、流程、动作、仪表盘、翻译与工具定义，而不是生成应用胶水代码。',

• title: '2. 编写本体', ⏎ body: 'Agent 以 Strict TypeScript 编辑本体——对象与字段、关系、动作、权限、流程与工具定义——及其投影——视图、仪表盘、翻译——而不是生成应用胶水代码。',

src/lib/home.ts

:10
− const sentenceCase = (s: string): string =› s.charAt(0).toUpperCase() + s.slice(1);

• const sentenceCase = (s: string): string =› s.charAt(0).toUpperCase() + s.slice(1); ⏎ // The media note under the hero image is titled with T2's first sentence — ⏎ // "One executable business ontology" in each locale — read from positioning ⏎ // rather than spelled here, so it cannot drift from the canonical line. ⏎ const t2Lead = (t2: string): string =› t2.split(/(?‹=[.。])\s*/)[0].replace(/[.。]$/, '');

:119 (base line 115)
− imageNoteTitle: '统一业务对象层',

• imageNoteTitle: t2Lead(positioning['zh-Hans'].t2),

:207 (base line 203)
− imageNoteTitle: 'Unified business object layer',

• imageNoteTitle: t2Lead(positioning.en.t2),

:296 (base line 292)
− imageNoteTitle: '統一業務オブジェクト層',

• imageNoteTitle: t2Lead(positioning.ja.t2),

:385 (base line 381)
− imageNoteTitle: 'Einheitliche Geschäftsobjektschicht',

• imageNoteTitle: t2Lead(positioning.de.t2),

:474 (base line 470)
− imageNoteTitle: 'Capa unificada de objetos de negocio',

• imageNoteTitle: t2Lead(positioning.es.t2),

:563 (base line 559)
− imageNoteTitle: 'Couche unifiée d’objets métier',

• imageNoteTitle: t2Lead(positioning.fr.t2),

:652 (base line 648)
− imageNoteTitle: '통합 비즈니스 객체 계층',

• imageNoteTitle: t2Lead(positioning.ko.t2),

:171 (base line 167)
− insightsTitle: '关于 AI-native 软件的实践思考',

• insightsTitle: '关于 AI 编写的软件的实践思考',

:259 (base line 255)
− insightsTitle: 'Practical thinking on AI-native software',

• insightsTitle: 'Practical thinking on AI-written software',

:348 (base line 344)
− insightsTitle: 'AI-native ソフトウェアの実践知',

• insightsTitle: 'AI が書くソフトウェアの実践知',

:437 (base line 433)
− insightsTitle: 'Praxiswissen zu AI-nativer Software',

• insightsTitle: 'Praxiswissen zu AI-geschriebener Software',

:526 (base line 522)
− insightsTitle: 'Ideas prácticas sobre software AI-native',

• insightsTitle: 'Ideas prácticas sobre software escrito por AI',

:615 (base line 611)
− insightsTitle: 'Réflexions pratiques sur les logiciels AI-native',

• insightsTitle: 'Réflexions pratiques sur les logiciels écrits par l’AI',

:704 (base line 700)
− insightsTitle: 'AI-native 소프트웨어에 대한 실무적 관점',

• insightsTitle: 'AI가 작성한 소프트웨어에 대한 실무적 관점',

:218 (base line 214)
− { title: 'Generate metadata, not app code', copy: 'For typical CRUD and workflow software, agents write the compact ObjectStack definition; the open ObjectStack runtime derives tables, APIs, UI, and tools, then enforces permissions and audit, while ObjectOS handles production deployment and team operations.

• { title: 'Write the ontology, not app code', copy: 'For typical CRUD and workflow software, agents write the business ontology — objects and fields, relations, actions, permissions, flows — as one compact ObjectStack definition; the open ObjectStack runtime derives tables, APIs, UI, and tools from it, then enforces permissions and audit, while ObjectOS handles production deployment and team operations.
  · 1 sentence unchanged

:130 (base line 126)
− { title: '生成元数据，而不是整套代码', copy: '对典型 CRUD 和流程型软件，Agent 编写紧凑的 ObjectStack 定义，开源 ObjectStack 运行时派生表、API、界面和工具，并强制执行权限与审计；ObjectOS 负责团队的生产部署与运营。

• { title: '编写本体，而不是整套代码', copy: '对典型 CRUD 和流程型软件，Agent 把业务本体——对象与字段、关系、动作、权限、流程——写成一份紧凑的 ObjectStack 定义，开源 ObjectStack 运行时从中派生表、API、界面和工具，并强制执行权限与审计；ObjectOS 负责团队的生产部署与运营。
  · 2 sentences unchanged

:307 (base line 303)
− { title: 'コードではなくメタデータを生成', copy:

• { title: 'コードではなくオントロジーを書く', copy:

:396 (base line 392)
− { title: 'Metadaten statt App-Code generieren', copy:

• { title: 'Die Ontologie schreiben, nicht App-Code', copy:

:485 (base line 481)
− { title: 'Genera metadatos, no código de app', copy:

• { title: 'Escribe la ontología, no código de app', copy:

:574 (base line 570)
− { title: 'Générez des métadonnées, pas du code applicatif', copy:

• { title: 'Écrivez l’ontologie, pas du code applicatif', copy:

:663 (base line 659)
− { title: '앱 코드가 아니라 메타데이터 생성', copy:

• { title: '앱 코드가 아니라 온톨로지 작성', copy:

src/lib/terms.ts

:63
− export function termDescription(term: Term, locale: Locale): string { ⏎ const label = term.label[locale]; ⏎ const descriptions: Record‹Locale, Record‹TermGroup, string›› = {

• export function termDescription(term: Term, locale: Locale): string { ⏎ // Traditional Chinese is derived from Simplified (s2twp), the same rule the ⏎ // labels follow above — never a hand-kept third copy. ⏎ if (locale === 'zh-Hant') return s2t(termDescription(term, 'zh-Hans')); ⏎ const label = term.label[locale]; ⏎ const descriptions: Record‹Exclude‹Locale, 'zh-Hant'›, Record‹TermGroup, string›› = {

:76 (base line 73)
− topic: 围绕${label}的文章，关注 AI-native 企业软件、受控数据、应用搭建和 Agent 工作流的实践。,

• topic: 围绕${label}的文章，关注可执行业务本体、受治理的数据、应用搭建和 Agent 工作流的实践。,

:78 (base line 75)
− role: 面向${label}的文章，讨论如何用 ObjectOS 构建、运行和治理 AI-native 业务应用。,

• role: 面向${label}的文章，讨论如何用 ObjectOS 构建、运行和治理 AI 编写的业务应用。,

:78 (removed; was base line 78)
− 'zh-Hant': { ⏎ topic: 圍繞${label}的文章，關注 AI-native 企業軟體、受控資料、應用搭建和 Agent 工作流的實踐。, ⏎ solution: 關於${label}場景的實踐思考，覆蓋資料模型、流程、權限、整合以及企業 AI Agent 的設計方式。, ⏎ role: 面向${label}的文章，討論如何用 ObjectOS 構建、執行和治理 AI-native 業務應用。, ⏎ industry: 面向${label}團隊的文章，討論如何連線現有系統、業務資料、流程與 AI Agent，而不是替換核心平臺。, ⏎ },

• (removed — zh-Hant is derived from zh-Hans by s2t at render time)

:82 (base line 85)
− topic: ${label}に関する記事。AI-native な企業ソフトウェア、管理されたデータ、アプリ開発、エージェントワークフローを実践的に扱います。,

• topic: ${label}に関する記事。実行可能なビジネスオントロジー、管理されたデータ、アプリ開発、エージェントワークフローを実践的に扱います。,

:84 (base line 87)
− role: ${label}向けに、ObjectOS で AI-native な業務アプリを構築、運用、統制する方法をまとめます。,

• role: ${label}向けに、ObjectOS で AI が書く業務アプリを構築、運用、統制する方法をまとめます。,

:88 (base line 91)
− topic: Artikel zu ${label}: praktische Gedanken zu AI-nativer Unternehmenssoftware, kontrollierten Daten, App-Entwicklung und Agent-Workflows.,

• topic: Artikel zu ${label}: praktische Gedanken zu ausführbaren Geschäftsontologien, kontrollierten Daten, App-Entwicklung und Agent-Workflows.,

:90 (base line 93)
− role: Artikel für ${label} über Aufbau, Betrieb und Governance AI-nativer Geschäftsanwendungen mit ObjectOS.,

• role: Artikel für ${label} über Aufbau, Betrieb und Governance AI-geschriebener Geschäftsanwendungen mit ObjectOS.,

:94 (base line 97)
− topic: Artículos sobre ${label}, con notas prácticas sobre software empresarial AI-native, datos gobernados, desarrollo de apps y flujos con agentes.,

• topic: Artículos sobre ${label}, con notas prácticas sobre ontologías de negocio ejecutables, datos gobernados, desarrollo de apps y flujos con agentes.,

:96 (base line 99)
− role: Artículos para ${label} sobre construir, operar y gobernar aplicaciones de negocio AI-native con ObjectOS.,

• role: Artículos para ${label} sobre construir, operar y gobernar aplicaciones de negocio escritas por AI con ObjectOS.,

:100 (base line 103)
− topic: Articles sur ${label}, avec des notes pratiques sur les logiciels d’entreprise AI-native, les données gouvernées, les applications et les workflows d’agents.,

• topic: Articles sur ${label}, avec des notes pratiques sur les ontologies métier exécutables, les données gouvernées, les applications et les workflows d’agents.,

:102 (base line 105)
− role: Articles pour ${label} sur la construction, l’exploitation et la gouvernance d’applications métier AI-native avec ObjectOS.,

• role: Articles pour ${label} sur la construction, l’exploitation et la gouvernance d’applications métier écrites par l’AI avec ObjectOS.,

:106 (base line 109)
− topic: ${label}에 관한 글입니다. AI-native 엔터프라이즈 소프트웨어, 관리되는 데이터, 앱 개발, 에이전트 워크플로를 실무 관점에서 다룹니다.,

• topic: ${label}에 관한 글입니다. 실행 가능한 비즈니스 온톨로지, 관리되는 데이터, 앱 개발, 에이전트 워크플로를 실무 관점에서 다룹니다.,

:108 (base line 111)
− role: ${label}를 위해 ObjectOS로 AI-native 비즈니스 애플리케이션을 구축, 운영, 거버넌스하는 방법을 다룹니다.,

• role: ${label}를 위해 ObjectOS로 AI가 작성한 비즈니스 애플리케이션을 구축, 운영, 거버넌스하는 방법을 다룹니다.,

src/pages/llms.txt.ts

:72
· 2 sentences unchanged
− It is executable: the ObjectStack runtime derives the database, REST API, screens, and MCP tools from it and enforces permissions and audit on every call.
− Views, dashboards, apps, and translations are projections of it, not part of it; it has no inheritance, no axioms, and no reasoner, and it is not a semantic layer over your existing systems.', ⏎ '- Metadata driven development with an AI as the author: building an application by writing its typed definition rather than its code, where a coding agent writes the definition and a person reviews the diff.
− The qualifier is the point.
− Metadata driven development in the low-code era meant a human clicking through a vendor’s builder, with the metadata held as a proprietary database row; with an AI as the author it means source files an agent writes, a reviewer reads, and version control tracks.
− What makes it worth doing under AI authorship is size: the whole definition stays small enough for an agent to hold whole, so the change a human must read stays small enough to actually read.',

• It is executable in the sense the next term defines: the ObjectStack runtime derives the database, REST API, screens, and MCP tools from it and enforces permissions and audit on every call.', ⏎ '- Executable business ontology: the definition of a business that a runtime runs — objects and fields, relations, actions, permissions, flows, and agent and tool definitions — authored as typed metadata, validated, and then executed, so that the database, API, screens, and agent tools are derived from it rather than described by it.
• Four boundaries come with the word.
• It is executable, not a knowledge-representation ontology: no inheritance, no axioms, no reasoner — the definition is validated rather than reasoned over.
• 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.
• What makes it worth writing this way under AI authorship is size: the whole definition stays small enough for an agent to hold whole, so the change a human must read stays small enough to actually read.',

src/lib/cluster-i18n.ts

:46
− 'ai-native-app-platform': { ⏎ 'zh-Hans': { title: 'AI-native 应用平台', shortTitle: 'AI-native 应用平台' }, ⏎ ja: { title: 'AI-native アプリプラットフォーム', shortTitle: 'AI-native アプリ' }, ⏎ de: { title: 'AI-native App-Plattform', shortTitle: 'AI-native App-Plattform' }, ⏎ es: { title: 'Plataforma de aplicaciones AI-native', shortTitle: 'Plataforma AI-native' }, ⏎ fr: { title: 'Plateforme applicative AI-native', shortTitle: 'Plateforme AI-native' }, ⏎ ko: { title: 'AI-native 앱 플랫폼', shortTitle: 'AI-native 앱 플랫폼' }, ⏎ },

• // The slug and URL keep the category name people search for; the copy no ⏎ // longer defines the product by it. The name is a noun phrase because the ⏎ // per-locale templates below interpolate it mid-sentence (ko keeps a final ⏎ // consonant so the templates' 이/은 particles stay right). ⏎ 'ai-native-app-platform': { ⏎ 'zh-Hans': { title: '可执行的业务本体', shortTitle: '可执行业务本体' }, ⏎ ja: { title: '実行可能なビジネスオントロジー', shortTitle: '実行可能なオントロジー' }, ⏎ de: { title: 'Ausführbare Geschäftsontologie', shortTitle: 'Ausführbare Geschäftsontologie' }, ⏎ es: { title: 'Ontología de negocio ejecutable', shortTitle: 'Ontología ejecutable' }, ⏎ fr: { title: 'Ontologie métier exécutable', shortTitle: 'Ontologie exécutable' }, ⏎ ko: { title: '실행 가능한 비즈니스 온톨로지 플랫폼', shortTitle: '실행 가능한 온톨로지' }, ⏎ },

:107 (base line 103)
− description: (name) =› ⏎ 了解 ${name} 如何连接现有业务系统、建模业务对象，并让 AI 在权限、审批和审计边界内工作。 − , ⏎ lead: (name) =› ⏎ ${name} 的核心不是再做一个演示页面，而是把真实业务对象、权限、流程、API 和 Agent 工具组织成一个可治理的运行层。 − , ⏎ definition: (name) =› ⏎ `${name} 把客户、工单、订单、设备、合同和审批等业务记录变成 AI 可以理解和调用的结构化对象。

• description: (name) =› ⏎ `了解 ${name} 如何连接现有业务系统、把业务建模成一份可执行的本体，并让 AI 在权限、审批和审计边界内工作。
• , ⏎ lead: (name) =› ⏎ ${name} 的核心不是再做一个演示页面，而是一份可执行的业务本体：对象与字段、关系、动作、权限、流程，以及 Agent 与工具定义。
• 视图、仪表盘、应用和翻译是它的投影，不是产品本身。
• , ⏎ definition: (name) =› ⏎ ${name} 把客户、工单、订单、设备、合同和审批等业务记录写进同一份本体：对象、权限、动作和流程声明在一起，运行时从中派生数据库、API、界面和 MCP 工具，并在每一次调用上执行权限与审计。
  · 2 sentences unchanged

:138 (base line 134)
− 低代码主要加速表单和流程搭建。ObjectOS 更关注底层业务对象、权限治理、系统集成、Agent 工具和长期演进。

• 低代码平台是最近的亲戚：那里同样由元数据生成表、API 和界面。区别在定义放在哪里、写给谁看。低代码把元数据当作配置存在厂商的数据库里、由人在界面上点出来；ObjectStack 把它写成你仓库里类型化、声明式的 TypeScript——进版本库、按 diff 审阅、运行前经 os validate 校验，并且是为 AI 来写而设计的。

src/lib/clusters.ts — CLUSTERS[0], field by field

title
− AI-Native App Platform

• What Is an AI-Native App Platform? One Executable Business Ontology

shortTitle
− AI-native app platform

• Executable business ontology

description
− Learn what an AI-native app platform is, how it differs from low-code, and how ObjectOS connects business objects, permissions, workflows, APIs, and AI agents.

• An AI-native app platform, defined the way ObjectStack defines it: one executable business ontology that AI writes, an open runtime runs, agents operate, and you own — how that differs from low-code and from AI code generation, and where ObjectOS fits.

lead
− An AI-native app platform is built around business objects, permissions, workflows, APIs, and agent tools from the start. It is not a page builder with a chat box; it is a governed runtime for AI-written business software.

• People search for an AI-native app platform and mean a place where AI-written business software can land and stay governable. ObjectStack’s answer is not a page builder with a chat box. It is one executable business ontology — objects and fields, relations, actions, permissions, flows, and agent and tool definitions — and the open runtime that runs it; the screens are projections of that definition, not the product.

definition
− An AI-native app platform turns requirements into structured application metadata: objects, fields, relationships, views, permissions, workflows, actions, APIs, and tools that agents can call. The platform gives AI a model of the business system instead of asking it to generate disconnected code.

• An executable business ontology is the definition of a business that a runtime runs. AI writes it as typed metadata in your repository; the ObjectStack runtime derives the database, REST API, screens, and MCP tools from it and enforces permissions and audit on every call; agents operate it under the same permissions as people; and you own the files, Apache-2.0. ObjectOS runs the same loop hosted or self-managed, with in-app AI, approvals, and operations on top.

whyNow — 3 → 3 paragraphs; 0 sentences identical (in place or moved), 3 removed, 3 added
− Enterprise AI needs access to real business records, not exported snapshots.
− Generated apps need permissions, audit trails, and lifecycle control after the first version ships.
− Business teams need systems that keep evolving as rules, integrations, and operating models change.

• Anyone can make an AI generate an app now; the bottleneck moved to reviewing, governing, and trusting what the AI wrote.
• Generated apps need permissions, audit trails, and lifecycle control after the first version ships — rules a runtime enforces, not rules a prompt remembers.
• A business keeps changing its rules, integrations, and operating model; a definition an agent can hold whole stays changeable, a generated codebase does not.

capabilities — 4 → 4 paragraphs; 0 sentences identical (in place or moved), 4 removed, 4 added
− Object modeling for customers, orders, cases, devices, contracts, approvals, and other business records.
− Metadata-driven screens, workflows, APIs, and agent tools generated from the same business specification.
− Permission-aware execution so users and AI agents operate inside the same governance boundary.
− Federation of a database you already run — read-only by default, and early — so the platform can read what already runs instead of forcing a migration.

• Executable: objects and fields, relations, actions, permissions, flows, and agent and tool definitions as typed metadata the runtime validates and runs — validated, not reasoned over.
• AI-writable: a coding agent writes the definition; Strict TypeScript, Zod schemas, and os validate reject what would fail at runtime; a person reviews a small diff instead of generated glue.
• Agent-operable: every object and exposed action doubles as a governed MCP tool, called under the signed-in user’s permissions, approvals, and audit.
• You own it: the definition lives in your repository under Apache-2.0, and a database you already run federates in place — read-only by default, and early.

useCases — 3 → 3 paragraphs; 1 sentences identical (in place or moved), 2 removed, 2 added
− Turn a repair, service, approval, or internal operations requirement into a running application.
− Replace fragile low-code prototypes with governed applications that can survive complexity.

• Turn a repair, service, approval, or internal operations requirement into a running application your agent writes and your team reviews.
• Replace fragile low-code prototypes with an ontology the runtime governs and an agent can refactor whole.

faq[0].question
− What is an AI-native app platform?

• What is an AI-native app platform?

faq[0].answer
− An AI-native app platform is an application runtime designed so AI can help model, generate, operate, and evolve business software. It treats objects, permissions, workflows, APIs, and agent tools as first-class metadata.

• In ObjectStack’s terms, an executable business ontology plus the runtime that runs it: the business is defined once — objects and fields, relations, actions, permissions, flows, and agent and tool definitions — AI writes that definition, the runtime derives and enforces everything else, agents operate it, and you own it. Views, dashboards, apps, and translations are projections of the ontology, not part of it.

faq[1].question
− How is an AI-native app platform different from low-code?

• How is it different from low-code?

faq[1].answer
− Low-code usually accelerates forms, pages, and workflows. An AI-native app platform focuses on the operating layer underneath them: business objects, governance, integrations, generated APIs, agent tools, and long-term change.

• Low-code platforms are the closest relatives: metadata generates tables, APIs, and UI there too. The difference is where the definition lives and who it is written for. Low-code keeps metadata as configuration in the vendor’s database, edited through its UI by a person; ObjectStack keeps it as typed, declarative TypeScript in your repository — versioned and reviewed as a diff, checked by os validate before it runs, and shaped for an AI to write.

faq[2].question
− Does AI-native mean the AI writes all the code?

• Where does the code go?

faq[2].answer
− No. The important shift is that AI works with structured application metadata and a governed runtime. Code may still exist, but the business model, permissions, and tools remain explicit and inspectable.

• Code does not disappear; it moves into the runtime. Hooks, action bodies, CEL expressions, and constrained JSX run inside the same permission and audit fence as everything derived from the ontology. What goes away is the generated codebase a definition would otherwise have to describe — and that no agent could hold whole.

articleSlugs: ["from-requirement-to-app","low-code-vs-ai-native-app-platform","extend-existing-systems-with-ai","self-hosted-ai-app-platform","ai-agent-business-data-security-boundaries"] → ["what-does-the-ontology-is-the-software-mean","from-requirement-to-app","low-code-vs-ai-native-app-platform","extend-existing-systems-with-ai","self-hosted-ai-app-platform","ai-agent-business-data-security-boundaries"]

content/glossary/en/ontology.ts — term, field by field

title
− Ontology in Enterprise Software: Definition, and Who Owns Yours

• 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 — 4 → 4 paragraphs; 9 sentences identical (in place or moved), 10 removed, 11 added
− 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.
− 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.
− 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.

• 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.
• 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.
• An ontology does not make an AI agent correct: modelling a business well remains slow, contested, human work that no format shortcuts.

alsoKnownAs: ["enterprise ontology","business ontology","domain ontology"] → ["executable business ontology","business ontology","enterprise ontology","domain ontology"]

relatedTerms: ["semantic-layer","knowledge-graph","object-type-and-action-type","application-metadata","definition-layer","typed-metadata","governed-runtime"] → ["ontology-projection","semantic-layer","knowledge-graph","object-type-and-action-type","application-metadata","definition-layer","typed-metadata","governed-runtime"]

articleSlugs: ["ai-ontology-open-protocol","enterprise-ontology-race-open-vs-closed","ontology-vs-semantic-layer-vs-knowledge-graph","enterprise-ontology-platform-comparison","objectos-action-tools"] → ["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"] → ["data-modeling","app-ui","permissions","mcp","agent-developer","platform","ai"]

content/glossary/zh-Hans/ontology.ts — term, field by field

title
− 企业软件里的本体（Ontology）：定义，以及它归谁所有

• 企业软件里的本体（Ontology）：可执行的业务本体，以及它归谁所有

description
− 本体是对一个业务领域的形式化建模——它有哪些类、每个类带哪些属性、彼此之间是什么关系——写成机器可读的形式，让软件和 AI Agent 能对业务本身做推理，而不是对着一堆原始数据表猜。

• 可执行的业务本体，是由运行时直接运行的那份业务定义——对象与字段、关系、动作、权限、流程，以及 Agent 与工具定义——它被校验，而不是被推理。

definition
− 本体（Ontology）在企业语境下，是对一个业务领域的形式化建模——业务打交道的那些类、描述它们的属性、以及把它们连起来的关系——以机器可读的形式表达出来，让软件（如今还有 AI Agent）能够对业务本身做推理，而不是对着一堆原始数据表猜。

• 本体（Ontology）在 ObjectStack 所用的意义上，是一份可执行的业务本体：对一个业务的定义——它的对象与字段、关系、动作、权限、流程，以及 Agent 与工具定义——以类型化元数据写出，由运行时校验后直接运行，让软件和 AI Agent 通过这一份定义去操作业务，而不是对着一堆原始数据表猜。

explanation — 4 → 4 paragraphs; 10 sentences identical (in place or moved), 9 removed, 10 added
− 这个词来自哲学，经由知识工程进入企业软件，但真正干活的那层含义很窄也很实用：本体为整个组织一次性命名类型（客户、工单、设备）、每个类型带的属性，以及类型之间的连接。
− 这正是它和数据库 schema 的分界。
− 在 ObjectStack 里，本体不是某个托管平台内部的一层：它就是应用自己的定义——对象与字段、关系、动作、权限、流程，以及 Agent 与工具定义——由运行时直接运行。
− 这份定义就是你的业务本体：开放、带版本、归你所有，放在你自己的仓库里，既不是散落在框架各处的代码，也不是锁在厂商系统里的一张图。
− 视图、仪表盘、应用和翻译是本体的投影，不是本体的一部分；代码并没有消失，而是以钩子、动作体、CEL 和受限 JSX 的形式搬进了运行时。
− 这一切归结为 ObjectStack README 开篇的那句话：本体即软件。
− 边界和主张同样重要。
− ObjectStack 的本体是可执行的，不是知识表示意义上的本体：没有继承、没有公理、没有推理机——它被校验，然后被运行。
− 它也不是架在你现有系统之上的语义层；联邦外部数据源默认只读，且尚在早期。

• 本体即软件。
• 在 ObjectStack 里，本体不是某个托管平台内部的一层：它就是应用自己的定义——对象与字段、关系、动作、权限、流程，以及 Agent 与工具定义——由运行时直接运行：数据库、REST API、界面和 MCP 工具都从它派生，权限与审计在每一次调用上执行。
• 这个词带着四条边界。
• 它是可执行的，不是知识表示意义上的本体：没有继承、没有公理、没有推理机——定义被校验，然后被运行。
• 它不是架在你现有系统之上的语义层：它本身就是系统，联邦外部数据源默认只读，且尚在早期。
• 视图、仪表盘、应用和翻译是本体的投影，不是本体的一部分。
• 代码也没有消失：它以钩子、动作体、CEL 和受限 JSX 的形式搬进了运行时。
• 这个词来自哲学，经由知识工程进入企业软件，在那里它指对一个领域的形式化建模——类、属性、关系——让软件能对其推理。
• 那层含义很窄也很实用：本体为整个组织一次性命名类型（客户、工单、设备）、每个类型带的属性，以及类型之间的连接，这正是它和数据库 schema 的分界。
• 在 ObjectStack 里，这份定义就是你的业务本体：开放、带版本、归你所有，放在你自己的仓库里，既不是散落在框架各处的代码，也不是锁在厂商系统里的一张图。

alsoKnownAs: ["企业本体","业务本体","领域本体"] → ["可执行业务本体","业务本体","企业本体","领域本体"]

relatedTerms: ["semantic-layer","knowledge-graph","object-type-and-action-type","application-metadata","definition-layer","typed-metadata","governed-runtime"] → ["ontology-projection","semantic-layer","knowledge-graph","object-type-and-action-type","application-metadata","definition-layer","typed-metadata","governed-runtime"]

articleSlugs: ["ai-ontology-open-protocol","enterprise-ontology-race-open-vs-closed","ontology-vs-semantic-layer-vs-knowledge-graph","enterprise-ontology-platform-comparison","objectos-action-tools"] → ["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"] → ["data-modeling","app-ui","permissions","mcp","agent-developer","platform","ai"]

content/glossary/en/metadata-driven-development.ts — term, field by field

explanation[0] — inserted at the head; explanation[1..4] are the base's [0..3], unchanged

• 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.

relatedTerms: ["application-metadata","typed-metadata","application-definition-vs-runtime","definition-layer","governed-runtime","vibe-coding","comprehension-debt","reviewable-diff"] → ["ontology","application-metadata","typed-metadata","application-definition-vs-runtime","definition-layer","governed-runtime","vibe-coding","comprehension-debt","reviewable-diff"]

content/glossary/zh-Hans/metadata-driven-development.ts — term, field by field

explanation[0] — inserted at the head; explanation[1..4] are the base's [0..3], unchanged

• 沿革说明：在 2026 年 10 月之前，本站用这个词来定义产品。现在定义产品的是可执行的业务本体——见本术语表的「本体（Ontology）」词条，以及下方的相关术语。元数据驱动开发仍然是写出那份本体的方法：定义是类型化元数据，而当作者是 AI Agent 时，人审阅的正是这份元数据。这一页保留下来，是因为它已有外部链接和搜索流量；下面的定义未变。

relatedTerms: ["application-metadata","typed-metadata","application-definition-vs-runtime","definition-layer","governed-runtime","vibe-coding","comprehension-debt","reviewable-diff"] → ["ontology","application-metadata","typed-metadata","application-definition-vs-runtime","definition-layer","governed-runtime","vibe-coding","comprehension-debt","reviewable-diff"]

Gates (all on 42648e1; each exit code captured before any pipe)

• pnpm content:lint — exit 0 — ✓ content lint passed (347 files, 46 glossary terms checked)
• pnpm content:lint --published — exit 0 — ✓ content lint passed (347 files, 46 glossary terms checked)
• pnpm check — exit 0 — Result (156 files): 0 errors, 0 warnings, 0 hints
• pnpm build — exit 0 — [build] 896 page(s) built in 73.91s · ✓ content lint --dist passed (486 built blog pages checked) · CJK line breaks, quotation marks (12422 curly marks, 0 wrong) and links (94974 internal links) all passed
• pnpm seo:smoke — exit 0 — SEO smoke test passed (886 HTML pages checked; 580 sitemap URLs against 306 noindexed pages; 5533 canonical/hreflang annotations; 16495 prose blocks language-checked; 94964 internal links redirect-checked)

check and build ran under the shared verify lock (slot www-233, held 112 s). The width warnings content:lint prints are on content/blog/what-does-the-ontology-is-the-software-mean/* (title 87 columns, description 206), a post this PR does not touch.

Browser check

Chromium at /opt/pw-browsers/chromium driving astro preview of the built dist/: 22 pages × 2 viewports (1440×750 and 390×844) = 44 page-views. Every one answered 200, scrollWidth equalled clientWidth (no horizontal overflow), and the page's changed sentence was found in the rendered text. Pages: home, the five capability pages, the three glossary pages (ontology, ontology-projection, metadata-driven-development) and the cluster page, each in en and zh-Hans, plus the zh-Hant projection term and the zh-Hant cluster page. Screenshots looked at: en home, en cluster at both widths (the long H1 wraps cleanly on the phone), zh-Hans ontology term (new definition and the 可执行业务本体 chip), zh-Hant projection term at 390, en metadata-driven-development (lineage note first), en app-ui at 390 (lead with "a projection of the ontology, not part of it").

Acceptance notes

Observed while measuring; none changed here, none is a defect this PR introduces:

• src/lib/cluster-i18n.ts ja/de/es/fr/ko templates still describe the cluster as a governed runtime for business objects with the generic low-code FAQ (no "AI-native" strings; noindexed fallbacks canonical to en). Outside the authored locales of this card.
• src/pages/llms.txt.ts:95 Articles line ("Practical writing on AI-native software …") is a page entry — the region No page explains the positioning: add an /ontology/ pillar page and a /compare/ page with a "when not to use it" section #235 holds; left as is. No page explains the positioning: add an /ontology/ pillar page and a /compare/ page with a "when not to use it" section #235 remains open and shares src/lib/home.ts (the #compare chips) and src/pages/llms.txt.ts (page entries) in other regions; the later lander merges main.
• src/lib/i18n.ts articlesLead (six locales) and src/components/ArticleList.astro carry "AI-native" — they belong to site(blog): the pillar post leads the Recommended grid; Articles hero lead in six locales; close the 641–900px grid hole (merge 2026-10-20 after post 2) #255 and were not touched.
• One prose "AI-native" each in content/glossary/{en,zh-Hans}/{permission-model,application-metadata}.ts; the section id ai-native in content/pages/{en,zh-Hans}/platform.ts is an anchor, not copy. Outside the file surface.
• The cluster page's hero-rail labels (heroRail, "Object layer" …) are shared chrome and untouched.
• zh-Hant renders 视图 as 檢視 on the new term (s2twp), the converter's existing behaviour on every zh-Hant page.

Scope kept to the file surface the claim names; the only shape change outside pure copy is terms.ts deriving zh-Hant from zh-Hans and home.ts reading T2's first sentence from positioning, both declared above.

---

Generated by Claude Code

Patch rounds 1–2 (added by the seat; the sections above describe 42648e1)

Heads: 42648e1 → 47bfaa1 (merge of origin/main a69829e, #258; no conflicts) → 9242de3 → 39ab729 → bb415e7.

• content/glossary/{en,zh-Hans}/ontology.ts pageSlugs now start with 'ontology', 'compare', so the term links /{locale}/ontology/ and /{locale}/compare/.
• src/pages/llms.txt.ts:95: Practical writing on AI-native software, … → Practical writing on executable business ontologies and AI-written software, …. This is one line beyond "Core Definitions only", on the seat's instruction.
• src/lib/clusters.ts title: AI-Native App Platform (main) → AI-Native App Platform: An Ontology You Run. The H1 is 258px / 3 lines at 1366×625, the same as /en/self-hosted-ai/; the first head's 10-word title was 430px / 5 lines.
• content/pages/{en,zh-Hans}/agent-developer.ts:13 heroTitle: Teach your agent the target format. → Teach your agent to write the ontology. · 教你的 Agent 目标格式。 → 教你的 Agent 写本体。

Gates on bb415e7 (the dev's run): content:lint, --published, check (160 files, 0/0/0), build (912 pages), seo:smoke (902 pages) — all exit 0. CI Build and deploy: success.

[objectstack-fleet]

席位核对

ACCEPT — repo:www.objectos.ai · seat 2 (session_017GeNDQH7E5S2rX8ajVAPxv), 2026-10-16T07:45Z, on head bb415e7, after two patch rounds. Reviewed against GitHub and the seat's own builds, not the report.

Check	Result
Shape	Draft PR to main. The first line is Fixes #233, the only closing keyword in the body. Assignee os-tesla.
Ruling (Ruling-ref 6209608204)	The built llms.txt Core Definitions read Open business ontology / Executable business ontology / Review AI generated code. The MDD entry is gone, and metadata-driven-development keeps its page and URL and opens with the lineage note. Both as ruled.
File surface	21 files, all inside the claimed surface. One extension: llms.txt:95, the Articles line, added on the seat's patch-round instruction. home.ts changed the three strings in all 7 authored locales, not only en/zh-Hans, so the home page stays consistent; accepted. No governed path.
CI on head	Build and deploy: completed/success on bb415e7.
Seat's own build	bb415e7 (and earlier 9242de3): pnpm build under the shared lock, VERDICT command-exit 0, 912 pages, ✓ content lint --dist passed. Tree clean.
Browser (seat)	13 pages × 1366×625 / 390×844 = 26 views, 0 failing, all 200, no overflow: en/zh-Hans home, the glossary ontology / ontology-projection / metadata-driven-development terms, the five capability pages, and the en/zh-Hans cluster. The glossary ontology term carries the /ontology/ and /compare/ links. Renders were looked at for the en cluster and the glossary term.
Layout defect caught and fixed	On the first head the cluster's 10-word title rendered a 5-line H1 (430px, bottom 595px at 1366×625): a laptop's first screen showed the title alone. At bb415e7 it is 258px / 3 lines (bottom 423px), the same as the sibling /en/self-hosted-ai/. 390×844: 123px, also the same as the sibling.
Leftover removed	The agent-developer heroTitle no longer says "target format" (en / zh-Hans; zh-Hant derived).

Acceptance notes:

• ja/de/es/fr/ko cluster templates still frame the cluster generically. They are noindexed fallbacks canonical to en, so this is noted, not filed.
• One prose "AI-native" each remains in permission-model.ts and application-metadata.ts (glossary). These are outside the claimed surface; noted, not filed.
• The word "run" in the cluster title (An Ontology You Run) is the executable claim in plain words; the definition stays in description and the lead.

Landing: ready, then squash by the seat. Merge publishes, so the seat follows the change to the deploy run.

---

Generated by Claude Code