# Objects and Types Status: settled semantic contract, 2026-09-11. The broader universal runtime is not yet complete; generic Definition composition, validation and publication have a bounded implementation recorded in [implementation status](../implementation/status.md). Owns: the universal object primitive, addressability, typed values and first-class type definitions. Read the [core object model and authority](core-object-model-and-authority.md) for cross-cutting invariants; read the [product definition](../product/definition.md) for intent; follow [Business Graph and Business DNA](business-model.md) for connections and business configuration. Source: architecture sources 01 section 4 and 02 sections 3, 4 and 11; see the [source ledger](../governance/source-map.md). ## Universal Primitive All persistent and addressable platform data uses one foundational model: ```text { id: , type: , value: } ``` `id` gives an object an address; `type` identifies its semantic meaning; `value` contains its typed/configured content. This is an architectural rule, not merely a convenient serialization format or a pattern restricted to business records. Customer, Person, Organisation, Product, Service, Project, Task, Order, Document, Campaign, Knowledge item, Workflow, independently addressable Workflow node, Event, Rule, Policy, Constraint, Goal, Decision, Relationship, UI definition, Integration configuration, business terminology and Business DNA information all use this model. Identity and permission data are not a separate conceptual exception. No capability may introduce a competing foundational schema merely because it has different business meaning. Capability Definitions and Business capability instances/configurations use the same universal object and configuration model. New concepts extend the vocabulary through types and configuration. Any proposed exception requires an explicit human architectural decision; none is approved here. ## Addressability and Values Anything needing independent identity, reuse, relationships, provenance, history or lifecycle should be addressable. This includes independently managed configuration, not just customer-facing records. Addressability does not imply classification. A contained or referenced Object does not automatically need a new Type, semantic role or persistence category. Containment and reference describe composition; identity, Type, revision and provenance describe the addressed Object. One Object may combine Data, Workflow, Logic, Relationship, Presentation and Configuration meanings where the applicable contract requires it. There is one Universal Object system. The descriptions Data Object, Logic Object, Workflow Object and Presentation Object are shorthand for an Object's predominant semantic function within that system; they are not separate object classes, stores, repositories, fixed classifications or mandatory Types. A predominantly data-oriented Object may contain logic, workflow and presentation Objects, a workflow-oriented Object may contain data and logic Objects, and a logic-oriented Object may contain data, workflow and presentation Objects. Semantic roles are non-exclusive, and identity does not imply a Type or role. An Object may contain other Objects recursively. A contained Object may remain inline when independent identity, reuse, relationships, provenance, history or lifecycle is not required. When one of those requirements applies, the Object uses the existing identity, revision and reference mechanisms; the need for an address does not itself create a new Type or semantic role. For example, a Capability Object named Marketing may contain an Object named Campaigns without either name creating a special Type or Capability-specific object system. These examples describe meaning and addressability, not a new JSON field layout or identifier encoding. The primitive does not require every nested property to become an object. Strings, numbers, booleans, dates, arrays and structured values remain valid inside a typed value. An ordinary scalar contact preference can remain a property; a reusable policy, related person or independently versioned workflow is not an anonymous repeated value. For example, a Customer object can contain a display name while referencing an Organisation object shared by CRM, sales and operations. A workflow definition can refer to a policy object instead of embedding copies that silently diverge. These examples specify semantic identity, not an approved JSON field layout or identifier encoding. Workflow Nodes follow the same rule: their object ID and retained object revision are authoritative. A Workflow Definition revision binds each Node by `node_id` and `node_revision`, identifies exactly one bound entry Node, and never embeds a second authoritative copy of Node configuration. An object address must not be confused with a mutable display label. Concrete address encoding and reference resolution are specified in [implementation architecture](../implementation/architecture.md#physical-model-mapping); they do not redefine semantic identity. ### Four semantic roles and value references The platform's semantic object model has four roles within this universal primitive: Data, Logic, Workflow and Presentation. These roles do not introduce a second storage model or replace D02 Type definitions. A Customer, Business or Invoice can be understood as a Data Object; a human interaction can be a Workflow Object; an automated evaluation can be a Logic Object; and a model-defined UI composition can be a Presentation Object. Workflow Definitions, Workflow Executions, Events, Commands, Attempts, Outcomes and other addressable records remain same-model configuration or execution records under their existing owners, not additional semantic roles. A Data Object's current `value` may be a concrete typed value or an object reference to a Data, Logic, Workflow or Presentation object. The reference is the current value itself. It is not a permanent initializer, computed-field binding or source property, and it does not imply immediate execution. When a concrete value is required, dependency inspection may follow the reference under the existing governed contracts; any Workflow or Logic execution requires an explicit governed operation and its normal authority, Command and evidence boundary. A later governed mutation may replace the reference with a primitive or another reference. Revisions and provenance retain history without inflating the current value. This does not collapse object references and structural Relationships. A reference can be the current value of a Data Object, while a Relationship remains an addressable connection when its endpoints, meaning, metadata, provenance, history or lifecycle require independent identity. The distinction is governed by meaning and addressability, not by another semantic object category. See [core object model and authority](core-object-model-and-authority.md#four-semantic-object-roles) for the canonical examples and invariants. Commands, Action Executions, Attempts, State definitions, state-transition occurrences, Assertions, materialised determinations and their provenance follow this same addressability contract. A State definition is not a transition occurrence; a change between States has its own address and historical context under [time and events](time-and-events.md). ### Object Presence, Definitions and Derived Condition An object may exist without a definition and may initially have no current value or constituents. A definition is an addressable descriptive/configurational object that describes an object's complete composition of Data, Workflow and Logic roles, including intended structure, dependencies, relationships, presentation, configuration or behavior; it may contain or reference recursively composed universal Objects. A Capability Definition is a reusable template/configuration composition, not a shallow list of Types, Operations or Views. It does not create the validity of an object or silently replace the actual configuration. Configuration and definitions therefore use the universal model without introducing a second Definition primitive. Every platform Definition, including User (the persisted Type and Definition still carry the legacy name Principal), Business, Capability and constituent Definitions, uses the universal `OBJECT_DEFINITION_TYPE`. This is not a Capability-specific Type or persistence category, and its validity is not limited to Definitions consumed by Initialization. A complete Definition payload must satisfy the applicable typed and structural validation before publication. A Definition's Object identity and retained Object revisions remain distinct from its Type identity/revision and from publication evidence. Publication availability belongs to successful publication evidence for an exact Object revision; it is not inferred from a universal `status` property, Object existence, Type membership or a release label. ### Generic Definition payload and reference contract The universal Definition payload and Candidate A reference semantics are settled. A Definition contains the complete recursive composition required to describe its subject, expressed through ordinary typed values and addressable Objects; it is not a shallow Type/Operation/View list or a capability-specific graph. The root Definition value identifies its subject Type and exact Type revision and carries the typed value being described. Inline constituents remain nested typed values validated against the exact applicable Type descriptors; they do not receive independent Object IDs. A separately addressable reference is explicitly discriminated as `object_reference` and contains exactly the target Object ID and positive Object revision. The target Object revision supplies the authoritative Type ID and Type revision. Do not copy an `expected_type` field into this reference or silently resolve the latest Object or Type revision. Required and optional constituents follow the applicable Type descriptor. An omitted optional constituent is valid; a missing required constituent is invalid. A present reference must resolve at the exact requested revision and be accessible in the publication context. Its Type and retained typed value must be compatible with the containing descriptor. A separately addressable Definition dependency must already be publication-available at that exact Object revision. Missing, inaccessible, nonexistent, incompatible, unavailable or unpublished required dependencies fail closed without disclosing protected Object existence. Repeated non-cyclic references are allowed; cycles are rejected. Validation is structural, finite and non-executing. The initial implementation uses depth 6, 100 unique Object revisions and 200 reference edges, matching the existing Definitions catalogue bounds. These are runtime resource limits, not additional Definition semantics. Validation never executes Workflow or Logic and does not create, revise, publish or apply dependencies. The Operation owner binds this validated payload to create/revise semantics, the expected Object version, atomic publication evidence and provenance. Operation dependency tuples remain Operation-specific and are not the generic Definition reference grammar. The same rule applies to every Capability Definition. Its complete composition is expressed through ordinary Universal Objects, inline typed values and, where independent addressability is required, exact references to other Objects. Data, Workflow, Logic, Relationship, Presentation and Configuration are meanings that Objects may fulfil or combine, not Capability-specific constituent classes. A Definition must not introduce a `composition`, `members`, `children` or graph schema merely to name its containment; the applicable implementation owner must reuse the existing Universal Object and reference mechanisms. Traversal inspects structure only and must not execute a referenced Workflow or Logic Object. The actual object and constituent graph remains authoritative for what exists. An object does not need to contain every possible constituent described by a definition, and a definition does not create absent constituents by itself. Normal Data, Workflow and Logic execution may establish, replace, modify or remove constituents where governed. A value's presence is not sufficient to establish semantic validity, and an absent value is not automatically an error. Applicable Type, definition, relationship and workflow rules determine resolution in context. For publication, inline recursive composition is valid within the complete payload. Each separately addressable Definition dependency must already be publication-available at the exact referenced Object revision before a dependent Definition can be published. Dependency inspection is bounded and non-executing; publication does not run referenced Workflow or Logic. State is the derived condition of the actual object and its applicable configuration, not an independently authoritative value. An implementation may materialize or cache that condition, but the materialization cannot override durable object data. A constituent change can therefore change the derived condition of its containing objects recursively. Inheritance propagates applicable characteristics only through constituents that exist; it does not create absent constituents. An object may be useful and meaningful while empty or partially configured; `empty` is not synonymous with `invalid`, and `complete` is not a universal persisted State. A Definition can expose missing or unresolved requirements by comparing its applicable revision with the actual Business configuration, relationships, evidence and constituent objects. Derivations may distinguish valid, not yet configured, unresolved, unavailable, unknown, stale, conflicting or awaiting human determination where that distinction matters, but these are contextual interpretations rather than a new mandatory State taxonomy or duplicate lifecycle field. ### State Identity A State definition is an addressable typed semantic object with stable identity. Its display label or code, such as `approved`, remains a primitive value, not the State's identity. Equal labels do not make two State definitions identical, and renaming a label does not create a new State identity or rewrite its historical use. Keep the State definition, a subject object's current State reference, and the occurrence of a transition into or out of that State distinct. Types identify the applicable State definitions and permitted transitions; historical references preserve the definition/version context actually used. A transition occurrence has its own address and links to its subject and before/after State definitions. This applies in the minimal runtime as well as later implementations. It does not impose a universal State enumeration, make every primitive value an object, or equate a UI loading/selection flag with business State. [Time and events](time-and-events.md#durable-history-and-transition-occurrences) owns transition history; [views and content](views-and-content.md#interaction-state-and-business-state) owns the UI distinction. ## First-Class Types ### Platform Initialization Definitions The initial runtime provides platform-owned, revisioned Definition objects for the foundational User (persisted under the legacy name Principal) and Business compositions. These Definitions describe a deliberately small, extensible set of applicable constituents; they are not a fixed User or Business schema and do not expose credentials, confirmation material, sessions or password hashes. A Definition revision is descriptive configuration. Existing instances do not silently change when a later platform revision is introduced. Constituent requirements may be recursive and may describe addressable constituent objects, relationship participation or primitive values. Multiplicity and optionality belong to the constituent requirement in the Definition. The first initialization slice uses addressable constituent objects where the value needs independent identity or history and keeps the existing universal object/revision model for all resulting data. A type definition is itself an addressable object, not an unrelated configuration schema or a PHP class masquerading as the platform model. It describes intended or recognised structure and applicable behavior where that definition is adopted and applicable; it does not impose a universal minimum schema on every object. An object may be arbitrary, empty or definition-less, and a definition may exist without every object adopting it. Type definitions may describe, subject to their explicit adoption and applicability: - Required and optional properties, property types and valid value structure. - Validation rules and permitted relationships. - Applicable addressable State definitions, valid transitions and behavioral capabilities. - Permission declarations and applicable ownership requirements. - UI representation and workflow capabilities. - Type-family membership, inheritance or composition where supported. The platform therefore provides schema and strong validation without a new foundational database schema for every concept. A type's permission declaration is interpreted under [identity and governance](identity-and-governance.md), its presentation under [views and content](views-and-content.md), and its historical meaning under [time and events](time-and-events.md). Those documents own evaluation, rendering and temporal semantics, respectively; this document owns the typed representation and validity boundary. Types and type families are structural retrieval dimensions, not vector labels. The [retrieval contract](retrieval.md) owns filtering and index use. Business Relationship Types, Platform Semantic Concepts and governed semantic mappings are typed addressable objects when they require independent identity, reuse, provenance, history or lifecycle. A Business Relationship Type remains valid without a Platform Semantic Concept or mapping. A Platform Semantic Concept is optional semantic knowledge, not a mandatory parent Type, and a mapping cannot silently redefine the Business Type's meaning or runtime constraints. Similar labels do not establish semantic equivalence; any mapping or reuse must be explicit, authorized, validated and historically traceable. ## Validation and Configuration Human-authored, imported, automated and AI-proposed objects are subject to the same deterministic validation boundary. An AI response that resembles a valid object is not evidence that its type, relationships, permissions or lifecycle transition is acceptable. Addressable configuration follows the primitive and must remain serializable, versionable, human-readable, AI-readable and schema-validatable. Executable configuration is interpreted by a controlled runtime, not arbitrary generated application code. A readable workflow configuration is distinct from a running workflow; see [workflow terminology](workflows-and-automation.md#terminology). Type validation does not by itself authorize an operation. A structurally valid update can still violate an applicable policy or lack permission. Conversely, permission does not excuse invalid values. Rejected proposals must not silently become authoritative business data. The Type-of-Type descriptor is the validation boundary for Type definitions. A Type definition is validated as a descriptor, including its declared property descriptors; it is not validated as an ordinary closed object instance and does not require an arbitrary nested `value` property. Configuration manifests retain the exact referenced Type identity and revision for ordinary values, while a `kind: type` declaration supplies a Type descriptor as its value. Generic Business Graph values must not contain credential or authentication material. The typed-value validation boundary recursively inspects object properties and array members after ASCII case-folding and replacing spaces and hyphens with underscores. It rejects exact whole-name matches for `password`, `password_hash`, `passphrase`, `auth_secret`, `authentication_secret`, `session_token`, `recovery_code`, `recovery_codes`, `api_key`, `client_secret`, `access_token`, `refresh_token`, `private_key`, `totp_secret`, `credential` and `credentials`. Substrings such as `token`, `secret`, `key`, `api_token`, `customer_secretary` and `key_account` remain valid. Credentials remain in their dedicated protected boundary; read projections do not perform this validation or redaction. Definitions extend business vocabulary under the [non-overridable foundations](../product/definition.md#non-overridable-foundations). Type or lifecycle configuration cannot redefine the runtime semantics that validate, authorise, record and commit its use. Business, Capability, Marketing, Network, Variable, Calculated Value, Knowledge, Analytics and AI are not additional semantic roles or competing primitives; they are objects, definitions, configurations, compositions or higher-level layers over Data, Workflow and Logic. Terms such as `complete`, `valid`, `active` or `approved` are configuration- or workflow-specific meanings, not universal kernel-level States. ## Storage Boundary Durable persistence is the authoritative representation of committed platform state. In-memory state, read models, projections, indexes and caches are non-authoritative; they cannot certify a mutation or override durable versions. The physical database schema implements the logical model, not the reverse. The semantic contract does not require one SQL table, an entity-attribute-value layout, a graph database, JSON-only storage or a particular identifier technology. Physical stores, blob handling and deterministic indexes implement this model without competing foundations. [Workflow commit](workflows-and-automation.md#action-preconditions-and-commit-boundary) controls consequential mutation and [time and events](time-and-events.md#durable-history-and-transition-occurrences) controls coherent required history. The old marketing tables are not a starting schema or migration target. [Implementation architecture](../implementation/architecture.md) records the chosen physical mechanism separately from this contract. ## Controlled Genesis Foundation-only Genesis establishes the generic object/revision prerequisites, Type-of-Type semantics, minimum foundational Type descriptors, required Genesis occurrence/ledger semantics, technical installation provenance, deterministic manifest verification and fresh-store/idempotent installation controls. It is not an ordinary permission bypass, a second platform opening, or permission for a model to install human authority. After foundation installation, normal customer/runtime state is empty: there are no human Users, credentials, Businesses, Memberships, Business-scoped AuthorityGrants or Business-scoped Policies. Genesis creates no owner, superuser, permanent administrator, first Business, customer/business View or permanent human runtime actor. Technical installation/release provenance is non-human evidence and cannot authenticate, authorize, impersonate a User or issue continuing authority. The [genesis mechanism](../implementation/architecture.md#controlled-bootstrap) and separate platform opening specify the remaining installation boundaries. Business, User, Membership, AuthorityGrant, Policy and any approved subscription or entitlement representation use the universal object/type model when they require durable identity, relationships, provenance, history or lifecycle. This representation does not collapse Business identity, creator provenance, authority or subscription into an ownership field, and it does not create an Account object merely to represent a commercial actor. [Identity and governance](identity-and-governance.md) and [subscriptions and entitlements](subscriptions-and-entitlements.md) own their meanings. User profile data follows the same boundary. Display name and approved personal profile attributes are typed values on the User object (the User Type is persisted under the legacy name Principal), with retained object revisions for changes. A User is a platform-scoped account and is distinct from a Person, which is a Business-scoped individual profile; neither requires the other. An email address used for authentication is not copied into that value: the confirmed identity association remains in the protected identity subsystem, where uniqueness, confirmation, authentication and revocation are enforced. Credentials, confirmation verifiers, session material and other security-sensitive identifiers are never generic User properties and never ordinary object projection fields. An optional profile image uses an addressable Media/Asset object or equivalent approved content type, referenced from the User profile. The object stores metadata and a protected reference to bytes; the bytes are handled by the media/storage boundary and are not placed in a generic primitive. A profile reference does not itself grant read or mutation authority. Generic retrieval must return only an authorized, safe image projection and must not traverse into storage secrets or unrelated Business data. ## Conformance and Implementation [D01-D10 are settled](../governance/decisions.md). Concrete type declarations, reference encodings and supported composition operations are implementation specifications. Unsupported declarations must fail explicitly; a small initial implementation must not collapse type identity, object identity, state, transition or history into one mutable record without their distinctions. Conformance examples: - A new Equipment type participates in the existing object/retrieval system without a new foundational Equipment schema. - The same Customer object can appear in CRM, sales, projects and marketing. - A workflow, event, permission definition and knowledge item are addressable under the same rule as business records. - A scalar note does not need an independent address unless its intended behavior requires one. - A module introducing an isolated customer model, or an AI bypassing type validation, is nonconforming.