Glossary term
Typed metadata
Typed metadata is application metadata whose keys and values are constrained by a published schema, so that an unknown field type, a misspelled permission, or a workflow step pointing at an object that does not exist is rejected at a validation gate when the definition is written, instead of being discovered in production after it runs.
Also known as schema-validated metadatatyped application definitionstrongly typed metadata
In practice
The distinction is between a configuration file and a contract. A YAML or JSON config file accepts whatever you put in it; the program that reads it decides at run time which keys it happens to recognize, and quietly ignores the rest. That default is where declared-but-unenforced settings come from: someone writes `requireApproval: ture`, nothing complains, and the approval that was declared never runs. Typed metadata inverts the default. The schema is published, every key has a type, and a key nobody recognizes is an error rather than a shrug — so what the file says and what the system does cannot drift apart without something failing loudly first.
Typing does more than reject typos, because a schema is readable by tooling as well as by validators. The same declaration drives editor completion while the definition is written, a validation gate in continuous integration, and the generated documentation a reader consults later. One published contract, three consumers — which is why the schema is worth maintaining as a first-class artifact rather than as validation logic scattered through whatever reads the file.
The argument gets sharper when an agent is the author. A model asked to add an approval rule fails in a characteristic way: it produces something plausible and adjacent — a real-looking key that this schema does not define, a permission value borrowed from a different platform it saw more often in training. Untyped configuration absorbs that silently and ships it. A schema rejects it at the point of authorship, where the agent can read the error and correct it in the same loop, and the schema also steers generation before the mistake happens, because a published type is exactly the kind of constraint a model can follow.
What typing does not do is worth stating, because overselling it is how validation becomes a substitute for review. A schema constrains shape, not intent. A permission set can be perfectly valid and still grant the wrong people access to salary data; a workflow can type-check and still route approvals to someone who left the company. Typed metadata moves an entire class of error from production to the validation gate and makes the rest smaller and more readable — it does not decide whether the declaration is correct, and nothing in the toolchain replaces the person who signs off.
Where this term is used
Pages and articles that put this term to work.
Product pages
- Data modeling Objects, relationships, validations, and formulas become tables, migrations, a query language, and REST APIs — with an object designer, an ER diagram, and datasource sync that federates existing databases in place.
- Platform ObjectOS is the commercial production platform for ObjectStack apps, combining in-app AI, deployment, and team operations with the open, governed ObjectStack runtime.
- 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
- 業務アプリは何トークンか? 完全な CRM 全体が 150k 未満 完全な CRM は型付きメタデータ全体で 150k トークン未満です。ビジネスロジックは 100k 未満、UI は約 50k。同梱のリファレンス CRM は約 16k です。コンテキストに丸ごと収まるソフトウェアは保守のされ方が変わります。
- Agent ルールファイルの書き方:AI にガバナンス可能なアプリを生成させる AGENTS.md、.cursor/rules、CLAUDE.md はコードスタイルだけを管理すべきではない。権限、承認、監査、対象メタデータ形式を書けば、AI 生成アプリはレビューしやすくなる。
- AI ネイティブアプリケーションの核心はコード生成ではなくメタデータ生成 コード生成はプロトタイプを速くしますが、エンタープライズアプリケーションには、オブジェクト、フィールド、関係、ビュー、権限、ワークフロー、アクション、Agent ツールをまとめて管理するメタデータ Runtime が必要です。