diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/cover-en.svg b/content/blog/when-not-to-use-an-executable-business-ontology/cover-en.svg
new file mode 100644
index 0000000..e597087
--- /dev/null
+++ b/content/blog/when-not-to-use-an-executable-business-ontology/cover-en.svg
@@ -0,0 +1,60 @@
+
diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/cover.svg b/content/blog/when-not-to-use-an-executable-business-ontology/cover.svg
new file mode 100644
index 0000000..5d3556e
--- /dev/null
+++ b/content/blog/when-not-to-use-an-executable-business-ontology/cover.svg
@@ -0,0 +1,60 @@
+
diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/index.mdx b/content/blog/when-not-to-use-an-executable-business-ontology/index.mdx
new file mode 100644
index 0000000..a520fd9
--- /dev/null
+++ b/content/blog/when-not-to-use-an-executable-business-ontology/index.mdx
@@ -0,0 +1,149 @@
+---
+title: "When Should You Not Use an Executable Business Ontology?"
+description: "Five workloads where an executable business ontology is the wrong tool today, what to use instead, the cost of choosing wrong, and a sourced decision table."
+author: ObjectStack Team
+date: 2026-11-05
+status: published
+topic: app-building
+audience: it
+solutions: []
+industries: []
+cover: ./cover-en.svg
+tags:
+ - Ontology
+ - Executable business ontology
+ - When to use
+---
+
+**Short answer: not for five workloads, and the ObjectStack documentation names them itself.** Replacing the core ERP or finance system of a large enterprise. Work whose value is integrating many existing systems. Analytics over data lakes. Algorithm-heavy domains such as pricing or scheduling, unless the algorithm is wrapped as an action. And anything that must run on a certified platform. For each there is a better tool, and this post says which one, why it is the right call, and what it costs to choose wrong. At the end: a decision table with a source on every row, and a ten-question self-check you can run on your own case before you install anything.
+
+An honest list of where a product is the wrong tool is the most useful thing a vendor can publish, because it is the one thing a buyer cannot get from the sales deck. ObjectStack's one-line positioning is "One executable business ontology. AI writes it, the runtime runs it, agents operate it, you own it." Everything below is about the edges of that sentence, taken from the project's own [when-to-use page](https://objectstack.ai/docs/concepts/when-to-use) and [comparison page](https://objectstack.ai/docs/concepts/compare) at `origin/main` on 2026-10-16, and from the source file where the limit is a line of code. This site's [comparison page](/en/compare/) already lists the five workloads and the five questions in one line each; this post is the long form: a scenario for each, the alternative and its case, the cost, and the deciding fact.
+
+## The six-kind test
+
+One test covers all five cases, so it is worth stating first. The concepts page defines the core of an executable business ontology as six kinds of thing: objects and fields, relations, actions, permissions, flows, and agent and tool definitions. The runtime derives the database, the API, the UI and the agent tools from those six, and enforces them on every call. Code does not disappear, but it moves into the runtime, as hooks, action bodies, CEL and constrained JSX, inside the fence the six kinds define.
+
+So ask of any workload: **is the hard part one of the six kinds?** If the difficult, valuable, risky part of the work is deciding what exists, how it relates, what may be done, by whom, and what happens when, the ontology is the tool, and an agent can write it. If the hard part is something else, a statutory calculation, a connection to forty systems, a scan over a petabyte, a solver, an auditor's certificate, then that part is not expressible as a definition, and the ontology at best wraps it and at worst imitates it. Call that the **six-kind test**. The five workloads below each fail it for a different reason, which is why they need five different alternatives rather than one.
+
+## 1. The core ERP or finance system of a large enterprise
+
+**The scenario.** A manufacturer with four thousand people has run its general ledger, consolidation and payroll on a packaged ERP for twelve years. A coding agent, shown the chart of accounts, offers to re-declare it as objects, with posting rules as flows and tax as formulas. The demo is convincing: journals, a trial balance, an approval on every entry.
+
+**What to use instead, and why it is right.** The packaged system, and build around it. The when-to-use page: "A general ledger, consolidation, tax and payroll carry regulation and edge cases that packaged systems already encode. Build around that core, not instead of it." In that market the regulation is the product. A payroll engine is a library of jurisdictions, filing calendars and retroactive corrections, maintained by people whose only job is to keep it current; a consolidation engine is years of intercompany eliminations and currency-translation edge cases. None of that is "what exists and who may do what". It is calculation, and it changes when a government changes it, not when your business does.
+
+**The cost of choosing wrong.** A second ledger. Every rule you re-encoded is now your diff to maintain, your audit to pass and your defect when the tax year rolls over, while the packaged system you kept for statutory reporting disagrees with your copy a little more each quarter. The agent that wrote the rules in a day cannot read a tax code for you.
+
+**The deciding fact.** The README's capability table lists twelve things the runtime provides: objects and fields, permissions, automation, approvals, views, dashboards and reports, actions, APIs and SDK, AI tools, translations, seed data, datasources. A ledger, a tax engine and a payroll run are not on it, and the project does not say they are coming.
+
+What is a fit, by the same page, is the long tail around that core: "vendor onboarding, inspections, internal requests", the spreadsheets and forms that track what the ERP does not. Each becomes a typed definition instead of a file that gets emailed around, and each can read the ERP's data without owning it, which is the next case.
+
+## 2. Workloads whose value is integrating many existing systems
+
+**The scenario.** A bank wants its agents to answer a customer question from core banking, the CRM, the card platform and the ticketing system at once, and to write a status back to two of them. None of those systems is moving. The job is to make them legible to an agent and to act across them.
+
+**What to use instead, and why.** A layer over the systems: a semantic or context layer for the reading, an operational ontology of the Palantir kind when there is writeback to govern. The comparison page concedes this plainly: "When the data already lives in a warehouse, a lakehouse and a dozen operational systems, these start where you are." Those products are built around the assumption that the system of record stays put; their object model is a view, their writes are writeback, and their value grows with the number of systems underneath. ObjectStack is built on the opposite assumption, that the ontology *is* the system and the database is derived from it.
+
+**The cost of choosing wrong.** This is the case most often got wrong, because the first week goes well. ObjectStack can federate an external database as a datasource with `schemaMode: 'external'`, and a read model over a legacy table is a short afternoon. Then the writes. Federated writes are off by default twice over: the datasource must declare `external.allowWrites: true` and the object must declare `external.writable: true`, and "with either gate off, insert/update/delete on the federated object is rejected." The gate is not advisory: `assertWriteAllowed` runs at the top of the engine's `insert` and `update`, before defaults, hooks and validation. Flip both gates per object and you now own write semantics against a schema you do not control, and `schemaMode: 'external'` fails boot on a schema mismatch, so an upstream column rename takes your app down. Or you build sync jobs instead, and by then you have built the integration layer you were trying not to buy, inside a tool whose own docs call its federation "early".
+
+**The deciding fact.** Two opt-ins, both default off: `allowWrites` on the datasource and `writable` on the object (`content/docs/data-modeling/external-datasources.mdx`, the section on writes), enforced by `assertWriteAllowed` in `packages/objectql/src/engine.ts`.
+
+The honest path exists, and it is narrow: connect read-only, measure, enable writes one object at a time, cut over per object. [How to move an internal system to metadata](/en/blog/how-to-move-an-internal-system-to-metadata/) walks it, including the cases where the right answer is not to move at all. That path is for a system you intend to *replace*. If you intend to keep forty systems and read across them, it is the wrong road.
+
+## 3. Analytics over data lakes
+
+**The scenario.** A retailer has three years of clickstream and point-of-sale events in object storage, as Parquet and Iceberg tables, and the merchandising team wants dashboards. Someone notices that the platform has dashboards, reports and a dataset layer its docs call semantic, and proposes pointing it at the lake.
+
+**What to use instead, and why.** The warehouse stack: a query engine built for columnar scans, a metric or semantic layer over it, and a BI tool on top. The analytics layer in ObjectStack is a metric layer for the application's own rows. Its documentation defines a dataset as "a base object, the relationships to include, and the declared dimensions and measures", with joins derived from the object graph; the schema makes that literal, describing a dataset's `object` as "Base object name". The when-to-use page says it in one sentence: the analytics layer "defines metrics over the app's own objects for its reports and dashboards. It is not built to query a lake." A warehouse semantic layer does the same job over a lake, and this site's comparison page says a company doing serious BI will still want one.
+
+**The cost of choosing wrong.** One of two copies. Either you load the lake into app objects, and now you have a second copy of three years of events with its own freshness and its own bill, in a row store derived from a business definition rather than designed for scans; or you federate a warehouse table and find you are sending analytical questions through an engine built to answer row-level queries for an application, with filter pushdown and nothing that knows a columnar file. The dashboards will render. They will not be the dashboards the merchandising team asked for.
+
+**The deciding fact.** The drivers the README lists are PostgreSQL, MySQL, SQLite, MongoDB, Turso, SQLite in WebAssembly and in-memory. There is no lake format, no columnar engine and no object-storage driver, and the dataset layer binds to an object, not to a table in a lake.
+
+## 4. Algorithm-heavy domains, such as pricing or scheduling
+
+**The scenario.** A logistics company's product is a route optimiser: a solver that takes a day's orders and a fleet and produces a plan, with a dispatch board where planners drag stops between vehicles and watch the plan re-solve. The orders, vehicles, drivers and plans are plainly objects; the company asks whether the whole thing could be an executable ontology.
+
+**What to use instead, and why.** Code, for the solver and for the board, and here the ontology's own documentation is the steelman. The when-to-use page: the ontology "declares what can be done; it does not express an optimiser." An action's `type` is one of `script`, `url`, `modal`, `flow`, `api` or `form`, and a `script` action's handler is code that runs with the app's full data authority. The definition owns the door, the permission on the door and the audit of who walked through it. The algorithm behind the door is yours, in whatever language solves it. The interface is the same story in the other direction: the comparison page says the Console is "server-driven from metadata, and an interface unlike any business app is easier to build directly."
+
+**The cost of choosing wrong.** Building the part that matters in the place with the least freedom. A solver can live behind an action, and for a scheduling run triggered from a record that is exactly right. A dispatch board cannot: constrained JSX in pages "is parsed into a server-driven UI tree, never executed as code", by design, so every interaction the planners need becomes a negotiation with a renderer built for lists, forms and boards. Six months in, the ontology is a thin wrapper around the thing you actually sell.
+
+**The deciding fact.** `ActionType` in `packages/spec/src/ui/action.zod.ts` is the closed set `script | url | modal | flow | api | form`. The algorithm is never one of them, only the route to it.
+
+The split that works: the business half, orders, vehicles, drivers, who may approve a plan, what happens when a plan is published, as the ontology, where an agent can write and operate it; the solver as code behind a `script` action, so permissions, audit and agent access apply to it like any other action; the planners' board as its own application. If the board *is* the product, start there.
+
+## 5. Workloads that require a certified platform
+
+**The scenario.** A hospital group wants an intake workflow, and its procurement requires that the platform it runs on hold a named attestation. A public-sector tender asks the same question of an ISO certificate. The workload itself, forms, routing, approvals and an audit trail, is a textbook fit.
+
+**What to use instead, and why.** Either a platform that holds the certificate, or a deployment you certify yourself, and the decision is the buyer's calendar, not the vendor's roadmap. The when-to-use page: "ObjectStack is open-source software you deploy and operate, and it carries no compliance certification of its own. Where a workload must run on a certified platform, certifying your deployment is work you own." That is not evasion; it is how certification works. An attestation covers a running environment, its controls and its operators, and an Apache-2.0 repository is none of those. This site's [security page](/en/security/) says the same of the commercial edition: "Certification depends on your running deployment, not a binary alone."
+
+**The cost of choosing wrong.** Discovering this at procurement rather than at design, when the timeline already assumed the platform brought its certificate. The audit then lands on your plan, unbudgeted, in front of the go-live.
+
+**The deciding fact.** The project's glossary lists even its own protocol conformance kit as "planned", with "no TCK program or certification mechanism in the codebase today". There is nothing to point an auditor at but your deployment.
+
+The workload is still a fit; the host is the question. The honest sequence is to price the certification work first, then decide.
+
+## Two more places another category starts ahead
+
+The comparison page adds two concessions that are not on the not-a-fit list, because they are about a kind of problem rather than a kind of workload. Both go through the six-kind test the same way.
+
+**Reasoning over heterogeneous data.** If the question is "what follows from everything we know", with class hierarchies, derived facts and consistency checks across vocabularies, that is a knowledge ontology's job, and ObjectStack has "no object inheritance, no axioms and no reasoner". The `abstract` key was removed from the spec rather than left as a promise. The definition is validated, then run; nothing is inferred at runtime. [The definition post](/en/blog/what-does-the-ontology-is-the-software-mean/) gives this negation its full treatment.
+
+**Ecosystem maturity.** Salesforce, Odoo and ERPNext "bring years of production use, packaged applications, app marketplaces and implementation partners. ObjectStack is younger; expect to build more of it yourself." If you need a packaged app this quarter and an implementation partner in your city, a younger platform is the wrong bet however its definitions are written.
+
+## The decision table
+
+Every row: the workload, whether it is a fit today and what to use instead, and the one fact that decides it, with its source. "Today" is a date: the sources are objectstack `origin/main` at `43567a8f`, read on 2026-10-16. Sources are named by file: when-to-use, compare and ontology are `content/docs/concepts/*.mdx`; external-datasources and analytics are under `content/docs/data-modeling/`; glossary is under `content/docs/getting-started/`; `engine.ts` is `packages/objectql/src/engine.ts`; `dataset.zod.ts` and `action.zod.ts` are under `packages/spec/src/ui/`.
+
+| Workload | Fit today? What to use instead | The deciding fact (source) |
+| :--- | :--- | :--- |
+| Core ERP or finance of a large enterprise | **No.** The packaged system; build around it | Regulation and edge cases are the product; the runtime's twelve capabilities include no ledger, tax or payroll engine (when-to-use; README capability table) |
+| Integrating many existing systems | **No.** A semantic or context layer; an operational ontology where there is writeback | Federation is read-only by default, twice: `allowWrites` on the datasource and `writable` on the object (external-datasources; `assertWriteAllowed` in `engine.ts`) |
+| Analytics over a data lake | **No.** A warehouse query engine, a metric layer, BI | A dataset binds to a base object; the drivers are row stores, with no lake format (analytics; `dataset.zod.ts`; README drivers) |
+| Algorithm-heavy domain | **Not for the algorithm.** Code; behind a `script` action when the rest is a business app | `ActionType` is script, url, modal, flow, api, form; the solver is never a type (`action.zod.ts`; when-to-use) |
+| Must run on a certified platform | **Not without work you own.** A certified platform, or certify your deployment | No compliance certification of its own; even the conformance kit is "planned" (when-to-use; glossary) |
+| Reasoning over heterogeneous data | **No.** A knowledge ontology with a reasoner | No inheritance, no axioms, no reasoner; `abstract` removed under ADR-0049 (ontology; compare) |
+| Needs a mature ecosystem now | **Not yet.** A metadata platform with packaged apps and partners | "ObjectStack is younger; expect to build more of it yourself" (compare) |
+| A new business app: CRM, ticketing, approvals, operations, internal tools | **Yes.** | Objects, relations, actions, permissions and flows are most of what these apps are (when-to-use) |
+| The long tail around a core ERP | **Yes.** | Small, specific, changes often; one typed definition per app, reading the ERP without owning it (when-to-use) |
+| A back office operated by agents from day one | **Yes.** | Every deployment is an MCP server, on by default, under the user's permissions (when-to-use; README) |
+
+
+
+## Run the self-check
+
+Ten questions, two stages, ten minutes. Stage one is the exclusion list; stage two is the when-to-use page's "Five questions before you start", quoted as it prints them.
+
+**Stage one. Any yes means the ontology is not the tool for that part.**
+
+1. Is the hard part of this workload a regulated calculation that a packaged system already encodes: a ledger, consolidation, tax, payroll?
+2. Does most of the value come from reading and writing systems you will keep and do not own?
+3. Is the data you want to analyse at rest in a lake or a warehouse rather than in the application's own records?
+4. Is the core of the product a solver, an optimiser or a simulation, or an interface unlike any business app?
+5. Must the workload run on a platform that holds a named certification, with no budget to certify a deployment of your own?
+
+**Stage two. Can your team answer these for the business, today?**
+
+6. "What we have — the objects and their fields."
+7. "How it relates — the lookups and master-detail links between them."
+8. "What can be done — the actions a user or an agent may take on a record."
+9. "Who may do it — permission sets, row-level and field-level security, sharing."
+10. "What happens when — record triggers, scheduled jobs, approvals, workflows."
+
+Five noes and five answers: the ontology is, in the page's words, "a day's work, because an agent does the writing." Five noes and no answers: "no tool helps yet, this one included. The first investment is answering these five questions, not installing anything." A yes in stage one: split the workload along that line, keep the part that passed, and use the table's alternative for the rest.
+
+## What this list does not say
+
+It does not say these limits are permanent. The page is titled "not a fit *today*", federation is called "early", and the table above carries a date; read it against the current page before you decide.
+
+It does not say the alternatives are better in general. A semantic layer is the right tool for reading across forty systems and the wrong one for running a ticketing desk, for the reasons the second section gives in the other direction. Each row's alternative is right for that row.
+
+And it does not say that failing one row fails the workload. Most real cases split: the intake workflow is a fit and the host is a procurement question; the dispatch domain is a fit and the solver is code; the departmental apps around the ERP are a fit and the ledger stays where it is. The six-kind test is applied to the hard part, not to the project name.
+
+## Where ObjectOS sits in this list
+
+Nothing above changes with the edition. "Want the same loop hosted, in the browser, nothing to install? That's ObjectOS, the commercial runtime environment built on ObjectStack." ObjectOS runs hosted in the browser with nothing to install (ObjectOS Cloud) or self-managed on your own infrastructure (ObjectOS Enterprise), and on either edition you can export your ontology and run it on the open-source ObjectStack runtime. The five workloads are about what an executable ontology can express, not about where it runs, so the list reads the same on every host. The one question that is about the host, certification, the security page answers for ObjectOS in the same terms as the open-source page: it depends on the running deployment.
+
+## If your case passed
+
+Then the fastest honest next step is not a demo; it is a definition. Point your coding agent at ObjectStack, with the rule file, the skills bundle and the tool server covered in [how to point your agent at ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/), and ask it for the first object: a few fields, one relation, one action, one permission set and one trigger. Run `npm run validate`, and read the diff before you read the Console. If you can read the whole diff and it says what your business does, the six-kind test has passed in practice, and [what the definition is](/en/ontology/) is the next page to hand the agent. If you cannot, nothing in this post was ever going to help, and you have just saved a project.
diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/index.zh-Hans.mdx b/content/blog/when-not-to-use-an-executable-business-ontology/index.zh-Hans.mdx
new file mode 100644
index 0000000..7d6b379
--- /dev/null
+++ b/content/blog/when-not-to-use-an-executable-business-ontology/index.zh-Hans.mdx
@@ -0,0 +1,149 @@
+---
+title: 什么时候不该用可执行业务本体？
+description: 五种今天不适合用可执行业务本体的工作负载：各自该用什么、为什么、选错的代价，加一张每行带出处的决策表和一份自检清单。
+author: ObjectStack Team
+date: 2026-11-05
+status: published
+topic: app-building
+audience: it
+solutions: []
+industries: []
+cover: ./cover.svg
+tags:
+ - 本体
+ - 可执行业务本体
+ - 选型
+---
+
+**先说结论：有五种工作负载不该用，而且是 ObjectStack 自己的文档点的名。** 取代大企业的核心 ERP 或财务系统；价值主要在于集成大量现有系统的工作；数据湖上的分析；定价、排程这类算法密集的领域——除非把算法包成一个动作；以及任何必须跑在认证平台上的工作。每一种都有一个更合适的工具。这篇文章逐个说清该用哪一个、为什么那是对的选择、选错了要付什么代价。文末有一张每行都带出处的决策表，还有一份十个问题的自检清单，装任何东西之前，先拿你自己的场景跑一遍。
+
+一份诚实的「什么情况下别用我」清单，是厂商能发布的最有用的东西，因为这是买方从销售材料里唯一拿不到的信息。ObjectStack 的一句话定位是「一份可执行的业务本体。AI 编写它，运行时运行它，Agent 操作它，你拥有它。」下面写的全是这句话的边界在哪里，材料取自项目自己的[什么时候用它](https://objectstack.ai/docs/concepts/when-to-use)页和[它与其他方案的对比](https://objectstack.ai/docs/concepts/compare)页（`origin/main`，2026 年 10 月 16 日读取），以及边界恰好就是一行代码的那些源码文件。本站的[对比页](/zh-Hans/compare/)已经把这五种工作负载和开工前的五个问题各用一行列过了；这篇是长版：每一种给一个具体场景、替代方案和它的道理、代价，以及一条起决定作用的事实。
+
+## 六类测试
+
+有一条测试能一次覆盖五种情形，所以先讲它。概念页把可执行业务本体的核心定义为六类东西：对象与字段、关系、动作、权限、流程、Agent 与工具定义。运行时从这六类推导出数据库、API、界面和 Agent 工具，并在每一次调用上强制执行它们。代码不会消失，但它搬进了运行时——钩子、动作体、CEL 和受限 JSX——在六类东西划出的围栏之内运行。
+
+于是对任何一个工作负载都可以问：**它最难的那部分，是不是这六类之一？** 如果这项工作里困难、值钱、有风险的部分，是在决定「有什么、怎么关联、能做什么、谁能做、什么时候发生什么」，那本体就是合适的工具，而且 Agent 写得出来。如果最难的部分是别的东西——一项法定计算、与四十个系统的连接、对 PB 级数据的扫描、一个求解器、一张审计师签发的证书——那这部分就不是一份定义能表达的，本体最多把它包起来，最糟是去模仿它。姑且把这叫作**六类测试**。下面五种工作负载各因为不同的原因过不了它，所以它们需要的是五个不同的替代方案，而不是一个。
+
+## 一、大企业的核心 ERP 或财务系统
+
+**场景。** 一家四千人的制造企业，总账、合并报表和薪酬在一套套装 ERP 上跑了十二年。编码 Agent 看过会计科目表之后，提议把它重新声明成对象：过账规则写成流程，税写成公式。演示很有说服力：凭证、试算平衡表、每一笔分录都带审批。
+
+**该用什么，为什么那是对的。** 用套装系统，并且围绕它来建。「什么时候用它」页这样写：「总账、合并、税务和薪酬承载着套装系统早已编码进去的法规与边角情况。围绕这个核心建，而不是取而代之。」在那个市场里，法规本身就是产品。一个薪酬引擎，是一座由税收辖区、申报日历和追溯调整组成的图书馆，由一群唯一工作就是保持它最新的人维护着；一个合并引擎，是多年积累的内部交易抵消和外币折算的边角情况。这些都不是「有什么、谁能做什么」，而是计算；它随政府的变化而变，不随你的业务而变。
+
+**选错的代价。** 第二本账。你重新编码的每一条规则，现在都是你要维护的 diff、你要通过的审计、换了税务年度之后出的缺陷；而你为法定申报留下的那套套装系统，每个季度都和你这份副本多差一点。一天就把规则写完的 Agent，没法替你读税法。
+
+**起决定作用的事实。** README 的能力表列出运行时提供的十二项能力：对象与字段、权限、自动化、审批、视图、仪表盘与报表、动作、API 与 SDK、AI 工具、翻译、种子数据、数据源。总账、税务引擎、薪酬计算都不在其中，项目也没有说它们在路上。
+
+同一页说适合的，是围绕这个核心的长尾：「供应商准入、巡检、内部申请」——那些追踪 ERP 不管的事的表格和表单。每一个都变成一份类型化定义，而不是靠邮件传来传去的文件；而且每一个都可以读 ERP 的数据而不必拥有它。这就是下一种情形。
+
+## 二、价值主要在于集成大量现有系统的工作
+
+**场景。** 一家银行希望它的 Agent 能同时从核心银行系统、CRM、卡平台和工单系统里回答一个客户的问题，并把一个状态写回其中两个。这些系统一个都不会搬。任务是让它们对 Agent 可读，并且能跨系统行动。
+
+**该用什么，为什么。** 架在这些系统之上的一层：读的部分用语义层或上下文层，有回写要治理时用 Palantir 那一类运营本体。对比页直接承认这一点：「当数据已经住在一个数据仓库、一个湖仓和十几个业务系统里时，它们从你所在的地方起步。」那些产品的前提假设就是记录系统留在原地：它们的对象模型是一个视图，它们的写入是回写，而它们的价值随底下系统的数量增长。ObjectStack 建立在相反的假设上——本体*就是*系统，数据库是从它推导出来的。
+
+**选错的代价。** 这是最常选错的一种，因为第一周会很顺。ObjectStack 可以用 `schemaMode: 'external'` 把一个外部数据库联邦接入为数据源，在一张遗留表上搭一个只读模型，一个下午就够。然后到了写入。联邦写入默认关闭，而且关了两道：数据源必须声明 `external.allowWrites: true`，对象必须声明 `external.writable: true`，「任一道闸门关着，对联邦对象的 insert/update/delete 都会被拒绝」。这道闸不是建议性的：`assertWriteAllowed` 在引擎的 `insert` 和 `update` 一开头就跑，在默认值、钩子和校验之前。你逐个对象把两道闸都打开，于是你开始对一个你不掌控的 schema 负责写入语义；而 `schemaMode: 'external'` 在 schema 不匹配时会让启动失败，上游改一个列名，你的应用就停了。或者你转而去写同步任务——到那时你已经把本来不想买的那层集成层自己造了一遍，而且是造在一个连自己的文档都把联邦称为「早期」的工具里。
+
+**起决定作用的事实。** 两道默认关闭的主动开启：数据源上的 `allowWrites` 和对象上的 `writable`（`content/docs/data-modeling/external-datasources.mdx` 讲写入的那一节），由 `packages/objectql/src/engine.ts` 里的 `assertWriteAllowed` 强制执行。
+
+诚实的路径是存在的，但很窄：只读接入，先测量，一个对象一个对象地开启写入，按对象切换。[如何把内部系统迁到元数据](/en/blog/how-to-move-an-internal-system-to-metadata/)走的就是这条路，包括那些正确答案是「根本不要迁」的情形。那条路是给你打算*取代*的系统走的。如果你打算留着四十个系统、跨着它们读，那就走错了路。
+
+## 三、数据湖上的分析
+
+**场景。** 一家零售商把三年的点击流和 POS 事件放在对象存储里，是 Parquet 和 Iceberg 表，品类团队想要仪表盘。有人注意到这个平台有仪表盘、报表，还有一个文档里称为语义层的数据集层，于是提议把它指向数据湖。
+
+**该用什么，为什么。** 数仓那一套：为列式扫描而生的查询引擎，上面一层指标层或语义层，顶上一个 BI 工具。ObjectStack 的分析层，是面向应用自己那些行的指标层。它的文档把数据集定义为「一个基础对象、要纳入的关系，以及声明出来的维度与度量」，连接从对象图推导；schema 把这件事写得很直白，数据集的 `object` 的描述就是「Base object name」（基础对象名）。「什么时候用它」页一句话说完：分析层「在应用自己的对象上定义指标，供它的报表和仪表盘使用。它不是为查询数据湖而建的。」数仓的语义层在数据湖之上做的是同一件事，本站的对比页也说，认真做 BI 的公司仍然需要一个。
+
+**选错的代价。** 两份副本选一份。要么把数据湖装进应用对象——于是你有了三年事件的第二份副本，带着它自己的新鲜度和它自己的账单，放在一个从业务定义推导出来、而不是为扫描设计的行存储里；要么联邦接入一张数仓表，然后发现你在把分析型问题送进一个为应用回答行级查询而建的引擎——有过滤下推，没有任何东西认识列式文件。仪表盘会渲染出来，但不会是品类团队要的那些仪表盘。
+
+**起决定作用的事实。** README 列出的驱动是 PostgreSQL、MySQL、SQLite、MongoDB、Turso、WebAssembly 里的 SQLite 和内存。没有数据湖格式，没有列式引擎，没有对象存储驱动；而数据集层绑定的是一个对象，不是数据湖里的一张表。
+
+## 四、定价、排程这类算法密集的领域
+
+**场景。** 一家物流公司的产品是路径优化器：一个求解器，输入一天的订单和一支车队，输出一份计划；再加一块调度看板，调度员把站点在车辆之间拖来拖去，看着计划重新求解。订单、车辆、司机和计划显然都是对象；公司问，整个东西能不能做成一份可执行本体。
+
+**该用什么，为什么。** 求解器和看板都用代码——而这里替代方案最有力的论证，恰恰来自本体自己的文档。「什么时候用它」页说：本体「声明能做什么；它不表达优化器。」一个动作的 `type` 只能是 `script`、`url`、`modal`、`flow`、`api`、`form` 之一，而一个 `script` 动作的处理函数是代码，以应用的全部数据权限运行。定义拥有的是那扇门、门上的权限、以及谁走过这扇门的审计。门后面的算法是你的，用什么语言能解就用什么。界面是同一个故事的另一个方向：对比页说，Console「是由元数据驱动的服务端渲染，一个不像任何业务应用的界面，直接做反而更容易。」
+
+**选错的代价。** 把最要紧的部分，建在自由度最小的地方。求解器可以住在一个动作后面——对于一次由记录触发的排程运行，这正合适。调度看板不行：页面里的受限 JSX「被解析成一棵服务端驱动的 UI 树，从不作为代码执行」，这是有意为之，于是调度员需要的每一个交互，都变成了和一个为列表、表单和看板而建的渲染器讨价还价。半年之后，本体成了你真正卖的那个东西外面薄薄的一层壳。
+
+**起决定作用的事实。** `packages/spec/src/ui/action.zod.ts` 里的 `ActionType` 是一个封闭集合：`script | url | modal | flow | api | form`。算法永远不是其中一项，它只是通往算法的那条路。
+
+行得通的切分是：业务那一半——订单、车辆、司机、谁可以批准一份计划、计划发布时发生什么——做成本体，让 Agent 能写、能操作；求解器做成 `script` 动作后面的代码，于是权限、审计和 Agent 访问像对待任何其他动作一样适用于它；调度员的看板做成它自己的应用。如果看板*就是*产品，从看板开始。
+
+## 五、必须跑在认证平台上的工作
+
+**场景。** 一家医院集团想要一个入院登记流程，它的采购要求所承载的平台持有某项指定的鉴证。一份政务招标对 ISO 证书问同一个问题。这项工作本身——表单、流转、审批、审计轨迹——是教科书式的适合。
+
+**该用什么，为什么。** 要么用一个持有证书的平台，要么由你自己为部署做认证；这个决定取决于买方的日历，不取决于厂商的路线图。「什么时候用它」页写道：「ObjectStack 是由你部署和运营的开源软件，它自身不带任何合规认证。当一项工作必须跑在认证平台上时，为你的部署做认证是你要承担的工作。」这不是回避，认证本来就是这样运作的：一份鉴证覆盖的是一个运行中的环境、它的控制措施和它的运营者，而一个 Apache-2.0 的代码仓库哪一样都不是。本站的[安全页](/zh-Hans/security/)对商业版说的是同一句话：认证取决于你运行中的部署，而不是一个二进制文件本身。
+
+**选错的代价。** 在采购阶段而不是设计阶段才发现这一点，而时间表早已默认平台会自带证书。于是审计落到你的计划里，没有预算，就在上线之前。
+
+**起决定作用的事实。** 项目的术语表把它自己的协议一致性测试套件都列为「计划中」，并写明「代码库里今天不存在 TCK 项目或认证机制」。除了你的部署，没有别的东西可以指给审计师看。
+
+这项工作仍然适合；问题在于它跑在哪里。诚实的顺序是先把认证工作的成本算出来，再做决定。
+
+## 另外两处别的类别起步更早
+
+对比页还承认了两点，它们不在「今天不适合」的清单上，因为它们说的是一类问题而不是一类工作负载。两者过六类测试的方式是一样的。
+
+**对异构数据做推理。** 如果问题是「从我们知道的一切能推出什么」——类层级、推导出的事实、跨词汇表的一致性检查——那是知识本体的工作，而 ObjectStack「没有对象继承、没有公理、没有推理器」。`abstract` 这个键是从 spec 里删掉的，而不是留作一个承诺。定义先校验、再运行；运行时不做任何推断。[那篇定义文章](/zh-Hans/blog/what-does-the-ontology-is-the-software-mean/)把这个「不是」讲全了。
+
+**生态成熟度。** Salesforce、Odoo 和 ERPNext「带来多年的生产使用、打包好的应用、应用市场和实施伙伴。ObjectStack 更年轻；要有更多东西自己建的准备。」如果你这个季度就需要一个打包好的应用、需要你所在城市里有一家实施伙伴，那么不管定义怎么写，一个更年轻的平台都是错的赌注。
+
+## 决策表
+
+每一行：工作负载、今天是否适合与该用什么，以及起决定作用的那一条事实和它的出处。「今天」是一个日期：出处是 objectstack `origin/main` 的 `43567a8f`，2026 年 10 月 16 日读取。出处按文件名写：when-to-use、compare、ontology 是 `content/docs/concepts/*.mdx`；external-datasources 和 analytics 在 `content/docs/data-modeling/` 下；glossary 在 `content/docs/getting-started/` 下；`engine.ts` 是 `packages/objectql/src/engine.ts`；`dataset.zod.ts` 和 `action.zod.ts` 在 `packages/spec/src/ui/` 下。
+
+| 工作负载 | 今天适合吗？该用什么 | 起决定作用的事实（出处） |
+| :--- | :--- | :--- |
+| 大企业的核心 ERP 或财务 | **否**：套装系统；围绕它建 | 法规和边角情况就是产品；运行时的十二项能力里没有总账、税务或薪酬引擎（when-to-use；README 能力表） |
+| 集成大量现有系统 | **否**：语义层或上下文层；有回写时用运营本体 | 联邦默认只读，而且关了两道：数据源上的 `allowWrites` 和对象上的 `writable`（external-datasources；`engine.ts` 的 `assertWriteAllowed`） |
+| 数据湖上的分析 | **否**：数仓查询引擎、指标层、BI | 数据集绑定到一个基础对象；驱动都是行存储，没有数据湖格式（analytics；`dataset.zod.ts`；README 驱动列表） |
+| 算法密集的领域 | **算法本身不适合**：代码；其余是业务应用时，放在 `script` 动作后面 | `ActionType` 是 script、url、modal、flow、api、form；求解器永远不是其中一种（`action.zod.ts`；when-to-use） |
+| 必须跑在认证平台上 | **不自己承担认证工作就不适合**：一个认证平台，或者为你的部署做认证 | 自身不带合规认证；连一致性测试套件都还是「计划中」（when-to-use；glossary） |
+| 对异构数据做推理 | **否**：带推理器的知识本体 | 没有继承、没有公理、没有推理器；`abstract` 按 ADR-0049 删除（ontology；compare） |
+| 现在就需要成熟生态 | **还不行**：有打包应用和实施伙伴的元数据平台 | 「ObjectStack 更年轻；要有更多东西自己建的准备」（compare） |
+| 新建业务应用：CRM、工单、审批、运营、内部工具 | **是** | 对象、关系、动作、权限和流程就是这些应用的大部分（when-to-use） |
+| 围绕核心 ERP 的长尾 | **是** | 小、具体、经常变；每个应用一份类型化定义，读 ERP 的数据而不拥有它（when-to-use） |
+| 从第一天起就由 Agent 操作的后台 | **是** | 每一个部署都是一个 MCP 服务器，默认开启，在用户自己的权限之下（when-to-use；README） |
+
+
+
+## 跑一遍自检
+
+十个问题，两个阶段，十分钟。第一阶段是排除清单；第二阶段是「什么时候用它」页上「开工前的五个问题」。
+
+**第一阶段。任一项答「是」，本体就不是这部分工作的工具。**
+
+1. 这项工作最难的部分，是不是一项套装系统早已编码好的法定计算：总账、合并、税务、薪酬？
+2. 大部分价值是不是来自读写那些你会留着、但并不拥有的系统？
+3. 你想分析的数据，是不是静置在数据湖或数仓里，而不在应用自己的记录里？
+4. 产品的核心是不是一个求解器、优化器或仿真，或者一个不像任何业务应用的界面？
+5. 这项工作是不是必须跑在持有指定认证的平台上，而且没有预算为自己的部署做认证？
+
+**第二阶段。你的团队今天能替业务回答这些吗？**
+
+6. 有什么——对象及其字段。
+7. 怎么关联——对象之间的查找（lookup）与主从（master-detail）链接。
+8. 能做什么——用户或 Agent 可以对一条记录发起的动作。
+9. 谁能做——权限集、行级与字段级安全、共享。
+10. 什么时候发生什么——记录触发器、定时任务、审批、工作流。
+
+五个「否」加五个答案：用那一页的话说，本体「是一天的活，因为写的是 Agent」。五个「否」但一个答案都没有：「还没有工具帮得上，这一个也不例外。第一笔投入是回答这五个问题，而不是安装任何东西。」第一阶段有一个「是」：沿着那条线把工作切开，留下通过的那部分，其余按表里的替代方案办。
+
+## 这份清单没有说的
+
+它没有说这些限制是永久的。那一页的标题是「*今天*不适合」，联邦被称为「早期」，上面的表带着日期；决定之前，拿它对照一下当前的页面。
+
+它没有说这些替代方案在一般意义上更好。语义层是跨四十个系统读数据的正确工具，也是运营一个工单台的错误工具——理由正是第二节反过来讲的那些。每一行的替代方案，只对那一行是对的。
+
+它也没有说过不了一行就等于整个工作过不了。真实的情形多半是切开的：入院登记流程适合，承载平台是采购问题；调度这个领域适合，求解器是代码；围绕 ERP 的部门应用适合，总账留在原地。六类测试针对的是最难的那部分，不是项目的名字。
+
+## ObjectOS 在这份清单里的位置
+
+上面说的一切不随版本而变。「想把同一个循环托管起来、在浏览器里用、什么都不用安装？那就是 ObjectOS——建立在 ObjectStack 之上的商业运行环境。」ObjectOS 既可托管在浏览器中、无需安装（ObjectOS Cloud），也可自管部署在你自己的基础设施上（ObjectOS Enterprise）；无论哪个版本，你都可以导出本体，拿到开源的 ObjectStack 运行时上运行。这五种工作负载说的是一份可执行本体能表达什么，不是它跑在哪里，所以这份清单在任何承载环境上读起来都一样。唯一一个和承载环境有关的问题是认证，安全页对 ObjectOS 的回答和开源页的措辞一致：取决于运行中的部署。
+
+## 如果你的场景通过了
+
+那么最快、也最诚实的下一步不是看演示，而是写一份定义。把你的编码 Agent 指向 ObjectStack——规则文件、技能包和工具服务器见[如何把你的 Agent 指向 ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/)——然后向它要第一个对象：几个字段、一个关系、一个动作、一个权限集、一个触发器。跑 `npm run validate`，先读 diff，再看 Console。如果你能把整份 diff 读完，而且它说的就是你的业务在做的事，那六类测试在实践中就通过了，下一页该交给 Agent 的是[定义本身是什么](/zh-Hans/ontology/)。如果读不完，这篇文章本来也帮不了你，而你刚刚省下了一个项目。
diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/index.zh-Hant.mdx b/content/blog/when-not-to-use-an-executable-business-ontology/index.zh-Hant.mdx
new file mode 100644
index 0000000..690bde1
--- /dev/null
+++ b/content/blog/when-not-to-use-an-executable-business-ontology/index.zh-Hant.mdx
@@ -0,0 +1,150 @@
+---
+# @generated zh-Hant from zh-Hans (s2twp) — edit the zh-Hans file; delete this line to hand-maintain.
+title: 什麼時候不該用可執行業務本體？
+description: 五種今天不適合用可執行業務本體的工作負載：各自該用什麼、為什麼、選錯的代價，加一張每行帶出處的決策表和一份自檢清單。
+author: ObjectStack Team
+date: 2026-11-05
+status: published
+topic: app-building
+audience: it
+solutions: []
+industries: []
+cover: ./cover.svg
+tags:
+ - 本體
+ - 可執行業務本體
+ - 選型
+---
+
+**先說結論：有五種工作負載不該用，而且是 ObjectStack 自己的文件點的名。** 取代大企業的核心 ERP 或財務系統；價值主要在於整合大量現有系統的工作；資料湖上的分析；定價、排程這類演算法密集的領域——除非把演算法包成一個動作；以及任何必須跑在認證平臺上的工作。每一種都有一個更合適的工具。這篇文章逐個說清該用哪一個、為什麼那是對的選擇、選錯了要付什麼代價。文末有一張每行都帶出處的決策表，還有一份十個問題的自檢清單，裝任何東西之前，先拿你自己的場景跑一遍。
+
+一份誠實的「什麼情況下別用我」清單，是廠商能釋出的最有用的東西，因為這是買方從銷售材料裡唯一拿不到的資訊。ObjectStack 的一句話定位是「一份可執行的業務本體。AI 編寫它，執行時執行它，Agent 操作它，你擁有它。」下面寫的全是這句話的邊界在哪裡，材料取自專案自己的[什麼時候用它](https://objectstack.ai/docs/concepts/when-to-use)頁和[它與其他方案的對比](https://objectstack.ai/docs/concepts/compare)頁（`origin/main`，2026 年 10 月 16 日讀取），以及邊界恰好就是一行程式碼的那些原始碼檔案。本站的[對比頁](/zh-Hant/compare/)已經把這五種工作負載和開工前的五個問題各用一行列過了；這篇是長版：每一種給一個具體場景、替代方案和它的道理、代價，以及一條起決定作用的事實。
+
+## 六類測試
+
+有一條測試能一次覆蓋五種情形，所以先講它。概念頁把可執行業務本體的核心定義為六類東西：物件與欄位、關係、動作、權限、流程、Agent 與工具定義。執行時從這六類推匯出資料庫、API、介面和 Agent 工具，並在每一次呼叫上強制執行它們。程式碼不會消失，但它搬進了執行時——鉤子、動作體、CEL 和受限 JSX——在六類東西劃出的圍欄之內執行。
+
+於是對任何一個工作負載都可以問：**它最難的那部分，是不是這六類之一？** 如果這項工作裡困難、值錢、有風險的部分，是在決定「有什麼、怎麼關聯、能做什麼、誰能做、什麼時候發生什麼」，那本體就是合適的工具，而且 Agent 寫得出來。如果最難的部分是別的東西——一項法定計算、與四十個系統的連線、對 PB 級資料的掃描、一個求解器、一張審計師簽發的證書——那這部分就不是一份定義能表達的，本體最多把它包起來，最糟是去模仿它。姑且把這叫作**六類測試**。下面五種工作負載各因為不同的原因過不了它，所以它們需要的是五個不同的替代方案，而不是一個。
+
+## 一、大企業的核心 ERP 或財務系統
+
+**場景。** 一家四千人的製造企業，總賬、合併報表和薪酬在一套套裝 ERP 上跑了十二年。編碼 Agent 看過會計科目表之後，提議把它重新宣告成物件：過賬規則寫成流程，稅寫成公式。演示很有說服力：憑證、試算平衡表、每一筆分錄都帶審批。
+
+**該用什麼，為什麼那是對的。** 用套裝系統，並且圍繞它來建。「什麼時候用它」頁這樣寫：「總賬、合併、稅務和薪酬承載著套裝系統早已編碼進去的法規與邊角情況。圍繞這個核心建，而不是取而代之。」在那個市場裡，法規本身就是產品。一個薪酬引擎，是一座由稅收轄區、申報日曆和追溯調整組成的圖書館，由一群唯一工作就是保持它最新的人維護著；一個合併引擎，是多年積累的內部交易抵消和外幣折算的邊角情況。這些都不是「有什麼、誰能做什麼」，而是計算；它隨政府的變化而變，不隨你的業務而變。
+
+**選錯的代價。** 第二本賬。你重新編碼的每一條規則，現在都是你要維護的 diff、你要通過的審計、換了稅務年度之後出的缺陷；而你為法定申報留下的那套套裝系統，每個季度都和你這份副本多差一點。一天就把規則寫完的 Agent，沒法替你讀稅法。
+
+**起決定作用的事實。** README 的能力表列出執行時提供的十二項能力：物件與欄位、權限、自動化、審批、檢視、儀表盤與報表、動作、API 與 SDK、AI 工具、翻譯、種子資料、資料來源。總賬、稅務引擎、薪酬計算都不在其中，專案也沒有說它們在路上。
+
+同一頁說適合的，是圍繞這個核心的長尾：「供應商准入、巡檢、內部申請」——那些追蹤 ERP 不管的事的表格和表單。每一個都變成一份型別化定義，而不是靠郵件傳來傳去的檔案；而且每一個都可以讀 ERP 的資料而不必擁有它。這就是下一種情形。
+
+## 二、價值主要在於整合大量現有系統的工作
+
+**場景。** 一家銀行希望它的 Agent 能同時從核心銀行系統、CRM、卡平臺和工單系統裡回答一個客戶的問題，並把一個狀態寫回其中兩個。這些系統一個都不會搬。任務是讓它們對 Agent 可讀，並且能跨系統行動。
+
+**該用什麼，為什麼。** 架在這些系統之上的一層：讀的部分用語義層或上下文層，有回寫要治理時用 Palantir 那一類運營本體。對比頁直接承認這一點：「當資料已經住在一個數據倉庫、一個湖倉和十幾個業務系統裡時，它們從你所在的地方起步。」那些產品的前提假設就是記錄系統留在原地：它們的物件模型是一個檢視，它們的寫入是回寫，而它們的價值隨底下系統的數量增長。ObjectStack 建立在相反的假設上——本體*就是*系統，資料庫是從它推匯出來的。
+
+**選錯的代價。** 這是最常選錯的一種，因為第一週會很順。ObjectStack 可以用 `schemaMode: 'external'` 把一個外部資料庫聯邦接入為資料來源，在一張遺留表上搭一個只讀模型，一個下午就夠。然後到了寫入。聯邦寫入預設關閉，而且關了兩道：資料來源必須宣告 `external.allowWrites: true`，物件必須宣告 `external.writable: true`，「任一道閘門關著，對聯邦物件的 insert/update/delete 都會被拒絕」。這道閘不是建議性的：`assertWriteAllowed` 在引擎的 `insert` 和 `update` 一開頭就跑，在預設值、鉤子和校驗之前。你逐個物件把兩道閘都開啟，於是你開始對一個你不掌控的 schema 負責寫入語義；而 `schemaMode: 'external'` 在 schema 不匹配時會讓啟動失敗，上游改一個列名，你的應用就停了。或者你轉而去寫同步任務——到那時你已經把本來不想買的那層整合層自己造了一遍，而且是造在一個連自己的文件都把聯邦稱為「早期」的工具裡。
+
+**起決定作用的事實。** 兩道預設關閉的主動開啟：資料來源上的 `allowWrites` 和物件上的 `writable`（`content/docs/data-modeling/external-datasources.mdx` 講寫入的那一節），由 `packages/objectql/src/engine.ts` 裡的 `assertWriteAllowed` 強制執行。
+
+誠實的路徑是存在的，但很窄：只讀接入，先測量，一個物件一個物件地開啟寫入，按物件切換。[如何把內部系統遷到後設資料](/en/blog/how-to-move-an-internal-system-to-metadata/)走的就是這條路，包括那些正確答案是「根本不要遷」的情形。那條路是給你打算*取代*的系統走的。如果你打算留著四十個系統、跨著它們讀，那就走錯了路。
+
+## 三、資料湖上的分析
+
+**場景。** 一家零售商把三年的點選流和 POS 事件放在物件儲存裡，是 Parquet 和 Iceberg 表，品類團隊想要儀表盤。有人注意到這個平臺有儀表盤、報表，還有一個文件裡稱為語義層的資料集層，於是提議把它指向資料湖。
+
+**該用什麼，為什麼。** 數倉那一套：為列式掃描而生的查詢引擎，上面一層指標層或語義層，頂上一個 BI 工具。ObjectStack 的分析層，是面向應用自己那些行的指標層。它的文件把資料集定義為「一個基礎物件、要納入的關係，以及宣告出來的維度與度量」，連線從物件圖推導；schema 把這件事寫得很直白，資料集的 `object` 的描述就是「Base object name」（基礎物件名）。「什麼時候用它」頁一句話說完：分析層「在應用自己的物件上定義指標，供它的報表和儀表盤使用。它不是為查詢資料湖而建的。」數倉的語義層在資料湖之上做的是同一件事，本站的對比頁也說，認真做 BI 的公司仍然需要一個。
+
+**選錯的代價。** 兩份副本選一份。要麼把資料湖裝進應用物件——於是你有了三年事件的第二份副本，帶著它自己的新鮮度和它自己的賬單，放在一個從業務定義推匯出來、而不是為掃描設計的行儲存裡；要麼聯邦接入一張數倉表，然後發現你在把分析型問題送進一個為應用回答行級查詢而建的引擎——有過濾下推，沒有任何東西認識列式檔案。儀表盤會渲染出來，但不會是品類團隊要的那些儀表盤。
+
+**起決定作用的事實。** README 列出的驅動是 PostgreSQL、MySQL、SQLite、MongoDB、Turso、WebAssembly 裡的 SQLite 和記憶體。沒有資料湖格式，沒有列式引擎，沒有物件儲存驅動；而資料集層繫結的是一個物件，不是資料湖裡的一張表。
+
+## 四、定價、排程這類演算法密集的領域
+
+**場景。** 一家物流公司的產品是路徑最佳化器：一個求解器，輸入一天的訂單和一支車隊，輸出一份計劃；再加一塊排程看板，排程員把站點在車輛之間拖來拖去，看著計劃重新求解。訂單、車輛、司機和計劃顯然都是物件；公司問，整個東西能不能做成一份可執行本體。
+
+**該用什麼，為什麼。** 求解器和看板都用程式碼——而這裡替代方案最有力的論證，恰恰來自本體自己的文件。「什麼時候用它」頁說：本體「宣告能做什麼；它不表達最佳化器。」一個動作的 `type` 只能是 `script`、`url`、`modal`、`flow`、`api`、`form` 之一，而一個 `script` 動作的處理函式是程式碼，以應用的全部資料權限執行。定義擁有的是那扇門、門上的權限、以及誰走過這扇門的審計。門後面的演算法是你的，用什麼語言能解就用什麼。介面是同一個故事的另一個方向：對比頁說，Console「是由後設資料驅動的服務端渲染，一個不像任何業務應用的介面，直接做反而更容易。」
+
+**選錯的代價。** 把最要緊的部分，建在自由度最小的地方。求解器可以住在一個動作後面——對於一次由記錄觸發的排程執行，這正合適。排程看板不行：頁面裡的受限 JSX「被解析成一棵服務端驅動的 UI 樹，從不作為程式碼執行」，這是有意為之，於是排程員需要的每一個互動，都變成了和一個為列表、表單和看板而建的渲染器討價還價。半年之後，本體成了你真正賣的那個東西外面薄薄的一層殼。
+
+**起決定作用的事實。** `packages/spec/src/ui/action.zod.ts` 裡的 `ActionType` 是一個封閉集合：`script | url | modal | flow | api | form`。演算法永遠不是其中一項，它只是通往演算法的那條路。
+
+行得通的切分是：業務那一半——訂單、車輛、司機、誰可以批准一份計劃、計劃釋出時發生什麼——做成本體，讓 Agent 能寫、能操作；求解器做成 `script` 動作後面的程式碼，於是權限、審計和 Agent 訪問像對待任何其他動作一樣適用於它；排程員的看板做成它自己的應用。如果看板*就是*產品，從看板開始。
+
+## 五、必須跑在認證平臺上的工作
+
+**場景。** 一家醫院集團想要一個入院登記流程，它的採購要求所承載的平臺持有某項指定的鑑證。一份政務招標對 ISO 證書問同一個問題。這項工作本身——表單、流轉、審批、審計軌跡——是教科書式的適合。
+
+**該用什麼，為什麼。** 要麼用一個持有證書的平臺，要麼由你自己為部署做認證；這個決定取決於買方的日曆，不取決於廠商的路線圖。「什麼時候用它」頁寫道：「ObjectStack 是由你部署和運營的開源軟體，它自身不帶任何合規認證。當一項工作必須跑在認證平臺上時，為你的部署做認證是你要承擔的工作。」這不是迴避，認證本來就是這樣運作的：一份鑑證覆蓋的是一個執行中的環境、它的控制措施和它的運營者，而一個 Apache-2.0 的程式碼倉庫哪一樣都不是。本站的[安全頁](/zh-Hant/security/)對商業版說的是同一句話：認證取決於你執行中的部署，而不是一個二進位制檔案本身。
+
+**選錯的代價。** 在採購階段而不是設計階段才發現這一點，而時間表早已預設平臺會自帶證書。於是審計落到你的計劃裡，沒有預算，就在上線之前。
+
+**起決定作用的事實。** 專案的術語表把它自己的協議一致性測試套件都列為「計劃中」，並寫明「程式碼庫裡今天不存在 TCK 專案或認證機制」。除了你的部署，沒有別的東西可以指給審計師看。
+
+這項工作仍然適合；問題在於它跑在哪裡。誠實的順序是先把認證工作的成本算出來，再做決定。
+
+## 另外兩處別的類別起步更早
+
+對比頁還承認了兩點，它們不在「今天不適合」的清單上，因為它們說的是一類問題而不是一類工作負載。兩者過六類測試的方式是一樣的。
+
+**對異構資料做推理。** 如果問題是「從我們知道的一切能推出什麼」——類層級、推匯出的事實、跨詞彙表的一致性檢查——那是知識本體的工作，而 ObjectStack「沒有物件繼承、沒有公理、沒有推理器」。`abstract` 這個鍵是從 spec 裡刪掉的，而不是留作一個承諾。定義先校驗、再執行；執行時不做任何推斷。[那篇定義文章](/zh-Hant/blog/what-does-the-ontology-is-the-software-mean/)把這個「不是」講全了。
+
+**生態成熟度。** Salesforce、Odoo 和 ERPNext「帶來多年的生產使用、打包好的應用、應用市場和實施夥伴。ObjectStack 更年輕；要有更多東西自己建的準備。」如果你這個季度就需要一個打包好的應用、需要你所在城市裡有一家實施夥伴，那麼不管定義怎麼寫，一個更年輕的平臺都是錯的賭注。
+
+## 決策表
+
+每一行：工作負載、今天是否適合與該用什麼，以及起決定作用的那一條事實和它的出處。「今天」是一個日期：出處是 objectstack `origin/main` 的 `43567a8f`，2026 年 10 月 16 日讀取。出處按檔名寫：when-to-use、compare、ontology 是 `content/docs/concepts/*.mdx`；external-datasources 和 analytics 在 `content/docs/data-modeling/` 下；glossary 在 `content/docs/getting-started/` 下；`engine.ts` 是 `packages/objectql/src/engine.ts`；`dataset.zod.ts` 和 `action.zod.ts` 在 `packages/spec/src/ui/` 下。
+
+| 工作負載 | 今天適合嗎？該用什麼 | 起決定作用的事實（出處） |
+| :--- | :--- | :--- |
+| 大企業的核心 ERP 或財務 | **否**：套裝系統；圍繞它建 | 法規和邊角情況就是產品；執行時的十二項能力裡沒有總賬、稅務或薪酬引擎（when-to-use；README 能力表） |
+| 整合大量現有系統 | **否**：語義層或上下文層；有回寫時用運營本體 | 聯邦預設只讀，而且關了兩道：資料來源上的 `allowWrites` 和物件上的 `writable`（external-datasources；`engine.ts` 的 `assertWriteAllowed`） |
+| 資料湖上的分析 | **否**：數倉查詢引擎、指標層、BI | 資料集繫結到一個基礎物件；驅動都是行儲存，沒有資料湖格式（analytics；`dataset.zod.ts`；README 驅動列表） |
+| 演算法密集的領域 | **演算法本身不適合**：程式碼；其餘是業務應用時，放在 `script` 動作後面 | `ActionType` 是 script、url、modal、flow、api、form；求解器永遠不是其中一種（`action.zod.ts`；when-to-use） |
+| 必須跑在認證平臺上 | **不自己承擔認證工作就不適合**：一個認證平臺，或者為你的部署做認證 | 自身不帶合規認證；連一致性測試套件都還是「計劃中」（when-to-use；glossary） |
+| 對異構資料做推理 | **否**：帶推理器的知識本體 | 沒有繼承、沒有公理、沒有推理器；`abstract` 按 ADR-0049 刪除（ontology；compare） |
+| 現在就需要成熟生態 | **還不行**：有打包應用和實施夥伴的後設資料平臺 | 「ObjectStack 更年輕；要有更多東西自己建的準備」（compare） |
+| 新建業務應用：CRM、工單、審批、運營、內部工具 | **是** | 物件、關係、動作、權限和流程就是這些應用的大部分（when-to-use） |
+| 圍繞核心 ERP 的長尾 | **是** | 小、具體、經常變；每個應用一份型別化定義，讀 ERP 的資料而不擁有它（when-to-use） |
+| 從第一天起就由 Agent 操作的後臺 | **是** | 每一個部署都是一個 MCP 伺服器，預設開啟，在使用者自己的權限之下（when-to-use；README） |
+
+
+
+## 跑一遍自檢
+
+十個問題，兩個階段，十分鐘。第一階段是排除清單；第二階段是「什麼時候用它」頁上「開工前的五個問題」。
+
+**第一階段。任一項答「是」，本體就不是這部分工作的工具。**
+
+1. 這項工作最難的部分，是不是一項套裝系統早已編碼好的法定計算：總賬、合併、稅務、薪酬？
+2. 大部分價值是不是來自讀寫那些你會留著、但並不擁有的系統？
+3. 你想分析的資料，是不是靜置在資料湖或數倉裡，而不在應用自己的記錄裡？
+4. 產品的核心是不是一個求解器、最佳化器或模擬，或者一個不像任何業務應用的介面？
+5. 這項工作是不是必須跑在持有指定認證的平臺上，而且沒有預算為自己的部署做認證？
+
+**第二階段。你的團隊今天能替業務回答這些嗎？**
+
+6. 有什麼——物件及其欄位。
+7. 怎麼關聯——物件之間的查詢（lookup）與主從（master-detail）連結。
+8. 能做什麼——使用者或 Agent 可以對一條記錄發起的動作。
+9. 誰能做——權限集、行級與欄位級安全、共享。
+10. 什麼時候發生什麼——記錄觸發器、定時任務、審批、工作流。
+
+五個「否」加五個答案：用那一頁的話說，本體「是一天的活，因為寫的是 Agent」。五個「否」但一個答案都沒有：「還沒有工具幫得上，這一個也不例外。第一筆投入是回答這五個問題，而不是安裝任何東西。」第一階段有一個「是」：沿著那條線把工作切開，留下通過的那部分，其餘按表裡的替代方案辦。
+
+## 這份清單沒有說的
+
+它沒有說這些限制是永久的。那一頁的標題是「*今天*不適合」，聯邦被稱為「早期」，上面的錶帶著日期；決定之前，拿它對照一下當前的頁面。
+
+它沒有說這些替代方案在一般意義上更好。語義層是跨四十個系統讀資料的正確工具，也是運營一個工單臺的錯誤工具——理由正是第二節反過來講的那些。每一行的替代方案，只對那一行是對的。
+
+它也沒有說過不了一行就等於整個工作過不了。真實的情形多半是切開的：入院登記流程適合，承載平臺是採購問題；排程這個領域適合，求解器是程式碼；圍繞 ERP 的部門應用適合，總賬留在原地。六類測試針對的是最難的那部分，不是專案的名字。
+
+## ObjectOS 在這份清單裡的位置
+
+上面說的一切不隨版本而變。「想把同一個迴圈託管起來、在瀏覽器裡用、什麼都不用安裝？那就是 ObjectOS——建立在 ObjectStack 之上的商業執行環境。」ObjectOS 既可託管在瀏覽器中、無需安裝（ObjectOS Cloud），也可自管部署在你自己的基礎設施上（ObjectOS Enterprise）；無論哪個版本，你都可以匯出本體，拿到開源的 ObjectStack 執行時上執行。這五種工作負載說的是一份可執行本體能表達什麼，不是它跑在哪裡，所以這份清單在任何承載環境上讀起來都一樣。唯一一個和承載環境有關的問題是認證，安全頁對 ObjectOS 的回答和開源頁的措辭一致：取決於執行中的部署。
+
+## 如果你的場景通過了
+
+那麼最快、也最誠實的下一步不是看演示，而是寫一份定義。把你的編碼 Agent 指向 ObjectStack——規則檔案、技能包和工具伺服器見[如何把你的 Agent 指向 ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/)——然後向它要第一個物件：幾個欄位、一個關係、一個動作、一個權限集、一個觸發器。跑 `npm run validate`，先讀 diff，再看 Console。如果你能把整份 diff 讀完，而且它說的就是你的業務在做的事，那六類測試在實踐中就通過了，下一頁該交給 Agent 的是[定義本身是什麼](/zh-Hant/ontology/)。如果讀不完，這篇文章本來也幫不了你，而你剛剛省下了一個專案。
diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/self-check-en.svg b/content/blog/when-not-to-use-an-executable-business-ontology/self-check-en.svg
new file mode 100644
index 0000000..28b0678
--- /dev/null
+++ b/content/blog/when-not-to-use-an-executable-business-ontology/self-check-en.svg
@@ -0,0 +1,97 @@
+
diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/self-check.svg b/content/blog/when-not-to-use-an-executable-business-ontology/self-check.svg
new file mode 100644
index 0000000..ff3af91
--- /dev/null
+++ b/content/blog/when-not-to-use-an-executable-business-ontology/self-check.svg
@@ -0,0 +1,97 @@
+