Core Object Model and Platform Authority
Status: settled cross-cutting semantic contract, 2026-10-05. This document is the conceptual authority for the platform-wide distinctions and invariants below. It does not replace the detailed contracts named in the owner map, create a second object/definition subsystem, or claim implementation evidence.
Purpose and Authority
Idiosyncrasy is an object-based platform. The object graph represents what exists; definitions describe intended or recognised configurations; derived state describes current condition; workflows describe behaviour; revisions preserve history; causality explains change; and explicit authority controls action.
This document reconciles those distinctions across the existing architecture. Detailed meanings remain with the canonical owners. D01-D10 remain settled and closed. This document creates no new architecture decision number.
The current object graph is authoritative for what exists. A definition, suggestion, view, assertion, workflow or AI response does not silently mutate that graph or grant permission. Authoritative changes use deterministic platform mechanisms after validation, authorization and any required human approval.
Generic Object and Definition Model
Idiosyncrasy has a generic Object model. Definitions describe the semantics and composition of Objects; they are not a privileged catalogue of domain or capability types. Objects may recursively contain, reference and relate to other Objects, down to primitive values. A domain word such as Marketing, Sales, Projects, Operations or CRM may remain useful product or business language, but it identifies a data-defined Object composition rather than a special runtime type, store, registry, hierarchy or execution subsystem.
The platform-wide model is:
GENERIC RUNTIME
Objects | Relationships | Revisions | Operations
↓
DATA-DEFINED SEMANTICS
Definitions | Data | Workflow | Logic | Presentation
↓
BUSINESS CONFIGURATION → AUTHORITY → USER-SPECIFIC EXPERIENCE
Data and Presentation are distinct semantic roles using the same Object, Relationship, Revision and Authority model. Presentation Objects curate how semantic Objects are exposed; Authority separately determines visibility, navigation, inspection, mutation and operation or workflow execution. These permissions must not be collapsed into a single adoption or capability flag.
Object Presentation in the Core Object Model
Object Presentation is the mechanism by which an existing Idiosyncrasy Object receives a configured visual representation in a UI context. It is not a second Object model, a copy of the Object being presented, a duplicate business-data store or an independent authority layer. Presentation participates in the universal Object model and existing configuration/projection contracts; it does not replace them.
A Presentation Object is a first-class persisted Object whose semantic role is Presentation. It is not merely a PHP rendering descriptor. It participates in the same generic Object, Revision, Relationship and Authorization model as other persisted Objects. Where it needs independent identity, provenance, lifecycle, reuse or authorization, that identity is retained in the authoritative object graph.
The general relationship is:
Object
↓
Presentation binding
↓
Presentation configuration
↓
Runtime projection
↓
Rendered presentation
Object authority
The underlying Object remains authoritative for its identity, Type, relationships, configuration, data, business meaning, revisions, provenance and applicable authority. A presentation consumes that Object and its permitted context; it must not duplicate business data merely to make the Object renderable. Presenting a Projects Object therefore does not create another Projects Object.
Presentation Objects and compatibility bindings
Presentation Objects are ordinary persisted Objects with the presentation semantic role. A Business has one exact governed presentation.dashboard_ref; that Dashboard PO recursively references child POs. The Business does not own a collection of top-level POs.
Older Presentation Instance bindings may remain only as explicitly classified migration compatibility for historical data. They are not required by the current Dashboard-root architecture and are not a second presentation authority.
Presentation composition as persisted Objects
Presentation composition is persisted as a recursive graph of Presentation Objects. Exact Object and revision references bind content and targets; generic Logic Objects calculate values where required. Projection is authorized, bounded and non-executing, and the generic renderer consumes only the resulting RenderablePresentation.elements projection. Presentation configuration must not introduce duplicate Objects, data, relationships, business authority, capability registries or parallel data models.
Presentation projection and rendering
Where a presentation needs derived, calculated, aggregated, related or authorised information, the runtime presentation projection combines presentation configuration with authoritative Objects/data and applicable access rules:
Presentation configuration
+
authoritative Object/data
+
applicable authority/access rules
↓
presentation projection
↓
renderable presentation model
↓
renderer
↓
visual output
The projection may assemble counts, status summaries, aggregations, related Object information, Type information, badges, links and other bounded presentation data. These projected values are not necessarily persisted on the Object being presented.
Nested presentation items are composition within the presentation, not necessarily separate persisted business Objects:
Projects presentation
├── Project Count
├── Active Projects
└── Project Types
An item may have a recognised key, label, projected value, badges, link and other bounded presentation metadata. The applicable presentation contract determines the supported fields and resolution rules.
Recursive presentation composition
Presentation composition follows the same generic model. A configured Object may reference another Object through authoritative configuration; the containing Object does not copy that Object:
Dashboard Presentation Object
↓
exact child Presentation Object reference
↓
child Presentation Object
↓
recursive Presentation Object projection
↓
generic rendered presentation
↓
nested presentation content
The Dashboard's direct children are navigation candidates only when their persisted navigation.navigable configuration is exactly true. Child containment alone does not create a menu entry. The generic projector and renderer do not know business-domain names.
The canonical distinction is therefore:
OBJECT
The authoritative business Object.
PRESENTATION INSTANCE
The binding that says an Object is being presented in a particular context.
PRESENTATION CONFIGURATION
Declarative instructions describing what/how to present it.
PRESENTATION PROJECTION
The runtime composition of authoritative information into a renderable model.
RENDERER
The visual output mechanism.
Detailed View/UI contracts own presentation definitions, projection forms, field selection and rendering behavior. This section owns the cross-cutting distinction between business authority, presentation binding, presentation intent, runtime projection and visual output.
Recursive Presentation Objects and Elements
The existing universal Object model remains the persistence and authority model for presentation configuration. A persisted Presentation Definition may reference a recursive graph of ordinary Presentation Objects; no separate presentation database, registry or Capability-specific presentation hierarchy is introduced.
The recursive shape is:
Presentation Object
├── Presentation Object
│ ├── Presentation Object
│ └── Presentation Object
│
└── Presentation Object
The parent may define presentation structure or containment, while child Presentation Objects define the presentation content within that structure. Traversal is recursive and has no arbitrary implementation-defined presentation depth limit. Termination comes from the persisted graph and normal graph safety mechanisms such as cycle detection.
A Presentation Definition and its Presentation Objects may expose ordered renderer-neutral elements with a bounded generic vocabulary such as text, container, collection, navigation and action. Elements may have semantic roles, declarative content sources, recursively ordered children, semantic layout metadata, governed behavior references and semantic targets. The element vocabulary is generic and must not encode Capability concepts or HTML terms.
Presentation Objects may reference content from configured literals, exact Object/value references, existing View field bindings or bounded documented derived sources. Resolution remains subject to exact revision, Business scope, authorization and provenance rules. A missing, unauthorized, invalid, unavailable or cyclic Presentation Object must not cause the renderer to gain access to unauthorized data; the authorized projection may suppress that branch, but may not invent a replacement element or infer presentation meaning from an Object Type or PHP array shape.
Business data and Presentation remain distinct. The business Object remains authoritative for its identity, relationships and values. A Presentation Object may reference that Object or one of its values for display, but must not duplicate business data merely because delivery requires it. The Presentation Object is authoritative for how the permitted data is presented.
Where a Presentation Object reference carries an exact persisted revision, projection resolves that specified revision. Omitted or invalid revisions do not silently default to another revision.
Presentation targets retain semantic identity, including target kind, exact Type/Object identity and optional exact View identity/revision. HTML URLs are delivery output and are not authoritative presentation values. Existing Operation, Command, Event, Action Execution and Outcome Objects continue to own governed behavior and evidence; Presentation Elements reference those mechanisms rather than creating a Presentation-specific execution system.
Business Dashboard root and presentation navigation
A Business has exactly one persisted Presentation Object root: its Dashboard. The Business lifecycle and the Presentation lifecycle remain separate. The association is a generic exact Object reference/relationship, not a Business-specific presentation collection or a second persistence mechanism:
Business
└── Dashboard Presentation Object
├── People Presentation Object
├── Marketing Presentation Object
├── Sales Presentation Object
└── Projects Presentation Object
The Dashboard and every descendant are ordinary persisted Presentation Objects. The hierarchy is recursive, preserves exact Object and revision identity, and may reference permitted Data, Workflow and Logic Objects or a bound_object. The Dashboard is distinguished only by data-defined root configuration/association; it is not a special Type, renderer or route.
Primary navigation is derived from the Dashboard's direct child Presentation Objects, while clicking Dashboard renders the Dashboard itself. A child is not intrinsically a menu item: navigability, label, order, icon, visibility, target and other behavior are data-defined properties of that child. Thus a Dashboard may contain navigable People and Marketing children alongside non-navigable KPI Summary, Recent Activity or Alerts content. The generic runtime must not branch on People, Marketing, Sales, Projects, Dashboard or any other business-domain name.
The runtime presentation representation is a renderer-neutral recursive composition of resolved generic elements. A renderer may translate kind, role, content, children, ordering, layout, behavior and target into a delivery format, but it must not decide that a field is a heading, badge, button, card, navigation item or domain-specific control. The bounded recursive element contract is implemented and verified through the generic projector and renderer tests.
Four Semantic Object Roles
Idiosyncrasy has exactly four semantic object roles: Data, Logic, Workflow and Presentation. These roles express the business meaning of objects within the existing universal object model; they are not values of the D02 Type system:
IDIOSYNCRASY
|
GLOBAL OBJECT MODEL
|
+---------------+---------------+
| | | |
DATA LOGIC WORKFLOW PRESENTATION
| | | |
+-------+-------+-------+
|
COMPOSITION
|
GOVERNED EXECUTION
These are semantic classifications within the existing universal object model. They are not values of the D02 Type system, storage systems, database schemas, application subsystems or replacements for the kernel. The type continues to identify domain meaning through D02; domain Types such as Business, Customer, Invoice and Workflow Definition remain valid. The existing {id, type, value} primitive, object identity, types, revisions, relationships, authority, mutation, Commands, Attempts, Outcomes, provenance, Events, validation and execution contracts remain in force.
The four roles are sufficient because complexity is created through recursive composition rather than an expanding taxonomy:
- **Data Object** represents a value or piece of state.
- **Logic Object** represents deterministic evaluation or controlled transformation.
- **Workflow Object** represents a human action or interaction.
- **Presentation Object** represents model-defined presentation structure and content.
The word role is deliberate. D02 type definitions continue to identify domain vocabulary and to validate typed values. Execution and audit records such as Workflow Execution, Command, Attempt, Outcome, Event and provenance remain addressable objects under the same kernel. Their infrastructure identity or D02 type does not create additional semantic roles. A Definition describes configured behaviour, evaluation, data or presentation; the corresponding role is the semantic interpretation of a composed Object.
The roles compose without a fixed presentation hierarchy. A Presentation Object may recursively contain or reference Presentation, Data, Logic and Workflow Objects. Presentation-role constituents define the visible structure; Data remains authoritative for business information; Logic may resolve derived, filtered, aggregated or context-relative values; and Workflow may expose governed interaction or process behavior. A reusable Presentation Object may therefore be projected against different current Object contexts without persisting a separate presentation graph for each business record. Collection and repeated-record resolution are generic mechanisms that may be used by this composition, not the definition of Presentation or a competing object model.
The former Capability Definition and Business Capability Instance model is retired from the current architecture. Existing terminology, Types, handlers, projectors, fixtures and routes carrying that name are legacy implementation material or historical evidence and are not inputs to new runtime work. Current Business composition is expressed directly through ordinary Objects, Relationships, Definitions, Configuration, Authority, Operations and Presentation Objects. No replacement Capability construct is authorized.
Data Object and current value
A Data Object's current value is either a concrete value or an object reference. A concrete value can be a primitive or a permitted nested value. An object reference can point to a Data, Logic, Workflow or Presentation object:
Data Object
current value
|
+-- primitive or static value
+-- reference -> Data
+-- reference -> Logic
+-- reference -> Workflow
+-- reference -> Presentation
The reference is the value itself. There is no separate initializer, source, computed-field, dynamic-field, default-provider, resolver or value-provider property in the semantic model. For example:
Customer.account_number
value = -> Logic: Generate Account Number
When the Logic produces CU-10482 through the governed execution path, the current value may become:
Customer.account_number
value = "CU-10482"
The earlier Logic reference is not a permanent binding. A later governed operation may replace the value with another primitive, a Data reference, a Workflow reference or a Logic reference. Revisions and provenance preserve what happened; they do not turn historical origin into current semantic state.
A reference does not mean "execute this object immediately." It means "the current value is this object." When a concrete value is required, dependency traversal may inspect the referenced object and its permitted dependencies, determine whether concrete Data is available, identify a Workflow requirement or determine that an explicit governed operation is required. Traversal itself does not execute Workflow or Logic; any required execution occurs only through the explicit authority, Policy, Command and evidence boundary below.
Reference authority and bounded dependency resolution
The governing boundary is:
REFERENCE != DEPENDENCY != EXECUTION != AUTHORITY
A Data value may reference Data, Logic, Workflow or Presentation. That reference identifies a value/object relationship only; it grants no read, discovery, traversal, execution, modification, participation or approval authority. Structural Relationships remain distinct: use one when the connection itself requires independently addressable endpoints, meaning, direction or role, cardinality where applicable, metadata, lifecycle, provenance, history or applicability. Ordinary value references must not be silently converted into Relationships. The detailed Relationship and Business-isolation contract remains owned by Business model.
Operation dependencies remain the exact-revision, allowlisted contract in Operation Contract. They do not silently rebind to newer revisions, recursively become another Operation, inherit authority, bypass authorization or become implicit execution instructions. Retrieval may traverse only authorized and contractually permitted references or Relationships; a visible source must never disclose an inaccessible target, and Business isolation applies throughout traversal.
Any future generic traversal must be explicitly bounded by visited object/revision/path tracking, maximum depth, node and edge limits, and evaluation/execution budgets. Cycles or budget exhaustion produce explicit evidence and a bounded outcome such as pause, reject or escalate; they do not create a universal CIRCULAR Data state. Missing, inaccessible, unavailable, unresolved, incompatible and execution-failure conditions remain distinct. Generic retrieval or traversal must never implicitly execute a Workflow or Logic object: execution requires an explicit governed operation/workflow action, current authority and Policy validation, Command admission and retained evidence under Workflows and automation.
Workflow Object and Logic Object
A Workflow Object represents a human action or interaction. Requests and inputs are therefore Workflow Objects, not a separate Request or Input type. Examples include Enter Customer Name, Create Customer, Approve Invoice, Review Segment, Select Customer and Identify Industry.
A Logic Object represents an automated action. Expressions, calculations, comparisons, queries, filters, transformations, collation, ranking, evaluation, aggregation, automated selection/classification, retrieval logic and deterministic business rules are purposes or compositions of Logic, not separate semantic roles. Logic is controlled/declarative platform behaviour, not arbitrary stored executable code.
The roles compose in both directions. Logic may contain Workflow where automation cannot determine an answer uniquely:
Logic: Search Customer
|
+-- Data: Search Term
+-- Data: Target Definition
+-- Logic: Query
+-- Logic: Filter
+-- Logic: Rank
+-- Data: Result Set
+-- Workflow: Select Result
Search is therefore a Logic composition, not a Search Object type. Conversely, a human process may contain automated reasoning:
Workflow: Create Business
|
+-- Workflow: Enter Business Name
+-- Workflow: Identify Industry
+-- Logic: Determine Services
+-- Logic: Determine Operating Model
+-- Workflow: Confirm Configuration
Data can reference any of the four roles, including another Data Object:
Customer.primary_contact
value = -> CustomerContact
Invoice.customer
value = -> Customer
This value/reference mechanism does not replace structural relationships. Where a connection requires independent relationship identity, endpoints, metadata, provenance, history or lifecycle, the existing Relationship contract applies. A current value and a structural relationship are distinct concerns; neither requires a separate relationship-value semantic category.
Composition and progressive Business configuration
Composition is recursive. Objects may contain, reference, use or produce other Data, Logic, Workflow and Presentation objects. A Business can therefore begin with values that are references and progressively acquire concrete values and further structure without a monolithic onboarding workflow or a separate self-configuration engine:
Business
|
+-- name
| value = -> Workflow: Enter Business Name
|
+-- industry
| value = -> Workflow: Identify Industry
|
+-- configuration
| value = -> Logic: Determine Initial Configuration
|
+-- services
| value = -> Logic: Determine Services
|
+-- operating_model
value = -> Logic: Determine Operating Model
For example:
Workflow: Identify Industry
|
v
"Design Agency"
|
v
Business.industry
value = "Design Agency"
The resulting Logic can use that value and compose further dependencies:
Logic: Determine Initial Configuration
|
+-- Business.industry
+-- Logic: Match Business Pattern
+-- Workflow: Do you provide web development?
+-- Workflow: Do you manage retainers?
+-- Logic: Determine Service Catalogue
The resulting Data, Logic, Workflow and Presentation objects become part of the same global object model. Reusable platform definitions and patterns such as Design Agency, Consultancy, Retailer or Manufacturer remain distinguishable from the actual Business data they help configure. This is an emergent property of composition and dependency traversal, not a separate onboarding or knowledge subsystem.
Dependency traversal is contextual
Dependency resolution is a platform capability, not a semantic object type and not a persisted resolution-state graph. The runtime walks only the branch required for the requested result, rather than assuming that every request must resolve an entire Business graph:
Requested Result
|
v
Logic A
|
v
Logic B
|
v
Data X
|
v
Workflow Y
|
v
Human provides value
|
v
Data X obtains concrete value
|
v
Explicit operation evaluates Logic B
|
v
Explicit operation evaluates Logic A
|
v
Requested Result
If the requested result is profitability, the relevant walk may be limited to revenue and costs, including direct, staff and operating costs. It need not resolve unrelated Business data. A required Workflow reference can be exposed as a task or interaction. A required Logic reference can be identified as a dependency; an explicit governed operation may evaluate it only after current authority and Policy validation and Command admission. Traversal itself does not evaluate Logic. An unavailable dependency can be reported with the actionable dependency where appropriate. The dependency graph is calculated for the operation; it is not automatically stored as the Data Object's semantic state.
The canonical resolution pattern is:
Data Object
|
| current value
v
Object Reference
|
+----> Data
+----> Workflow
+----> Logic
|
v
dependency traversal
|
+----> concrete data
+----> Workflow requirement
+----> further Logic
+----> unavailable dependency
|
v
concrete result
|
v
Data Object.value = concrete value
The current value may remain a reference until a concrete result is available. No universal Data Object states such as UNRESOLVED, PENDING, BLOCKED, FAILED or RESOLVED are required. Resolved, legitimately absent, unresolved, incompatible and execution-failure distinctions remain useful execution conditions under the Workflow contract; they must not be confused with a persisted value-state taxonomy. A UI may present a Workflow reference as a To Do, required input, outstanding action or notification, but these are projections of the model.
Value replacement example
Customer.segment
|
+-- initially:
value = -> Logic: Determine Segment
|
+-- after evaluation:
value = "Premium"
|
+-- later:
value = -> Workflow: Review Segment
|
+-- after human review:
value = "Enterprise"
References are values, not permanent computed-field relationships. A resolved value is ordinary current Data. Later replacement is a governed mutation, and the relevant revisions, Commands, Attempts, Outcomes, provenance and Events explain the transitions without being embedded in the current value.
Unresolved dependency example
Customer.account_number
value = -> Logic: Generate Account Number
If that Logic requires Customer.id and Business.code, and:
Business.code
value = -> Workflow: Enter Business Code
then Customer.account_number does not yet have a concrete value. It continues to contain the Logic reference. The dependency walk can expose Workflow: Enter Business Code as the actionable human requirement. It must not add Customer.account_number.status = PENDING merely to describe this execution condition.
Authority, mutation and history
Reference connectivity does not grant authority. A Logic or Presentation reference to another Logic or Workflow object permits discovery of a dependency subject to access rules; it does not authorize execution, modification, participation or approval. The server-resolved authority model remains authoritative, and browser-supplied dependency or permission information cannot alter it.
Every change to a Data Object's value, including replacement by a primitive or reference, continues through the one governed mutation path. UI, API, Workflow and AI-assisted changes converge on the existing validation, authority, Command, Attempt, Outcome, revision, provenance and Event boundaries. Current value remains minimal. Questions about origin, actor, command, time or producing Workflow/Logic belong to retained history and provenance, not extra current-value metadata.
Optional AI and infrastructure distinctions
AI may propose or refine Data, Logic, Workflow and Presentation definitions, interpret a Business description, suggest a Business pattern or help construct a composition. It is optional and may not become a foundational execution dependency. Proposed output remains untrusted until Idiosyncrasy validation, authority, approval and governed execution accept it. AI is not an AI Object, Intelligence Object, Knowledge Object, Reasoning Object or Agent Object semantic type.
The model deliberately does not make Request, Input, Form Field, Computed Field, Dynamic Field, Initializer, Calculation, Search, Query, Automation, Intelligence, Knowledge, Configuration, Initialisation, Trigger, Event or To Do additional semantic roles. These names may still identify infrastructure records, definitions, execution responsibilities, projections or audit evidence under their canonical owners. For example, an Event record remains valid Event infrastructure; it is not a fourth business semantic role. A CLI initializer may remain a chosen installation mechanism; it is not a Data value-provider concept.
External side effects remain governed by the existing Command -> Attempt -> Outcome -> Provenance/Event architecture. Logic definitions are declarative/controlled and must not become eval(), arbitrary PHP, arbitrary scripts or unrestricted stored code.
Execution concerns that remain implementation questions
The four-role model does not settle every runtime mechanism. The implementation must still define, under the existing owners, how to:
- detect and bound circular dependency walks such as `Logic A -> Logic B -> Logic A`, report the chain and pause/reject/escalate without persisting a `CIRCULAR` semantic state;
- handle competing mutations such as two Logic objects or a Workflow and Logic attempting to change one Data Object, using revisions, optimistic concurrency, Command ordering, Attempts, Outcomes, retries and stale-reference checks;
- distinguish reference values from structural Relationship objects and resolve each through the appropriate existing mechanism;
- choose the exact contextual traversal, caching/materialization and evaluation mechanics without storing a universal dependency graph as object state; and
- define exact execution timing, including when a reference is required, evaluated, replaced or retained after an unavailable dependency.
These are execution, mutation, relationship and implementation contracts. They do not justify a new semantic object role, a new resolver subsystem, a universal resolution state machine or an alternative mutation path.
Semantic invariants
The following invariants are architectural:
1. There are exactly four semantic object roles: Data, Logic, Workflow and Presentation; they are not D02 Type values. 2. All four roles exist within one global object model. 3. A Data Object's current value may be concrete or an object reference. 4. The reference itself is the current value; no separate initializer concept is required. 5. A reference may point to Data, Logic, Workflow or Presentation. 6. A referenced object may contain further references recursively. 7. Dependency resolution is a platform capability, not a semantic object type. 8. Lack of a concrete value does not require a persisted resolution state. 9. A referenced object may produce a concrete result that becomes the Data Object's new value. 10. A later governed operation may replace that value with another primitive or object reference. 11. Authority is independent of semantic role. 12. A reference does not grant authority to execute or modify its target. 13. History and provenance are independent of the current semantic value. 14. AI is optional and is not required for core platform operation. 15. External side effects remain governed by the existing execution architecture. 16. Circular dependency handling is an execution concern, not an additional semantic role. 17. Competing mutations and concurrency are execution/mutation concerns, not an additional semantic role.
Foundational Invariants
Objects and identity
1. Everything persistently addressable uses the universal object model. Independently identifiable definitions, relationships, workflow components, conditions, configuration, events, evidence and history are objects under the same model. 2. An object has identity independent of its current data. Adding, changing, removing or replacing data does not by itself destroy the object. 3. Objects may be empty, arbitrary and recursively composed. A definition is not required for an object to exist. 4. Constituents may themselves be objects. A containing object's meaning and condition can depend on its constituents without creating a second foundational model. 5. A scalar or nested value remains valid when it does not require independent identity, reuse, provenance, history or lifecycle. Addressability is determined by meaning and governance, not by a rule that every property must become an object. 6. Object identity must not be replaced by display labels, generated names or copies such as Name_1. Revisions identify successive versions of the same object.
Containment, reference, revision, Type and semantic role are distinct. An Object may contain another Object, be contained by another Object, or reference an Object without changing either Object's identity or assigning a new semantic Type. Independent identity is required only where reuse, relationships, provenance, history, lifecycle or another documented authority reason requires it. Data, Workflow, Logic, Relationship, Presentation and Configuration describe how an Object participates in the model; they are not separate Object systems or mandatory classifications. One Object may participate in several of those descriptions at once.
Objects and types owns the universal primitive, addressability, typed validity, Type definitions and State identity.
Definitions and configuration
A definition is an addressable object that describes an intended or recognised configuration. It may contain, reference or relate the complete recursive composition required to define and operate what it describes: constituents, relationships, values, constraints, dependencies, applicable state characteristics, workflows, Logic, Operations, presentation configuration or other Definitions. A reusable Definition is a composition/template, not a list of Types, Operations and Views. The Objects participating in that composition remain ordinary universal Objects and may themselves contain further Objects.
Definitions are descriptive rather than universally prescriptive:
- Actual object configuration is the authority for what currently exists.
- A definition can exist without every instance adopting it.
- An object can exist without a definition.
- A candidate or suggested definition is not an adopted definition.
- Adoption is an authorized configuration decision represented by a new revision and retained history.
- A later definition does not automatically migrate existing instances.
Configuration is object data assembled from objects, constituents, relationships, definitions, values, state, workflows and revisions. It does not require a separate universal configuration subsystem. A Definition describes or configures an object's composition of Data, Logic, Workflow and Presentation roles and its relevant constituent structure; the Definition is not an additional semantic role and is not merely a runtime composition. Type definitions, Operation Contracts, Policies, Views, Forms and Workflow Definitions remain distinct kinds of governed configuration even though they share the object foundation.
Definitions may evolve independently from instances. The platform may discover patterns, propose improvements or present candidate definitions, but a suitably authorized human or governed deterministic process must decide whether an instance adopts one. AI may assist discovery and explanation; it cannot silently select or apply authoritative configuration.
The adoption boundary is explicit: when Definition B emerges, an instance remains bound to Definition A until an appropriately authorized human decision or governed deterministic decision adopts or reconfigures it. Adoption binds the selected definition revision, records the resulting object revision and preserves the prior binding and causal history. Definition discovery, suggestion, publication or installation alone never performs adoption; migration or reconfiguration is a separate future detailed contract.
The foundational Definition lifecycle is therefore: discover or author a candidate; validate and govern its descriptive structure; publish or make the applicable revision available; select/apply it for a Business or configured composition; resolve its requirements against actual Business objects and relationships; use the resulting configuration; and propose later revisions or changes for explicit review. These stages are distinct conclusions and operations, not a universal Definition status field. A platform-owned Definition remains distinct from a Business's application/instantiation, Business-specific configuration, actual object instances and later Definition revisions. Applying a Definition does not mutate the platform Definition or copy Business-scoped configuration into platform scope. Definition identity/revision and release or publication provenance remain distinct retained evidence. No parallel definition graph bypasses normal identity, revision, authority, provenance or mutation boundaries.
Platform Definition publication is a distinct governed mutation that makes one exact Definition Object revision available. It does not establish a universal Definition status field, replace Object identity/revision with a release identifier, or apply/adopt the Definition for a Business. The generic platform Operation is definition.publish; its Operation, authorization and Command contract is owned by Operation Contract. Human publication authority is owned by Identity and Governance.
definition.publish accepts one complete, validated Definition payload using the universal OBJECT_DEFINITION_TYPE, including platform User, Business and other constituent Definitions. It creates a new Definition Object or revises an existing Object at the exact expected revision. The Object mutation, publication availability of that exact resulting revision, and required provenance/evidence form one atomic governed outcome. Object identity/revision remains distinct from Definition payload fields, Type identity/revision and publication evidence. Inline recursive composition remains valid. Each separately addressable Definition dependency must already be publication-available at the exact referenced revision before a dependent Definition is published. Dependency inspection is bounded and non-executing.
The established project-owner User (a platform account; the User Type is persisted under the legacy name Principal) receives the narrow direct platform AuthorityGrant and matching active Policy for definition.publish through normal platform installation/configuration. This does not create or self-authorise a User, add authority to Genesis, or introduce a bootstrap protocol. Publisher reassignment and revocation are deferred. Identity and Governance owns this permission boundary.
Draft authoring is outside publication. Publication does not instantiate a Business, apply a Definition to a Business, migrate instances, execute Workflow or Logic, or perform Genesis, Initialization, platform opening, Explorer projection or IDY-008 application. Business application remains separate and binds an exact Definition identity/revision. Manifests do not establish publication authority.
Candidate A is the only Definition reference representation: {kind: "object_reference", id: <Object ID>, revision: <positive exact Object revision>}. The exact target Object revision supplies its Type identity and Type revision. Inline constituents remain nested typed values with no independent identity. Requiredness and compatibility are determined by the applicable Type descriptor. Missing, inaccessible, incompatible or unpublished Definition dependencies fail closed; no latest-revision fallback is allowed. Structural traversal is bounded, rejects cycles and never executes Workflow or Logic.
Definitions may identify required, optional, unresolved, conflicting or not-yet-configured constituents without creating placeholder instances or artificial completeness flags. A containing object may be meaningful while empty or partially configured. Normal Data, Workflow and Logic execution can establish, modify, replace or remove constituents where the applicable object and governance contract permits it; constituency is not a capability-specific adoption or membership subsystem. The applicable condition is derived from the Definition revision, actual constituents, relationships, values, evidence, authority and context. Useful concepts such as valid, not yet configured, unresolved, unavailable, unknown, stale, conflicting or awaiting human determination remain contextual interpretations, not a mandatory universal State enumeration.
Business model owns Business DNA and configuration assembly. Semantics owns Rule, Policy, Constraint, Goal and Decision meanings. Workflows and automation owns executable workflow configuration. Views and content owns presentation definitions.
Assignment semantics
Retained-reference and resolved-value assignment are two semantics of the same underlying assignment/mutation mechanism, not separate variable, binding or calculated-field systems:
- A **retained reference** keeps the relationship to the source object authoritative. The current value of the assigned object is derived or evaluated from that source, so a later source change can produce a corresponding current result without another assignment.
- A **resolved assignment** evaluates the source at assignment time and replaces the retained source relationship with the resulting value. A later source change does not alter that value until another governed mutation changes it.
Either form may later be replaced by a Data, Logic, Workflow or Presentation mutation. A resolved value should retain provenance and causal evidence identifying its source object, relevant event or execution, authority and definition/revision where the existing provenance model supports that evidence. Retaining that evidence does not preserve dynamic dependence on the source. The current object value and its historical explanation remain distinct.
Values and derived state
A value may be present, absent, changed, removed, unresolved or replaced. These words describe the value or an execution condition in context; they are not a universal persisted Data Object state taxonomy. Value presence is not semantic validity, and absence is not automatically an error. Resolution depends on the object, applicable definition, relationships, workflow requirements and context.
The cross-cutting rule is: store facts, evidence, relationships and history; derive conclusions and conditions from them rather than introducing duplicated classifications or flags. A conclusion such as whether a Business exists, participates in a network, has an associated User, can be represented by a User, has operational entitlement, or permits a particular operation is derived from the authoritative objects, relationships, authority, entitlements, applicable Policy, events and history in context. None of those conclusions requires a universal Business lifecycle state or a combined claimed, recognised, authorised, subscribed or remaining field. Likewise, the commercial conditions Subscribed, Unsubscribed, never-activated and lapsed, and the Licensed/Guest classification, are derived from entitlement evidence and history and are never stored lifecycle fields (intended future architecture; all Businesses are currently treated as active and no entitlement is enforced); see derived commercial conditions. Licensed status never grants authority.
State is the derived current condition of an object. It is not an independently authoritative field and there is no universal kernel status vocabulary. An implementation may materialize or cache state, but the materialization cannot override the underlying object condition.
The same rule applies to relationship participation, authority availability, workflow conditions, capability presence, capability access depth, analytics and UI projections. A materialized determination or index may improve performance or discovery, but it is a replaceable projection: the underlying facts remain the semantic source of truth, and a changed fact, relationship, entitlement, AuthorityGrant, Policy or historical correction must be able to invalidate or recompute it. Derived state must not become a second authoritative store or conceal the distinction between information that exists and an operation that is permitted.
A state transition occurs when the derived condition changes. Changes to a value, constituent, relationship, definition, configuration or propagated child condition can cause that transition. Derived state propagates recursively through containing structures; a parent must not require a separately assigned status to reflect a constituent change.
Inheritance describes applicable characteristics through an existing constituent structure. It does not create absent constituents or make optional constituents mandatory. A definition or inherited characteristic applies only where the relevant governed object and relationship exist.
Time and events owns transition occurrences, temporal interpretation and historical state. Views and content owns the distinction between interaction state and business State.
Relationships and graph reality
Relationships are ordinary addressable objects when they need identity, constituents, metadata, provenance, state, history or lifecycle. They can have two or more endpoints and can themselves participate in relationships and workflows. Endpoint data identifies what is related; labels do not replace identity.
The relationship and endpoint graph is descriptive reality. Traversal does not infer authority, semantic equivalence or an unrecorded relationship. A relationship can remain an object when an endpoint becomes unavailable or unresolved. Endpoint loss produces a condition requiring governed resolution; it does not silently destroy the relationship or erase its history.
An absent endpoint may be legitimately inapplicable, unresolved for a required operation or inaccessible under authority. These conditions must remain distinguishable. Possible resolutions include substitution, amendment, removal of relationship data or explicit retirement/destruction under the applicable governance contract.
Business model owns relationship meaning, integrity, cardinality, applicability and Business DNA. Identity and governance owns access to endpoints and relationship metadata.
Deletion, revisions and causality
Ordinary deletion means removal of current data, not destruction of object identity. It does not silently cascade through dependent objects, relationships, provenance or history. Explicit retirement or destruction is a separate governed operation with its own authority and evidence.
Meaningful data and configuration changes produce revisions. Historical revisions remain discoverable to the extent required by the applicable retention and access rules. The current revision does not rewrite the circumstances under which an earlier revision, action or decision occurred.
Causal history must explain not only what changed, but why and through what chain. Where applicable it links the underlying value or object change, Command, Attempt, Outcome, revision, derived-state transition, Event, workflow and subsequent action. Correlation groups related activity but does not prove causation; provenance identifies origin and derivation but does not grant authority.
Time and events owns temporal meaning, revisions, transition occurrences, events, provenance relationships and causal explanation. Workflows and automation owns execution identity, attempts, outcomes, recovery and compensation.
Workflow and Dependency Invariants
Workflows are object configurations describing behaviour in response to conditions, events and state changes. Workflow definitions, nodes, executions, dependencies, commands, attempts and outcomes use the universal model where independently addressable.
Before a dependent operation executes, its required inputs and dependencies must be resolved. The platform distinguishes at least:
- **Resolved:** the dependency exists, is accessible and can be used.
- **Legitimately absent:** the dependency is not applicable or is not required for this configuration.
- **Unresolved:** the dependency is required or expected but cannot currently be resolved.
- **Incompatible configuration:** the workflow is not appropriate for the current object/configuration.
- **Execution failure:** the dependency was resolvable, but the attempted operation failed.
An unresolved dependency is a condition, not a license to invent data and not automatically the same as execution failure. A workflow may request information, invoke a resolution workflow, ask an authorized human, choose a configured alternative or pause. It must not manufacture missing values merely to satisfy its own preconditions. An unresolved condition may produce an event that records the operation, dependency, object, workflow and causal context.
Workflows must be bounded. The runtime should evaluate causal ancestry and configured execution limits before continuing. A detectable cycle must be rejected, paused or flagged for authorized human resolution. A cycle discovered during operation must pause the active execution and preserve enough causal evidence to explain the cycle. No configuration may consume unlimited resources through recursive execution.
Workflows and automation owns dependency evaluation, execution states, cycle handling, retry/recovery and finite runtime boundaries. Time and events owns event and history meaning.
Authority and Human Control
Authority is independent of object description, authorship, creation, ownership labels, relationship membership, assertions, definitions, workflow configuration and AI output. Creating an object or supplying a value does not grant continuing permission to inspect, change, approve, adopt or execute it.
A suggestion is not authority, an authority grant is not adoption, and adoption is not proof that execution succeeded. Permission, approval, configuration adoption, mutation and outcome remain distinct facts. Authority is established only through the explicit identity and governance model and is checked at the authoritative mutation/read boundary.
AI may interpret, ask questions, discover candidate definitions, propose configurations, identify ambiguity and assist resolution. It has no implicit authority. Human-only paths must remain available for the same fundamental configuration and operating processes. AI and human inputs use the same deterministic validation, authorization, approval, mutation, revision and evidence boundaries.
Identity and governance owns authority, isolation, permission, approval and delegation. AI owns optional provider assistance and output validation. Product definition owns the non-overridable runtime foundations.
Initialization and Configuration Boundaries
The following operations remain separate:
Foundation-only Genesis
-> platform opening
-> User registration and confirmation
-> authenticated, bounded onboarding
-> governed business.create
-> Business-scoped configuration installation
-> explicit definition adoption or instance configuration
Foundation-only Genesis establishes generic prerequisites and foundational vocabulary. It creates no human User, Business, Membership, continuing authority or first Business. Platform opening installs approved identity-lifecycle and platform capability descriptors without creating human state. business.create creates a Business and its initial governance through the ordinary governed mutation boundary. IDY-008 installs reusable configuration into an already-existing, governed Business; it does not create identity, authority, a Business, operational instances or automatic definition adoption/migration.
The distinctions above are conceptual contracts. Their physical storage, materialized indexes, workflow interpreter, release packaging, reconciliation and current verification status belong to the implementation owners and must not be inferred from this document.
Owner Map
| Cross-cutting concern | Detailed owner | | --- | --- | | Universal object, Type and State identity | Objects and types | | Business Graph, Relationships and configuration assembly | Business model | | Rule, Policy, Constraint, Goal and Decision meanings | Semantics | | Revision, Event, time, provenance and causality | Time and events | | Workflow dependencies, execution and bounded recovery | Workflows and automation | | Authority, isolation, approval and delegation | Identity and governance | | Optional AI assistance and output validation | AI | | Projection and interaction state | Views and content | | Physical mechanisms and implementation evidence | Implementation architecture, implementation status |
Conformance Boundary
A conforming implementation can represent an empty object, retain object identity after data removal, distinguish actual configuration from intended definition, derive and propagate state, retain unresolved relationships, preserve revisions and causal history, resolve workflow dependencies without fabricating data, stop bounded cycles, and refuse authority inferred from authorship, connectivity or AI output.
A simpler first implementation may support only a bounded subset of these capabilities, but it must preserve the distinctions and fail explicitly where support is absent. Documentation alignment is not runtime evidence. Current implementation limitations and verification results are recorded only in implementation status.