From f334b8b2cff2488c591687367a0cf36ba019b064 Mon Sep 17 00:00:00 2001 From: "objectstack-fleet[bot]" Date: Fri, 16 Oct 2026 07:59:21 +0000 Subject: [PATCH 1/6] content(blog): when should you not use an executable business ontology? (slot 2026-11-05) One new post directory. en and zh-Hans authored (the Chinese re-derived from the same sources), zh-Hant generated by pnpm gen:zh-hant. Five workloads that are not a fit today, each with a scenario, the alternative and its case, the cost of choosing wrong and the deciding fact with its source; two further concessions from the comparison page; a sourced decision table and a ten-question self-check. Cover and self-check diagram as zh / en SVG pairs with an explicit fill on every text node. Co-Authored-By: Claude Claude-Session: https://claude.ai/code/session_017GeNDQH7E5S2rX8ajVAPxv --- .../cover-en.svg | 60 +++++++ .../cover.svg | 60 +++++++ .../index.mdx | 149 +++++++++++++++++ .../index.zh-Hans.mdx | 149 +++++++++++++++++ .../index.zh-Hant.mdx | 150 ++++++++++++++++++ .../self-check-en.svg | 96 +++++++++++ .../self-check.svg | 96 +++++++++++ 7 files changed, 760 insertions(+) create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/cover-en.svg create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/cover.svg create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/index.mdx create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/index.zh-Hans.mdx create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/index.zh-Hant.mdx create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/self-check-en.svg create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/self-check.svg 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 @@ + + + + + + + + + + + AN HONEST LIST + When not to use + an executable + business ontology + Five workloads where it is the wrong tool today, + what to use instead, and the fact that decides each. + + + + is the hard part one of the six kinds? + + + + + + 1 + Core ERP or finance of a large enterprise + → the packaged system; build around it + + + + + 2 + Integrating many existing systems + → a layer over those systems + + + + + 3 + Analytics over a data lake + → the warehouse stack + + + + + 4 + Algorithm-heavy domains + → code, behind an action if at all + + + + + 5 + A certified platform required + → certification you own + + + Sources: objectstack when-to-use.mdx and compare.mdx, origin/main 43567a8f, read 2026-10-16. + 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 @@ + + + + + + + + + + + 一份诚实的清单 + 可执行业务本体 + 什么时候 + 不该用？ + 五种今天不适合的工作负载、各自该用什么， + 以及决定取舍的那一条事实。 + + + + 最难的部分，是不是六类之一？ + + + + + + 1 + 大企业的核心 ERP 或财务系统 + → 套装系统；围绕它建，不取代它 + + + + + 2 + 以集成大量现有系统为主的工作 + → 架在这些系统之上的一层 + + + + + 3 + 数据湖上的分析 + → 数仓那一套 + + + + + 4 + 算法密集的领域 + → 代码；至多包成一个动作 + + + + + 5 + 必须跑在认证平台上 + → 认证是你自己的工作 + + + 来源：objectstack 的 when-to-use.mdx 与 compare.mdx，origin/main 43567a8f，2026-10-16 读取。 + 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..3cb379b --- /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, 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. + +| Workload | Fit today? | 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.mdx`; 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.mdx`; `objectql/src/engine.ts`, `assertWriteAllowed`) | +| 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.mdx`; `spec/src/ui/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 (`spec/src/ui/action.zod.ts`; `when-to-use.mdx`) | +| 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.mdx`; `glossary.mdx`) | +| Reasoning over heterogeneous data | No | A knowledge ontology with a reasoner | No inheritance, no axioms, no reasoner; `abstract` removed under ADR-0049 (`ontology.mdx`; `compare.mdx`) | +| 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.mdx`) | +| 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.mdx`) | +| 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.mdx`) | +| 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.mdx`; README) | + +![The self-check in two stages. Stage one, five exclusions, any yes means the ontology is not the tool for that part: a ledger, consolidation, tax or payroll calculation; value mostly in systems you keep and do not own; data at rest in a lake or warehouse; a solver, optimiser or an interface unlike any business app; a platform that must hold a named certification. Stage two, the five questions before you start: what we have, how it relates, what can be done, who may do it, what happens when. Three verdicts: five noes and five answers is a fit and a day's work for an agent; any yes splits the workload on that line; noes without answers means no tool helps yet.](./self-check-en.svg) + +## 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..e959764 --- /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 日读取），以及边界恰好就是一行代码的那些源码文件。本站导航里的「对比」页已经把这五种工作负载和开工前的五个问题各用一行列过了；这篇是长版：每一种给一个具体场景、替代方案和它的道理、代价，以及一条起决定作用的事实。 + +## 六类测试 + +有一条测试能一次覆盖五种情形，所以先讲它。概念页把可执行业务本体的核心定义为六类东西：对象与字段、关系、动作、权限、流程、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 日读取。 + +| 工作负载 | 今天适合吗 | 该用什么 | 起决定作用的事实（出处） | +| :--- | :--- | :--- | :--- | +| 大企业的核心 ERP 或财务 | 否 | 套装系统；围绕它建 | 法规和边角情况就是产品；运行时的十二项能力里没有总账、税务或薪酬引擎（`when-to-use.mdx`；README 能力表） | +| 集成大量现有系统 | 否 | 语义层或上下文层；有回写时用运营本体 | 联邦默认只读，而且关了两道：数据源上的 `allowWrites` 和对象上的 `writable`（`external-datasources.mdx`；`objectql/src/engine.ts` 的 `assertWriteAllowed`） | +| 数据湖上的分析 | 否 | 数仓查询引擎、指标层、BI | 数据集绑定到一个基础对象；驱动都是行存储，没有数据湖格式（`analytics.mdx`；`spec/src/ui/dataset.zod.ts`；README 驱动列表） | +| 算法密集的领域 | 算法本身不适合 | 代码；其余是业务应用时，放在 `script` 动作后面 | `ActionType` 是 `script, url, modal, flow, api, form`；求解器永远不是其中一种（`spec/src/ui/action.zod.ts`；`when-to-use.mdx`） | +| 必须跑在认证平台上 | 不自己承担认证工作就不适合 | 一个认证平台，或者为你的部署做认证 | 自身不带合规认证；连一致性测试套件都还是「计划中」（`when-to-use.mdx`；`glossary.mdx`） | +| 对异构数据做推理 | 否 | 带推理器的知识本体 | 没有继承、没有公理、没有推理器；`abstract` 按 ADR-0049 删除（`ontology.mdx`；`compare.mdx`） | +| 现在就需要成熟生态 | 还不行 | 有打包应用和实施伙伴的元数据平台 | 「ObjectStack 更年轻；要有更多东西自己建的准备」（`compare.mdx`） | +| 新建业务应用：CRM、工单、审批、运营、内部工具 | 是 | | 对象、关系、动作、权限和流程就是这些应用的大部分（`when-to-use.mdx`） | +| 围绕核心 ERP 的长尾 | 是 | | 小、具体、经常变；每个应用一份类型化定义，读 ERP 的数据而不拥有它（`when-to-use.mdx`） | +| 从第一天起就由 Agent 操作的后台 | 是 | | 每一个部署都是一个 MCP 服务器，默认开启，在用户自己的权限之下（`when-to-use.mdx`；README） | + +![两阶段自检。第一阶段，五项排除，任一项答「是」就说明本体不是这部分工作的工具：总账、合并、税务或薪酬计算；价值主要在你留着但不拥有的系统里；数据静置在数据湖或数仓里；核心是求解器、优化器，或一个不像任何业务应用的界面；平台必须持有指定认证。第二阶段，开工前的五个问题：有什么、怎么关联、能做什么、谁能做、什么时候发生什么。三种判定：五个「否」加五个答案是适合，对 Agent 来说是一天的活；任一个「是」就沿那条线把工作切开；只有「否」没有答案，说明还没有工具帮得上。](./self-check.svg) + +## 跑一遍自检 + +十个问题，两个阶段，十分钟。第一阶段是排除清单；第二阶段是「什么时候用它」页上「开工前的五个问题」。 + +**第一阶段。任一项答「是」，本体就不是这部分工作的工具。** + +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 的是[定义本身是什么](https://objectstack.ai/docs/concepts/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..89abfe1 --- /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 日讀取），以及邊界恰好就是一行程式碼的那些原始碼檔案。本站導航裡的「對比」頁已經把這五種工作負載和開工前的五個問題各用一行列過了；這篇是長版：每一種給一個具體場景、替代方案和它的道理、代價，以及一條起決定作用的事實。 + +## 六類測試 + +有一條測試能一次覆蓋五種情形，所以先講它。概念頁把可執行業務本體的核心定義為六類東西：物件與欄位、關係、動作、權限、流程、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 日讀取。 + +| 工作負載 | 今天適合嗎 | 該用什麼 | 起決定作用的事實（出處） | +| :--- | :--- | :--- | :--- | +| 大企業的核心 ERP 或財務 | 否 | 套裝系統；圍繞它建 | 法規和邊角情況就是產品；執行時的十二項能力裡沒有總賬、稅務或薪酬引擎（`when-to-use.mdx`；README 能力表） | +| 整合大量現有系統 | 否 | 語義層或上下文層；有回寫時用運營本體 | 聯邦預設只讀，而且關了兩道：資料來源上的 `allowWrites` 和物件上的 `writable`（`external-datasources.mdx`；`objectql/src/engine.ts` 的 `assertWriteAllowed`） | +| 資料湖上的分析 | 否 | 數倉查詢引擎、指標層、BI | 資料集繫結到一個基礎物件；驅動都是行儲存，沒有資料湖格式（`analytics.mdx`；`spec/src/ui/dataset.zod.ts`；README 驅動列表） | +| 演算法密集的領域 | 演算法本身不適合 | 程式碼；其餘是業務應用時，放在 `script` 動作後面 | `ActionType` 是 `script, url, modal, flow, api, form`；求解器永遠不是其中一種（`spec/src/ui/action.zod.ts`；`when-to-use.mdx`） | +| 必須跑在認證平臺上 | 不自己承擔認證工作就不適合 | 一個認證平臺，或者為你的部署做認證 | 自身不帶合規認證；連一致性測試套件都還是「計劃中」（`when-to-use.mdx`；`glossary.mdx`） | +| 對異構資料做推理 | 否 | 帶推理器的知識本體 | 沒有繼承、沒有公理、沒有推理器；`abstract` 按 ADR-0049 刪除（`ontology.mdx`；`compare.mdx`） | +| 現在就需要成熟生態 | 還不行 | 有打包應用和實施夥伴的後設資料平臺 | 「ObjectStack 更年輕；要有更多東西自己建的準備」（`compare.mdx`） | +| 新建業務應用：CRM、工單、審批、運營、內部工具 | 是 | | 物件、關係、動作、權限和流程就是這些應用的大部分（`when-to-use.mdx`） | +| 圍繞核心 ERP 的長尾 | 是 | | 小、具體、經常變；每個應用一份型別化定義，讀 ERP 的資料而不擁有它（`when-to-use.mdx`） | +| 從第一天起就由 Agent 操作的後臺 | 是 | | 每一個部署都是一個 MCP 伺服器，預設開啟，在使用者自己的權限之下（`when-to-use.mdx`；README） | + +![兩階段自檢。第一階段，五項排除，任一項答「是」就說明本體不是這部分工作的工具：總賬、合併、稅務或薪酬計算；價值主要在你留著但不擁有的系統裡；資料靜置在資料湖或數倉裡；核心是求解器、最佳化器，或一個不像任何業務應用的介面；平臺必須持有指定認證。第二階段，開工前的五個問題：有什麼、怎麼關聯、能做什麼、誰能做、什麼時候發生什麼。三種判定：五個「否」加五個答案是適合，對 Agent 來說是一天的活；任一個「是」就沿那條線把工作切開；只有「否」沒有答案，說明還沒有工具幫得上。](./self-check.svg) + +## 跑一遍自檢 + +十個問題，兩個階段，十分鐘。第一階段是排除清單；第二階段是「什麼時候用它」頁上「開工前的五個問題」。 + +**第一階段。任一項答「是」，本體就不是這部分工作的工具。** + +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 的是[定義本身是什麼](https://objectstack.ai/docs/concepts/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..6b37383 --- /dev/null +++ b/content/blog/when-not-to-use-an-executable-business-ontology/self-check-en.svg @@ -0,0 +1,96 @@ + + + + THE SELF-CHECK + Ten questions, two stages + + + + + STAGE ONE · ANY YES: NOT THE TOOL FOR THAT PART + Five exclusions + + + 1 + Is the hard part a ledger, consolidation, tax or payroll + calculation a packaged system already encodes? + → the packaged system; build around it + + + 2 + Does most of the value come from reading and writing + systems you will keep and do not own? + → a layer over them; federate read-only at most + + + 3 + Is the data you want to analyse at rest in a lake or + warehouse, not in the application's own records? + → the warehouse stack: engine, metric layer, BI + + + 4 + Is the core a solver, an optimiser, a simulation, or + an interface unlike any business app? + → code; behind a script action at most + + + 5 + Must it run on a platform that holds a named + certification, with no budget to certify your own? + → a certified platform, or an audit you own + + + + + + STAGE TWO · CAN THE TEAM ANSWER THESE TODAY? + Five questions before you start + + + 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 + five answers + A fit. The ontology is a day's work, + because an agent does the writing. + + + + Any yes in stage one + Split the workload on that line and use + the table's alternative for the rest. + + + + Noes, but no answers + No tool helps yet. Answer the five + questions first; install nothing. + + + Stage one from when-to-use.mdx, Not a fit today; stage two from its Five questions before you start. objectstack origin/main 43567a8f, 2026-10-16. + 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..079e970 --- /dev/null +++ b/content/blog/when-not-to-use-an-executable-business-ontology/self-check.svg @@ -0,0 +1,96 @@ + + + + 自检清单 + 十个问题，两个阶段 + + + + + 第一阶段 · 任一项答「是」，本体就不是这部分的工具 + 五项排除 + + + 1 + 最难的部分，是不是套装系统早已编码好的 + 法定计算：总账、合并、税务、薪酬？ + → 套装系统；围绕它建 + + + 2 + 大部分价值，是不是来自读写那些你会留着、 + 但并不拥有的系统？ + → 架在它们之上的一层；至多只读联邦 + + + 3 + 要分析的数据，是不是静置在数据湖或数仓里， + 而不在应用自己的记录里？ + → 数仓那一套：引擎、指标层、BI + + + 4 + 核心是不是求解器、优化器、仿真， + 或一个不像任何业务应用的界面？ + → 代码；至多放在 script 动作后面 + + + 5 + 是不是必须跑在持有指定认证的平台上， + 而且没有预算为自己的部署做认证？ + → 认证平台，或者你自己承担的审计 + + + + + + 第二阶段 · 团队今天答得出来吗 + 开工前的五个问题 + + + 6 + 有什么 + 对象及其字段 + + + 7 + 怎么关联 + 对象之间的查找与主从链接 + + + 8 + 能做什么 + 用户或 Agent 可以对一条记录发起的动作 + + + 9 + 谁能做 + 权限集、行级与字段级安全、共享 + + + 10 + 什么时候发生什么 + 记录触发器、定时任务、审批、工作流 + + + + + 五个「否」+ 五个答案 + 适合。本体是一天的活， + 因为写的是 Agent。 + + + + 第一阶段有一个「是」 + 沿那条线把工作切开， + 其余按表里的替代方案办。 + + + + 都是「否」，但没有答案 + 还没有工具帮得上。先回答 + 五个问题；什么都别装。 + + + 第一阶段出自 when-to-use.mdx 的「今天不适合」，第二阶段出自同页的「开工前的五个问题」。objectstack origin/main 43567a8f，2026-10-16。 + From 64a1442f9074690ef106c9c7ace399880ffa43ea Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 16 Oct 2026 08:01:28 +0000 Subject: [PATCH 2/6] content(blog): keep the self-check SVG root tag under the size detector's 1000-byte window Astro's SVG metadata probe validates the root tag inside the first 1000 bytes; the long aria-label pushed it past that and the build failed with NoImageMetadata. The long description moves into a desc element and the aria-label is one sentence. Co-Authored-By: Claude Claude-Session: https://claude.ai/code/session_017GeNDQH7E5S2rX8ajVAPxv --- .../self-check-en.svg | 3 ++- .../self-check.svg | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) 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 index 6b37383..28b0678 100644 --- 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 @@ -1,4 +1,5 @@ - + + Stage one, five exclusions: is the hard part a ledger, consolidation, tax or payroll calculation a packaged system already encodes, then the packaged system, build around it; does most of the value come from reading and writing systems you will keep and do not own, then a layer over them, federate read-only at most; is the data at rest in a lake or warehouse rather than the application's own records, then the warehouse stack; is the core a solver, an optimiser, a simulation or an interface unlike any business app, then code, behind a script action at most; must it run on a platform holding a named certification with no budget to certify your own, then a certified platform or an audit you own. Stage two, the five questions before you start: what we have, how it relates, what can be done, who may do it, what happens when. Three verdicts: five noes and five answers is a fit, a day's work because an agent does the writing; any yes in stage one splits the workload on that line; noes without answers means no tool helps yet, answer the five questions first and install nothing. THE SELF-CHECK 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 index 079e970..ff3af91 100644 --- 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 @@ -1,4 +1,5 @@ - + + 第一阶段，五项排除：最难的部分是不是套装系统早已编码好的法定计算，总账、合并、税务、薪酬，那就用套装系统、围绕它建；大部分价值是不是来自读写那些你会留着但并不拥有的系统，那就用架在它们之上的一层、至多只读联邦；要分析的数据是不是静置在数据湖或数仓里而不在应用自己的记录里，那就用数仓那一套；核心是不是求解器、优化器、仿真，或一个不像任何业务应用的界面，那就用代码、至多放在 script 动作后面；是不是必须跑在持有指定认证的平台上而且没有预算为自己的部署做认证，那就用认证平台或者你自己承担的审计。第二阶段，开工前的五个问题：有什么、怎么关联、能做什么、谁能做、什么时候发生什么。三种判定：五个「否」加五个答案是适合，一天的活，因为写的是 Agent；第一阶段有一个「是」就沿那条线把工作切开；都是「否」但没有答案，说明还没有工具帮得上，先回答五个问题，什么都别装。 自检清单 From f9955fa8bbc86b87b44d7e89889fcf679a9978b7 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 16 Oct 2026 08:16:11 +0000 Subject: [PATCH 3/6] content(blog): three-column decision table so it fits a phone column without sideways scroll The layout gives every column a 104px floor, so a four-column table scrolls at 390px; merging the fit verdict with the alternative keeps all four facets in three columns, and the sources move to short file names with a legend line. Co-Authored-By: Claude Claude-Session: https://claude.ai/code/session_017GeNDQH7E5S2rX8ajVAPxv --- .../index.mdx | 28 +++++++++---------- .../index.zh-Hans.mdx | 28 +++++++++---------- .../index.zh-Hant.mdx | 28 +++++++++---------- 3 files changed, 42 insertions(+), 42 deletions(-) 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 index 3cb379b..a520fd9 100644 --- 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 @@ -93,20 +93,20 @@ The comparison page adds two concessions that are not on the not-a-fit list, bec ## The decision table -Every row: the workload, whether it is a fit today, 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. - -| Workload | Fit today? | 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.mdx`; 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.mdx`; `objectql/src/engine.ts`, `assertWriteAllowed`) | -| 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.mdx`; `spec/src/ui/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 (`spec/src/ui/action.zod.ts`; `when-to-use.mdx`) | -| 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.mdx`; `glossary.mdx`) | -| Reasoning over heterogeneous data | No | A knowledge ontology with a reasoner | No inheritance, no axioms, no reasoner; `abstract` removed under ADR-0049 (`ontology.mdx`; `compare.mdx`) | -| 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.mdx`) | -| 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.mdx`) | -| 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.mdx`) | -| 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.mdx`; README) | +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) | ![The self-check in two stages. Stage one, five exclusions, any yes means the ontology is not the tool for that part: a ledger, consolidation, tax or payroll calculation; value mostly in systems you keep and do not own; data at rest in a lake or warehouse; a solver, optimiser or an interface unlike any business app; a platform that must hold a named certification. Stage two, the five questions before you start: what we have, how it relates, what can be done, who may do it, what happens when. Three verdicts: five noes and five answers is a fit and a day's work for an agent; any yes splits the workload on that line; noes without answers means no tool helps yet.](./self-check-en.svg) 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 index e959764..cc3a0a7 100644 --- 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 @@ -93,20 +93,20 @@ tags: ## 决策表 -每一行：工作负载、今天是否适合、该用什么，以及起决定作用的那一条事实和它的出处。「今天」是一个日期：出处是 objectstack `origin/main` 的 `43567a8f`，2026 年 10 月 16 日读取。 - -| 工作负载 | 今天适合吗 | 该用什么 | 起决定作用的事实（出处） | -| :--- | :--- | :--- | :--- | -| 大企业的核心 ERP 或财务 | 否 | 套装系统；围绕它建 | 法规和边角情况就是产品；运行时的十二项能力里没有总账、税务或薪酬引擎（`when-to-use.mdx`；README 能力表） | -| 集成大量现有系统 | 否 | 语义层或上下文层；有回写时用运营本体 | 联邦默认只读，而且关了两道：数据源上的 `allowWrites` 和对象上的 `writable`（`external-datasources.mdx`；`objectql/src/engine.ts` 的 `assertWriteAllowed`） | -| 数据湖上的分析 | 否 | 数仓查询引擎、指标层、BI | 数据集绑定到一个基础对象；驱动都是行存储，没有数据湖格式（`analytics.mdx`；`spec/src/ui/dataset.zod.ts`；README 驱动列表） | -| 算法密集的领域 | 算法本身不适合 | 代码；其余是业务应用时，放在 `script` 动作后面 | `ActionType` 是 `script, url, modal, flow, api, form`；求解器永远不是其中一种（`spec/src/ui/action.zod.ts`；`when-to-use.mdx`） | -| 必须跑在认证平台上 | 不自己承担认证工作就不适合 | 一个认证平台，或者为你的部署做认证 | 自身不带合规认证；连一致性测试套件都还是「计划中」（`when-to-use.mdx`；`glossary.mdx`） | -| 对异构数据做推理 | 否 | 带推理器的知识本体 | 没有继承、没有公理、没有推理器；`abstract` 按 ADR-0049 删除（`ontology.mdx`；`compare.mdx`） | -| 现在就需要成熟生态 | 还不行 | 有打包应用和实施伙伴的元数据平台 | 「ObjectStack 更年轻；要有更多东西自己建的准备」（`compare.mdx`） | -| 新建业务应用：CRM、工单、审批、运营、内部工具 | 是 | | 对象、关系、动作、权限和流程就是这些应用的大部分（`when-to-use.mdx`） | -| 围绕核心 ERP 的长尾 | 是 | | 小、具体、经常变；每个应用一份类型化定义，读 ERP 的数据而不拥有它（`when-to-use.mdx`） | -| 从第一天起就由 Agent 操作的后台 | 是 | | 每一个部署都是一个 MCP 服务器，默认开启，在用户自己的权限之下（`when-to-use.mdx`；README） | +每一行：工作负载、今天是否适合与该用什么，以及起决定作用的那一条事实和它的出处。「今天」是一个日期：出处是 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） | ![两阶段自检。第一阶段，五项排除，任一项答「是」就说明本体不是这部分工作的工具：总账、合并、税务或薪酬计算；价值主要在你留着但不拥有的系统里；数据静置在数据湖或数仓里；核心是求解器、优化器，或一个不像任何业务应用的界面；平台必须持有指定认证。第二阶段，开工前的五个问题：有什么、怎么关联、能做什么、谁能做、什么时候发生什么。三种判定：五个「否」加五个答案是适合，对 Agent 来说是一天的活；任一个「是」就沿那条线把工作切开；只有「否」没有答案，说明还没有工具帮得上。](./self-check.svg) 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 index 89abfe1..019ceca 100644 --- 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 @@ -94,20 +94,20 @@ tags: ## 決策表 -每一行：工作負載、今天是否適合、該用什麼，以及起決定作用的那一條事實和它的出處。「今天」是一個日期：出處是 objectstack `origin/main` 的 `43567a8f`，2026 年 10 月 16 日讀取。 - -| 工作負載 | 今天適合嗎 | 該用什麼 | 起決定作用的事實（出處） | -| :--- | :--- | :--- | :--- | -| 大企業的核心 ERP 或財務 | 否 | 套裝系統；圍繞它建 | 法規和邊角情況就是產品；執行時的十二項能力裡沒有總賬、稅務或薪酬引擎（`when-to-use.mdx`；README 能力表） | -| 整合大量現有系統 | 否 | 語義層或上下文層；有回寫時用運營本體 | 聯邦預設只讀，而且關了兩道：資料來源上的 `allowWrites` 和物件上的 `writable`（`external-datasources.mdx`；`objectql/src/engine.ts` 的 `assertWriteAllowed`） | -| 資料湖上的分析 | 否 | 數倉查詢引擎、指標層、BI | 資料集繫結到一個基礎物件；驅動都是行儲存，沒有資料湖格式（`analytics.mdx`；`spec/src/ui/dataset.zod.ts`；README 驅動列表） | -| 演算法密集的領域 | 演算法本身不適合 | 程式碼；其餘是業務應用時，放在 `script` 動作後面 | `ActionType` 是 `script, url, modal, flow, api, form`；求解器永遠不是其中一種（`spec/src/ui/action.zod.ts`；`when-to-use.mdx`） | -| 必須跑在認證平臺上 | 不自己承擔認證工作就不適合 | 一個認證平臺，或者為你的部署做認證 | 自身不帶合規認證；連一致性測試套件都還是「計劃中」（`when-to-use.mdx`；`glossary.mdx`） | -| 對異構資料做推理 | 否 | 帶推理器的知識本體 | 沒有繼承、沒有公理、沒有推理器；`abstract` 按 ADR-0049 刪除（`ontology.mdx`；`compare.mdx`） | -| 現在就需要成熟生態 | 還不行 | 有打包應用和實施夥伴的後設資料平臺 | 「ObjectStack 更年輕；要有更多東西自己建的準備」（`compare.mdx`） | -| 新建業務應用：CRM、工單、審批、運營、內部工具 | 是 | | 物件、關係、動作、權限和流程就是這些應用的大部分（`when-to-use.mdx`） | -| 圍繞核心 ERP 的長尾 | 是 | | 小、具體、經常變；每個應用一份型別化定義，讀 ERP 的資料而不擁有它（`when-to-use.mdx`） | -| 從第一天起就由 Agent 操作的後臺 | 是 | | 每一個部署都是一個 MCP 伺服器，預設開啟，在使用者自己的權限之下（`when-to-use.mdx`；README） | +每一行：工作負載、今天是否適合與該用什麼，以及起決定作用的那一條事實和它的出處。「今天」是一個日期：出處是 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） | ![兩階段自檢。第一階段，五項排除，任一項答「是」就說明本體不是這部分工作的工具：總賬、合併、稅務或薪酬計算；價值主要在你留著但不擁有的系統裡；資料靜置在資料湖或數倉裡；核心是求解器、最佳化器，或一個不像任何業務應用的介面；平臺必須持有指定認證。第二階段，開工前的五個問題：有什麼、怎麼關聯、能做什麼、誰能做、什麼時候發生什麼。三種判定：五個「否」加五個答案是適合，對 Agent 來說是一天的活；任一個「是」就沿那條線把工作切開；只有「否」沒有答案，說明還沒有工具幫得上。](./self-check.svg) From 9f18a2fceb5cf4f1272a6e65ac32442e2cba9b57 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 16 Oct 2026 08:42:58 +0000 Subject: [PATCH 4/6] content(blog): link the zh-Hans post to this site's compare and ontology pages The generator now rewrites a single-segment /zh-Hans/ link to a marketing page into /zh-Hant/, so the two links withheld in the first round come back: the comparison page where the post says it goes further than it, and the ontology page as the next thing to hand the agent. zh-Hant regenerated. Co-Authored-By: Claude Claude-Session: https://claude.ai/code/session_017GeNDQH7E5S2rX8ajVAPxv --- .../index.zh-Hans.mdx | 4 ++-- .../index.zh-Hant.mdx | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) 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 index cc3a0a7..7d6b379 100644 --- 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 @@ -17,7 +17,7 @@ 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 日读取），以及边界恰好就是一行代码的那些源码文件。本站导航里的「对比」页已经把这五种工作负载和开工前的五个问题各用一行列过了；这篇是长版：每一种给一个具体场景、替代方案和它的道理、代价，以及一条起决定作用的事实。 +一份诚实的「什么情况下别用我」清单，是厂商能发布的最有用的东西，因为这是买方从销售材料里唯一拿不到的信息。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/)已经把这五种工作负载和开工前的五个问题各用一行列过了；这篇是长版：每一种给一个具体场景、替代方案和它的道理、代价，以及一条起决定作用的事实。 ## 六类测试 @@ -146,4 +146,4 @@ tags: ## 如果你的场景通过了 -那么最快、也最诚实的下一步不是看演示，而是写一份定义。把你的编码 Agent 指向 ObjectStack——规则文件、技能包和工具服务器见[如何把你的 Agent 指向 ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/)——然后向它要第一个对象：几个字段、一个关系、一个动作、一个权限集、一个触发器。跑 `npm run validate`，先读 diff，再看 Console。如果你能把整份 diff 读完，而且它说的就是你的业务在做的事，那六类测试在实践中就通过了，下一页该交给 Agent 的是[定义本身是什么](https://objectstack.ai/docs/concepts/ontology)。如果读不完，这篇文章本来也帮不了你，而你刚刚省下了一个项目。 +那么最快、也最诚实的下一步不是看演示，而是写一份定义。把你的编码 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 index 019ceca..690bde1 100644 --- 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 @@ -18,7 +18,7 @@ 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 日讀取），以及邊界恰好就是一行程式碼的那些原始碼檔案。本站導航裡的「對比」頁已經把這五種工作負載和開工前的五個問題各用一行列過了；這篇是長版：每一種給一個具體場景、替代方案和它的道理、代價，以及一條起決定作用的事實。 +一份誠實的「什麼情況下別用我」清單，是廠商能釋出的最有用的東西，因為這是買方從銷售材料裡唯一拿不到的資訊。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/)已經把這五種工作負載和開工前的五個問題各用一行列過了；這篇是長版：每一種給一個具體場景、替代方案和它的道理、代價，以及一條起決定作用的事實。 ## 六類測試 @@ -147,4 +147,4 @@ tags: ## 如果你的場景通過了 -那麼最快、也最誠實的下一步不是看演示，而是寫一份定義。把你的編碼 Agent 指向 ObjectStack——規則檔案、技能包和工具伺服器見[如何把你的 Agent 指向 ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/)——然後向它要第一個物件：幾個欄位、一個關係、一個動作、一個權限集、一個觸發器。跑 `npm run validate`，先讀 diff，再看 Console。如果你能把整份 diff 讀完，而且它說的就是你的業務在做的事，那六類測試在實踐中就通過了，下一頁該交給 Agent 的是[定義本身是什麼](https://objectstack.ai/docs/concepts/ontology)。如果讀不完，這篇文章本來也幫不了你，而你剛剛省下了一個專案。 +那麼最快、也最誠實的下一步不是看演示，而是寫一份定義。把你的編碼 Agent 指向 ObjectStack——規則檔案、技能包和工具伺服器見[如何把你的 Agent 指向 ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/)——然後向它要第一個物件：幾個欄位、一個關係、一個動作、一個權限集、一個觸發器。跑 `npm run validate`，先讀 diff，再看 Console。如果你能把整份 diff 讀完，而且它說的就是你的業務在做的事，那六類測試在實踐中就通過了，下一頁該交給 Agent 的是[定義本身是什麼](/zh-Hant/ontology/)。如果讀不完，這篇文章本來也幫不了你，而你剛剛省下了一個專案。 From 3a54977f9ba6286258ba0c2f9cc27bc1a454707a Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 28 Oct 2026 02:30:21 +0000 Subject: [PATCH 5/6] content(blog): re-date the post to 2026-10-28 and re-source it on tag @objectstack/cli@18.2.0 Publish-day prep for the when-not-to-use post. Every cited line was re-read at the release tag @objectstack/cli@18.2.0 (npm `latest` on 2026-10-28). Two README facts moved: the driver package table now lives in CONTRIBUTING.md (the README keeps its five-store Datasources row), and the ObjectOS paragraph was reworded; the post's ObjectOS section now carries the three-edition clause verbatim from src/lib/positioning.ts. Everything else holds unchanged. Source labels in the body and the four SVGs now read "tag @objectstack/cli@18.2.0, read 2026-10-28"; zh-Hant regenerated with pnpm gen:zh-hant. Co-Authored-By: Claude --- .../cover-en.svg | 2 +- .../cover.svg | 2 +- .../index.mdx | 12 ++++++------ .../index.zh-Hans.mdx | 12 ++++++------ .../index.zh-Hant.mdx | 12 ++++++------ .../self-check-en.svg | 2 +- .../self-check.svg | 2 +- 7 files changed, 22 insertions(+), 22 deletions(-) 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 index e597087..5864292 100644 --- 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 @@ -56,5 +56,5 @@ → certification you own - Sources: objectstack when-to-use.mdx and compare.mdx, origin/main 43567a8f, read 2026-10-16. + Sources: objectstack when-to-use.mdx and compare.mdx, tag @objectstack/cli@18.2.0, read 2026-10-28. 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 index 5d3556e..c5fcce1 100644 --- 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 @@ -56,5 +56,5 @@ → 认证是你自己的工作 - 来源：objectstack 的 when-to-use.mdx 与 compare.mdx，origin/main 43567a8f，2026-10-16 读取。 + 来源：objectstack 的 when-to-use.mdx 与 compare.mdx，标签 @objectstack/cli@18.2.0，2026-10-28 读取。 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 index a520fd9..ef5dd4b 100644 --- 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 @@ -2,7 +2,7 @@ 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 +date: 2026-10-28 status: published topic: app-building audience: it @@ -17,7 +17,7 @@ tags: **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. +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 tag `@objectstack/cli@18.2.0`, read 2026-10-28, 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 @@ -57,7 +57,7 @@ The honest path exists, and it is narrow: connect read-only, measure, enable wri **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. +**The deciding fact.** The datasources the README lists are PostgreSQL, MySQL, SQLite, MongoDB and in-memory; the package directory, which the README now hands to `CONTRIBUTING.md`, adds Turso and SQLite in WebAssembly. 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 @@ -93,13 +93,13 @@ The comparison page adds two concessions that are not on the not-a-fit list, bec ## 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/`. +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 at tag `@objectstack/cli@18.2.0`, the version `npm view @objectstack/cli dist-tags` reported as `latest` on 2026-10-28, read that day. 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/`; README and `CONTRIBUTING.md` are at the repository root. | 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) | +| 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 datasources; `CONTRIBUTING.md` 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) | @@ -142,7 +142,7 @@ And it does not say that failing one row fails the workload. Most real cases spl ## 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. +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 comes in three editions: ObjectOS Community, open source and free to self-host; ObjectOS Cloud, hosted in the browser with nothing to install; and ObjectOS Enterprise, self-managed on your own infrastructure. On every edition you can export your ontology and run it on another. 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 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 index 7d6b379..0b6f56c 100644 --- 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 @@ -2,7 +2,7 @@ title: 什么时候不该用可执行业务本体？ description: 五种今天不适合用可执行业务本体的工作负载：各自该用什么、为什么、选错的代价，加一张每行带出处的决策表和一份自检清单。 author: ObjectStack Team -date: 2026-11-05 +date: 2026-10-28 status: published topic: app-building audience: it @@ -17,7 +17,7 @@ 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/)已经把这五种工作负载和开工前的五个问题各用一行列过了；这篇是长版：每一种给一个具体场景、替代方案和它的道理、代价，以及一条起决定作用的事实。 +一份诚实的「什么情况下别用我」清单，是厂商能发布的最有用的东西，因为这是买方从销售材料里唯一拿不到的信息。ObjectStack 的一句话定位是「一份可执行的业务本体。AI 编写它，运行时运行它，Agent 操作它，你拥有它。」下面写的全是这句话的边界在哪里，材料取自项目自己的[什么时候用它](https://objectstack.ai/docs/concepts/when-to-use)页和[它与其他方案的对比](https://objectstack.ai/docs/concepts/compare)页（标签 `@objectstack/cli@18.2.0`，2026 年 10 月 28 日读取），以及边界恰好就是一行代码的那些源码文件。本站的[对比页](/zh-Hans/compare/)已经把这五种工作负载和开工前的五个问题各用一行列过了；这篇是长版：每一种给一个具体场景、替代方案和它的道理、代价，以及一条起决定作用的事实。 ## 六类测试 @@ -57,7 +57,7 @@ tags: **选错的代价。** 两份副本选一份。要么把数据湖装进应用对象——于是你有了三年事件的第二份副本，带着它自己的新鲜度和它自己的账单，放在一个从业务定义推导出来、而不是为扫描设计的行存储里；要么联邦接入一张数仓表，然后发现你在把分析型问题送进一个为应用回答行级查询而建的引擎——有过滤下推，没有任何东西认识列式文件。仪表盘会渲染出来，但不会是品类团队要的那些仪表盘。 -**起决定作用的事实。** README 列出的驱动是 PostgreSQL、MySQL、SQLite、MongoDB、Turso、WebAssembly 里的 SQLite 和内存。没有数据湖格式，没有列式引擎，没有对象存储驱动；而数据集层绑定的是一个对象，不是数据湖里的一张表。 +**起决定作用的事实。** README 列出的数据源是 PostgreSQL、MySQL、SQLite、MongoDB 和内存；README 如今把包目录交给了 `CONTRIBUTING.md`，那里再加上 Turso 和 WebAssembly 里的 SQLite。没有数据湖格式，没有列式引擎，没有对象存储驱动；而数据集层绑定的是一个对象，不是数据湖里的一张表。 ## 四、定价、排程这类算法密集的领域 @@ -93,13 +93,13 @@ tags: ## 决策表 -每一行：工作负载、今天是否适合与该用什么，以及起决定作用的那一条事实和它的出处。「今天」是一个日期：出处是 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/` 下。 +每一行：工作负载、今天是否适合与该用什么，以及起决定作用的那一条事实和它的出处。「今天」是一个日期：出处是 objectstack 的标签 `@objectstack/cli@18.2.0`，即 `npm view @objectstack/cli dist-tags` 在 2026 年 10 月 28 日报告为 `latest` 的那个版本，当天读取。出处按文件名写：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/` 下；README 和 `CONTRIBUTING.md` 在仓库根目录。 | 工作负载 | 今天适合吗？该用什么 | 起决定作用的事实（出处） | | :--- | :--- | :--- | | 大企业的核心 ERP 或财务 | **否**：套装系统；围绕它建 | 法规和边角情况就是产品；运行时的十二项能力里没有总账、税务或薪酬引擎（when-to-use；README 能力表） | | 集成大量现有系统 | **否**：语义层或上下文层；有回写时用运营本体 | 联邦默认只读，而且关了两道：数据源上的 `allowWrites` 和对象上的 `writable`（external-datasources；`engine.ts` 的 `assertWriteAllowed`） | -| 数据湖上的分析 | **否**：数仓查询引擎、指标层、BI | 数据集绑定到一个基础对象；驱动都是行存储，没有数据湖格式（analytics；`dataset.zod.ts`；README 驱动列表） | +| 数据湖上的分析 | **否**：数仓查询引擎、指标层、BI | 数据集绑定到一个基础对象；驱动都是行存储，没有数据湖格式（analytics；`dataset.zod.ts`；README 数据源；`CONTRIBUTING.md` 驱动列表） | | 算法密集的领域 | **算法本身不适合**：代码；其余是业务应用时，放在 `script` 动作后面 | `ActionType` 是 script、url、modal、flow、api、form；求解器永远不是其中一种（`action.zod.ts`；when-to-use） | | 必须跑在认证平台上 | **不自己承担认证工作就不适合**：一个认证平台，或者为你的部署做认证 | 自身不带合规认证；连一致性测试套件都还是「计划中」（when-to-use；glossary） | | 对异构数据做推理 | **否**：带推理器的知识本体 | 没有继承、没有公理、没有推理器；`abstract` 按 ADR-0049 删除（ontology；compare） | @@ -142,7 +142,7 @@ tags: ## ObjectOS 在这份清单里的位置 -上面说的一切不随版本而变。「想把同一个循环托管起来、在浏览器里用、什么都不用安装？那就是 ObjectOS——建立在 ObjectStack 之上的商业运行环境。」ObjectOS 既可托管在浏览器中、无需安装（ObjectOS Cloud），也可自管部署在你自己的基础设施上（ObjectOS Enterprise）；无论哪个版本，你都可以导出本体，拿到开源的 ObjectStack 运行时上运行。这五种工作负载说的是一份可执行本体能表达什么，不是它跑在哪里，所以这份清单在任何承载环境上读起来都一样。唯一一个和承载环境有关的问题是认证，安全页对 ObjectOS 的回答和开源页的措辞一致：取决于运行中的部署。 +上面说的一切不随版本而变。「想把同一个循环托管起来、在浏览器里用、什么都不用安装？那就是 ObjectOS——建立在 ObjectStack 之上的商业运行环境。」ObjectOS 有三个版本：ObjectOS Community，开源、可免费自托管；ObjectOS Cloud，托管在浏览器中、无需安装；ObjectOS Enterprise，自管部署在你自己的基础设施上。无论哪个版本，你都可以导出本体，拿到另一个版本上运行。这五种工作负载说的是一份可执行本体能表达什么，不是它跑在哪里，所以这份清单在任何承载环境上读起来都一样。唯一一个和承载环境有关的问题是认证，安全页对 ObjectOS 的回答和开源页的措辞一致：取决于运行中的部署。 ## 如果你的场景通过了 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 index 690bde1..e449b1f 100644 --- 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 @@ -3,7 +3,7 @@ title: 什麼時候不該用可執行業務本體？ description: 五種今天不適合用可執行業務本體的工作負載：各自該用什麼、為什麼、選錯的代價，加一張每行帶出處的決策表和一份自檢清單。 author: ObjectStack Team -date: 2026-11-05 +date: 2026-10-28 status: published topic: app-building audience: it @@ -18,7 +18,7 @@ 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/)已經把這五種工作負載和開工前的五個問題各用一行列過了；這篇是長版：每一種給一個具體場景、替代方案和它的道理、代價，以及一條起決定作用的事實。 +一份誠實的「什麼情況下別用我」清單，是廠商能釋出的最有用的東西，因為這是買方從銷售材料裡唯一拿不到的資訊。ObjectStack 的一句話定位是「一份可執行的業務本體。AI 編寫它，執行時執行它，Agent 操作它，你擁有它。」下面寫的全是這句話的邊界在哪裡，材料取自專案自己的[什麼時候用它](https://objectstack.ai/docs/concepts/when-to-use)頁和[它與其他方案的對比](https://objectstack.ai/docs/concepts/compare)頁（標籤 `@objectstack/cli@18.2.0`，2026 年 10 月 28 日讀取），以及邊界恰好就是一行程式碼的那些原始碼檔案。本站的[對比頁](/zh-Hant/compare/)已經把這五種工作負載和開工前的五個問題各用一行列過了；這篇是長版：每一種給一個具體場景、替代方案和它的道理、代價，以及一條起決定作用的事實。 ## 六類測試 @@ -58,7 +58,7 @@ tags: **選錯的代價。** 兩份副本選一份。要麼把資料湖裝進應用物件——於是你有了三年事件的第二份副本，帶著它自己的新鮮度和它自己的賬單，放在一個從業務定義推匯出來、而不是為掃描設計的行儲存裡；要麼聯邦接入一張數倉表，然後發現你在把分析型問題送進一個為應用回答行級查詢而建的引擎——有過濾下推，沒有任何東西認識列式檔案。儀表盤會渲染出來，但不會是品類團隊要的那些儀表盤。 -**起決定作用的事實。** README 列出的驅動是 PostgreSQL、MySQL、SQLite、MongoDB、Turso、WebAssembly 裡的 SQLite 和記憶體。沒有資料湖格式，沒有列式引擎，沒有物件儲存驅動；而資料集層繫結的是一個物件，不是資料湖裡的一張表。 +**起決定作用的事實。** README 列出的資料來源是 PostgreSQL、MySQL、SQLite、MongoDB 和記憶體；README 如今把包目錄交給了 `CONTRIBUTING.md`，那裡再加上 Turso 和 WebAssembly 裡的 SQLite。沒有資料湖格式，沒有列式引擎，沒有物件儲存驅動；而資料集層繫結的是一個物件，不是資料湖裡的一張表。 ## 四、定價、排程這類演算法密集的領域 @@ -94,13 +94,13 @@ tags: ## 決策表 -每一行：工作負載、今天是否適合與該用什麼，以及起決定作用的那一條事實和它的出處。「今天」是一個日期：出處是 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/` 下。 +每一行：工作負載、今天是否適合與該用什麼，以及起決定作用的那一條事實和它的出處。「今天」是一個日期：出處是 objectstack 的標籤 `@objectstack/cli@18.2.0`，即 `npm view @objectstack/cli dist-tags` 在 2026 年 10 月 28 日報告為 `latest` 的那個版本，當天讀取。出處按檔名寫：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/` 下；README 和 `CONTRIBUTING.md` 在倉庫根目錄。 | 工作負載 | 今天適合嗎？該用什麼 | 起決定作用的事實（出處） | | :--- | :--- | :--- | | 大企業的核心 ERP 或財務 | **否**：套裝系統；圍繞它建 | 法規和邊角情況就是產品；執行時的十二項能力裡沒有總賬、稅務或薪酬引擎（when-to-use；README 能力表） | | 整合大量現有系統 | **否**：語義層或上下文層；有回寫時用運營本體 | 聯邦預設只讀，而且關了兩道：資料來源上的 `allowWrites` 和物件上的 `writable`（external-datasources；`engine.ts` 的 `assertWriteAllowed`） | -| 資料湖上的分析 | **否**：數倉查詢引擎、指標層、BI | 資料集繫結到一個基礎物件；驅動都是行儲存，沒有資料湖格式（analytics；`dataset.zod.ts`；README 驅動列表） | +| 資料湖上的分析 | **否**：數倉查詢引擎、指標層、BI | 資料集繫結到一個基礎物件；驅動都是行儲存，沒有資料湖格式（analytics；`dataset.zod.ts`；README 資料來源；`CONTRIBUTING.md` 驅動列表） | | 演算法密集的領域 | **演算法本身不適合**：程式碼；其餘是業務應用時，放在 `script` 動作後面 | `ActionType` 是 script、url、modal、flow、api、form；求解器永遠不是其中一種（`action.zod.ts`；when-to-use） | | 必須跑在認證平臺上 | **不自己承擔認證工作就不適合**：一個認證平臺，或者為你的部署做認證 | 自身不帶合規認證；連一致性測試套件都還是「計劃中」（when-to-use；glossary） | | 對異構資料做推理 | **否**：帶推理器的知識本體 | 沒有繼承、沒有公理、沒有推理器；`abstract` 按 ADR-0049 刪除（ontology；compare） | @@ -143,7 +143,7 @@ tags: ## ObjectOS 在這份清單裡的位置 -上面說的一切不隨版本而變。「想把同一個迴圈託管起來、在瀏覽器裡用、什麼都不用安裝？那就是 ObjectOS——建立在 ObjectStack 之上的商業執行環境。」ObjectOS 既可託管在瀏覽器中、無需安裝（ObjectOS Cloud），也可自管部署在你自己的基礎設施上（ObjectOS Enterprise）；無論哪個版本，你都可以匯出本體，拿到開源的 ObjectStack 執行時上執行。這五種工作負載說的是一份可執行本體能表達什麼，不是它跑在哪裡，所以這份清單在任何承載環境上讀起來都一樣。唯一一個和承載環境有關的問題是認證，安全頁對 ObjectOS 的回答和開源頁的措辭一致：取決於執行中的部署。 +上面說的一切不隨版本而變。「想把同一個迴圈託管起來、在瀏覽器裡用、什麼都不用安裝？那就是 ObjectOS——建立在 ObjectStack 之上的商業執行環境。」ObjectOS 有三個版本：ObjectOS Community，開源、可免費自託管；ObjectOS Cloud，託管在瀏覽器中、無需安裝；ObjectOS Enterprise，自管部署在你自己的基礎設施上。無論哪個版本，你都可以匯出本體，拿到另一個版本上執行。這五種工作負載說的是一份可執行本體能表達什麼，不是它跑在哪裡，所以這份清單在任何承載環境上讀起來都一樣。唯一一個和承載環境有關的問題是認證，安全頁對 ObjectOS 的回答和開源頁的措辭一致：取決於執行中的部署。 ## 如果你的場景通過了 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 index 28b0678..2cead81 100644 --- 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 @@ -93,5 +93,5 @@ questions first; install nothing. - Stage one from when-to-use.mdx, Not a fit today; stage two from its Five questions before you start. objectstack origin/main 43567a8f, 2026-10-16. + Stage one from when-to-use.mdx, Not a fit today; stage two from its Five questions before you start. objectstack tag @objectstack/cli@18.2.0, 2026-10-28. 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 index ff3af91..434b49b 100644 --- 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 @@ -93,5 +93,5 @@ 五个问题；什么都别装。 - 第一阶段出自 when-to-use.mdx 的「今天不适合」，第二阶段出自同页的「开工前的五个问题」。objectstack origin/main 43567a8f，2026-10-16。 + 第一阶段出自 when-to-use.mdx 的「今天不适合」，第二阶段出自同页的「开工前的五个问题」。objectstack 标签 @objectstack/cli@18.2.0，2026-10-28。 From 6e6e4c820505b0cc60940e7d378e408e5d743771 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 28 Oct 2026 02:40:51 +0000 Subject: [PATCH 6/6] content(blog): backfill ja, ko, de, es and fr for the when-not-to-use post Faithful translations of the corrected English post. title, description and tags are translated; date, topic, audience and status match en; no updated. Each locale quotes its own positioning strings verbatim from src/lib/positioning.ts (T2, T4 and the three-edition E1). Verbatim doc quotes stay English under span lang="en" with a translation alongside, following the executable-ontology-vs-knowledge-ontology backfills. Links go same-locale where the target exists (security page, the definition post) and to /en/ otherwise. Non-Chinese locales use the *-en.svg assets. Co-Authored-By: Claude --- .../index.de.mdx | 149 ++++++++++++++++++ .../index.es.mdx | 149 ++++++++++++++++++ .../index.fr.mdx | 149 ++++++++++++++++++ .../index.ja.mdx | 149 ++++++++++++++++++ .../index.ko.mdx | 149 ++++++++++++++++++ 5 files changed, 745 insertions(+) create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/index.de.mdx create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/index.es.mdx create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/index.fr.mdx create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/index.ja.mdx create mode 100644 content/blog/when-not-to-use-an-executable-business-ontology/index.ko.mdx diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/index.de.mdx b/content/blog/when-not-to-use-an-executable-business-ontology/index.de.mdx new file mode 100644 index 0000000..520fc36 --- /dev/null +++ b/content/blog/when-not-to-use-an-executable-business-ontology/index.de.mdx @@ -0,0 +1,149 @@ +--- +title: "Wann sollte man eine ausführbare Geschäftsontologie nicht verwenden?" +description: "Fünf Workloads, für die eine ausführbare Geschäftsontologie heute das falsche Werkzeug ist, was stattdessen passt, was die falsche Wahl kostet, und eine Entscheidungstabelle mit Quelle in jeder Zeile." +author: ObjectStack Team +date: 2026-10-28 +status: published +topic: app-building +audience: it +solutions: [] +industries: [] +cover: ./cover-en.svg +tags: + - Ontologie + - Ausführbare Geschäftsontologie + - Wann einsetzen +--- + +**Kurze Antwort: nicht für fünf Workloads, und die ObjectStack-Dokumentation nennt sie selbst.** Das Kern-ERP oder Finanzsystem eines Großunternehmens ersetzen. Arbeit, deren Wert in der Integration vieler bestehender Systeme liegt. Analytik über Data Lakes. Algorithmenlastige Domänen wie Pricing oder Scheduling, es sei denn, der Algorithmus wird als Aktion gekapselt. Und alles, was auf einer zertifizierten Plattform laufen muss. Für jeden Fall gibt es ein besseres Werkzeug, und dieser Beitrag sagt, welches, warum es die richtige Wahl ist und was die falsche Wahl kostet. Am Ende: eine Entscheidungstabelle mit einer Quelle in jeder Zeile und ein Selbsttest mit zehn Fragen, den Sie an Ihrem eigenen Fall durchführen können, bevor Sie irgendetwas installieren. + +Eine ehrliche Liste, wo ein Produkt das falsche Werkzeug ist, ist das Nützlichste, was ein Anbieter veröffentlichen kann, denn es ist das eine, was ein Käufer aus dem Vertriebsdeck nicht bekommt. Die einzeilige Positionierung von ObjectStack lautet: „Eine ausführbare Geschäftsontologie. AI schreibt sie, die Runtime führt sie aus, Agents bedienen sie, Sie besitzen sie.“ Alles Folgende handelt von den Rändern dieses Satzes, entnommen der projekteigenen [When-to-use-Seite](https://objectstack.ai/docs/concepts/when-to-use) und [Vergleichsseite](https://objectstack.ai/docs/concepts/compare) am Tag `@objectstack/cli@18.2.0`, gelesen am 2026-10-28, sowie der Quelldatei, wo die Grenze eine Codezeile ist. Die [Vergleichsseite](/en/compare/) dieser Website listet die fünf Workloads und die fünf Fragen bereits in je einer Zeile; dieser Beitrag ist die Langform: ein Szenario für jeden Fall, die Alternative und ihre Begründung, die Kosten und der entscheidende Fakt. + +## Der Sechs-Arten-Test + +Ein Test deckt alle fünf Fälle ab, deshalb lohnt es sich, ihn zuerst zu nennen. Die Konzeptseite definiert den Kern einer ausführbaren Geschäftsontologie als sechs Arten von Dingen: Objekte und Felder, Relationen, Aktionen, Berechtigungen, Flows sowie Agent- und Tool-Definitionen. Die Runtime leitet aus diesen sechs die Datenbank, die API, die UI und die Agent-Tools ab und setzt sie bei jedem Aufruf durch. Code verschwindet nicht, aber er wandert in die Runtime, als Hooks, Aktionsrümpfe, CEL und eingeschränktes JSX, innerhalb des Zauns, den die sechs Arten ziehen. + +Fragen Sie also bei jedem Workload: **Ist der schwierige Teil eine der sechs Arten?** Wenn der schwierige, wertvolle, riskante Teil der Arbeit darin besteht, zu entscheiden, was existiert, wie es zusammenhängt, was getan werden darf, von wem, und was wann geschieht, dann ist die Ontologie das Werkzeug, und ein Agent kann sie schreiben. Wenn der schwierige Teil etwas anderes ist, eine gesetzliche Berechnung, eine Verbindung zu vierzig Systemen, ein Scan über ein Petabyte, ein Solver, das Zertifikat eines Auditors, dann ist dieser Teil nicht als Definition ausdrückbar, und die Ontologie kapselt ihn bestenfalls und imitiert ihn schlimmstenfalls. Nennen wir das den **Sechs-Arten-Test**. Jeder der fünf Workloads unten fällt aus einem anderen Grund durch, und deshalb brauchen sie fünf verschiedene Alternativen statt einer. + +## 1. Das Kern-ERP oder Finanzsystem eines Großunternehmens + +**Das Szenario.** Ein Hersteller mit viertausend Mitarbeitenden betreibt Hauptbuch, Konsolidierung und Lohnabrechnung seit zwölf Jahren auf einem Standard-ERP. Ein Coding-Agent, dem man den Kontenplan zeigt, bietet an, ihn als Objekte neu zu deklarieren, mit Buchungsregeln als Flows und Steuern als Formeln. Die Demo überzeugt: Journale, eine Saldenbilanz, eine Freigabe für jede Buchung. + +**Was stattdessen, und warum es richtig ist.** Das Standardsystem, und darum herum bauen. Die When-to-use-Seite: "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." (Hauptbuch, Konsolidierung, Steuern und Lohnabrechnung tragen Regulierung und Sonderfälle, die Standardsysteme bereits kodieren. Bauen Sie um diesen Kern herum, nicht an seiner Stelle.) In diesem Markt ist die Regulierung das Produkt. Eine Lohnabrechnungs-Engine ist eine Bibliothek von Steuerhoheiten, Meldekalendern und rückwirkenden Korrekturen, gepflegt von Menschen, deren einzige Aufgabe es ist, sie aktuell zu halten; eine Konsolidierungs-Engine ist jahrelange Erfahrung mit Intercompany-Eliminierungen und Sonderfällen der Währungsumrechnung. Nichts davon ist „was existiert und wer was darf“. Es ist Berechnung, und sie ändert sich, wenn eine Regierung sie ändert, nicht wenn Ihr Geschäft es tut. + +**Die Kosten der falschen Wahl.** Ein zweites Hauptbuch. Jede Regel, die Sie neu kodiert haben, ist jetzt Ihr Diff, den Sie pflegen, Ihr Audit, das Sie bestehen, und Ihr Defekt, wenn das Steuerjahr wechselt, während das Standardsystem, das Sie für die gesetzliche Berichterstattung behalten haben, Quartal für Quartal etwas weiter von Ihrer Kopie abweicht. Der Agent, der die Regeln an einem Tag geschrieben hat, kann kein Steuergesetz für Sie lesen. + +**Der entscheidende Fakt.** Die Fähigkeitstabelle der README listet zwölf Dinge, die die Runtime bereitstellt: Objekte und Felder, Berechtigungen, Automatisierung, Freigaben, Views, Dashboards und Reports, Aktionen, APIs und SDK, AI-Tools, Übersetzungen, Seed-Daten, Datenquellen. Ein Hauptbuch, eine Steuer-Engine und ein Lohnlauf stehen nicht darauf, und das Projekt sagt nicht, dass sie kommen. + +Was laut derselben Seite passt, ist der Long Tail um diesen Kern: "vendor onboarding, inspections, internal requests" (Lieferanten-Onboarding, Inspektionen, interne Anträge), die Tabellen und Formulare, die nachhalten, was das ERP nicht abdeckt. Jedes davon wird zu einer typisierten Definition statt einer Datei, die per E-Mail herumgereicht wird, und jedes kann die Daten des ERP lesen, ohne sie zu besitzen, was der nächste Fall ist. + +## 2. Workloads, deren Wert in der Integration vieler bestehender Systeme liegt + +**Das Szenario.** Eine Bank möchte, dass ihre Agents eine Kundenfrage aus dem Kernbankensystem, dem CRM, der Kartenplattform und dem Ticketsystem auf einmal beantworten und einen Status in zwei davon zurückschreiben. Keines dieser Systeme wird abgelöst. Die Aufgabe ist, sie für einen Agent lesbar zu machen und über sie hinweg zu handeln. + +**Was stattdessen, und warum.** Eine Schicht über den Systemen: ein Semantic Layer oder Context Layer für das Lesen, eine operative Ontologie nach Art von Palantir, wenn Rückschreibungen zu steuern sind. Die Vergleichsseite räumt das offen ein: "When the data already lives in a warehouse, a lakehouse and a dozen operational systems, these start where you are." (Wenn die Daten bereits in einem Warehouse, einem Lakehouse und einem Dutzend operativer Systeme liegen, beginnen diese dort, wo Sie sind.) Diese Produkte sind um die Annahme gebaut, dass das System of Record bleibt, wo es ist; ihr Objektmodell ist eine View, ihre Schreibvorgänge sind Writeback, und ihr Wert wächst mit der Zahl der Systeme darunter. ObjectStack ist auf der gegenteiligen Annahme gebaut: dass die Ontologie *das* System ist und die Datenbank aus ihr abgeleitet wird. + +**Die Kosten der falschen Wahl.** Dies ist der Fall, der am häufigsten falsch entschieden wird, weil die erste Woche gut läuft. ObjectStack kann eine externe Datenbank mit `schemaMode: 'external'` als Datenquelle föderieren, und ein Lesemodell über einer Legacy-Tabelle ist ein kurzer Nachmittag. Dann kommen die Schreibvorgänge. Föderierte Schreibvorgänge sind standardmäßig doppelt abgeschaltet: Die Datenquelle muss `external.allowWrites: true` deklarieren und das Objekt `external.writable: true`, und "with either gate off, insert/update/delete on the federated object is rejected." (Ist eines der beiden Gates geschlossen, wird insert/update/delete auf dem föderierten Objekt abgewiesen.) Das Gate ist nicht beratend: `assertWriteAllowed` läuft ganz oben in `insert` und `update` der Engine, vor Defaults, Hooks und Validierung. Öffnen Sie beide Gates pro Objekt, und Sie besitzen nun Schreibsemantik gegen ein Schema, das Sie nicht kontrollieren, und `schemaMode: 'external'` lässt den Boot bei einer Schema-Abweichung fehlschlagen, sodass eine Spaltenumbenennung upstream Ihre App stilllegt. Oder Sie bauen stattdessen Sync-Jobs, und dann haben Sie die Integrationsschicht gebaut, die Sie nicht kaufen wollten, in einem Werkzeug, dessen eigene Dokumentation seine Föderation "early" (früh) nennt. + +**Der entscheidende Fakt.** Zwei Opt-ins, beide standardmäßig aus: `allowWrites` auf der Datenquelle und `writable` auf dem Objekt (`content/docs/data-modeling/external-datasources.mdx`, der Abschnitt über Schreibvorgänge), durchgesetzt von `assertWriteAllowed` in `packages/objectql/src/engine.ts`. + +Der ehrliche Weg existiert, und er ist schmal: nur lesend anbinden, messen, Schreibvorgänge Objekt für Objekt freischalten, pro Objekt umstellen. [How to move an internal system to metadata](/en/blog/how-to-move-an-internal-system-to-metadata/) geht ihn durch, einschließlich der Fälle, in denen die richtige Antwort ist, gar nicht zu migrieren. Dieser Weg ist für ein System, das Sie *ersetzen* wollen. Wenn Sie vierzig Systeme behalten und über sie hinweg lesen wollen, ist es die falsche Straße. + +## 3. Analytik über Data Lakes + +**Das Szenario.** Ein Händler hat drei Jahre Clickstream- und Kassenereignisse im Objektspeicher, als Parquet- und Iceberg-Tabellen, und das Merchandising-Team will Dashboards. Jemand bemerkt, dass die Plattform Dashboards, Reports und eine Dataset-Schicht hat, die ihre Dokumentation semantisch nennt, und schlägt vor, sie auf den Lake zu richten. + +**Was stattdessen, und warum.** Der Warehouse-Stack: eine Query-Engine für spaltenorientierte Scans, eine Metrik- oder Semantikschicht darüber und ein BI-Tool obenauf. Die Analytik-Schicht in ObjectStack ist eine Metrikschicht für die eigenen Zeilen der Anwendung. Ihre Dokumentation definiert ein Dataset als "a base object, the relationships to include, and the declared dimensions and measures" (ein Basisobjekt, die einzubeziehenden Beziehungen und die deklarierten Dimensionen und Kennzahlen), mit Joins, die aus dem Objektgraphen abgeleitet werden; das Schema macht das wörtlich und beschreibt das `object` eines Datasets als "Base object name" (Name des Basisobjekts). Die When-to-use-Seite sagt es in einem Satz: Die Analytik-Schicht "defines metrics over the app's own objects for its reports and dashboards. It is not built to query a lake." (definiert Metriken über die eigenen Objekte der App für deren Reports und Dashboards. Sie ist nicht dafür gebaut, einen Lake abzufragen.) Ein Warehouse-Semantic-Layer erledigt dieselbe Aufgabe über einem Lake, und die Vergleichsseite dieser Website sagt, dass ein Unternehmen mit ernsthaftem BI weiterhin einen wollen wird. + +**Die Kosten der falschen Wahl.** Eine von zwei Kopien. Entweder laden Sie den Lake in App-Objekte, und haben nun eine zweite Kopie von drei Jahren Ereignissen mit eigener Aktualität und eigener Rechnung, in einem Zeilenspeicher, der aus einer Geschäftsdefinition abgeleitet statt für Scans entworfen ist; oder Sie föderieren eine Warehouse-Tabelle und stellen fest, dass Sie analytische Fragen durch eine Engine schicken, die gebaut ist, um Zeilenabfragen für eine Anwendung zu beantworten, mit Filter-Pushdown und nichts, das eine spaltenorientierte Datei kennt. Die Dashboards werden rendern. Es werden nicht die Dashboards sein, die das Merchandising-Team wollte. + +**Der entscheidende Fakt.** Die Datenquellen, die die README listet, sind PostgreSQL, MySQL, SQLite, MongoDB und In-Memory; das Paketverzeichnis, das die README jetzt an `CONTRIBUTING.md` abgibt, ergänzt Turso und SQLite in WebAssembly. Es gibt kein Lake-Format, keine spaltenorientierte Engine und keinen Objektspeicher-Treiber, und die Dataset-Schicht bindet an ein Objekt, nicht an eine Tabelle in einem Lake. + +## 4. Algorithmenlastige Domänen wie Pricing oder Scheduling + +**Das Szenario.** Das Produkt eines Logistikunternehmens ist ein Routenoptimierer: ein Solver, der die Aufträge eines Tages und eine Flotte nimmt und einen Plan erzeugt, mit einem Dispositionsboard, auf dem Planer Stopps zwischen Fahrzeugen verschieben und zusehen, wie der Plan neu gelöst wird. Aufträge, Fahrzeuge, Fahrer und Pläne sind offensichtlich Objekte; das Unternehmen fragt, ob das Ganze eine ausführbare Ontologie sein könnte. + +**Was stattdessen, und warum.** Code, für den Solver und für das Board, und hier ist die eigene Dokumentation der Ontologie das stärkste Argument der Gegenseite. Die When-to-use-Seite: Die Ontologie "declares what can be done; it does not express an optimiser." (deklariert, was getan werden kann; sie drückt keinen Optimierer aus.) Der `type` einer Aktion ist einer von `script`, `url`, `modal`, `flow`, `api` oder `form`, und der Handler einer `script`-Aktion ist Code, der mit der vollen Datenautorität der App läuft. Die Definition besitzt die Tür, die Berechtigung an der Tür und das Audit, wer hindurchgegangen ist. Der Algorithmus hinter der Tür gehört Ihnen, in welcher Sprache auch immer ihn löst. Die Oberfläche ist dieselbe Geschichte in die andere Richtung: Die Vergleichsseite sagt, die Console sei "server-driven from metadata, and an interface unlike any business app is easier to build directly." (servergetrieben aus Metadaten, und eine Oberfläche, die keiner Geschäftsanwendung gleicht, ist direkt leichter zu bauen.) + +**Die Kosten der falschen Wahl.** Den Teil, der zählt, an dem Ort mit der geringsten Freiheit zu bauen. Ein Solver kann hinter einer Aktion leben, und für einen Scheduling-Lauf, der von einem Datensatz ausgelöst wird, ist das genau richtig. Ein Dispositionsboard kann das nicht: Eingeschränktes JSX in Seiten "is parsed into a server-driven UI tree, never executed as code" (wird in einen servergetriebenen UI-Baum geparst, nie als Code ausgeführt), absichtlich, sodass jede Interaktion, die die Planer brauchen, zu einer Verhandlung mit einem Renderer wird, der für Listen, Formulare und Boards gebaut ist. Sechs Monate später ist die Ontologie eine dünne Hülle um das, was Sie tatsächlich verkaufen. + +**Der entscheidende Fakt.** `ActionType` in `packages/spec/src/ui/action.zod.ts` ist die geschlossene Menge `script | url | modal | flow | api | form`. Der Algorithmus ist nie einer davon, nur der Weg zu ihm. + +Die Aufteilung, die funktioniert: die Geschäftshälfte, Aufträge, Fahrzeuge, Fahrer, wer einen Plan freigeben darf, was geschieht, wenn ein Plan veröffentlicht wird, als Ontologie, wo ein Agent sie schreiben und bedienen kann; der Solver als Code hinter einer `script`-Aktion, sodass Berechtigungen, Audit und Agent-Zugriff für ihn gelten wie für jede andere Aktion; das Board der Planer als eigene Anwendung. Wenn das Board *das* Produkt ist, fangen Sie dort an. + +## 5. Workloads, die eine zertifizierte Plattform erfordern + +**Das Szenario.** Eine Krankenhausgruppe will einen Aufnahme-Workflow, und ihr Einkauf verlangt, dass die Plattform, auf der er läuft, eine bestimmte Attestierung besitzt. Eine öffentliche Ausschreibung stellt dieselbe Frage zu einem ISO-Zertifikat. Der Workload selbst, Formulare, Routing, Freigaben und ein Audit-Trail, passt wie aus dem Lehrbuch. + +**Was stattdessen, und warum.** Entweder eine Plattform, die das Zertifikat besitzt, oder ein Deployment, das Sie selbst zertifizieren, und die Entscheidung ist der Kalender des Käufers, nicht die Roadmap des Anbieters. Die When-to-use-Seite: "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." (ObjectStack ist Open-Source-Software, die Sie bereitstellen und betreiben, und sie trägt keine eigene Compliance-Zertifizierung. Wo ein Workload auf einer zertifizierten Plattform laufen muss, ist die Zertifizierung Ihres Deployments Arbeit, die Ihnen gehört.) Das ist kein Ausweichen; so funktioniert Zertifizierung. Eine Attestierung deckt eine laufende Umgebung, ihre Kontrollen und ihre Betreiber ab, und ein Apache-2.0-Repository ist nichts davon. Die [Sicherheitsseite](/de/security/) dieser Website sagt dasselbe über die kommerzielle Edition: "Certification depends on your running deployment, not a binary alone." (Die Zertifizierung hängt von Ihrem laufenden Deployment ab, nicht von einer Binärdatei allein.) + +**Die Kosten der falschen Wahl.** Das erst beim Einkauf statt beim Entwurf zu entdecken, wenn der Zeitplan bereits annahm, die Plattform bringe ihr Zertifikat mit. Das Audit landet dann auf Ihrem Plan, ohne Budget, kurz vor dem Go-live. + +**Der entscheidende Fakt.** Das Glossar des Projekts führt selbst sein eigenes Protokoll-Konformitätskit als "planned" (geplant), mit "no TCK program or certification mechanism in the codebase today" (heute kein TCK-Programm und kein Zertifizierungsmechanismus in der Codebasis). Es gibt nichts, worauf man einen Auditor verweisen könnte, außer Ihrem Deployment. + +Der Workload passt weiterhin; der Host ist die Frage. Die ehrliche Reihenfolge ist, zuerst die Zertifizierungsarbeit zu bepreisen und dann zu entscheiden. + +## Zwei weitere Stellen, an denen eine andere Kategorie vorne startet + +Die Vergleichsseite fügt zwei Zugeständnisse hinzu, die nicht auf der Nicht-passend-Liste stehen, weil sie von einer Art von Problem handeln statt von einer Art von Workload. Beide gehen durch den Sechs-Arten-Test auf dieselbe Weise. + +**Schließen über heterogene Daten.** Wenn die Frage lautet „was folgt aus allem, was wir wissen“, mit Klassenhierarchien, abgeleiteten Fakten und Konsistenzprüfungen über Vokabulare hinweg, dann ist das die Aufgabe einer Wissensontologie, und ObjectStack hat "no object inheritance, no axioms and no reasoner" (keine Objektvererbung, keine Axiome und keinen Reasoner). Der Schlüssel `abstract` wurde aus der Spezifikation entfernt statt als Versprechen stehen zu bleiben. Die Definition wird validiert, dann ausgeführt; nichts wird zur Laufzeit gefolgert. [Der Grundsatzbeitrag](/de/blog/what-does-the-ontology-is-the-software-mean/) behandelt diese Verneinung vollständig. + +**Reife des Ökosystems.** Salesforce, Odoo und ERPNext "bring years of production use, packaged applications, app marketplaces and implementation partners. ObjectStack is younger; expect to build more of it yourself." (bringen Jahre des Produktiveinsatzes, paketierte Anwendungen, App-Marktplätze und Implementierungspartner mit. ObjectStack ist jünger; rechnen Sie damit, mehr davon selbst zu bauen.) Wenn Sie dieses Quartal eine paketierte App brauchen und einen Implementierungspartner in Ihrer Stadt, ist eine jüngere Plattform die falsche Wette, wie auch immer ihre Definitionen geschrieben sind. + +## Die Entscheidungstabelle + +Jede Zeile: der Workload, ob er heute passt und was stattdessen zu verwenden ist, und der eine Fakt, der es entscheidet, mit seiner Quelle. „Heute“ ist ein Datum: Die Quellen sind objectstack am Tag `@objectstack/cli@18.2.0`, der Version, die `npm view @objectstack/cli dist-tags` am 2026-10-28 als `latest` meldete, an diesem Tag gelesen. Quellen werden nach Datei benannt: when-to-use, compare und ontology sind `content/docs/concepts/*.mdx`; external-datasources und analytics liegen unter `content/docs/data-modeling/`; glossary liegt unter `content/docs/getting-started/`; `engine.ts` ist `packages/objectql/src/engine.ts`; `dataset.zod.ts` und `action.zod.ts` liegen unter `packages/spec/src/ui/`; README und `CONTRIBUTING.md` liegen im Repository-Root. + +| Workload | Passt heute? Was stattdessen | Der entscheidende Fakt (Quelle) | +| :--- | :--- | :--- | +| Kern-ERP oder Finanzen eines Großunternehmens | **Nein.** Das Standardsystem; darum herum bauen | Regulierung und Sonderfälle sind das Produkt; die zwölf Fähigkeiten der Runtime enthalten keine Hauptbuch-, Steuer- oder Lohn-Engine (when-to-use; README-Fähigkeitstabelle) | +| Integration vieler bestehender Systeme | **Nein.** Ein Semantic oder Context Layer; eine operative Ontologie, wo Writeback stattfindet | Föderation ist standardmäßig doppelt nur lesend: `allowWrites` auf der Datenquelle und `writable` auf dem Objekt (external-datasources; `assertWriteAllowed` in `engine.ts`) | +| Analytik über einen Data Lake | **Nein.** Eine Warehouse-Query-Engine, eine Metrikschicht, BI | Ein Dataset bindet an ein Basisobjekt; die Treiber sind Zeilenspeicher, ohne Lake-Format (analytics; `dataset.zod.ts`; README-Datenquellen; `CONTRIBUTING.md`-Treiber) | +| Algorithmenlastige Domäne | **Nicht für den Algorithmus.** Code; hinter einer `script`-Aktion, wenn der Rest eine Geschäftsanwendung ist | `ActionType` ist script, url, modal, flow, api, form; der Solver ist nie ein Typ (`action.zod.ts`; when-to-use) | +| Muss auf einer zertifizierten Plattform laufen | **Nicht ohne Arbeit, die Ihnen gehört.** Eine zertifizierte Plattform, oder Ihr Deployment zertifizieren | Keine eigene Compliance-Zertifizierung; selbst das Konformitätskit ist „geplant“ (when-to-use; glossary) | +| Schließen über heterogene Daten | **Nein.** Eine Wissensontologie mit Reasoner | Keine Vererbung, keine Axiome, kein Reasoner; `abstract` unter ADR-0049 entfernt (ontology; compare) | +| Braucht jetzt ein reifes Ökosystem | **Noch nicht.** Eine Metadatenplattform mit paketierten Apps und Partnern | „ObjectStack ist jünger; rechnen Sie damit, mehr davon selbst zu bauen“ (compare) | +| Eine neue Geschäftsanwendung: CRM, Ticketing, Freigaben, Operations, interne Tools | **Ja.** | Objekte, Relationen, Aktionen, Berechtigungen und Flows sind das meiste, was diese Apps sind (when-to-use) | +| Der Long Tail um ein Kern-ERP | **Ja.** | Klein, spezifisch, ändert sich oft; eine typisierte Definition pro App, die das ERP liest, ohne es zu besitzen (when-to-use) | +| Ein Backoffice, das vom ersten Tag an von Agents bedient wird | **Ja.** | Jedes Deployment ist ein MCP-Server, standardmäßig an, unter den Berechtigungen des Nutzers (when-to-use; README) | + +![Der Selbsttest in zwei Stufen. Stufe eins, fünf Ausschlüsse, jedes Ja bedeutet, dass die Ontologie nicht das Werkzeug für diesen Teil ist: eine Hauptbuch-, Konsolidierungs-, Steuer- oder Lohnberechnung; Wert hauptsächlich in Systemen, die Sie behalten und nicht besitzen; Daten, die in einem Lake oder Warehouse ruhen; ein Solver, Optimierer oder eine Oberfläche, die keiner Geschäftsanwendung gleicht; eine Plattform, die eine bestimmte Zertifizierung besitzen muss. Stufe zwei, die fünf Fragen vor dem Start: was wir haben, wie es zusammenhängt, was getan werden kann, wer es tun darf, was wann geschieht. Drei Urteile: fünf Nein und fünf Antworten passen und sind ein Tag Arbeit für einen Agent; jedes Ja teilt den Workload entlang dieser Linie; Nein ohne Antworten heißt, dass noch kein Werkzeug hilft.](./self-check-en.svg) + +## Führen Sie den Selbsttest durch + +Zehn Fragen, zwei Stufen, zehn Minuten. Stufe eins ist die Ausschlussliste; Stufe zwei sind die "Five questions before you start" (Fünf Fragen, bevor Sie beginnen) der When-to-use-Seite, zitiert, wie sie dort stehen. + +**Stufe eins. Jedes Ja bedeutet, dass die Ontologie nicht das Werkzeug für diesen Teil ist.** + +1. Ist der schwierige Teil dieses Workloads eine regulierte Berechnung, die ein Standardsystem bereits kodiert: Hauptbuch, Konsolidierung, Steuern, Lohnabrechnung? +2. Kommt der größte Teil des Werts aus dem Lesen und Schreiben von Systemen, die Sie behalten und nicht besitzen? +3. Ruhen die Daten, die Sie analysieren wollen, in einem Lake oder Warehouse statt in den eigenen Datensätzen der Anwendung? +4. Ist der Kern des Produkts ein Solver, ein Optimierer oder eine Simulation, oder eine Oberfläche, die keiner Geschäftsanwendung gleicht? +5. Muss der Workload auf einer Plattform laufen, die eine bestimmte Zertifizierung besitzt, ohne Budget, ein eigenes Deployment zu zertifizieren? + +**Stufe zwei. Kann Ihr Team diese Fragen für das Geschäft heute beantworten?** + +6. "What we have — the objects and their fields." (Was wir haben: die Objekte und ihre Felder.) +7. "How it relates — the lookups and master-detail links between them." (Wie es zusammenhängt: die Lookups und Master-Detail-Verknüpfungen zwischen ihnen.) +8. "What can be done — the actions a user or an agent may take on a record." (Was getan werden kann: die Aktionen, die ein Nutzer oder ein Agent auf einem Datensatz ausführen darf.) +9. "Who may do it — permission sets, row-level and field-level security, sharing." (Wer es tun darf: Berechtigungssets, Sicherheit auf Zeilen- und Feldebene, Freigabe.) +10. "What happens when — record triggers, scheduled jobs, approvals, workflows." (Was wann geschieht: Datensatz-Trigger, geplante Jobs, Freigaben, Workflows.) + +Fünf Nein und fünf Antworten: Die Ontologie ist, in den Worten der Seite, "a day's work, because an agent does the writing." (ein Tag Arbeit, weil ein Agent das Schreiben übernimmt.) Fünf Nein und keine Antworten: "no tool helps yet, this one included. The first investment is answering these five questions, not installing anything." (Noch hilft kein Werkzeug, dieses eingeschlossen. Die erste Investition ist, diese fünf Fragen zu beantworten, nicht irgendetwas zu installieren.) Ein Ja in Stufe eins: Teilen Sie den Workload entlang dieser Linie, behalten Sie den Teil, der bestanden hat, und verwenden Sie für den Rest die Alternative aus der Tabelle. + +## Was diese Liste nicht sagt + +Sie sagt nicht, dass diese Grenzen dauerhaft sind. Die Seite trägt den Titel „not a fit *today*“ (passt *heute* nicht), die Föderation wird „early“ (früh) genannt, und die Tabelle oben trägt ein Datum; lesen Sie sie gegen die aktuelle Seite, bevor Sie entscheiden. + +Sie sagt nicht, dass die Alternativen im Allgemeinen besser sind. Ein Semantic Layer ist das richtige Werkzeug, um über vierzig Systeme hinweg zu lesen, und das falsche, um einen Ticketdesk zu betreiben, aus den Gründen, die der zweite Abschnitt in die andere Richtung nennt. Die Alternative jeder Zeile ist für diese Zeile richtig. + +Und sie sagt nicht, dass das Durchfallen in einer Zeile den Workload durchfallen lässt. Die meisten realen Fälle teilen sich: Der Aufnahme-Workflow passt und der Host ist eine Einkaufsfrage; die Dispositionsdomäne passt und der Solver ist Code; die Abteilungs-Apps um das ERP passen und das Hauptbuch bleibt, wo es ist. Der Sechs-Arten-Test wird auf den schwierigen Teil angewandt, nicht auf den Projektnamen. + +## Wo ObjectOS in dieser Liste steht + +Nichts von dem Obigen ändert sich mit der Edition. „Dieselbe Schleife gehostet, im Browser, ohne Installation? Das ist ObjectOS, die kommerzielle Laufzeitumgebung auf Basis von ObjectStack.“ ObjectOS gibt es in drei Editionen: ObjectOS Community, quelloffen und kostenlos selbst gehostet; ObjectOS Cloud, gehostet im Browser ohne Installation; und ObjectOS Enterprise, selbst verwaltet auf Ihrer eigenen Infrastruktur. In jeder Edition können Sie Ihre Ontologie exportieren und in einer anderen ausführen. Die fünf Workloads handeln davon, was eine ausführbare Ontologie ausdrücken kann, nicht davon, wo sie läuft, also liest sich die Liste auf jedem Host gleich. Die eine Frage, die den Host betrifft, die Zertifizierung, beantwortet die Sicherheitsseite für ObjectOS in denselben Worten wie die Open-Source-Seite: Sie hängt vom laufenden Deployment ab. + +## Wenn Ihr Fall bestanden hat + +Dann ist der schnellste ehrliche nächste Schritt keine Demo; es ist eine Definition. Richten Sie Ihren Coding-Agent auf ObjectStack, mit der Regeldatei, dem Skills-Bundle und dem Tool-Server, die in [how to point your agent at ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/) behandelt werden, und bitten Sie ihn um das erste Objekt: ein paar Felder, eine Relation, eine Aktion, ein Berechtigungsset und einen Trigger. Führen Sie `npm run validate` aus und lesen Sie den Diff, bevor Sie die Console lesen. Wenn Sie den ganzen Diff lesen können und er sagt, was Ihr Geschäft tut, hat der Sechs-Arten-Test in der Praxis bestanden, und [was die Definition ist](/en/ontology/) ist die nächste Seite, die Sie dem Agent geben. Wenn nicht, hätte nichts in diesem Beitrag je geholfen, und Sie haben gerade ein Projekt gespart. diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/index.es.mdx b/content/blog/when-not-to-use-an-executable-business-ontology/index.es.mdx new file mode 100644 index 0000000..9263314 --- /dev/null +++ b/content/blog/when-not-to-use-an-executable-business-ontology/index.es.mdx @@ -0,0 +1,149 @@ +--- +title: "¿Cuándo no deberías usar una ontología de negocio ejecutable?" +description: "Cinco cargas de trabajo donde una ontología de negocio ejecutable es hoy la herramienta equivocada, qué usar en su lugar, el coste de elegir mal y una tabla de decisión con fuente en cada fila." +author: ObjectStack Team +date: 2026-10-28 +status: published +topic: app-building +audience: it +solutions: [] +industries: [] +cover: ./cover-en.svg +tags: + - Ontología + - Ontología de negocio ejecutable + - Cuándo usarla +--- + +**Respuesta corta: no para cinco cargas de trabajo, y la propia documentación de ObjectStack las nombra.** Sustituir el ERP o el sistema financiero central de una gran empresa. Trabajo cuyo valor está en integrar muchos sistemas existentes. Analítica sobre data lakes. Dominios con mucho algoritmo, como pricing o planificación, salvo que el algoritmo se envuelva en una acción. Y cualquier cosa que deba ejecutarse en una plataforma certificada. Para cada caso hay una herramienta mejor, y este artículo dice cuál, por qué es la decisión correcta y qué cuesta equivocarse. Al final: una tabla de decisión con una fuente en cada fila y una autoevaluación de diez preguntas que puedes aplicar a tu propio caso antes de instalar nada. + +Una lista honesta de dónde un producto es la herramienta equivocada es lo más útil que un proveedor puede publicar, porque es lo único que un comprador no obtiene de la presentación comercial. El posicionamiento en una línea de ObjectStack es: «Una ontología de negocio ejecutable. La AI la escribe, el runtime la ejecuta, los agentes la operan, tú la posees.» Todo lo que sigue trata de los bordes de esa frase, tomados de la propia [página when-to-use](https://objectstack.ai/docs/concepts/when-to-use) del proyecto y de su [página de comparación](https://objectstack.ai/docs/concepts/compare) en la etiqueta `@objectstack/cli@18.2.0`, leída el 2026-10-28, y del archivo fuente donde el límite es una línea de código. La [página de comparación](/en/compare/) de este sitio ya enumera las cinco cargas de trabajo y las cinco preguntas en una línea cada una; este artículo es la versión larga: un escenario para cada caso, la alternativa y su justificación, el coste y el hecho decisivo. + +## La prueba de las seis clases + +Una sola prueba cubre los cinco casos, así que conviene enunciarla primero. La página de conceptos define el núcleo de una ontología de negocio ejecutable como seis clases de cosas: objetos y campos, relaciones, acciones, permisos, flujos, y definiciones de agentes y herramientas. El runtime deriva la base de datos, la API, la UI y las herramientas de agente a partir de esas seis, y las hace cumplir en cada llamada. El código no desaparece, pero se traslada al runtime, como hooks, cuerpos de acciones, CEL y JSX restringido, dentro del cercado que definen las seis clases. + +Así que pregunta de cualquier carga de trabajo: **¿la parte difícil es una de las seis clases?** Si la parte difícil, valiosa y arriesgada del trabajo es decidir qué existe, cómo se relaciona, qué puede hacerse, quién puede hacerlo y qué ocurre cuándo, la ontología es la herramienta, y un agente puede escribirla. Si la parte difícil es otra cosa, un cálculo legal, una conexión con cuarenta sistemas, un escaneo sobre un petabyte, un solver, el certificado de un auditor, entonces esa parte no es expresable como definición, y la ontología en el mejor de los casos la envuelve y en el peor la imita. Llamémoslo la **prueba de las seis clases**. Cada una de las cinco cargas de trabajo de abajo la suspende por una razón distinta, y por eso necesitan cinco alternativas distintas en lugar de una. + +## 1. El ERP o el sistema financiero central de una gran empresa + +**El escenario.** Un fabricante con cuatro mil personas lleva doce años con su libro mayor, su consolidación y su nómina en un ERP empaquetado. Un agente de programación, al que se le muestra el plan de cuentas, se ofrece a redeclararlo como objetos, con reglas de asiento como flujos e impuestos como fórmulas. La demo convence: diarios, un balance de comprobación, una aprobación en cada asiento. + +**Qué usar en su lugar, y por qué es lo correcto.** El sistema empaquetado, y construir alrededor de él. La página when-to-use: "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." (Un libro mayor, la consolidación, los impuestos y la nómina llevan regulación y casos límite que los sistemas empaquetados ya codifican. Construye alrededor de ese núcleo, no en su lugar.) En ese mercado la regulación es el producto. Un motor de nómina es una biblioteca de jurisdicciones, calendarios de presentación y correcciones retroactivas, mantenida por personas cuyo único trabajo es mantenerla al día; un motor de consolidación son años de eliminaciones intercompañía y de casos límite de conversión de divisas. Nada de eso es «qué existe y quién puede hacer qué». Es cálculo, y cambia cuando un gobierno lo cambia, no cuando lo hace tu negocio. + +**El coste de elegir mal.** Un segundo libro mayor. Cada regla que recodificaste es ahora tu diff que mantener, tu auditoría que superar y tu defecto cuando cambia el ejercicio fiscal, mientras el sistema empaquetado que conservaste para la información legal discrepa un poco más de tu copia cada trimestre. El agente que escribió las reglas en un día no puede leer un código tributario por ti. + +**El hecho decisivo.** La tabla de capacidades del README enumera doce cosas que el runtime proporciona: objetos y campos, permisos, automatización, aprobaciones, vistas, paneles e informes, acciones, APIs y SDK, herramientas de AI, traducciones, datos semilla, fuentes de datos. Un libro mayor, un motor fiscal y un proceso de nómina no están en ella, y el proyecto no dice que vayan a llegar. + +Lo que sí encaja, según la misma página, es la larga cola alrededor de ese núcleo: "vendor onboarding, inspections, internal requests" (alta de proveedores, inspecciones, solicitudes internas), las hojas de cálculo y formularios que registran lo que el ERP no cubre. Cada uno se convierte en una definición tipada en lugar de un archivo que circula por correo, y cada uno puede leer los datos del ERP sin poseerlos, que es el siguiente caso. + +## 2. Cargas de trabajo cuyo valor está en integrar muchos sistemas existentes + +**El escenario.** Un banco quiere que sus agentes respondan a la pregunta de un cliente desde el core bancario, el CRM, la plataforma de tarjetas y el sistema de tickets a la vez, y que escriban un estado en dos de ellos. Ninguno de esos sistemas se va a mover. El trabajo es hacerlos legibles para un agente y actuar a través de ellos. + +**Qué usar en su lugar, y por qué.** Una capa sobre los sistemas: una capa semántica o de contexto para la lectura, una ontología operativa al estilo de Palantir cuando hay escritura de vuelta que gobernar. La página de comparación lo reconoce sin rodeos: "When the data already lives in a warehouse, a lakehouse and a dozen operational systems, these start where you are." (Cuando los datos ya viven en un warehouse, un lakehouse y una docena de sistemas operativos, estas empiezan donde tú estás.) Esos productos están construidos sobre el supuesto de que el sistema de registro se queda donde está; su modelo de objetos es una vista, sus escrituras son writeback, y su valor crece con el número de sistemas que hay debajo. ObjectStack está construido sobre el supuesto contrario: que la ontología *es* el sistema y la base de datos se deriva de ella. + +**El coste de elegir mal.** Este es el caso en que más se falla, porque la primera semana va bien. ObjectStack puede federar una base de datos externa como fuente de datos con `schemaMode: 'external'`, y un modelo de lectura sobre una tabla heredada es una tarde corta. Luego llegan las escrituras. Las escrituras federadas están apagadas por defecto dos veces: la fuente de datos debe declarar `external.allowWrites: true` y el objeto debe declarar `external.writable: true`, y "with either gate off, insert/update/delete on the federated object is rejected." (con cualquiera de las dos puertas cerrada, insert/update/delete sobre el objeto federado se rechaza.) La puerta no es consultiva: `assertWriteAllowed` se ejecuta al principio de `insert` y `update` del motor, antes de valores por defecto, hooks y validación. Abre ambas puertas objeto por objeto y ahora posees la semántica de escritura contra un esquema que no controlas, y `schemaMode: 'external'` hace fallar el arranque ante una discrepancia de esquema, así que un renombrado de columna aguas arriba tumba tu aplicación. O construyes trabajos de sincronización en su lugar, y para entonces has construido la capa de integración que intentabas no comprar, dentro de una herramienta cuya propia documentación llama a su federación "early" (temprana). + +**El hecho decisivo.** Dos opt-ins, ambos apagados por defecto: `allowWrites` en la fuente de datos y `writable` en el objeto (`content/docs/data-modeling/external-datasources.mdx`, la sección sobre escrituras), aplicados por `assertWriteAllowed` en `packages/objectql/src/engine.ts`. + +El camino honesto existe, y es estrecho: conectar en solo lectura, medir, habilitar escrituras un objeto a la vez, migrar objeto por objeto. [How to move an internal system to metadata](/en/blog/how-to-move-an-internal-system-to-metadata/) lo recorre, incluidos los casos en los que la respuesta correcta es no migrar en absoluto. Ese camino es para un sistema que pretendes *sustituir*. Si pretendes conservar cuarenta sistemas y leer a través de ellos, es la carretera equivocada. + +## 3. Analítica sobre data lakes + +**El escenario.** Un minorista tiene tres años de eventos de clickstream y de punto de venta en almacenamiento de objetos, como tablas Parquet e Iceberg, y el equipo de merchandising quiere paneles. Alguien nota que la plataforma tiene paneles, informes y una capa de datasets que su documentación llama semántica, y propone apuntarla al lake. + +**Qué usar en su lugar, y por qué.** La pila de warehouse: un motor de consulta construido para escaneos columnares, una capa de métricas o semántica sobre él y una herramienta de BI encima. La capa analítica de ObjectStack es una capa de métricas para las filas propias de la aplicación. Su documentación define un dataset como "a base object, the relationships to include, and the declared dimensions and measures" (un objeto base, las relaciones a incluir y las dimensiones y medidas declaradas), con joins derivados del grafo de objetos; el esquema lo hace literal, describiendo el `object` de un dataset como "Base object name" (nombre del objeto base). La página when-to-use lo dice en una frase: la capa analítica "defines metrics over the app's own objects for its reports and dashboards. It is not built to query a lake." (define métricas sobre los propios objetos de la app para sus informes y paneles. No está construida para consultar un lake.) Una capa semántica de warehouse hace el mismo trabajo sobre un lake, y la página de comparación de este sitio dice que una empresa que hace BI en serio seguirá queriendo una. + +**El coste de elegir mal.** Una de dos copias. O cargas el lake en objetos de la app, y ahora tienes una segunda copia de tres años de eventos con su propia frescura y su propia factura, en un almacén de filas derivado de una definición de negocio en lugar de diseñado para escaneos; o federas una tabla de warehouse y descubres que estás enviando preguntas analíticas a través de un motor construido para responder consultas a nivel de fila para una aplicación, con pushdown de filtros y nada que conozca un archivo columnar. Los paneles se renderizarán. No serán los paneles que pidió el equipo de merchandising. + +**El hecho decisivo.** Las fuentes de datos que enumera el README son PostgreSQL, MySQL, SQLite, MongoDB y en memoria; el directorio de paquetes, que el README ahora delega en `CONTRIBUTING.md`, añade Turso y SQLite en WebAssembly. No hay formato de lake, ni motor columnar, ni driver de almacenamiento de objetos, y la capa de datasets se vincula a un objeto, no a una tabla en un lake. + +## 4. Dominios con mucho algoritmo, como pricing o planificación + +**El escenario.** El producto de una empresa logística es un optimizador de rutas: un solver que toma los pedidos de un día y una flota y produce un plan, con un tablero de despacho donde los planificadores arrastran paradas entre vehículos y ven cómo el plan se vuelve a resolver. Los pedidos, vehículos, conductores y planes son claramente objetos; la empresa pregunta si todo el conjunto podría ser una ontología ejecutable. + +**Qué usar en su lugar, y por qué.** Código, para el solver y para el tablero, y aquí la propia documentación de la ontología es el mejor argumento a favor de la alternativa. La página when-to-use: la ontología "declares what can be done; it does not express an optimiser." (declara qué puede hacerse; no expresa un optimizador.) El `type` de una acción es uno de `script`, `url`, `modal`, `flow`, `api` o `form`, y el handler de una acción `script` es código que se ejecuta con toda la autoridad de datos de la app. La definición posee la puerta, el permiso de la puerta y la auditoría de quién la cruzó. El algoritmo tras la puerta es tuyo, en el lenguaje que lo resuelva. La interfaz es la misma historia en la otra dirección: la página de comparación dice que la Console es "server-driven from metadata, and an interface unlike any business app is easier to build directly." (dirigida por el servidor a partir de metadatos, y una interfaz que no se parece a ninguna aplicación de negocio es más fácil de construir directamente.) + +**El coste de elegir mal.** Construir la parte que importa en el lugar con menos libertad. Un solver puede vivir detrás de una acción, y para una ejecución de planificación lanzada desde un registro eso es exactamente lo correcto. Un tablero de despacho no puede: el JSX restringido en las páginas "is parsed into a server-driven UI tree, never executed as code" (se parsea en un árbol de UI dirigido por el servidor, nunca se ejecuta como código), por diseño, así que cada interacción que los planificadores necesitan se convierte en una negociación con un renderizador construido para listas, formularios y tableros. Seis meses después, la ontología es un envoltorio fino alrededor de lo que realmente vendes. + +**El hecho decisivo.** `ActionType` en `packages/spec/src/ui/action.zod.ts` es el conjunto cerrado `script | url | modal | flow | api | form`. El algoritmo nunca es uno de ellos, solo la ruta hacia él. + +La división que funciona: la mitad de negocio, pedidos, vehículos, conductores, quién puede aprobar un plan, qué ocurre cuando se publica un plan, como ontología, donde un agente puede escribirla y operarla; el solver como código detrás de una acción `script`, de modo que permisos, auditoría y acceso de agentes se le aplican como a cualquier otra acción; el tablero de los planificadores como su propia aplicación. Si el tablero *es* el producto, empieza por ahí. + +## 5. Cargas de trabajo que requieren una plataforma certificada + +**El escenario.** Un grupo hospitalario quiere un flujo de admisión, y su área de compras exige que la plataforma en la que se ejecute posea una certificación concreta. Una licitación pública hace la misma pregunta sobre un certificado ISO. La carga de trabajo en sí, formularios, enrutamiento, aprobaciones y una pista de auditoría, encaja de manual. + +**Qué usar en su lugar, y por qué.** O bien una plataforma que posea el certificado, o bien un despliegue que certifiques tú mismo, y la decisión es el calendario del comprador, no la hoja de ruta del proveedor. La página when-to-use: "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." (ObjectStack es software de código abierto que tú despliegas y operas, y no lleva ninguna certificación de cumplimiento propia. Donde una carga de trabajo deba ejecutarse en una plataforma certificada, certificar tu despliegue es trabajo que te pertenece.) Eso no es evasión; así funciona la certificación. Una certificación cubre un entorno en ejecución, sus controles y sus operadores, y un repositorio Apache-2.0 no es ninguna de esas cosas. La [página de seguridad](/es/security/) de este sitio dice lo mismo de la edición comercial: "Certification depends on your running deployment, not a binary alone." (La certificación depende de tu despliegue en ejecución, no de un binario por sí solo.) + +**El coste de elegir mal.** Descubrirlo en la fase de compras en lugar de en el diseño, cuando el calendario ya daba por hecho que la plataforma traía su certificado. La auditoría cae entonces sobre tu plan, sin presupuesto, justo antes de la puesta en marcha. + +**El hecho decisivo.** El glosario del proyecto lista incluso su propio kit de conformidad del protocolo como "planned" (planificado), con "no TCK program or certification mechanism in the codebase today" (ningún programa TCK ni mecanismo de certificación en el código hoy). No hay nada que mostrar a un auditor salvo tu despliegue. + +La carga de trabajo sigue encajando; la cuestión es el anfitrión. La secuencia honesta es poner precio primero al trabajo de certificación y luego decidir. + +## Dos lugares más donde otra categoría sale con ventaja + +La página de comparación añade dos concesiones que no están en la lista de lo que no encaja, porque tratan de un tipo de problema y no de un tipo de carga de trabajo. Ambas pasan por la prueba de las seis clases de la misma manera. + +**Razonar sobre datos heterogéneos.** Si la pregunta es «qué se deduce de todo lo que sabemos», con jerarquías de clases, hechos derivados y comprobaciones de consistencia entre vocabularios, ese es el trabajo de una ontología de conocimiento, y ObjectStack tiene "no object inheritance, no axioms and no reasoner" (sin herencia de objetos, sin axiomas y sin razonador). La clave `abstract` se eliminó de la especificación en lugar de dejarla como promesa. La definición se valida y luego se ejecuta; nada se infiere en tiempo de ejecución. [El artículo de la definición](/es/blog/what-does-the-ontology-is-the-software-mean/) trata esta negación a fondo. + +**Madurez del ecosistema.** Salesforce, Odoo y ERPNext "bring years of production use, packaged applications, app marketplaces and implementation partners. ObjectStack is younger; expect to build more of it yourself." (aportan años de uso en producción, aplicaciones empaquetadas, mercados de apps y socios de implementación. ObjectStack es más joven; espera construir más por tu cuenta.) Si necesitas una app empaquetada este trimestre y un socio de implementación en tu ciudad, una plataforma más joven es la apuesta equivocada, se escriban como se escriban sus definiciones. + +## La tabla de decisión + +Cada fila: la carga de trabajo, si encaja hoy y qué usar en su lugar, y el único hecho que lo decide, con su fuente. «Hoy» es una fecha: las fuentes son objectstack en la etiqueta `@objectstack/cli@18.2.0`, la versión que `npm view @objectstack/cli dist-tags` reportó como `latest` el 2026-10-28, leída ese día. Las fuentes se nombran por archivo: when-to-use, compare y ontology son `content/docs/concepts/*.mdx`; external-datasources y analytics están bajo `content/docs/data-modeling/`; glossary está bajo `content/docs/getting-started/`; `engine.ts` es `packages/objectql/src/engine.ts`; `dataset.zod.ts` y `action.zod.ts` están bajo `packages/spec/src/ui/`; README y `CONTRIBUTING.md` están en la raíz del repositorio. + +| Carga de trabajo | ¿Encaja hoy? Qué usar en su lugar | El hecho decisivo (fuente) | +| :--- | :--- | :--- | +| ERP o finanzas centrales de una gran empresa | **No.** El sistema empaquetado; construir alrededor | La regulación y los casos límite son el producto; las doce capacidades del runtime no incluyen motor de libro mayor, fiscal ni de nómina (when-to-use; tabla de capacidades del README) | +| Integrar muchos sistemas existentes | **No.** Una capa semántica o de contexto; una ontología operativa donde hay writeback | La federación es de solo lectura por defecto, dos veces: `allowWrites` en la fuente de datos y `writable` en el objeto (external-datasources; `assertWriteAllowed` en `engine.ts`) | +| Analítica sobre un data lake | **No.** Un motor de consulta de warehouse, una capa de métricas, BI | Un dataset se vincula a un objeto base; los drivers son almacenes de filas, sin formato de lake (analytics; `dataset.zod.ts`; fuentes de datos del README; drivers de `CONTRIBUTING.md`) | +| Dominio con mucho algoritmo | **No para el algoritmo.** Código; detrás de una acción `script` cuando el resto es una app de negocio | `ActionType` es script, url, modal, flow, api, form; el solver nunca es un tipo (`action.zod.ts`; when-to-use) | +| Debe ejecutarse en una plataforma certificada | **No sin trabajo que te pertenece.** Una plataforma certificada, o certificar tu despliegue | Sin certificación de cumplimiento propia; incluso el kit de conformidad está «planificado» (when-to-use; glossary) | +| Razonar sobre datos heterogéneos | **No.** Una ontología de conocimiento con razonador | Sin herencia, sin axiomas, sin razonador; `abstract` eliminado bajo ADR-0049 (ontology; compare) | +| Necesita un ecosistema maduro ya | **Todavía no.** Una plataforma de metadatos con apps empaquetadas y socios | «ObjectStack es más joven; espera construir más por tu cuenta» (compare) | +| Una nueva app de negocio: CRM, tickets, aprobaciones, operaciones, herramientas internas | **Sí.** | Objetos, relaciones, acciones, permisos y flujos son la mayor parte de lo que son estas apps (when-to-use) | +| La larga cola alrededor de un ERP central | **Sí.** | Pequeña, específica, cambia a menudo; una definición tipada por app, que lee el ERP sin poseerlo (when-to-use) | +| Un back office operado por agentes desde el primer día | **Sí.** | Cada despliegue es un servidor MCP, activado por defecto, bajo los permisos del usuario (when-to-use; README) | + +![La autoevaluación en dos etapas. Etapa uno, cinco exclusiones, cualquier sí significa que la ontología no es la herramienta para esa parte: un cálculo de libro mayor, consolidación, impuestos o nómina; valor principalmente en sistemas que conservas y no posees; datos en reposo en un lake o warehouse; un solver, un optimizador o una interfaz que no se parece a ninguna app de negocio; una plataforma que debe poseer una certificación concreta. Etapa dos, las cinco preguntas antes de empezar: qué tenemos, cómo se relaciona, qué puede hacerse, quién puede hacerlo, qué ocurre cuándo. Tres veredictos: cinco noes y cinco respuestas es un encaje y un día de trabajo para un agente; cualquier sí divide la carga de trabajo por esa línea; noes sin respuestas significa que ninguna herramienta ayuda todavía.](./self-check-en.svg) + +## Haz la autoevaluación + +Diez preguntas, dos etapas, diez minutos. La etapa uno es la lista de exclusión; la etapa dos son las "Five questions before you start" (Cinco preguntas antes de empezar) de la página when-to-use, citadas tal como las imprime. + +**Etapa uno. Cualquier sí significa que la ontología no es la herramienta para esa parte.** + +1. ¿La parte difícil de esta carga de trabajo es un cálculo regulado que un sistema empaquetado ya codifica: libro mayor, consolidación, impuestos, nómina? +2. ¿La mayor parte del valor proviene de leer y escribir sistemas que conservarás y no posees? +3. ¿Los datos que quieres analizar están en reposo en un lake o un warehouse en lugar de en los registros propios de la aplicación? +4. ¿El núcleo del producto es un solver, un optimizador o una simulación, o una interfaz que no se parece a ninguna app de negocio? +5. ¿Debe la carga de trabajo ejecutarse en una plataforma que posea una certificación concreta, sin presupuesto para certificar un despliegue propio? + +**Etapa dos. ¿Puede tu equipo responder a esto para el negocio, hoy?** + +6. "What we have — the objects and their fields." (Qué tenemos: los objetos y sus campos.) +7. "How it relates — the lookups and master-detail links between them." (Cómo se relaciona: los lookups y los enlaces maestro-detalle entre ellos.) +8. "What can be done — the actions a user or an agent may take on a record." (Qué puede hacerse: las acciones que un usuario o un agente puede ejecutar sobre un registro.) +9. "Who may do it — permission sets, row-level and field-level security, sharing." (Quién puede hacerlo: conjuntos de permisos, seguridad a nivel de fila y de campo, compartición.) +10. "What happens when — record triggers, scheduled jobs, approvals, workflows." (Qué ocurre cuándo: disparadores de registro, trabajos programados, aprobaciones, flujos de trabajo.) + +Cinco noes y cinco respuestas: la ontología es, en palabras de la página, "a day's work, because an agent does the writing." (un día de trabajo, porque un agente hace la escritura.) Cinco noes y ninguna respuesta: "no tool helps yet, this one included. The first investment is answering these five questions, not installing anything." (ninguna herramienta ayuda todavía, esta incluida. La primera inversión es responder a estas cinco preguntas, no instalar nada.) Un sí en la etapa uno: divide la carga de trabajo por esa línea, conserva la parte que pasó y usa la alternativa de la tabla para el resto. + +## Lo que esta lista no dice + +No dice que estos límites sean permanentes. La página se titula «not a fit *today*» (no encaja *hoy*), la federación se llama «early» (temprana), y la tabla de arriba lleva fecha; léela contra la página actual antes de decidir. + +No dice que las alternativas sean mejores en general. Una capa semántica es la herramienta correcta para leer a través de cuarenta sistemas y la equivocada para operar un servicio de tickets, por las razones que la segunda sección da en la otra dirección. La alternativa de cada fila es correcta para esa fila. + +Y no dice que suspender una fila suspenda la carga de trabajo. La mayoría de los casos reales se dividen: el flujo de admisión encaja y el anfitrión es una cuestión de compras; el dominio de despacho encaja y el solver es código; las apps departamentales alrededor del ERP encajan y el libro mayor se queda donde está. La prueba de las seis clases se aplica a la parte difícil, no al nombre del proyecto. + +## Dónde se sitúa ObjectOS en esta lista + +Nada de lo anterior cambia con la edición. «¿Quieres el mismo ciclo alojado, en el navegador, sin instalar nada? Eso es ObjectOS, el entorno de ejecución comercial construido sobre ObjectStack.» ObjectOS se ofrece en tres ediciones: ObjectOS Community, open source y gratuita para autoalojar; ObjectOS Cloud, alojada en el navegador sin instalar nada; y ObjectOS Enterprise, autogestionada en tu propia infraestructura. En cualquier edición puedes exportar tu ontología y ejecutarla en otra. Las cinco cargas de trabajo tratan de lo que una ontología ejecutable puede expresar, no de dónde se ejecuta, así que la lista se lee igual en cualquier anfitrión. La única pregunta que trata del anfitrión, la certificación, la responde la página de seguridad para ObjectOS en los mismos términos que la página de código abierto: depende del despliegue en ejecución. + +## Si tu caso pasó la prueba + +Entonces el siguiente paso más rápido y honesto no es una demo; es una definición. Apunta tu agente de programación a ObjectStack, con el archivo de reglas, el paquete de skills y el servidor de herramientas que cubre [how to point your agent at ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/), y pídele el primer objeto: unos pocos campos, una relación, una acción, un conjunto de permisos y un disparador. Ejecuta `npm run validate` y lee el diff antes de leer la Console. Si puedes leer todo el diff y dice lo que hace tu negocio, la prueba de las seis clases ha pasado en la práctica, y [qué es la definición](/en/ontology/) es la siguiente página que entregar al agente. Si no puedes, nada en este artículo iba a ayudarte, y acabas de ahorrarte un proyecto. diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/index.fr.mdx b/content/blog/when-not-to-use-an-executable-business-ontology/index.fr.mdx new file mode 100644 index 0000000..4a9c089 --- /dev/null +++ b/content/blog/when-not-to-use-an-executable-business-ontology/index.fr.mdx @@ -0,0 +1,149 @@ +--- +title: "Quand ne pas utiliser une ontologie métier exécutable ?" +description: "Cinq charges de travail pour lesquelles une ontologie métier exécutable est aujourd’hui le mauvais outil, quoi utiliser à la place, le coût d’un mauvais choix, et une table de décision avec une source par ligne." +author: ObjectStack Team +date: 2026-10-28 +status: published +topic: app-building +audience: it +solutions: [] +industries: [] +cover: ./cover-en.svg +tags: + - Ontologie + - Ontologie métier exécutable + - Quand l’utiliser +--- + +**Réponse courte : pas pour cinq charges de travail, et la documentation d’ObjectStack les nomme elle-même.** Remplacer l’ERP ou le système financier central d’une grande entreprise. Un travail dont la valeur tient à l’intégration de nombreux systèmes existants. L’analytique sur des data lakes. Les domaines à forte composante algorithmique comme le pricing ou l’ordonnancement, sauf si l’algorithme est encapsulé dans une action. Et tout ce qui doit tourner sur une plateforme certifiée. Pour chacun il existe un meilleur outil, et cet article dit lequel, pourquoi c’est le bon choix, et ce que coûte un mauvais choix. À la fin : une table de décision avec une source sur chaque ligne, et une auto-évaluation en dix questions que vous pouvez appliquer à votre propre cas avant d’installer quoi que ce soit. + +Une liste honnête des cas où un produit est le mauvais outil est la chose la plus utile qu’un éditeur puisse publier, parce que c’est la seule qu’un acheteur ne trouve pas dans la présentation commerciale. Le positionnement en une ligne d’ObjectStack est : « Une ontologie métier exécutable. L’AI l’écrit, le runtime l’exécute, les agents l’opèrent, vous la possédez. » Tout ce qui suit porte sur les bords de cette phrase, tirés de la [page when-to-use](https://objectstack.ai/docs/concepts/when-to-use) et de la [page de comparaison](https://objectstack.ai/docs/concepts/compare) du projet au tag `@objectstack/cli@18.2.0`, lues le 2026-10-28, et du fichier source lorsque la limite est une ligne de code. La [page de comparaison](/en/compare/) de ce site liste déjà les cinq charges de travail et les cinq questions en une ligne chacune ; cet article est la version longue : un scénario pour chacune, l’alternative et ses raisons, le coût, et le fait décisif. + +## Le test des six sortes + +Un seul test couvre les cinq cas, il vaut donc la peine de l’énoncer d’abord. La page de concepts définit le cœur d’une ontologie métier exécutable comme six sortes de choses : objets et champs, relations, actions, permissions, flux, et définitions d’agents et d’outils. Le runtime dérive de ces six la base de données, l’API, l’UI et les outils d’agent, et les fait respecter à chaque appel. Le code ne disparaît pas, mais il se déplace dans le runtime, sous forme de hooks, de corps d’actions, de CEL et de JSX contraint, à l’intérieur de l’enclos que définissent les six sortes. + +Demandez donc de toute charge de travail : **la partie difficile est-elle l’une des six sortes ?** Si la partie difficile, précieuse et risquée du travail consiste à décider ce qui existe, comment cela se relie, ce qui peut être fait, par qui, et ce qui se passe quand, l’ontologie est l’outil, et un agent peut l’écrire. Si la partie difficile est autre chose, un calcul réglementaire, une connexion à quarante systèmes, un balayage d’un pétaoctet, un solveur, le certificat d’un auditeur, alors cette partie n’est pas exprimable comme définition, et l’ontologie au mieux l’enveloppe et au pire l’imite. Appelons cela le **test des six sortes**. Chacune des cinq charges de travail ci-dessous l’échoue pour une raison différente, et c’est pourquoi elles ont besoin de cinq alternatives différentes plutôt que d’une seule. + +## 1. L’ERP ou le système financier central d’une grande entreprise + +**Le scénario.** Un industriel de quatre mille personnes fait tourner depuis douze ans son grand livre, sa consolidation et sa paie sur un ERP progiciel. Un agent de codage, à qui l’on montre le plan comptable, propose de le redéclarer en objets, avec les règles d’écriture comme flux et la fiscalité comme formules. La démo est convaincante : journaux, balance, une approbation sur chaque écriture. + +**Quoi utiliser à la place, et pourquoi c’est juste.** Le progiciel, et construire autour. La page when-to-use : "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." (Un grand livre, la consolidation, la fiscalité et la paie portent une réglementation et des cas limites que les progiciels encodent déjà. Construisez autour de ce cœur, pas à sa place.) Sur ce marché, la réglementation est le produit. Un moteur de paie est une bibliothèque de juridictions, de calendriers déclaratifs et de corrections rétroactives, maintenue par des gens dont le seul métier est de la tenir à jour ; un moteur de consolidation, ce sont des années d’éliminations intragroupe et de cas limites de conversion de devises. Rien de cela n’est « ce qui existe et qui peut faire quoi ». C’est du calcul, et il change quand un gouvernement le change, pas quand votre entreprise change. + +**Le coût d’un mauvais choix.** Un second grand livre. Chaque règle que vous avez réencodée est désormais votre diff à maintenir, votre audit à passer et votre défaut quand l’exercice fiscal bascule, tandis que le progiciel que vous avez gardé pour les déclarations légales s’écarte un peu plus de votre copie chaque trimestre. L’agent qui a écrit les règles en une journée ne peut pas lire un code des impôts pour vous. + +**Le fait décisif.** La table des capacités du README liste douze choses que le runtime fournit : objets et champs, permissions, automatisation, approbations, vues, tableaux de bord et rapports, actions, API et SDK, outils AI, traductions, données d’amorçage, sources de données. Un grand livre, un moteur fiscal et un traitement de paie n’y figurent pas, et le projet ne dit pas qu’ils arrivent. + +Ce qui convient, selon la même page, c’est la longue traîne autour de ce cœur : "vendor onboarding, inspections, internal requests" (intégration de fournisseurs, inspections, demandes internes), les tableurs et formulaires qui suivent ce que l’ERP ne couvre pas. Chacun devient une définition typée au lieu d’un fichier qui circule par e-mail, et chacun peut lire les données de l’ERP sans les posséder, ce qui est le cas suivant. + +## 2. Les charges de travail dont la valeur tient à l’intégration de nombreux systèmes existants + +**Le scénario.** Une banque veut que ses agents répondent à la question d’un client depuis le core banking, le CRM, la plateforme cartes et le système de tickets à la fois, et écrivent un statut en retour dans deux d’entre eux. Aucun de ces systèmes ne bouge. Le travail consiste à les rendre lisibles pour un agent et à agir à travers eux. + +**Quoi utiliser à la place, et pourquoi.** Une couche au-dessus des systèmes : une couche sémantique ou de contexte pour la lecture, une ontologie opérationnelle à la manière de Palantir lorsqu’il y a une écriture en retour à gouverner. La page de comparaison le concède sans détour : "When the data already lives in a warehouse, a lakehouse and a dozen operational systems, these start where you are." (Quand les données vivent déjà dans un entrepôt, un lakehouse et une douzaine de systèmes opérationnels, celles-ci partent de là où vous êtes.) Ces produits sont construits sur l’hypothèse que le système de référence reste en place ; leur modèle d’objets est une vue, leurs écritures sont du writeback, et leur valeur croît avec le nombre de systèmes en dessous. ObjectStack est construit sur l’hypothèse inverse : l’ontologie *est* le système et la base de données en est dérivée. + +**Le coût d’un mauvais choix.** C’est le cas le plus souvent mal jugé, parce que la première semaine se passe bien. ObjectStack peut fédérer une base de données externe comme source de données avec `schemaMode: 'external'`, et un modèle de lecture sur une table héritée est l’affaire d’un court après-midi. Puis viennent les écritures. Les écritures fédérées sont désactivées par défaut deux fois : la source de données doit déclarer `external.allowWrites: true` et l’objet doit déclarer `external.writable: true`, et "with either gate off, insert/update/delete on the federated object is rejected." (si l’une ou l’autre porte est fermée, insert/update/delete sur l’objet fédéré est rejeté.) La porte n’est pas consultative : `assertWriteAllowed` s’exécute en tête de `insert` et `update` du moteur, avant les valeurs par défaut, les hooks et la validation. Ouvrez les deux portes objet par objet et vous possédez désormais une sémantique d’écriture contre un schéma que vous ne contrôlez pas, et `schemaMode: 'external'` fait échouer le démarrage en cas de divergence de schéma, de sorte qu’un renommage de colonne en amont met votre application hors service. Ou bien vous construisez des tâches de synchronisation à la place, et vous avez alors construit la couche d’intégration que vous essayiez de ne pas acheter, à l’intérieur d’un outil dont la propre documentation qualifie sa fédération d’"early" (précoce). + +**Le fait décisif.** Deux opt-ins, tous deux désactivés par défaut : `allowWrites` sur la source de données et `writable` sur l’objet (`content/docs/data-modeling/external-datasources.mdx`, la section sur les écritures), appliqués par `assertWriteAllowed` dans `packages/objectql/src/engine.ts`. + +Le chemin honnête existe, et il est étroit : connecter en lecture seule, mesurer, activer les écritures un objet à la fois, basculer objet par objet. [How to move an internal system to metadata](/en/blog/how-to-move-an-internal-system-to-metadata/) le parcourt, y compris les cas où la bonne réponse est de ne pas migrer du tout. Ce chemin est pour un système que vous comptez *remplacer*. Si vous comptez garder quarante systèmes et lire à travers eux, c’est la mauvaise route. + +## 3. L’analytique sur des data lakes + +**Le scénario.** Un distributeur a trois ans d’événements de clickstream et de points de vente dans un stockage objet, en tables Parquet et Iceberg, et l’équipe merchandising veut des tableaux de bord. Quelqu’un remarque que la plateforme a des tableaux de bord, des rapports et une couche de datasets que sa documentation qualifie de sémantique, et propose de la pointer vers le lake. + +**Quoi utiliser à la place, et pourquoi.** La pile entrepôt : un moteur de requête conçu pour les balayages en colonnes, une couche de métriques ou sémantique par-dessus, et un outil de BI au sommet. La couche analytique d’ObjectStack est une couche de métriques pour les lignes propres de l’application. Sa documentation définit un dataset comme "a base object, the relationships to include, and the declared dimensions and measures" (un objet de base, les relations à inclure, et les dimensions et mesures déclarées), avec des jointures dérivées du graphe d’objets ; le schéma le rend littéral en décrivant l’`object` d’un dataset comme "Base object name" (nom de l’objet de base). La page when-to-use le dit en une phrase : la couche analytique "defines metrics over the app's own objects for its reports and dashboards. It is not built to query a lake." (définit des métriques sur les propres objets de l’application pour ses rapports et tableaux de bord. Elle n’est pas conçue pour interroger un lake.) Une couche sémantique d’entrepôt fait le même travail sur un lake, et la page de comparaison de ce site dit qu’une entreprise qui fait de la BI sérieuse en voudra toujours une. + +**Le coût d’un mauvais choix.** L’une de deux copies. Soit vous chargez le lake dans des objets applicatifs, et vous avez maintenant une seconde copie de trois ans d’événements avec sa propre fraîcheur et sa propre facture, dans un magasin en lignes dérivé d’une définition métier plutôt que conçu pour les balayages ; soit vous fédérez une table d’entrepôt et découvrez que vous envoyez des questions analytiques à travers un moteur conçu pour répondre à des requêtes au niveau de la ligne pour une application, avec un pushdown des filtres et rien qui connaisse un fichier en colonnes. Les tableaux de bord s’afficheront. Ce ne seront pas ceux que l’équipe merchandising a demandés. + +**Le fait décisif.** Les sources de données que liste le README sont PostgreSQL, MySQL, SQLite, MongoDB et en mémoire ; le répertoire des paquets, que le README confie désormais à `CONTRIBUTING.md`, ajoute Turso et SQLite en WebAssembly. Il n’y a ni format de lake, ni moteur en colonnes, ni pilote de stockage objet, et la couche de datasets se lie à un objet, pas à une table dans un lake. + +## 4. Les domaines à forte composante algorithmique, comme le pricing ou l’ordonnancement + +**Le scénario.** Le produit d’une entreprise de logistique est un optimiseur de tournées : un solveur qui prend les commandes d’une journée et une flotte et produit un plan, avec un tableau de dispatch où les planificateurs glissent des arrêts d’un véhicule à l’autre et regardent le plan se recalculer. Les commandes, véhicules, chauffeurs et plans sont manifestement des objets ; l’entreprise demande si l’ensemble pourrait être une ontologie exécutable. + +**Quoi utiliser à la place, et pourquoi.** Du code, pour le solveur et pour le tableau, et ici la propre documentation de l’ontologie est le meilleur argument en faveur de l’alternative. La page when-to-use : l’ontologie "declares what can be done; it does not express an optimiser." (déclare ce qui peut être fait ; elle n’exprime pas un optimiseur.) Le `type` d’une action est l’un de `script`, `url`, `modal`, `flow`, `api` ou `form`, et le handler d’une action `script` est du code qui s’exécute avec toute l’autorité de l’application sur les données. La définition possède la porte, la permission sur la porte et l’audit de qui l’a franchie. L’algorithme derrière la porte est le vôtre, dans le langage qui le résout. L’interface est la même histoire dans l’autre sens : la page de comparaison dit que la Console est "server-driven from metadata, and an interface unlike any business app is easier to build directly." (pilotée par le serveur à partir des métadonnées, et une interface qui ne ressemble à aucune application métier est plus facile à construire directement.) + +**Le coût d’un mauvais choix.** Construire la partie qui compte à l’endroit qui a le moins de liberté. Un solveur peut vivre derrière une action, et pour un calcul d’ordonnancement déclenché depuis un enregistrement, c’est exactement ce qu’il faut. Un tableau de dispatch ne le peut pas : le JSX contraint dans les pages "is parsed into a server-driven UI tree, never executed as code" (est analysé en un arbre d’UI piloté par le serveur, jamais exécuté comme du code), par conception, de sorte que chaque interaction dont les planificateurs ont besoin devient une négociation avec un moteur de rendu conçu pour des listes, des formulaires et des tableaux. Six mois plus tard, l’ontologie est une fine enveloppe autour de ce que vous vendez réellement. + +**Le fait décisif.** `ActionType` dans `packages/spec/src/ui/action.zod.ts` est l’ensemble fermé `script | url | modal | flow | api | form`. L’algorithme n’en fait jamais partie, seulement le chemin vers lui. + +Le découpage qui fonctionne : la moitié métier, commandes, véhicules, chauffeurs, qui peut approuver un plan, ce qui se passe quand un plan est publié, en ontologie, où un agent peut l’écrire et l’opérer ; le solveur en code derrière une action `script`, de sorte que permissions, audit et accès des agents s’y appliquent comme à toute autre action ; le tableau des planificateurs comme application à part entière. Si le tableau *est* le produit, commencez par là. + +## 5. Les charges de travail qui exigent une plateforme certifiée + +**Le scénario.** Un groupe hospitalier veut un parcours d’admission, et ses achats exigent que la plateforme sur laquelle il tourne détienne une attestation nommée. Un appel d’offres public pose la même question à propos d’un certificat ISO. La charge de travail elle-même, formulaires, routage, approbations et piste d’audit, convient comme dans un manuel. + +**Quoi utiliser à la place, et pourquoi.** Soit une plateforme qui détient le certificat, soit un déploiement que vous certifiez vous-même, et la décision relève du calendrier de l’acheteur, pas de la feuille de route de l’éditeur. La page when-to-use : "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." (ObjectStack est un logiciel open source que vous déployez et exploitez, et il ne porte aucune certification de conformité propre. Lorsqu’une charge de travail doit tourner sur une plateforme certifiée, certifier votre déploiement est un travail qui vous appartient.) Ce n’est pas une esquive ; c’est ainsi que fonctionne la certification. Une attestation couvre un environnement en exploitation, ses contrôles et ses opérateurs, et un dépôt Apache-2.0 n’est rien de tout cela. La [page sécurité](/fr/security/) de ce site dit la même chose de l’édition commerciale : "Certification depends on your running deployment, not a binary alone." (La certification dépend de votre déploiement en exploitation, pas d’un binaire seul.) + +**Le coût d’un mauvais choix.** Le découvrir au moment des achats plutôt qu’à la conception, quand le calendrier supposait déjà que la plateforme apportait son certificat. L’audit tombe alors sur votre plan, sans budget, juste avant la mise en production. + +**Le fait décisif.** Le glossaire du projet liste même son propre kit de conformité au protocole comme "planned" (planifié), avec "no TCK program or certification mechanism in the codebase today" (aucun programme TCK ni mécanisme de certification dans le code aujourd’hui). Il n’y a rien à montrer à un auditeur sinon votre déploiement. + +La charge de travail convient toujours ; l’hôte est la question. La séquence honnête est de chiffrer d’abord le travail de certification, puis de décider. + +## Deux autres endroits où une autre catégorie part devant + +La page de comparaison ajoute deux concessions qui ne figurent pas dans la liste de ce qui ne convient pas, parce qu’elles portent sur un type de problème plutôt que sur un type de charge de travail. Les deux passent par le test des six sortes de la même manière. + +**Raisonner sur des données hétérogènes.** Si la question est « qu’est-ce qui découle de tout ce que nous savons », avec des hiérarchies de classes, des faits dérivés et des vérifications de cohérence entre vocabulaires, c’est le travail d’une ontologie de connaissances, et ObjectStack n’a "no object inheritance, no axioms and no reasoner" (pas d’héritage d’objets, pas d’axiomes et pas de raisonneur). La clé `abstract` a été retirée de la spécification plutôt que laissée comme une promesse. La définition est validée, puis exécutée ; rien n’est inféré à l’exécution. [L’article de définition](/fr/blog/what-does-the-ontology-is-the-software-mean/) traite pleinement cette négation. + +**Maturité de l’écosystème.** Salesforce, Odoo et ERPNext "bring years of production use, packaged applications, app marketplaces and implementation partners. ObjectStack is younger; expect to build more of it yourself." (apportent des années d’usage en production, des applications packagées, des places de marché et des partenaires d’intégration. ObjectStack est plus jeune ; attendez-vous à en construire davantage vous-même.) Si vous avez besoin d’une application packagée ce trimestre et d’un partenaire d’intégration dans votre ville, une plateforme plus jeune est le mauvais pari, quelle que soit la manière dont ses définitions sont écrites. + +## La table de décision + +Chaque ligne : la charge de travail, si elle convient aujourd’hui et quoi utiliser à la place, et le seul fait qui tranche, avec sa source. « Aujourd’hui » est une date : les sources sont objectstack au tag `@objectstack/cli@18.2.0`, la version que `npm view @objectstack/cli dist-tags` a signalée comme `latest` le 2026-10-28, lue ce jour-là. Les sources sont nommées par fichier : when-to-use, compare et ontology sont `content/docs/concepts/*.mdx` ; external-datasources et analytics sont sous `content/docs/data-modeling/` ; glossary est sous `content/docs/getting-started/` ; `engine.ts` est `packages/objectql/src/engine.ts` ; `dataset.zod.ts` et `action.zod.ts` sont sous `packages/spec/src/ui/` ; README et `CONTRIBUTING.md` sont à la racine du dépôt. + +| Charge de travail | Convient aujourd’hui ? Quoi utiliser à la place | Le fait décisif (source) | +| :--- | :--- | :--- | +| ERP ou finance centrale d’une grande entreprise | **Non.** Le progiciel ; construire autour | La réglementation et les cas limites sont le produit ; les douze capacités du runtime n’incluent aucun moteur de grand livre, fiscal ou de paie (when-to-use ; table des capacités du README) | +| Intégrer de nombreux systèmes existants | **Non.** Une couche sémantique ou de contexte ; une ontologie opérationnelle là où il y a du writeback | La fédération est en lecture seule par défaut, deux fois : `allowWrites` sur la source de données et `writable` sur l’objet (external-datasources ; `assertWriteAllowed` dans `engine.ts`) | +| Analytique sur un data lake | **Non.** Un moteur de requête d’entrepôt, une couche de métriques, de la BI | Un dataset se lie à un objet de base ; les pilotes sont des magasins en lignes, sans format de lake (analytics ; `dataset.zod.ts` ; sources de données du README ; pilotes de `CONTRIBUTING.md`) | +| Domaine à forte composante algorithmique | **Pas pour l’algorithme.** Du code ; derrière une action `script` quand le reste est une application métier | `ActionType` est script, url, modal, flow, api, form ; le solveur n’est jamais un type (`action.zod.ts` ; when-to-use) | +| Doit tourner sur une plateforme certifiée | **Pas sans un travail qui vous appartient.** Une plateforme certifiée, ou certifier votre déploiement | Aucune certification de conformité propre ; même le kit de conformité est « planifié » (when-to-use ; glossary) | +| Raisonner sur des données hétérogènes | **Non.** Une ontologie de connaissances avec un raisonneur | Pas d’héritage, pas d’axiomes, pas de raisonneur ; `abstract` retiré sous ADR-0049 (ontology ; compare) | +| A besoin d’un écosystème mûr maintenant | **Pas encore.** Une plateforme de métadonnées avec applications packagées et partenaires | « ObjectStack est plus jeune ; attendez-vous à en construire davantage vous-même » (compare) | +| Une nouvelle application métier : CRM, tickets, approbations, opérations, outils internes | **Oui.** | Objets, relations, actions, permissions et flux sont l’essentiel de ce que sont ces applications (when-to-use) | +| La longue traîne autour d’un ERP central | **Oui.** | Petite, spécifique, change souvent ; une définition typée par application, qui lit l’ERP sans le posséder (when-to-use) | +| Un back-office opéré par des agents dès le premier jour | **Oui.** | Chaque déploiement est un serveur MCP, activé par défaut, sous les permissions de l’utilisateur (when-to-use ; README) | + +![L’auto-évaluation en deux étapes. Étape un, cinq exclusions, tout oui signifie que l’ontologie n’est pas l’outil pour cette partie : un calcul de grand livre, de consolidation, fiscal ou de paie ; une valeur surtout dans des systèmes que vous gardez et ne possédez pas ; des données au repos dans un lake ou un entrepôt ; un solveur, un optimiseur ou une interface qui ne ressemble à aucune application métier ; une plateforme qui doit détenir une certification nommée. Étape deux, les cinq questions avant de commencer : ce que nous avons, comment cela se relie, ce qui peut être fait, qui peut le faire, ce qui se passe quand. Trois verdicts : cinq non et cinq réponses, cela convient et c’est une journée de travail pour un agent ; tout oui découpe la charge de travail selon cette ligne ; des non sans réponses signifie qu’aucun outil n’aide encore.](./self-check-en.svg) + +## Faites l’auto-évaluation + +Dix questions, deux étapes, dix minutes. L’étape un est la liste d’exclusion ; l’étape deux reprend les "Five questions before you start" (Cinq questions avant de commencer) de la page when-to-use, citées telles qu’elle les imprime. + +**Étape un. Tout oui signifie que l’ontologie n’est pas l’outil pour cette partie.** + +1. La partie difficile de cette charge de travail est-elle un calcul réglementé qu’un progiciel encode déjà : grand livre, consolidation, fiscalité, paie ? +2. L’essentiel de la valeur vient-il de la lecture et de l’écriture de systèmes que vous garderez et ne possédez pas ? +3. Les données que vous voulez analyser sont-elles au repos dans un lake ou un entrepôt plutôt que dans les propres enregistrements de l’application ? +4. Le cœur du produit est-il un solveur, un optimiseur ou une simulation, ou une interface qui ne ressemble à aucune application métier ? +5. La charge de travail doit-elle tourner sur une plateforme qui détient une certification nommée, sans budget pour certifier un déploiement à vous ? + +**Étape deux. Votre équipe peut-elle y répondre pour l’entreprise, aujourd’hui ?** + +6. "What we have — the objects and their fields." (Ce que nous avons : les objets et leurs champs.) +7. "How it relates — the lookups and master-detail links between them." (Comment cela se relie : les lookups et les liens maître-détail entre eux.) +8. "What can be done — the actions a user or an agent may take on a record." (Ce qui peut être fait : les actions qu’un utilisateur ou un agent peut exécuter sur un enregistrement.) +9. "Who may do it — permission sets, row-level and field-level security, sharing." (Qui peut le faire : jeux de permissions, sécurité au niveau des lignes et des champs, partage.) +10. "What happens when — record triggers, scheduled jobs, approvals, workflows." (Ce qui se passe quand : déclencheurs d’enregistrement, tâches planifiées, approbations, workflows.) + +Cinq non et cinq réponses : l’ontologie est, selon les mots de la page, "a day's work, because an agent does the writing." (une journée de travail, parce qu’un agent fait l’écriture.) Cinq non et aucune réponse : "no tool helps yet, this one included. The first investment is answering these five questions, not installing anything." (aucun outil n’aide encore, celui-ci compris. Le premier investissement est de répondre à ces cinq questions, pas d’installer quoi que ce soit.) Un oui à l’étape un : découpez la charge de travail selon cette ligne, gardez la partie qui a passé, et utilisez l’alternative de la table pour le reste. + +## Ce que cette liste ne dit pas + +Elle ne dit pas que ces limites sont permanentes. La page s’intitule « not a fit *today* » (ne convient pas *aujourd’hui*), la fédération est qualifiée d’« early » (précoce), et la table ci-dessus porte une date ; relisez-la face à la page actuelle avant de décider. + +Elle ne dit pas que les alternatives sont meilleures en général. Une couche sémantique est le bon outil pour lire à travers quarante systèmes et le mauvais pour faire tourner un centre de tickets, pour les raisons que la deuxième section donne dans l’autre sens. L’alternative de chaque ligne est juste pour cette ligne. + +Et elle ne dit pas qu’échouer une ligne fait échouer la charge de travail. La plupart des cas réels se découpent : le parcours d’admission convient et l’hôte est une question d’achats ; le domaine du dispatch convient et le solveur est du code ; les applications départementales autour de l’ERP conviennent et le grand livre reste où il est. Le test des six sortes s’applique à la partie difficile, pas au nom du projet. + +## Où se situe ObjectOS dans cette liste + +Rien de ce qui précède ne change avec l’édition. « Vous voulez la même boucle, hébergée, dans le navigateur, sans rien installer ? C’est ObjectOS, l’environnement d’exécution commercial construit sur ObjectStack. » ObjectOS existe en trois éditions : ObjectOS Community, open source et gratuite à auto-héberger ; ObjectOS Cloud, hébergée dans le navigateur, sans rien installer ; et ObjectOS Enterprise, autogérée sur votre propre infrastructure. Quelle que soit l’édition, vous pouvez exporter votre ontologie et l’exécuter sur une autre. Les cinq charges de travail portent sur ce qu’une ontologie exécutable peut exprimer, pas sur l’endroit où elle tourne, donc la liste se lit de la même façon sur tout hôte. La seule question qui porte sur l’hôte, la certification, la page sécurité y répond pour ObjectOS dans les mêmes termes que la page open source : cela dépend du déploiement en exploitation. + +## Si votre cas a passé le test + +Alors la prochaine étape la plus rapide et la plus honnête n’est pas une démo ; c’est une définition. Pointez votre agent de codage vers ObjectStack, avec le fichier de règles, le bundle de skills et le serveur d’outils couverts dans [how to point your agent at ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/), et demandez-lui le premier objet : quelques champs, une relation, une action, un jeu de permissions et un déclencheur. Lancez `npm run validate`, et lisez le diff avant de lire la Console. Si vous pouvez lire tout le diff et qu’il dit ce que fait votre entreprise, le test des six sortes a passé en pratique, et [ce qu’est la définition](/en/ontology/) est la page suivante à donner à l’agent. Si vous ne le pouvez pas, rien dans cet article n’allait vous aider, et vous venez d’économiser un projet. diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/index.ja.mdx b/content/blog/when-not-to-use-an-executable-business-ontology/index.ja.mdx new file mode 100644 index 0000000..df49cae --- /dev/null +++ b/content/blog/when-not-to-use-an-executable-business-ontology/index.ja.mdx @@ -0,0 +1,149 @@ +--- +title: "実行可能なビジネスオントロジーを使うべきでないのはどんなときか？" +description: "実行可能なビジネスオントロジーが今日は不向きな 5 つのワークロード、代わりに使うべきもの、選び間違えたときの代償、そして各行に出典を付けた判断表。" +author: ObjectStack Team +date: 2026-10-28 +status: published +topic: app-building +audience: it +solutions: [] +industries: [] +cover: ./cover-en.svg +tags: + - オントロジー + - 実行可能なビジネスオントロジー + - 使いどころ +--- + +**結論から言うと、5 つのワークロードには向かない。しかもそれは ObjectStack のドキュメント自身が名指ししている。** 大企業の基幹 ERP や財務システムの置き換え。多数の既存システムを統合することに価値があるもの。データレイク上の分析。アルゴリズムをアクションとして包まないかぎりの、プライシングやスケジューリングのようなアルゴリズム中心の領域。そして認証済みプラットフォーム上で動かさなければならないすべて。それぞれにより適した道具があり、本稿はそれがどれか、なぜそれが正しい選択か、選び間違えると何を払うことになるかを述べる。最後に、各行に出典を付けた判断表と、何かをインストールする前に自分のケースで試せる 10 問のセルフチェックを置く。 + +ある製品がどこで不向きかを正直に書いた一覧は、ベンダーが公開できるもののうちでいちばん役に立つ。買い手が営業資料から決して得られない唯一のものだからだ。ObjectStack の一行ポジショニングは「実行可能なビジネスオントロジーをひとつ。AI が書き、ランタイムが動かし、エージェントが操作し、あなたが所有する。」である。以下はすべてこの一文の縁についてであり、材料はプロジェクト自身の [when-to-use ページ](https://objectstack.ai/docs/concepts/when-to-use)と[比較ページ](https://objectstack.ai/docs/concepts/compare)（タグ `@objectstack/cli@18.2.0`、2026-10-28 読取）、そして境界がちょうど一行のコードであるソースファイルから取った。本サイトの[比較ページ](/en/compare/)はすでに 5 つのワークロードと 5 つの質問を一行ずつ挙げている。本稿はその長い版だ。それぞれにシナリオ、代替案とその根拠、代償、決め手となる事実を与える。 + +## 六種テスト + +ひとつのテストで 5 つのケース全部を覆えるので、先に述べておく。コンセプトのページは、実行可能なビジネスオントロジーの核を六種のものとして定義する。オブジェクトとフィールド、リレーション、アクション、権限、フロー、そしてエージェントとツールの定義だ。ランタイムはこの六種からデータベース、API、UI、エージェントのツールを導出し、呼び出しのたびにそれらを強制する。コードは消えない。だがランタイムの中へ、フック、アクション本体、CEL、制約付き JSX として移り、六種が引いた柵の内側で動く。 + +だからどのワークロードにもこう問えばよい。**難しい部分は六種のどれかか？** 仕事のうち難しく、価値があり、リスクのある部分が、何が存在し、どう関係し、何ができ、誰ができ、いつ何が起きるかを決めることであるなら、オントロジーが道具であり、エージェントがそれを書ける。難しい部分がそれ以外のもの、法定の計算、40 のシステムへの接続、ペタバイトの走査、ソルバー、監査人の証明書であるなら、その部分は定義として表現できず、オントロジーはせいぜいそれを包み、最悪の場合それを真似る。これを**六種テスト**と呼ぶ。以下の 5 つのワークロードはそれぞれ別の理由でこのテストに落ちる。だから必要なのはひとつではなく 5 つの異なる代替案なのだ。 + +## 1. 大企業の基幹 ERP や財務システム + +**シナリオ。** 従業員 4,000 人の製造業者が、総勘定元帳、連結、給与計算をパッケージ ERP で 12 年間運用している。勘定科目表を見せられたコーディングエージェントが、それをオブジェクトとして再宣言し、転記ルールをフローに、税を数式にすることを申し出る。デモは説得力がある。仕訳帳、試算表、すべての伝票への承認。 + +**代わりに何を使い、なぜそれが正しいか。** パッケージシステムを使い、その周りに築く。when-to-use ページはこう言う。"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."（総勘定元帳、連結、税、給与は、パッケージシステムがすでに符号化している規制と例外を抱えている。その核の代わりにではなく、その周りに築け。）この市場では規制こそが製品だ。給与エンジンとは、管轄区域、申告カレンダー、遡及訂正のライブラリであり、それを最新に保つことだけを仕事にする人々が維持している。連結エンジンとは、長年にわたる内部取引消去と為替換算の例外の蓄積だ。どれも「何が存在し、誰が何をできるか」ではない。それは計算であり、あなたの事業が変わるときではなく、政府が変えるときに変わる。 + +**選び間違えたときの代償。** 第二の元帳。あなたが再符号化したルールの一つひとつが、いまや維持すべき diff、通すべき監査、課税年度が替わるたびの不具合になる。一方で法定報告のために残したパッケージシステムは、四半期ごとにあなたの写しから少しずつずれていく。一日でルールを書いたエージェントは、あなたの代わりに税法を読んではくれない。 + +**決め手となる事実。** README の機能表はランタイムが提供する 12 項目を挙げている。オブジェクトとフィールド、権限、自動化、承認、ビュー、ダッシュボードとレポート、アクション、API と SDK、AI ツール、翻訳、シードデータ、データソース。元帳、税エンジン、給与計算はそこにないし、プロジェクトはそれらが来るとも言っていない。 + +同じページが適していると言うのは、その核の周りのロングテールだ。"vendor onboarding, inspections, internal requests"（取引先オンボーディング、点検、社内申請）、つまり ERP が扱わないものを追跡するスプレッドシートやフォームである。その一つひとつが、メールで回されるファイルではなく型付きの定義になり、ERP のデータを所有せずに読める。それが次のケースだ。 + +## 2. 多数の既存システムを統合することに価値があるワークロード + +**シナリオ。** ある銀行は、エージェントが勘定系、CRM、カードプラットフォーム、チケットシステムから顧客の質問にまとめて答え、そのうち 2 つにステータスを書き戻せるようにしたい。どのシステムも動かない。仕事は、それらをエージェントに読めるようにし、横断して行動することだ。 + +**代わりに何を使い、なぜか。** システムの上に載る層。読みにはセマンティック層やコンテキスト層、統治すべき書き戻しがあるなら Palantir 型の運用オントロジー。比較ページはこれを率直に認めている。"When the data already lives in a warehouse, a lakehouse and a dozen operational systems, these start where you are."（データがすでにウェアハウス、レイクハウス、十数の業務システムに住んでいるなら、これらはあなたのいる場所から始める。）それらの製品は、記録システムが動かないという前提で作られている。オブジェクトモデルはビューであり、書き込みは書き戻しであり、価値は下にあるシステムの数とともに増える。ObjectStack は逆の前提、オントロジーこそ*が*システムでありデータベースはそこから導出される、という前提で作られている。 + +**選び間違えたときの代償。** これはいちばんよく間違えられるケースだ。最初の一週間はうまくいくからである。ObjectStack は `schemaMode: 'external'` で外部データベースをデータソースとしてフェデレートでき、レガシーテーブル上の読み取りモデルは午後ひとつで済む。それから書き込みになる。フェデレートした書き込みは既定で二重に閉じている。データソースが `external.allowWrites: true` を宣言し、オブジェクトが `external.writable: true` を宣言しなければならず、"with either gate off, insert/update/delete on the federated object is rejected."（どちらかのゲートが閉じていれば、フェデレートしたオブジェクトへの insert/update/delete は拒否される。）このゲートは助言ではない。`assertWriteAllowed` はエンジンの `insert` と `update` の先頭で、デフォルト値、フック、検証の前に走る。オブジェクトごとに両方のゲートを開けば、あなたは自分の制御下にないスキーマに対する書き込みの意味論を背負うことになり、`schemaMode: 'external'` はスキーマ不一致で起動を失敗させるので、上流で列名がひとつ変わればあなたのアプリは止まる。あるいは代わりに同期ジョブを作り、気づけば、買わずに済ませようとしていた統合層を、自分の文書でフェデレーションを "early"（初期段階）と呼ぶ道具の中に作り上げている。 + +**決め手となる事実。** 既定でどちらも無効な 2 つのオプトイン。データソースの `allowWrites` とオブジェクトの `writable`（`content/docs/data-modeling/external-datasources.mdx` の書き込みの節）であり、`packages/objectql/src/engine.ts` の `assertWriteAllowed` が強制する。 + +正直な道は存在するが、狭い。読み取り専用で接続し、測り、オブジェクトごとに書き込みを有効にし、オブジェクト単位で切り替える。[How to move an internal system to metadata](/en/blog/how-to-move-an-internal-system-to-metadata/) はその道を、まったく移行しないのが正解であるケースも含めて辿る。その道は*置き換える*つもりのシステムのためのものだ。40 のシステムを残して横断的に読むつもりなら、それは間違った道である。 + +## 3. データレイク上の分析 + +**シナリオ。** ある小売業者は 3 年分のクリックストリームと POS のイベントを Parquet と Iceberg のテーブルとしてオブジェクトストレージに持ち、マーチャンダイジングチームはダッシュボードを欲しがっている。誰かが、このプラットフォームにはダッシュボード、レポート、そして文書がセマンティックと呼ぶデータセット層があることに気づき、それをレイクに向けようと提案する。 + +**代わりに何を使い、なぜか。** ウェアハウスのスタック。列指向の走査のために作られたクエリエンジン、その上のメトリクス層またはセマンティック層、そのうえの BI ツール。ObjectStack の分析層は、アプリケーション自身の行のためのメトリクス層だ。その文書はデータセットを "a base object, the relationships to include, and the declared dimensions and measures"（ベースオブジェクト、含めるリレーション、宣言されたディメンションとメジャー）と定義し、結合はオブジェクトグラフから導出される。スキーマはそれを文字どおりにし、データセットの `object` を "Base object name"（ベースオブジェクト名）と記述する。when-to-use ページは一文で言う。分析層は "defines metrics over the app's own objects for its reports and dashboards. It is not built to query a lake."（アプリ自身のオブジェクト上にレポートとダッシュボードのためのメトリクスを定義する。レイクに問い合わせるためには作られていない。）ウェアハウスのセマンティック層はレイク上で同じ仕事をし、本サイトの比較ページも、本格的に BI をやる会社はやはりそれを欲しがるだろうと言っている。 + +**選び間違えたときの代償。** 2 つの写しのどちらか。レイクをアプリのオブジェクトに読み込めば、3 年分のイベントの第二の写しが、独自の鮮度と独自の請求書を伴って、走査用に設計されたのではなく業務定義から導出された行ストアに置かれる。あるいはウェアハウスのテーブルをフェデレートし、分析の質問を、アプリケーションのために行単位のクエリに答えるよう作られたエンジン、フィルタのプッシュダウンはあるが列指向ファイルを知るものは何もないエンジンに流していることに気づく。ダッシュボードは描画される。だがマーチャンダイジングチームが求めたダッシュボードにはならない。 + +**決め手となる事実。** README が挙げるデータソースは PostgreSQL、MySQL、SQLite、MongoDB、インメモリであり、README がいま `CONTRIBUTING.md` に委ねているパッケージ一覧が Turso と WebAssembly 上の SQLite を加える。レイクのフォーマットも、列指向エンジンも、オブジェクトストレージのドライバもなく、データセット層が束縛されるのはオブジェクトであって、レイクの中のテーブルではない。 + +## 4. プライシングやスケジューリングのようなアルゴリズム中心の領域 + +**シナリオ。** ある物流会社の製品は配送経路最適化だ。一日分の注文と車両群を受け取って計画を出すソルバーと、計画担当者が停車地を車両間でドラッグし、計画が再計算されるのを見るディスパッチボード。注文、車両、ドライバー、計画は明らかにオブジェクトである。会社は、全体を実行可能なオントロジーにできないかと尋ねる。 + +**代わりに何を使い、なぜか。** ソルバーにもボードにもコードを。そしてここでは、オントロジー自身の文書が代替案の最も強い論拠になる。when-to-use ページはこう言う。オントロジーは "declares what can be done; it does not express an optimiser."（何ができるかを宣言する。最適化器を表現するものではない。）アクションの `type` は `script`、`url`、`modal`、`flow`、`api`、`form` のいずれかであり、`script` アクションのハンドラは、アプリの全データ権限で動くコードだ。定義が所有するのは扉、扉の権限、誰がそこを通ったかの監査である。扉の向こうのアルゴリズムはあなたのもので、解ける言語なら何でもいい。インターフェースは同じ話の逆方向だ。比較ページは Console を "server-driven from metadata, and an interface unlike any business app is easier to build directly."（メタデータからサーバー駆動であり、どの業務アプリにも似ていないインターフェースは直接作るほうが容易だ）と言う。 + +**選び間違えたときの代償。** いちばん重要な部分を、いちばん自由の少ない場所に作ること。ソルバーはアクションの裏に住めるし、レコードから起動されるスケジューリング実行にはまさにそれが正しい。ディスパッチボードはそうはいかない。ページ内の制約付き JSX は意図的に "is parsed into a server-driven UI tree, never executed as code"（サーバー駆動の UI ツリーに解析され、コードとして実行されることはない）ので、計画担当者が必要とするすべての操作が、リスト、フォーム、ボードのために作られたレンダラーとの交渉になる。半年後、オントロジーは、あなたが実際に売っているものの周りの薄い皮になっている。 + +**決め手となる事実。** `packages/spec/src/ui/action.zod.ts` の `ActionType` は閉じた集合 `script | url | modal | flow | api | form` である。アルゴリズムは決してその一員ではなく、そこへ至る経路にすぎない。 + +うまくいく切り分けはこうだ。業務の半分、注文、車両、ドライバー、誰が計画を承認できるか、計画が公開されたら何が起きるか、をオントロジーにし、エージェントが書いて操作できるようにする。ソルバーは `script` アクションの裏のコードにし、権限、監査、エージェントのアクセスが他のアクションと同じように適用されるようにする。計画担当者のボードは独立したアプリケーションにする。ボード*が*製品なら、そこから始めればよい。 + +## 5. 認証済みプラットフォームを必要とするワークロード + +**シナリオ。** ある病院グループが入院受付のワークフローを欲しがっていて、その調達部門は、それが動くプラットフォームが特定の認証を保持していることを求める。公共入札が ISO 認証について同じ問いを立てる。ワークロード自体、フォーム、ルーティング、承認、監査証跡は、教科書どおりの適合だ。 + +**代わりに何を使い、なぜか。** 認証を持つプラットフォームか、自分で認証を取るデプロイメントか。そして決めるのは買い手のカレンダーであって、ベンダーのロードマップではない。when-to-use ページはこう言う。"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."（ObjectStack はあなたがデプロイし運用するオープンソースソフトウェアであり、それ自体のコンプライアンス認証を持たない。ワークロードが認証済みプラットフォーム上で動かなければならない場合、あなたのデプロイメントを認証することはあなたが負う仕事だ。）これは逃げではなく、認証とはそういうものだ。認証が覆うのは稼働中の環境、その統制、その運用者であり、Apache-2.0 のリポジトリはそのどれでもない。本サイトの[セキュリティページ](/ja/security/)は商用版についても同じことを言う。"Certification depends on your running deployment, not a binary alone."（認証は稼働中のデプロイメントに依存し、バイナリ単体では決まらない。） + +**選び間違えたときの代償。** 設計時ではなく調達時にこれに気づくこと。スケジュールはすでにプラットフォームが認証を持ってくる前提で組まれている。すると監査は予算なしで、本番稼働の直前にあなたの計画に落ちてくる。 + +**決め手となる事実。** プロジェクトの用語集は、自身のプロトコル適合キットさえ "planned"（計画中）とし、"no TCK program or certification mechanism in the codebase today"（今日のコードベースに TCK プログラムも認証の仕組みもない）と書いている。監査人に示せるものは、あなたのデプロイメント以外にない。 + +ワークロードは依然として適合する。問題はホストだ。正直な順序は、まず認証作業の費用を見積もり、それから決めることである。 + +## もう 2 か所、別のカテゴリが先行する場面 + +比較ページはさらに 2 つの譲歩を加えている。それらは不適合の一覧にはない。ワークロードの種類ではなく問題の種類についてだからだ。どちらも六種テストを同じように通る。 + +**異種データ上の推論。** 問いが「我々の知るすべてから何が導かれるか」であり、クラス階層、導出された事実、語彙を横断する整合性検査を伴うなら、それは知識オントロジーの仕事であり、ObjectStack には "no object inheritance, no axioms and no reasoner"（オブジェクト継承も、公理も、推論器もない）。`abstract` キーは約束として残されるのではなく仕様から削除された。定義は検証され、それから実行される。実行時に推論されるものは何もない。[定義の記事](/ja/blog/what-does-the-ontology-is-the-software-mean/)がこの否定を余すところなく扱っている。 + +**エコシステムの成熟度。** Salesforce、Odoo、ERPNext は "bring years of production use, packaged applications, app marketplaces and implementation partners. ObjectStack is younger; expect to build more of it yourself."（長年の本番利用、パッケージ化されたアプリケーション、アプリマーケットプレイス、導入パートナーをもたらす。ObjectStack はより若い。より多くを自分で作る覚悟をしてほしい。）今四半期にパッケージ化されたアプリが必要で、自分の街に導入パートナーが必要なら、定義がどう書かれていようと、より若いプラットフォームは間違った賭けだ。 + +## 判断表 + +各行は、ワークロード、今日適合するかと代わりに何を使うか、そしてそれを決めるひとつの事実と出典。「今日」は日付である。出典は objectstack のタグ `@objectstack/cli@18.2.0`、すなわち `npm view @objectstack/cli dist-tags` が 2026-10-28 に `latest` と報告したバージョンで、同日に読んだ。出典はファイル名で示す。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/` 配下、README と `CONTRIBUTING.md` はリポジトリのルートにある。 + +| ワークロード | 今日適合するか？代わりに何を使うか | 決め手となる事実（出典） | +| :--- | :--- | :--- | +| 大企業の基幹 ERP や財務 | **否。** パッケージシステム。その周りに築く | 規制と例外が製品そのもの。ランタイムの 12 の機能に元帳、税、給与のエンジンはない（when-to-use、README 機能表） | +| 多数の既存システムの統合 | **否。** セマンティック層またはコンテキスト層。書き戻しがあるなら運用オントロジー | フェデレーションは既定で二重に読み取り専用。データソースの `allowWrites` とオブジェクトの `writable`（external-datasources、`engine.ts` の `assertWriteAllowed`） | +| データレイク上の分析 | **否。** ウェアハウスのクエリエンジン、メトリクス層、BI | データセットはベースオブジェクトに束縛される。ドライバは行ストアで、レイクのフォーマットはない（analytics、`dataset.zod.ts`、README データソース、`CONTRIBUTING.md` ドライバ） | +| アルゴリズム中心の領域 | **アルゴリズムには不向き。** コード。残りが業務アプリなら `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） | +| 初日からエージェントが運用するバックオフィス | **是。** | すべてのデプロイメントが MCP サーバーで、既定で有効、ユーザーの権限のもとで動く（when-to-use、README） | + +![二段階のセルフチェック。第一段階は 5 つの除外で、どれかひとつでも「はい」なら、その部分にオントロジーは道具ではない。元帳、連結、税、給与の計算。価値の大半が、残すが所有しないシステムにある。データがレイクやウェアハウスに静置されている。ソルバー、最適化器、あるいはどの業務アプリにも似ていないインターフェース。特定の認証を保持しなければならないプラットフォーム。第二段階は開始前の 5 つの質問。何を持っているか、どう関係するか、何ができるか、誰ができるか、いつ何が起きるか。3 つの判定。5 つの「いいえ」と 5 つの答えなら適合で、エージェントなら一日の仕事。どれかひとつの「はい」はその線でワークロードを分割する。答えのない「いいえ」は、まだどの道具も役に立たないことを意味する。](./self-check-en.svg) + +## セルフチェックを実行する + +10 問、2 段階、10 分。第一段階は除外リスト、第二段階は when-to-use ページの "Five questions before you start"（始める前の 5 つの質問）を、そこに印字されているとおりに引用したものだ。 + +**第一段階。どれかひとつでも「はい」なら、その部分にオントロジーは道具ではない。** + +1. このワークロードの難しい部分は、パッケージシステムがすでに符号化している規制上の計算か。元帳、連結、税、給与か。 +2. 価値の大半は、残すが所有しないシステムの読み書きから来るか。 +3. 分析したいデータは、アプリケーション自身のレコードではなく、レイクやウェアハウスに静置されているか。 +4. 製品の核はソルバー、最適化器、シミュレーションか、あるいはどの業務アプリにも似ていないインターフェースか。 +5. ワークロードは特定の認証を保持するプラットフォーム上で動かなければならず、自分のデプロイメントを認証する予算はないか。 + +**第二段階。あなたのチームは、事業についてこれらに今日答えられるか。** + +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."（いつ何が起きるか。レコードトリガー、スケジュールジョブ、承認、ワークフロー。） + +5 つの「いいえ」と 5 つの答え。オントロジーは、そのページの言葉で "a day's work, because an agent does the writing."（一日の仕事だ。書くのはエージェントだから。）5 つの「いいえ」と答えなし。"no tool helps yet, this one included. The first investment is answering these five questions, not installing anything."（まだどの道具も役に立たない。これも含めて。最初の投資は、何かをインストールすることではなく、この 5 つの質問に答えることだ。）第一段階に「はい」がひとつ。その線でワークロードを分割し、通った部分を残し、残りには表の代替案を使う。 + +## この一覧が言っていないこと + +これらの限界が恒久的だとは言っていない。ページのタイトルは「not a fit *today*」（*今日は*不向き）であり、フェデレーションは「early」（初期段階）と呼ばれ、上の表には日付が付いている。決める前に現在のページと照らし合わせてほしい。 + +代替案が一般に優れているとも言っていない。セマンティック層は 40 のシステムを横断して読むには正しい道具であり、チケットデスクを運用するには間違った道具である。理由は第 2 節が逆方向から述べたとおりだ。各行の代替案は、その行に対して正しい。 + +そして、一行に落ちればワークロード全体が落ちるとも言っていない。現実のケースの多くは分割される。入院受付のワークフローは適合し、ホストは調達の問題だ。ディスパッチの領域は適合し、ソルバーはコードだ。ERP の周りの部門アプリは適合し、元帳はそのままの場所に残る。六種テストが適用されるのは難しい部分であって、プロジェクト名ではない。 + +## この一覧の中での ObjectOS の位置 + +上のどれもエディションによって変わらない。「同じループをホスト型で、ブラウザだけで、何もインストールせずに使いたい？それが ObjectOS — ObjectStack の上に構築された商用ランタイム環境です。」ObjectOS には 3 つのエディションがあります。オープンソースで無料でセルフホストできる ObjectOS Community、ブラウザ上でホストされインストール不要の ObjectOS Cloud、自社インフラでセルフマネージドの ObjectOS Enterprise です。どのエディションでも、オントロジーをエクスポートして別のエディションで実行できます。5 つのワークロードは実行可能なオントロジーが何を表現できるかについてであり、どこで動くかについてではない。だからこの一覧はどのホスト上でも同じように読める。ホストに関わる唯一の問い、認証については、セキュリティページが ObjectOS について、オープンソースのページと同じ言葉で答えている。稼働中のデプロイメントに依存する、と。 + +## あなたのケースが通ったなら + +最速で最も正直な次の一歩はデモではなく、定義だ。[how to point your agent at ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/) で扱うルールファイル、スキルバンドル、ツールサーバーを使ってコーディングエージェントを ObjectStack に向け、最初のオブジェクトを頼む。いくつかのフィールド、ひとつのリレーション、ひとつのアクション、ひとつの権限セット、ひとつのトリガー。`npm run validate` を実行し、Console を読む前に diff を読む。diff を全部読めて、それがあなたの事業のしていることを語っているなら、六種テストは実践で通ったのであり、次にエージェントへ渡すページは[定義とは何か](/en/ontology/)だ。読めないなら、本稿の何もあなたの役には立たなかったはずで、あなたはいまプロジェクトをひとつ節約したことになる。 diff --git a/content/blog/when-not-to-use-an-executable-business-ontology/index.ko.mdx b/content/blog/when-not-to-use-an-executable-business-ontology/index.ko.mdx new file mode 100644 index 0000000..af99a85 --- /dev/null +++ b/content/blog/when-not-to-use-an-executable-business-ontology/index.ko.mdx @@ -0,0 +1,149 @@ +--- +title: "실행 가능한 비즈니스 온톨로지를 쓰지 말아야 할 때는 언제인가?" +description: "실행 가능한 비즈니스 온톨로지가 오늘은 맞지 않는 다섯 가지 워크로드, 대신 쓸 것, 잘못 골랐을 때의 비용, 그리고 모든 행에 출처를 단 결정표." +author: ObjectStack Team +date: 2026-10-28 +status: published +topic: app-building +audience: it +solutions: [] +industries: [] +cover: ./cover-en.svg +tags: + - 온톨로지 + - 실행 가능한 비즈니스 온톨로지 + - 언제 쓸까 +--- + +**짧은 답: 다섯 가지 워크로드에는 쓰지 말라. 그리고 그 다섯은 ObjectStack 문서가 스스로 지목한다.** 대기업의 핵심 ERP나 재무 시스템을 대체하는 일. 많은 기존 시스템을 통합하는 데 가치가 있는 일. 데이터 레이크 위의 분석. 알고리즘을 액션으로 감싸지 않는 한, 가격 책정이나 스케줄링 같은 알고리즘 중심 도메인. 그리고 인증된 플랫폼 위에서 실행되어야 하는 모든 것. 각각에는 더 나은 도구가 있으며, 이 글은 그것이 무엇인지, 왜 그것이 옳은 선택인지, 잘못 고르면 무엇을 치르게 되는지를 말한다. 끝에는 모든 행에 출처를 단 결정표와, 무엇이든 설치하기 전에 자기 사례에 돌려 볼 수 있는 열 문항의 자가 점검이 있다. + +어떤 제품이 어디에서 맞지 않는 도구인지 정직하게 적은 목록은 벤더가 발표할 수 있는 가장 유용한 것이다. 구매자가 영업 자료에서는 결코 얻을 수 없는 유일한 것이기 때문이다. ObjectStack의 한 줄 포지셔닝은 “실행 가능한 비즈니스 온톨로지 하나. AI가 쓰고, 런타임이 실행하고, 에이전트가 운영하고, 당신이 소유합니다.”이다. 아래의 모든 내용은 그 문장의 가장자리에 관한 것으로, 프로젝트 자신의 [when-to-use 페이지](https://objectstack.ai/docs/concepts/when-to-use)와 [비교 페이지](https://objectstack.ai/docs/concepts/compare)(태그 `@objectstack/cli@18.2.0`, 2026-10-28 읽음), 그리고 한계가 곧 한 줄의 코드인 소스 파일에서 가져왔다. 이 사이트의 [비교 페이지](/en/compare/)는 이미 다섯 가지 워크로드와 다섯 가지 질문을 각각 한 줄로 나열한다. 이 글은 그 긴 판이다. 각각에 시나리오, 대안과 그 근거, 비용, 그리고 결정적 사실을 준다. + +## 여섯 종류 테스트 + +하나의 테스트가 다섯 사례를 모두 덮으므로 먼저 말해 둘 가치가 있다. 개념 페이지는 실행 가능한 비즈니스 온톨로지의 핵심을 여섯 종류의 것으로 정의한다. 오브젝트와 필드, 관계, 액션, 권한, 플로우, 그리고 에이전트와 도구 정의. 런타임은 이 여섯에서 데이터베이스, API, UI, 에이전트 도구를 도출하고, 모든 호출에서 그것들을 강제한다. 코드는 사라지지 않지만 런타임 안으로, 훅, 액션 본문, CEL, 제한된 JSX로 옮겨 가서, 여섯 종류가 정의한 울타리 안에서 돈다. + +그러니 어떤 워크로드에든 이렇게 물어라. **어려운 부분이 여섯 종류 중 하나인가?** 일에서 어렵고, 가치 있고, 위험한 부분이 무엇이 존재하는지, 어떻게 연결되는지, 무엇을 할 수 있는지, 누가 할 수 있는지, 언제 무엇이 일어나는지를 정하는 것이라면, 온톨로지가 도구이고 에이전트가 그것을 쓸 수 있다. 어려운 부분이 다른 것, 즉 법정 계산, 40개 시스템과의 연결, 페타바이트 스캔, 솔버, 감사인의 인증서라면, 그 부분은 정의로 표현할 수 없고, 온톨로지는 잘해야 그것을 감싸고 최악의 경우 흉내 낸다. 이것을 **여섯 종류 테스트**라고 부르자. 아래의 다섯 워크로드는 각각 다른 이유로 이 테스트에 실패하며, 그래서 하나가 아니라 다섯 개의 서로 다른 대안이 필요하다. + +## 1. 대기업의 핵심 ERP나 재무 시스템 + +**시나리오.** 직원 4천 명의 제조사가 총계정원장, 연결, 급여를 패키지 ERP에서 12년째 운영하고 있다. 계정과목표를 본 코딩 에이전트가 그것을 오브젝트로 다시 선언하겠다고 제안한다. 전기 규칙은 플로우로, 세금은 수식으로. 데모는 설득력 있다. 분개장, 시산표, 모든 분개에 승인. + +**대신 쓸 것, 그리고 왜 그것이 옳은가.** 패키지 시스템을 쓰고 그 주위에 지어라. when-to-use 페이지는 이렇게 말한다. "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."(총계정원장, 연결, 세금, 급여는 패키지 시스템이 이미 인코딩한 규제와 예외 사례를 안고 있다. 그 핵심을 대체하지 말고 그 주위에 지어라.) 그 시장에서는 규제가 곧 제품이다. 급여 엔진은 관할권, 신고 일정, 소급 정정의 라이브러리이며, 그것을 최신으로 유지하는 것만이 유일한 일인 사람들이 관리한다. 연결 엔진은 수년간 쌓인 내부거래 제거와 환산 예외 사례다. 그중 어느 것도 “무엇이 존재하고 누가 무엇을 할 수 있는가”가 아니다. 그것은 계산이며, 당신의 사업이 바뀔 때가 아니라 정부가 바꿀 때 바뀐다. + +**잘못 골랐을 때의 비용.** 두 번째 원장. 당신이 다시 인코딩한 모든 규칙이 이제 당신이 유지해야 할 diff, 통과해야 할 감사, 과세 연도가 바뀔 때의 결함이 된다. 한편 법정 보고를 위해 남겨 둔 패키지 시스템은 분기마다 당신의 사본과 조금씩 더 어긋난다. 하루 만에 규칙을 쓴 에이전트는 당신을 대신해 세법을 읽어 주지 않는다. + +**결정적 사실.** README의 기능 표는 런타임이 제공하는 열두 가지를 나열한다. 오브젝트와 필드, 권한, 자동화, 승인, 뷰, 대시보드와 보고서, 액션, API와 SDK, AI 도구, 번역, 시드 데이터, 데이터소스. 원장, 세금 엔진, 급여 처리는 거기에 없고, 프로젝트는 그것들이 온다고 말하지도 않는다. + +같은 페이지가 맞는다고 말하는 것은 그 핵심 주변의 롱테일이다. "vendor onboarding, inspections, internal requests"(공급업체 온보딩, 점검, 내부 요청), 즉 ERP가 다루지 않는 것을 추적하는 스프레드시트와 양식들. 각각은 이메일로 돌아다니는 파일 대신 타입이 있는 정의가 되고, 각각은 ERP의 데이터를 소유하지 않고도 읽을 수 있다. 그것이 다음 사례다. + +## 2. 많은 기존 시스템을 통합하는 데 가치가 있는 워크로드 + +**시나리오.** 한 은행은 에이전트가 코어 뱅킹, CRM, 카드 플랫폼, 티켓 시스템에서 고객의 질문에 한 번에 답하고, 그중 둘에 상태를 되써 주기를 원한다. 그 시스템들 중 어느 것도 움직이지 않는다. 일은 그것들을 에이전트가 읽을 수 있게 하고, 그것들을 가로질러 행동하는 것이다. + +**대신 쓸 것, 그리고 왜.** 시스템들 위의 계층. 읽기에는 시맨틱 계층이나 컨텍스트 계층, 다스려야 할 되쓰기가 있을 때는 Palantir류의 운영 온톨로지. 비교 페이지는 이를 솔직하게 인정한다. "When the data already lives in a warehouse, a lakehouse and a dozen operational systems, these start where you are."(데이터가 이미 웨어하우스, 레이크하우스, 십여 개의 운영 시스템에 살고 있다면, 이들은 당신이 있는 곳에서 시작한다.) 그 제품들은 기록 시스템이 그대로 있다는 가정 위에 지어졌다. 그들의 오브젝트 모델은 뷰이고, 쓰기는 되쓰기이며, 가치는 아래에 있는 시스템의 수와 함께 커진다. ObjectStack은 반대의 가정, 즉 온톨로지가 *곧* 시스템이고 데이터베이스는 거기서 도출된다는 가정 위에 지어졌다. + +**잘못 골랐을 때의 비용.** 가장 자주 틀리는 사례다. 첫 주가 잘 풀리기 때문이다. ObjectStack은 `schemaMode: 'external'`로 외부 데이터베이스를 데이터소스로 연합할 수 있고, 레거시 테이블 위의 읽기 모델은 짧은 오후면 된다. 그다음이 쓰기다. 연합된 쓰기는 기본적으로 두 겹으로 꺼져 있다. 데이터소스는 `external.allowWrites: true`를, 오브젝트는 `external.writable: true`를 선언해야 하며, "with either gate off, insert/update/delete on the federated object is rejected."(어느 한쪽 게이트라도 닫혀 있으면 연합된 오브젝트에 대한 insert/update/delete는 거부된다.) 이 게이트는 권고가 아니다. `assertWriteAllowed`는 엔진의 `insert`와 `update` 맨 위에서, 기본값, 훅, 검증보다 먼저 실행된다. 오브젝트마다 두 게이트를 모두 열면 당신은 이제 당신이 통제하지 않는 스키마에 대한 쓰기 의미론을 소유하게 되고, `schemaMode: 'external'`은 스키마 불일치 시 부팅을 실패시키므로 업스트림의 컬럼 이름 하나가 바뀌면 당신의 앱이 내려간다. 아니면 대신 동기화 작업을 만들고, 그때쯤이면 사지 않으려 했던 통합 계층을, 자기 문서에서 연합을 "early"(초기)라고 부르는 도구 안에 직접 지어 버린 셈이 된다. + +**결정적 사실.** 기본적으로 둘 다 꺼진 두 개의 옵트인. 데이터소스의 `allowWrites`와 오브젝트의 `writable`(`content/docs/data-modeling/external-datasources.mdx`, 쓰기에 관한 절)이며, `packages/objectql/src/engine.ts`의 `assertWriteAllowed`가 강제한다. + +정직한 길은 존재하고, 좁다. 읽기 전용으로 연결하고, 측정하고, 오브젝트 하나씩 쓰기를 켜고, 오브젝트 단위로 전환한다. [How to move an internal system to metadata](/en/blog/how-to-move-an-internal-system-to-metadata/)가 그 길을, 아예 옮기지 않는 것이 정답인 경우까지 포함해 걷는다. 그 길은 당신이 *대체*하려는 시스템을 위한 것이다. 40개 시스템을 그대로 두고 가로질러 읽으려 한다면, 그것은 잘못된 길이다. + +## 3. 데이터 레이크 위의 분석 + +**시나리오.** 한 소매업체가 3년치 클릭스트림과 POS 이벤트를 Parquet와 Iceberg 테이블로 오브젝트 스토리지에 갖고 있고, 머천다이징 팀은 대시보드를 원한다. 누군가 이 플랫폼에 대시보드, 보고서, 그리고 문서가 시맨틱이라 부르는 데이터셋 계층이 있음을 알아채고, 그것을 레이크로 향하게 하자고 제안한다. + +**대신 쓸 것, 그리고 왜.** 웨어하우스 스택. 컬럼 스캔을 위해 만들어진 쿼리 엔진, 그 위의 메트릭 또는 시맨틱 계층, 그리고 맨 위의 BI 도구. ObjectStack의 분석 계층은 애플리케이션 자신의 행을 위한 메트릭 계층이다. 그 문서는 데이터셋을 "a base object, the relationships to include, and the declared dimensions and measures"(베이스 오브젝트, 포함할 관계, 그리고 선언된 차원과 측정값)로 정의하고, 조인은 오브젝트 그래프에서 도출된다. 스키마는 이를 문자 그대로 만들어 데이터셋의 `object`를 "Base object name"(베이스 오브젝트 이름)으로 기술한다. when-to-use 페이지는 한 문장으로 말한다. 분석 계층은 "defines metrics over the app's own objects for its reports and dashboards. It is not built to query a lake."(앱 자신의 오브젝트 위에 보고서와 대시보드를 위한 메트릭을 정의한다. 레이크를 질의하기 위해 만들어지지 않았다.) 웨어하우스의 시맨틱 계층은 레이크 위에서 같은 일을 하며, 이 사이트의 비교 페이지도 BI를 진지하게 하는 회사는 여전히 그것을 원할 것이라고 말한다. + +**잘못 골랐을 때의 비용.** 두 사본 중 하나. 레이크를 앱 오브젝트에 적재하면, 이제 3년치 이벤트의 두 번째 사본이 자체 신선도와 자체 청구서를 갖고, 스캔을 위해 설계된 것이 아니라 비즈니스 정의에서 도출된 행 저장소에 놓인다. 아니면 웨어하우스 테이블을 연합하고, 분석 질문을 애플리케이션을 위해 행 단위 쿼리에 답하도록 만들어진 엔진, 필터 푸시다운은 있지만 컬럼 파일을 아는 것은 아무것도 없는 엔진으로 보내고 있음을 알게 된다. 대시보드는 렌더링될 것이다. 머천다이징 팀이 요청한 대시보드는 아닐 것이다. + +**결정적 사실.** README가 나열하는 데이터소스는 PostgreSQL, MySQL, SQLite, MongoDB, 인메모리이고, README가 이제 `CONTRIBUTING.md`에 넘긴 패키지 디렉터리가 Turso와 WebAssembly 안의 SQLite를 더한다. 레이크 포맷도, 컬럼 엔진도, 오브젝트 스토리지 드라이버도 없으며, 데이터셋 계층은 오브젝트에 바인딩되지, 레이크 안의 테이블에 바인딩되지 않는다. + +## 4. 가격 책정이나 스케줄링 같은 알고리즘 중심 도메인 + +**시나리오.** 한 물류 회사의 제품은 경로 최적화기다. 하루치 주문과 차량을 받아 계획을 내놓는 솔버, 그리고 플래너가 정차지를 차량 사이로 끌어다 놓고 계획이 다시 풀리는 것을 지켜보는 배차 보드. 주문, 차량, 기사, 계획은 분명히 오브젝트다. 회사는 이 전부가 실행 가능한 온톨로지가 될 수 있는지 묻는다. + +**대신 쓸 것, 그리고 왜.** 솔버에도 보드에도 코드. 그리고 여기서는 온톨로지 자신의 문서가 대안을 위한 가장 강력한 논거다. when-to-use 페이지는 온톨로지가 "declares what can be done; it does not express an optimiser."(무엇을 할 수 있는지를 선언한다. 최적화기를 표현하지는 않는다.)라고 말한다. 액션의 `type`은 `script`, `url`, `modal`, `flow`, `api`, `form` 중 하나이고, `script` 액션의 핸들러는 앱의 전체 데이터 권한으로 실행되는 코드다. 정의가 소유하는 것은 문, 문의 권한, 누가 그 문을 지나갔는지의 감사다. 문 뒤의 알고리즘은 당신의 것이며, 그것을 풀 수 있는 어떤 언어든 좋다. 인터페이스는 같은 이야기의 반대 방향이다. 비교 페이지는 Console이 "server-driven from metadata, and an interface unlike any business app is easier to build directly."(메타데이터에서 서버 구동되며, 어떤 비즈니스 앱과도 닮지 않은 인터페이스는 직접 만드는 것이 더 쉽다)라고 말한다. + +**잘못 골랐을 때의 비용.** 가장 중요한 부분을 자유가 가장 적은 곳에 짓는 것. 솔버는 액션 뒤에 살 수 있고, 레코드에서 트리거되는 스케줄링 실행에는 그것이 정확히 옳다. 배차 보드는 그럴 수 없다. 페이지 안의 제한된 JSX는 설계상 "is parsed into a server-driven UI tree, never executed as code"(서버 구동 UI 트리로 파싱되며, 코드로 실행되는 일은 결코 없다)이므로, 플래너가 필요로 하는 모든 상호작용이 목록, 양식, 보드를 위해 만들어진 렌더러와의 협상이 된다. 여섯 달 뒤, 온톨로지는 당신이 실제로 파는 것을 둘러싼 얇은 껍데기가 된다. + +**결정적 사실.** `packages/spec/src/ui/action.zod.ts`의 `ActionType`은 닫힌 집합 `script | url | modal | flow | api | form`이다. 알고리즘은 결코 그중 하나가 아니며, 거기로 가는 경로일 뿐이다. + +통하는 분할은 이렇다. 비즈니스 절반, 즉 주문, 차량, 기사, 누가 계획을 승인할 수 있는지, 계획이 게시되면 무엇이 일어나는지는 온톨로지로 만들어 에이전트가 쓰고 운영할 수 있게 한다. 솔버는 `script` 액션 뒤의 코드로 만들어 권한, 감사, 에이전트 접근이 다른 모든 액션과 마찬가지로 적용되게 한다. 플래너의 보드는 자체 애플리케이션으로 만든다. 보드가 *곧* 제품이라면 거기서 시작하라. + +## 5. 인증된 플랫폼을 요구하는 워크로드 + +**시나리오.** 한 병원 그룹이 입원 접수 워크플로를 원하고, 그 구매 부서는 그것이 돌아가는 플랫폼이 특정 인증을 보유할 것을 요구한다. 공공 입찰은 ISO 인증서에 대해 같은 질문을 던진다. 워크로드 자체, 즉 양식, 라우팅, 승인, 감사 추적은 교과서적인 적합 사례다. + +**대신 쓸 것, 그리고 왜.** 인증서를 보유한 플랫폼이거나, 당신이 직접 인증하는 배포이며, 결정은 벤더의 로드맵이 아니라 구매자의 달력이 한다. when-to-use 페이지는 이렇게 말한다. "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."(ObjectStack은 당신이 배포하고 운영하는 오픈소스 소프트웨어이며, 자체 컴플라이언스 인증을 갖고 있지 않다. 워크로드가 인증된 플랫폼에서 실행되어야 하는 곳에서는, 당신의 배포를 인증하는 것은 당신이 소유한 일이다.) 이것은 회피가 아니다. 인증은 원래 그렇게 동작한다. 인증은 실행 중인 환경, 그 통제, 그 운영자를 다루며, Apache-2.0 저장소는 그중 어느 것도 아니다. 이 사이트의 [보안 페이지](/ko/security/)는 상용 에디션에 대해 같은 말을 한다. "Certification depends on your running deployment, not a binary alone."(인증은 실행 중인 배포에 달려 있지, 바이너리 하나에 달려 있지 않다.) + +**잘못 골랐을 때의 비용.** 설계 단계가 아니라 구매 단계에서 이것을 발견하는 것. 그때쯤이면 일정은 이미 플랫폼이 인증서를 가져온다고 가정하고 있다. 그러면 감사는 예산 없이, 가동 직전에 당신의 계획 위로 떨어진다. + +**결정적 사실.** 프로젝트의 용어집은 자체 프로토콜 적합성 키트조차 "planned"(계획됨)로 나열하며, "no TCK program or certification mechanism in the codebase today"(오늘 코드베이스에는 TCK 프로그램도 인증 메커니즘도 없다)라고 적는다. 감사인에게 가리킬 것은 당신의 배포 말고는 없다. + +워크로드는 여전히 적합하다. 문제는 호스트다. 정직한 순서는 먼저 인증 작업의 비용을 산정한 다음 결정하는 것이다. + +## 다른 범주가 앞서 출발하는 두 곳 더 + +비교 페이지는 두 가지 양보를 더 추가하는데, 그것들은 부적합 목록에 없다. 워크로드의 종류가 아니라 문제의 종류에 관한 것이기 때문이다. 둘 다 여섯 종류 테스트를 같은 방식으로 통과한다. + +**이종 데이터에 대한 추론.** 질문이 “우리가 아는 모든 것에서 무엇이 따라 나오는가”이고, 클래스 계층, 도출된 사실, 어휘를 가로지르는 일관성 검사를 동반한다면, 그것은 지식 온톨로지의 일이며, ObjectStack에는 "no object inheritance, no axioms and no reasoner"(오브젝트 상속도, 공리도, 추론기도 없다). `abstract` 키는 약속으로 남겨지는 대신 스펙에서 제거되었다. 정의는 검증된 다음 실행된다. 런타임에 추론되는 것은 아무것도 없다. [정의 글](/ko/blog/what-does-the-ontology-is-the-software-mean/)이 이 부정을 충분히 다룬다. + +**생태계 성숙도.** Salesforce, Odoo, ERPNext는 "bring years of production use, packaged applications, app marketplaces and implementation partners. ObjectStack is younger; expect to build more of it yourself."(수년간의 프로덕션 사용, 패키지 애플리케이션, 앱 마켓플레이스, 구현 파트너를 가져온다. ObjectStack은 더 젊다. 더 많은 것을 직접 지을 각오를 하라.) 이번 분기에 패키지 앱이 필요하고 당신의 도시에 구현 파트너가 필요하다면, 정의가 어떻게 쓰이든 더 젊은 플랫폼은 잘못된 베팅이다. + +## 결정표 + +각 행은 워크로드, 오늘 적합한지와 대신 쓸 것, 그리고 그것을 결정하는 하나의 사실과 출처다. “오늘”은 날짜다. 출처는 objectstack의 태그 `@objectstack/cli@18.2.0`, 즉 `npm view @objectstack/cli dist-tags`가 2026-10-28에 `latest`로 보고한 버전이며, 그날 읽었다. 출처는 파일 이름으로 쓴다. 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/` 아래, README와 `CONTRIBUTING.md`는 저장소 루트에 있다. + +| 워크로드 | 오늘 적합한가? 대신 쓸 것 | 결정적 사실(출처) | +| :--- | :--- | :--- | +| 대기업의 핵심 ERP나 재무 | **아니오.** 패키지 시스템. 그 주위에 짓는다 | 규제와 예외 사례가 곧 제품. 런타임의 열두 기능에 원장, 세금, 급여 엔진은 없다(when-to-use; README 기능 표) | +| 많은 기존 시스템의 통합 | **아니오.** 시맨틱 또는 컨텍스트 계층. 되쓰기가 있으면 운영 온톨로지 | 연합은 기본적으로 두 겹으로 읽기 전용. 데이터소스의 `allowWrites`와 오브젝트의 `writable`(external-datasources; `engine.ts`의 `assertWriteAllowed`) | +| 데이터 레이크 위의 분석 | **아니오.** 웨어하우스 쿼리 엔진, 메트릭 계층, BI | 데이터셋은 베이스 오브젝트에 바인딩. 드라이버는 행 저장소이고 레이크 포맷은 없다(analytics; `dataset.zod.ts`; README 데이터소스; `CONTRIBUTING.md` 드라이버) | +| 알고리즘 중심 도메인 | **알고리즘에는 아니오.** 코드. 나머지가 비즈니스 앱이면 `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) | +| 첫날부터 에이전트가 운영하는 백오피스 | **예.** | 모든 배포가 MCP 서버이고, 기본으로 켜져 있으며, 사용자의 권한 아래에 있다(when-to-use; README) | + +![두 단계의 자가 점검. 1단계는 다섯 가지 배제로, 어느 하나라도 예이면 온톨로지는 그 부분의 도구가 아니다. 원장, 연결, 세금, 급여 계산. 가치의 대부분이 당신이 남겨 두되 소유하지 않는 시스템에 있음. 데이터가 레이크나 웨어하우스에 정지해 있음. 솔버, 최적화기, 또는 어떤 비즈니스 앱과도 닮지 않은 인터페이스. 특정 인증을 보유해야 하는 플랫폼. 2단계는 시작 전 다섯 가지 질문. 무엇을 갖고 있는가, 어떻게 연결되는가, 무엇을 할 수 있는가, 누가 할 수 있는가, 언제 무엇이 일어나는가. 세 가지 판정. 다섯 번의 아니오와 다섯 개의 답은 적합이며 에이전트에게는 하루 일. 어느 하나의 예는 그 선을 따라 워크로드를 나눈다. 답 없는 아니오는 아직 어떤 도구도 도움이 되지 않음을 뜻한다.](./self-check-en.svg) + +## 자가 점검을 돌려 보라 + +열 문항, 두 단계, 십 분. 1단계는 배제 목록이고, 2단계는 when-to-use 페이지의 "Five questions before you start"(시작하기 전 다섯 가지 질문)를 거기 인쇄된 그대로 인용한 것이다. + +**1단계. 어느 하나라도 예이면 온톨로지는 그 부분의 도구가 아니다.** + +1. 이 워크로드의 어려운 부분이 패키지 시스템이 이미 인코딩한 규제 계산인가. 원장, 연결, 세금, 급여인가? +2. 가치의 대부분이 당신이 남겨 두되 소유하지 않는 시스템을 읽고 쓰는 데서 오는가? +3. 분석하려는 데이터가 애플리케이션 자신의 레코드가 아니라 레이크나 웨어하우스에 정지해 있는가? +4. 제품의 핵심이 솔버, 최적화기, 시뮬레이션이거나, 어떤 비즈니스 앱과도 닮지 않은 인터페이스인가? +5. 워크로드가 특정 인증을 보유한 플랫폼에서 실행되어야 하며, 자체 배포를 인증할 예산이 없는가? + +**2단계. 당신의 팀은 오늘 비즈니스에 대해 이것들에 답할 수 있는가?** + +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."(언제 무엇이 일어나는가. 레코드 트리거, 예약 작업, 승인, 워크플로.) + +다섯 번의 아니오와 다섯 개의 답. 온톨로지는 그 페이지의 말로 "a day's work, because an agent does the writing."(하루 일이다. 쓰는 것은 에이전트이기 때문이다.) 다섯 번의 아니오와 답 없음. "no tool helps yet, this one included. The first investment is answering these five questions, not installing anything."(아직 어떤 도구도 도움이 되지 않는다. 이것도 포함해서. 첫 투자는 무언가를 설치하는 것이 아니라 이 다섯 가지 질문에 답하는 것이다.) 1단계에 예가 하나. 그 선을 따라 워크로드를 나누고, 통과한 부분을 남기고, 나머지에는 표의 대안을 쓴다. + +## 이 목록이 말하지 않는 것 + +이 한계들이 영구적이라고 말하지 않는다. 페이지의 제목은 “not a fit *today*”(*오늘은* 맞지 않음)이고, 연합은 “early”(초기)라고 불리며, 위의 표에는 날짜가 붙어 있다. 결정하기 전에 현재 페이지와 대조하라. + +대안이 일반적으로 더 낫다고 말하지 않는다. 시맨틱 계층은 40개 시스템을 가로질러 읽기에는 옳은 도구이고, 티켓 데스크를 운영하기에는 틀린 도구다. 이유는 2절이 반대 방향에서 말한 그대로다. 각 행의 대안은 그 행에 대해서 옳다. + +그리고 한 행에 실패하면 워크로드가 실패한다고 말하지 않는다. 대부분의 실제 사례는 나뉜다. 입원 접수 워크플로는 적합하고 호스트는 구매의 문제다. 배차 도메인은 적합하고 솔버는 코드다. ERP 주변의 부서 앱은 적합하고 원장은 있던 자리에 남는다. 여섯 종류 테스트는 어려운 부분에 적용되지, 프로젝트 이름에 적용되지 않는다. + +## 이 목록에서 ObjectOS의 자리 + +위의 어느 것도 에디션에 따라 바뀌지 않는다. “같은 루프를 호스팅으로, 브라우저에서, 아무것도 설치하지 않고 쓰고 싶다면? 그것이 ObjectOS, ObjectStack 위에 구축된 상용 런타임 환경입니다.” ObjectOS는 세 가지 에디션으로 제공됩니다. 오픈소스이며 무료로 직접 호스팅하는 ObjectOS Community, 설치 없이 브라우저에서 호스팅되는 ObjectOS Cloud, 자체 인프라에서 직접 운영하는 ObjectOS Enterprise입니다. 어느 에디션에서든 온톨로지를 내보내 다른 에디션에서 실행할 수 있습니다. 다섯 가지 워크로드는 실행 가능한 온톨로지가 무엇을 표현할 수 있는지에 관한 것이지, 어디서 실행되는지에 관한 것이 아니다. 그래서 이 목록은 어떤 호스트에서든 같게 읽힌다. 호스트에 관한 유일한 질문인 인증에 대해, 보안 페이지는 ObjectOS에 대해 오픈소스 페이지와 같은 말로 답한다. 실행 중인 배포에 달려 있다고. + +## 당신의 사례가 통과했다면 + +그렇다면 가장 빠르고 정직한 다음 단계는 데모가 아니라 정의다. [how to point your agent at ObjectStack](/en/blog/how-to-point-your-agent-at-objectstack/)에서 다루는 규칙 파일, 스킬 번들, 도구 서버로 코딩 에이전트를 ObjectStack에 향하게 하고, 첫 오브젝트를 요청하라. 필드 몇 개, 관계 하나, 액션 하나, 권한 집합 하나, 트리거 하나. `npm run validate`를 실행하고, Console을 읽기 전에 diff를 읽어라. diff 전체를 읽을 수 있고 그것이 당신의 비즈니스가 하는 일을 말한다면, 여섯 종류 테스트는 실전에서 통과한 것이며, 에이전트에게 다음으로 건넬 페이지는 [정의란 무엇인가](/en/ontology/)다. 읽을 수 없다면, 이 글의 어떤 것도 애초에 당신을 도울 수 없었을 것이고, 당신은 방금 프로젝트 하나를 아낀 것이다.