Glossary term
Application definition vs. runtime
Application definition vs. runtime is the architectural split between what an application is — a typed, version-controlled declaration of its objects, fields, relationships, permissions, workflows, actions, and APIs — and what runs it: an engine that reads that declaration on every request and derives the database, the API, the interface, and the permission and audit enforcement from it, so that the definition stays portable and the engine stays replaceable.
Also known as definition vs runtimedeclaration versus executionseparating application definition from application runtime
In practice
The split is easiest to see by looking at where it is absent. In a generated application, the definition and the runtime are the same artifact: a generator turns a specification into controllers, forms, and migrations, and from that moment the specification is a historical document. Nothing reads it again. Change the generated code and the specification is wrong; change the specification and the code is unaffected. In a system that keeps the split, the declaration is the live source — the engine consults it on every request, so there is no gap in which the two can disagree, and no separate act of regeneration to remember.
The consequence people actually care about is lock-in, and it has two halves that are often confused. An open definition format with one proprietary engine that can execute it is not portable, however readable the files are; you can take your declarations elsewhere and nothing there will run them. An open engine with an undocumented internal format is not portable either; you can host it yourself right up until you want to read what it is hosting. Portability requires both halves — a definition you can read and diff without running anything, and at least one runtime you can operate yourself.
The strongest argument against the split is worth stating plainly: an integrated system that owns both halves can be better engineered. It can change the format and the engine together, ship features that need both, and avoid the compatibility surface a stable declaration format imposes. That argument holds for a single product with a single vendor. It stops holding once several parties depend on the same declarations — the application, the agents that call it, the auditors who read what happened, and tooling from vendors who will never coordinate a release with each other.
The practical test is two questions, and both are answerable in an afternoon. Can you read the whole application without running it — open a file, see what an object is, who may edit it, and which step requires approval? And could a second, independently built runtime execute those same files? Answering yes to the first and no to the second is the common case, and it is worth naming honestly rather than counting as a pass.
Where this term is used
Pages and articles that put this term to work.
Product pages
- Platform ObjectOS is the commercial production platform for ObjectStack apps, combining in-app AI, deployment, and team operations with the open, governed ObjectStack runtime.
- Product tour See how teams use ObjectOS to take an ObjectStack app from a business request to production: typed metadata, a human-reviewed diff, and governed operation.
- Agent developer Teach a coding agent the open ObjectStack target format, Strict TypeScript definitions, Zod schemas, validation gate, and whole-context proof needed to generate reviewable applications.
Articles
- Enterprise AI Ontology: Why the Definition and Runtime Should Be Open Ontology MCP went GA in June 2026 — the vendors made the agent interface an open protocol themselves. Definitions are following. The runtime is the layer nobody opened, and that is where portability actually lives.
- Metadata, Not Code Generation: What Makes AI-Built Apps Governable Code generation can speed up prototypes, but enterprise applications need a metadata runtime where objects, fields, views, permissions, workflows, actions, and agent tools are governed together.
- Self-Hosted AI Application Platforms: Why the Runtime Belongs to You Once AI reads business data, triggers workflows, generates applications, and calls tools, enterprises need control over the runtime that governs objects, permissions, tools, approvals, and audit evidence.