# Object Definitions and Business Configuration Discovery

**Status:** nonnormative discovery record; proposed concepts and open questions only  
**Date:** 2026-09-23  
**Scope:** documentation and architectural discovery  
**Implementation status:** this document records no implementation, schema, migration, deployment, or runtime evidence beyond the repository evidence identified below.

## 1. Purpose and Scope

This document investigates whether reusable object definitions and Business configuration can be expressed through Idiosyncrasy's existing contracts. It does not establish a new `Object Definition` primitive, amend D01-D10, make Type/meta-type behavior user-editable, or approve a candidate catalogue for implementation.

The subsequent [Core Object Model and Platform Authority](../architecture/core-object-model-and-authority.md) contract now settles the conceptual role of a definition: it is an addressable descriptive object where independent identity is required, while Type, State, Relationship Type, View/Form, Workflow, Policy and Operation Contract definitions retain their own owners and meanings. This discovery record remains nonnormative for composition grammar, editor behavior, adoption mechanics and implementation depth.

The proposed hierarchy is treated as a hypothesis:

```text
Primitive value
    -> reusable object definition
    -> composite object definition
    -> Business configuration
    -> object instance
    -> primitive values
```

The discovery question is narrower and more useful than assuming that hierarchy is correct:

> What existing platform objects, Types, relationships, configuration declarations and controlled runtime behavior are sufficient to describe reusable structure, and where would a genuinely new architectural contract be required?

This document distinguishes:

| Label | Meaning in this document |
|---|---|
| **Established contract** | Explicitly stated by a current canonical architecture or implementation contract. |
| **Bounded evidence** | Behavior or structure observed in the current implementation/status record. It does not enlarge the semantic contract. |
| **Derived possibility** | A conclusion that appears compatible with existing contracts, but is not itself approved behavior. |
| **Hypothesis** | A proposal to test in later discovery, not a decision. |
| **Open question** | The current evidence does not determine the answer. |
| **Architectural decision required** | A choice that would change or materially constrain the existing semantic contract and needs explicit approval. |

### Non-goals

This record does not:

- implement definitions, configuration editing, migrations, schema changes, APIs, UI or runtime behavior;
- create a new Type, meta-type, engine, module system or mutation mechanism;
- make platform Type/meta-type machinery user-editable or executable;
- turn the candidate vocabulary into a release plan or implementation backlog;
- assume that every business capability can be reduced to typed data;
- treat AI as necessary for authoring or applying configuration; or
- authorize staging or production deployment.

## 2. Existing Architectural Foundations

The governing route is already established:

- [D08 - Configuration, Definition & Extensibility](../governance/decisions.md#d08---configuration-definition-extensibility) is settled and routes extensibility to [Product Definition](../product/definition.md#composition-and-extensibility), [Objects and Types](../architecture/objects-and-types.md), and [Business Model](../architecture/business-model.md#business-dna).
- [Objects and Types](../architecture/objects-and-types.md) owns the universal `id + type + value` model, addressability, typed validity and the Type-of-Type validation boundary.
- [Business Model](../architecture/business-model.md) owns the connected Business Graph, relationships and Business DNA. It explicitly rejects a separate DNA store or a capability-owned duplicate object model.
- [Identity and Governance](../architecture/identity-and-governance.md) owns Principal, Business context, isolation, authority, approval and delegation.
- [Views and Content](../architecture/views-and-content.md) owns model-projection UI and the distinction between editing values, interaction state and authoritative business state.
- [Operation Contract](../architecture/operation-contract.md) owns reusable business capability definitions, exact revision binding and trusted runtime handlers. An Operation is not a permission, Policy, Workflow or executable configuration.
- [Workflows and Automation](../architecture/workflows-and-automation.md) and [Time and Events](../architecture/time-and-events.md) own execution, attempts, outcomes, effects, events and historical meaning.
- [IDY-008](../implementation/idy-008-contract.md) specifies reusable, versioned Business-scoped configuration installation through the existing Command boundary.
- [AI](../architecture/ai.md) and the product's [AI-supported, not AI-dependent principle](../product/definition.md#ai-supported-not-ai-dependent) require a deterministic manual path and prevent provider output from becoming authority.
- [Core Object Model and Platform Authority](../architecture/core-object-model-and-authority.md) owns the cross-cutting distinction between actual graph reality, descriptive definitions, derived State, revisioned adoption and explicit authority.

The architecture therefore contains several related definition meanings under one object foundation. The word `definition` is a cross-cutting descriptive role, not one additional universal primitive or interchangeable class. Exact ownership, validation, adoption and execution meaning remain category-specific.

## 3. Discovery Chain: What Already Exists?

The requested chain can be stated using current contracts without assuming a new layer:

```text
Generic addressable Object foundation
    -> Type identity and retained revision
    -> Business-scoped typed configuration (including IDY-008 declarations)
    -> relationships and exact references between configuration objects
    -> View/Form projections for human editing
    -> fixed Operations, Workflows, Policies and Command commit behavior
```

| Stage | What is explicitly supported | What appears possible | What is not evidenced or is unresolved |
|---|---|---|---|
| Generic Object foundation | Persistent/addressable data uses `{id, type, value}`; independently identifiable configuration may be addressable. | A reusable definition is represented by an ordinary addressable object or an owner-specific Type-governed descriptor where independent identity is needed. | No separate universal `Object Definition` primitive is established; category-specific adoption remains open. |
| Type / revision | Types are first-class addressable definitions; typed values and retained object revisions are distinct. | A definition can bind to an exact Type and revision, then be referenced by configuration or instances. | The precise binding required by each definition category remains implementation/contract detail, not an unresolved foundational model. |
| Business configuration / IDY-008 | Reusable releases install Business-scoped `type`, `state`, `transition`, `relationship_type`, `policy`, `view`, `form`, `workflow` and `workflow_node` declarations through governed Commands. | A definition catalogue could be packaged as reusable release content and installed into an existing governed Business. | IDY-008 does not define a general nested-definition composition language, instance seeding, or a user-facing definition editor. |
| Composition | Types can declare properties; relationships can connect addressable objects; configuration can reference exact objects/revisions. | Composite structures may be expressed through typed properties plus explicit relationships and dependencies. | Inheritance, collections, recursive definitions, defaults, extension semantics and compatibility rules are not fully specified as one model. |
| Reuse | Addressability, exact references, Business scope and release-local IDs support reuse patterns. | Reuse may use canonical references, packaged releases or Business-specific composition. | Whether reuse means reference, inheritance, copy, extension or some combination remains open. |
| Editable representation | Views and Forms project authorized model data and submit Operations; IDY-008 includes view/form declarations. | A generic configuration editor could render permitted definition metadata and route changes through the existing mutation boundary. | Generic definition-editing controls, permissions, approval flow and impact previews are not evidenced as a complete feature. |
| Platform behavior | Commands, Operations, Workflows, Policies, validation, authority, provenance and events remain controlled runtime responsibilities. | A configuration can select and parameterize supported behavior. | Arbitrary behavior, new handlers, reporting semantics and external effects cannot be inferred from data definitions. |

**Interpretation:** the architecture establishes a substantial definition/configuration layer as typed, addressable and versioned data without requiring a separate universal Definition type. It does not require all definition categories to be represented identically; ownership, validation, adoption and execution remain category-specific and implementation evidence is still bounded.

## 4. Generic Object and Revision Model

### Established contract

[Objects and Types](../architecture/objects-and-types.md#universal-primitive) defines one foundational representation:

```text
{
    id: <unique address>,
    type: <semantic type>,
    value: <typed/configured value>
}
```

The same conceptual model covers Business objects, Types, relationships, configuration, workflows, views, policies, events and evidence. A nested scalar remains valid when it does not need independent identity, reuse, relationships, provenance, history or lifecycle. A value that does need those properties should be addressable rather than silently duplicated.

The semantic contract also distinguishes:

- a semantic object from its primitive properties;
- a Type definition from an ordinary instance value;
- a State definition from a subject's State reference and from a transition occurrence; and
- an addressable Workflow Node revision from a Workflow Definition revision that binds to it.

The chosen implementation maps this model to generic object/revision storage, but [Implementation Architecture](../implementation/architecture.md) remains the mechanism owner and [Implementation Status](../implementation/status.md) owns evidence. The status record says the new universal runtime is not complete even though bounded generic object, configuration, graph, UI and operation slices have evidence. That distinction matters here: bounded implementation evidence does not prove a complete definition system.

### Definition roles without adding a primitive

The word `definition` may describe a role played by existing objects, for example:

- a Type definition describing valid instance structure;
- a State, Transition, Relationship Type, View/Form, Workflow, Policy or Operation Contract object;
- a Business-owned configuration object assembling references to those definitions; or
- a reusable release containing declarations that install such objects in a Business.

This vocabulary is useful, but these objects do not automatically become one interchangeable class. Their owners, validation rules, authority, lifecycle and execution meaning remain distinct.

### Evidence and boundary

| Question | Existing evidence | Interpretation | Confidence | Open issue |
|---|---|---|---|---|
| Can a reusable definition be addressable? | Addressability applies to independently reusable/configurable data in [Objects and Types](../architecture/objects-and-types.md#addressability-and-values). | Yes, as a derived possibility where independent identity is needed. | High | Which definition categories need independent identity rather than nested typed values? |
| Can an instance retain the definition context used? | Object revisions retain Type identity/revision; historical references are explicit in the architecture. | A definition-aware instance could bind to exact definition/Type revisions if the relevant contract requires it. | Medium | Whether instances bind to a definition revision, a Type revision, or both is unresolved. |
| Does generic persistence itself create definition semantics? | The universal model is representation, not a complete domain contract. | No. Storage does not decide composition, reuse, permission or execution behavior. | High | Which semantic owner should define each future definition category? |

## 5. Type and Platform-Controlled Meta-Type Boundary

### Established contract

[Objects and Types](../architecture/objects-and-types.md#first-class-types) makes Type definitions first-class addressable objects. The Type-of-Type descriptor is the validation boundary for Type definitions. A `kind: type` configuration declaration supplies a Type descriptor as its value; it is not an ordinary closed object instance with an arbitrary nested `value` field.

The Type contract can describe required and optional properties, valid value structure, validation rules, permitted relationships, applicable States/transitions, permission declarations, UI representation, workflows and type-family membership where supported. It explicitly says that Type/lifecycle configuration cannot redefine the runtime semantics that validate, authorize, record and commit use of the configuration.

[Product Definition](../product/definition.md#non-overridable-foundations) reinforces that a Business may define previously unanticipated concepts within the universal model, but cannot redefine or disable foundational authentication, authority, provenance, state-transition, Policy-enforcement or commit-integrity semantics.

### Discovery conclusion

A prospective reusable definition mechanism must operate below or alongside the platform-controlled Type/meta-type boundary, not by making Type or Type-of-Type behavior arbitrary user code. At minimum, it would need to:

1. use the existing Type descriptor and validation rules for any user-authored structure;
2. preserve platform ownership of Type identity, descriptor interpretation and meta-type validation;
3. keep typed validity separate from authorization and Policy;
4. reject unsupported composition declarations instead of inventing defaults; and
5. retain exact Type/revision references where configuration or execution depends on a particular contract.

This does **not** decide whether a future user-facing editor may author Business-owned Type declarations through a governed configuration workflow. It only identifies the boundary such an editor would have to respect. A user-facing editor for Type declarations would be a new governed capability, not permission to make the meta-type machinery user-editable in the broad sense.

### What is not currently supported or evidenced

The repository does not establish:

- a general-purpose public Type designer;
- an arbitrary user-defined meta-type system;
- executable Type definitions;
- automatic inheritance or structural subtyping;
- automatic migration of instances when a Type changes; or
- a universal compatibility algorithm for all Type revisions.

These absences are open implementation or architecture questions depending on the desired behavior. They must not be filled by treating the Type descriptor as an unrestricted programming language.

## 6. Business-Scoped Configuration and IDY-008

### Established contract

[Business Model](../architecture/business-model.md#business-dna) defines Business DNA as linked definitions and configuration inside the same Business Graph. It is not a second store or a monolithic DNA record. Business-specific configuration can include terminology, Types, relationships, lifecycle declarations, Policies, workflows, views/forms, permissions and integration configuration, each interpreted by its responsible owner.

The [IDY-008 contract](../implementation/idy-008-contract.md#purpose-and-invariants) provides a concrete bounded mechanism:

- configuration is addressable typed data;
- a trusted release has `manifest_id`, `version`, `release_id` and `declarations`;
- a release contains no target Business, Principal or authority identity;
- the target Business is resolved from authenticated/server-governed context;
- supported declaration kinds include `type`, `state`, `transition`, `relationship_type`, `policy`, `view`, `form`, `workflow` and `workflow_node`;
- declarations are validated before mutation, dependency-ordered and bound to exact references where required; and
- installation compiles to individually governed Commands through the existing mutation boundary.

IDY-008 deliberately excludes Business creation, identity lifecycle, authority bootstrapping, operational records and seeded relationship instances. The Business must already exist through governed `business.create`, with Membership, AuthorityGrant and Policy context established separately. [Identity and Governance](../architecture/identity-and-governance.md#business-creation-and-administration) and [D01/D08](../governance/decisions.md#d08---configuration-definition-extensibility) are therefore constraints on any definition assembly proposal.

### Platform capability versus Business configuration

The current model supports a useful distinction:

| Capability layer | Meaning | Current route |
|---|---|---|
| Platform foundation | Universal identity, Type validity, isolation, authorization, revision/history, Command integrity and controlled runtime behavior. | D01-D10 and their canonical owners. |
| Reusable configuration content | Declarations that can be packaged, verified and installed for an existing Business. | IDY-008 release and dependency contract. |
| Business-owned configuration | The Business's selected vocabulary, relationships, Policies, views, forms, workflows and terminology. | Business DNA and Business-scoped objects. |
| Operational instances | Actual enquiries, projects, invoices, people, products or other records. | Normal Business-scoped objects and governed mutations; not seeded by IDY-008 by default. |

The phrase “enabled capability” is not yet a single established object. It could refer to an installed declaration, an active Business configuration, a permitted Operation, a View/Form availability projection, or a combination. Choosing one meaning would require further contract work.

## 7. Definition Composition

### What existing contracts can express

Composition can plausibly be assembled from existing mechanisms:

- **Typed properties:** a Type descriptor can declare fields and nested typed value structure.
- **Addressable references:** a property or configuration declaration can refer to an independently managed object where identity, reuse, history or lifecycle matters.
- **Relationships:** a Business Relationship Type can define endpoint types, direction, cardinality, slots and lifecycle/integrity semantics. Relationships remain distinct from authority.
- **Dependencies:** IDY-008 declarations and Operation Contracts use explicit dependency references and exact revisions.
- **Lifecycle:** Types may identify applicable States/transitions; workflows and Operations provide controlled execution for changes.
- **Validation:** typed validity, relationship integrity, current versions, authority and Policy are separate checks.
- **Business scope:** configuration and operational objects must preserve authorized Business isolation.
- **Evidence:** consequential changes use Command, Action Execution/Attempt, Outcome, Provenance and Event/history contracts.

A conceptual example such as `Product -> Price -> Money` can therefore be read as a possible combination of a Product Type, a Money Type, a Decimal property, a Currency reference/value and any required relationship or validation declarations. This is an interpretation for discovery, not an approved field layout.

### Composition questions not answered by current contracts

The existing documents do not select one universal representation for:

- embedded structure versus addressable nested object;
- single versus multiple values and collection ordering;
- required versus optional properties and default values;
- recursive definitions and cycle handling;
- inheritance, mixins, composition or extension;
- whether a relationship slot is represented inside a Type, by a Relationship Type, or both;
- definition-level versus instance-level lifecycle;
- compatibility of changed property constraints; or
- whether a definition's revision must be adopted explicitly by each Business or instance.

Some of these can be resolved as implementation specifications within existing contracts; others would materially affect Type, revision, Business DNA or migration semantics and would require explicit architectural approval.

### Composition boundary table

| Question | Existing evidence | Derived possibility | Status |
|---|---|---|---|
| Can `Money` be nested in another value? | Scalar and structured values may remain nested when independent identity is unnecessary. | Yes, if the Business does not need Money identity, reuse, lifecycle or independent history. | Possible, not mandated. |
| Can `Money` be independently reused? | Independently reusable configuration/object concepts may be addressable. | Yes, through a dedicated Type/object and explicit references. | Possible, subject to a concrete contract. |
| Can `Product` contain a collection of component definitions? | Types and relationships support structure and connections in principle. | Likely expressible through typed collection values and/or Relationship Types. | Hypothesis; collection semantics are open. |
| Can recursive structures be accepted? | No general recursive-definition contract is identified. | Only if cycle validation, depth/termination and lifecycle semantics are explicitly specified. | Open. |

## 8. Definition Reuse

### Reuse models to investigate

The architecture supports several distinct meanings that must not be collapsed:

| Reuse model | Meaning | Benefits | Risks/open consequences |
|---|---|---|---|
| Canonical reference | Multiple configurations or instances refer to one addressable definition and exact revision. | Preserves shared identity, provenance and one authoritative lineage. | A definition change may affect future resolution; adoption and compatibility must be explicit. |
| Composition | A composite definition refers to reusable component definitions without copying them. | Keeps components independently governed and reusable. | Requires dependency, cycle, scope and compatibility rules. |
| Inheritance/extension | A definition derives from another and adds or restricts structure/behavior. | May reduce repetition and express domain specialization. | Needs precedence, substitutability, validation and revision semantics not currently settled. |
| Copy/version | A new definition starts from an existing one but has independent identity and later evolution. | Allows deliberate divergence and Business ownership. | Provenance, source lineage, drift and change impact must remain visible. |
| Packaged release | A trusted release installs a set of declarations into each Business with deterministic runtime identities. | Reusable distribution without sharing Business-owned runtime identity. | Installation, upgrades, partial failure and reconciliation are governed by IDY-008; it is not automatic inheritance. |

### What is already constrained

[Business Model](../architecture/business-model.md#assembly-and-business-ownership) says an assembly may select reusable platform definitions and add Business-owned vocabulary, workflows, views and knowledge relationships. It also says reuse does not transfer authority or overwrite Business-specific definitions. [IDY-008](../implementation/idy-008-contract.md#release-local-identity-and-runtime-binding) separates release-local declaration identity from the Business-bound runtime identity.

[Operation Contract](../architecture/operation-contract.md#5-lifecycle-and-revision-binding) requires exact revision binding for every execution surface and forbids silent rebinding to a newer revision. The same principle is a strong existing constraint for any definition consumed by consequential behavior, but applying it to all instances is not yet decided.

### Change after reuse

The current architecture establishes retained revisions, explicit historical references and no silent rewriting of prior meaning. It does not answer all adoption questions. In particular, a future definition system would need to decide whether:

- existing configurations remain pinned to the exact definition revision;
- a Business can opt into a newer compatible revision;
- a new Business configuration revision is created when adopting it;
- existing instances remain valid, require migration, or can be interpreted under the old definition;
- incompatible changes are rejected before publication; and
- deprecated definitions remain usable for historical reads but unavailable for new instances or edits.

These are not merely packaging details if they change the meaning or validity of durable Business data. They are open questions below.

## 9. Configuration as an Editable Representation

### Three editing activities that must remain separate

1. **Editing object values:** changing an instance's current typed values, subject to Type validity, authority, Policy, expected version and Command commit.
2. **Editing a definition/configuration:** changing the structure, relationships, lifecycle or declared configuration that future or existing objects may use, subject to its own authority, revision, approval and impact rules.
3. **Assembling Business capability:** selecting or installing reusable configuration for an existing Business, subject to Business context, configuration authority, dependency checks and reconciliation.

A form that edits a Customer's `name` is not a Type editor. A form that enables a Product configuration is not permission to create Product instances. A visible action is not authority.

### Existing UI and mutation boundary

[Views and Content](../architecture/views-and-content.md#viewui-contract) establishes model-projection UI: views and forms select permitted information and actions, validate at the server, reference approved Operation revisions where applicable and submit through the shared Command boundary. They cannot grant authority, broaden Business scope or bypass Policy.

This supports a **derived possibility** for a generic definition/configuration editor with controls for labels, property declarations, references, lifecycle metadata and selected capability configuration. Such an editor would still need:

- a platform-approved definition/configuration vocabulary;
- authorized retrieval of the relevant Business and dependencies;
- deterministic validation and unsupported-declaration rejection;
- explicit distinction between draft/proposed and active configuration;
- revision and optimistic-concurrency handling;
- impact and dependency inspection before approval where required;
- exact Operation references for state-changing actions; and
- Command, provenance, event and outcome evidence for committed changes.

The current repository does not evidence a complete generic definition editor or a universal editor permission model. The existing target UI evidence is a bounded presentation and admission slice, not proof of this future surface. [Implementation Status](../implementation/status.md) must remain the authority for what is built and verified.

### Manual and AI-assisted paths

The manual path is the baseline:

```text
Authorized human
    -> definition/configuration editor
    -> deterministic validation
    -> authority/Policy/approval checks
    -> Command
    -> commit and evidence
```

An optional AI-assisted path may prepare a proposal:

```text
Authorized human request
    -> authorized context assembly
    -> AI proposal
    -> human review/edit
    -> deterministic validation
    -> authority/Policy/approval checks
    -> same Command path
```

[AI](../architecture/ai.md#validation-of-every-output) requires provider output to remain untrusted proposed material. AI cannot provide permission, approval, a new Type semantics, or an alternative mutation path. A provider outage must leave the manual path usable.

## 10. Definition versus Platform Behaviour

### Critical boundary

A definition can describe data structure and select supported platform responsibilities. It cannot, by merely existing as typed data, create arbitrary deterministic behavior.

| Concern | Plausibly configurable/structural | Remains platform-controlled or requires explicit behavior |
|---|---|---|
| Fields and attributes | Names, labels, descriptions, required/optional declarations and typed value shape where supported. | Interpretation of unsupported field semantics and protection of credential/runtime fields. |
| Types | Business-owned Type declarations within the Type-of-Type validation boundary. | Meta-type interpretation, universal validity rules and non-overridable platform semantics. |
| Relationships | Relationship Types, endpoint compatibility, direction, cardinality and selected lifecycle declarations. | Isolation, authorization, integrity enforcement and relationship mutation commit. |
| Revisions | Definition/configuration revisions and exact references where contracts require them. | Optimistic concurrency, immutable history and stale-write rejection. |
| Validation | Declarative value constraints and type-level structure where supported. | Runtime validators, cross-object checks, authority, Policy and commit-time rechecks. |
| Commands | Configuration may identify or consume approved Operations. | Command identity, admission, effects, atomicity and mutation authority. |
| Lifecycle | States, transitions and workflow definitions within supported vocabulary. | Execution, scheduling, retry/recovery, unsafe-effect handling and event/history semantics. |
| Permissions | Business configuration may declare applicable permission metadata or Policies. | Principal identity, isolation, AuthorityGrants, Policy resolution and fail-closed enforcement. |
| Provenance/events | Configuration can carry references and committed changes produce evidence. | Evidence creation, attribution, temporal meaning and historical retention. |
| Reporting/integrations | Definitions may supply fields, views or mappings consumed by existing services. | Query semantics, analytics calculations, external adapters, delivery and failure handling. |

The boundary follows [Product Definition](../product/definition.md#non-overridable-foundations): configuration can define meaning and permitted behavior within the foundations, but cannot redefine the foundations' enforcement semantics.

### Configuration is not automatically capability

The proposition “adding a valid object definition adds platform capability” is only partly supported:

- It is plausible for capabilities whose data, relationships, views and supported lifecycle already fit existing engines.
- It does not follow for behavior requiring a new trusted handler, external side effect, complex calculation, specialized reporting, integration adapter, scheduling guarantee, approval rule or recovery contract.
- A valid definition can make data representable without making it actionable, discoverable, reportable or authorized.
- An Operation Contract may describe a reusable capability, but its fixed trusted handler remains platform-controlled and its reference is not permission.

The [seven-question architectural test](../product/definition.md#seven-question-architectural-test) must be applied before proposing a new engine or treating a new noun as a generic configuration feature.

## 11. Concrete Boundary Examples

These examples are tests of the boundary, not proposed schemas or approved catalogue entries.

### Money

**Structural possibility:**

- a Type may describe an amount and currency value;
- a Money value may be nested inside an Invoice or Product value when independent identity and lifecycle are unnecessary;
- a Business may define labels, requiredness, decimal constraints, currency references and presentation through supported Type, View/Form and configuration mechanisms; and
- a reusable Money concept may be an addressable typed object or shared configuration if it needs independent identity, provenance or revision.

**Platform-controlled behavior:**

- decimal precision, rounding, currency conversion, tax treatment and financial calculations require explicit deterministic semantics;
- validation of cross-field or cross-object financial constraints cannot be assumed from field declarations alone;
- authorization, audit/provenance and commit atomicity remain governed runtime concerns; and
- external exchange-rate or accounting integrations require controlled adapters and failure handling.

**Finding:** a basic Money structure appears composable from existing typed values and relationships. A financial capability is not thereby created.

### Project

**Structural possibility:**

- a Project Type may declare descriptive fields, dates, references to a Business customer/Organisation/Person, and relationships to Tasks, Documents, People or other objects;
- States and Transitions may describe a configured lifecycle;
- Views and Forms may project permitted Project data and actions; and
- a Business may install a reusable Project configuration through an approved release pattern.

**Platform-controlled behavior:**

- creating, assigning, closing or approving a Project requires Operations/Commands, authority and Policy;
- task scheduling, notifications, capacity, dependencies, reporting and integrations require supported platform responsibilities;
- lifecycle transitions need authoritative validation, expected versions, provenance and events; and
- a relationship such as “Customer owns Project” does not grant permission or administrative authority.

**Finding:** Project is a strong candidate for composition over existing objects, relationships, views, workflows and Operations. The existence of a Project Type does not establish a complete project-management capability.

### Invoice

**Structural possibility:**

- an Invoice Type may describe document identity, line-item references, dates, Money values, customer/Organisation references and status/lifecycle declarations;
- relationships may connect an Invoice to a Customer, Project, payment or source document where those concepts are independently addressable; and
- Forms/Views may support authorized drafting and inspection.

**Platform-controlled behavior:**

- totals, tax, rounding, numbering, duplicate prevention, issuance, payment state and ledger/reporting semantics require deterministic behavior and likely explicit Operations;
- issuing or cancelling an Invoice requires authority, Policy, state-transition validation, provenance and durable events;
- external accounting/payment delivery requires integration contracts, idempotency and Unknown/Reconciliation handling; and
- regulatory or jurisdiction-specific requirements cannot be inferred from a generic field definition.

**Finding:** Invoice shows most clearly why structure is not behavior. Configuration may describe the model and presentation, but trusted platform behavior is still required for financial correctness, authorization, execution and external effects.

## 12. Architectural Relationship Model

The following is a conceptual relationship map, not a new engine or implementation design. `Kernel` is used here only as discovery shorthand for the platform-controlled foundation; it is not an additional canonical responsibility or a new software module in the current architecture map.

| Existing concept | Established responsibility | Role in this discovery | Boundary for a prospective definition mechanism |
|---|---|---|---|
| Kernel/foundation | Universal identity, controlled Genesis, isolation and foundational enforcement are distributed across the settled architecture owners. | Supplies the non-overridable rules within which definitions and configuration must operate. | A definition cannot disable authentication, authority, provenance, validation, commit integrity or isolation. |
| Type / meta-type | [Objects and Types](../architecture/objects-and-types.md) owns Type identity, descriptors and the Type-of-Type validation boundary. | Provides valid structure and semantic type identity for definitions and instances. | Type interpretation and meta-type behavior remain platform-controlled; user configuration is not arbitrary executable schema logic. |
| Object | The universal addressable `id + type + value` model. | Candidate definitions, configuration, instances and evidence may use the same representation when independently addressable. | Representation alone does not decide composition, authority, lifecycle or behavior. |
| Object revision | Objects retain immutable versioned history and exact historical meaning under the relevant contracts. | Provides lineage for definition/configuration changes and instance mutations. | Revision adoption, compatibility and instance migration remain open beyond existing exact-reference rules. |
| Relationship | [Business Model](../architecture/business-model.md) owns relationship meaning, endpoint compatibility, cardinality, lifecycle and Business Graph semantics. | Connects composite definitions, definitions to dependencies, and instances to related objects. | A relationship never grants authority; cross-Business traversal and integrity remain governed. |
| Command | [Operation Contract](../architecture/operation-contract.md) and workflow contracts route consequential requests through the sole Command mutation boundary. | Applies definition/configuration changes and instance changes atomically where the approved operation supports them. | A definition cannot submit arbitrary effects or create an alternate mutation path. |
| Attempt | [Workflows and Automation](../architecture/workflows-and-automation.md) distinguishes an individual try from an execution and its result. | Retains attempts to install, apply or execute configuration/operations where those workflows exist. | Retry, recovery and unsafe repeat behavior remain runtime contracts, not definition data. |
| Outcome | Execution evidence records success, failure or uncertainty without proving an effect automatically. | Makes configuration and capability application results inspectable. | Unknown/Reconciliation cannot be converted into assumed success by a definition editor or AI proposal. |
| Provenance | [Identity and Governance](../architecture/identity-and-governance.md) and [Time and Events](../architecture/time-and-events.md) require attributable actor, authority, context and history. | Explains who proposed, approved, installed, changed or used a definition/configuration. | Provenance is evidence, not a substitute for current authorization. |
| Event | [Time and Events](../architecture/time-and-events.md) owns durable occurrences and historical interpretation. | Records significant configuration, lifecycle and instance changes when the responsible contract requires it. | Events do not become an alternate current-state store or permission signal. |
| Business | [Business Model](../architecture/business-model.md) and [Identity and Governance](../architecture/identity-and-governance.md) define an independent Business, Graph, DNA, context and administration. | Owns Business-specific vocabulary and configuration assembled from approved reusable content. | Configuration installation requires an existing governed Business; it cannot bootstrap Business identity or authority. |
| Principal | Identity and Governance owns authenticated operating identity and authority attribution. | Identifies the actor proposing, approving, installing or mutating configuration. | A Person object, relationship or AI output is not automatically a Principal or permission. |
| Configuration | Business DNA and IDY-008 own the current bounded configuration assembly mechanism. | Selects, packages and installs supported definitions, relationships, views, workflows and policies. | There is no single established `enabled capability` object or universal editor contract. |
| Mutation service | The shared Command/Operation path performs validation, authority and commit checks. | Provides the common path for manual, API, workflow and future AI-originated proposals. | Repositories, Views, Forms and providers cannot bypass the mutation boundary. |

The map exposes the key dependency direction:

```text
Type validity + Object identity/revision
    -> configuration and relationship references
    -> authorized View/Form or Operation invocation
    -> Command validation/authority/commit
    -> Attempt/Outcome/Provenance/Event evidence
    -> durable Business and instance history
```

This is a conceptual chain. It does not claim that every step is currently implemented as a generic definition workflow.

## 13. Candidate Definition Catalogue

The following vocabulary is a discovery catalogue only. These candidates are not approved Types, IDY-008 declarations, release contents, implementation tasks or a product backlog. Their likely reuse and relationships are hypotheses to be tested against the responsible canonical owners.

### Primitive candidates

| Candidate | Purpose | Constituent definitions | Likely relationships/reuse | Unresolved questions |
|---|---|---|---|---|
| Text | Human-readable or machine-readable text value. | None beyond platform-supported text validity. | Labels, names, descriptions and notes across most definitions. | Length, rich text, localization and search semantics. |
| Integer | Whole-number value. | None. | Counts, quantities, sequence values and thresholds. | Range, unit and calculation semantics. |
| Decimal | Precise numeric value. | None. | Amounts, rates, measurements and quantities. | Precision, scale, rounding and financial use. |
| Boolean | True/false value. | None. | Flags and binary configuration choices. | Nullability and whether a flag should instead be a State. |
| Date | Calendar date. | None. | Effective dates, due dates and date ranges. | Calendar, timezone and temporal applicability rules. |
| DateTime | Date and time value. | None. | Events, scheduling, validity periods and audit context. | Precision, timezone and recorded/effective-time distinction. |
| Reference | Typed reference to an addressable object. | Referenced Type/object identity and exact revision where required. | Shared definitions, Business objects, relationships and dependencies. | Scope checks, stale references and historical resolution. |

### Common reusable object candidates

| Candidate | Purpose | Constituent definitions | Likely relationships/reuse | Unresolved questions |
|---|---|---|---|---|
| Address | A reusable location or postal address structure. | Text values, optional locality/region/postcode/country definitions. | Person, Organisation, Customer, Supplier, Location and Invoice. | Whether address identity, effective periods and validation require an object. |
| Contact | Contact details and preferred communication channels. | Text, Reference, channel/status values and optional dates. | Person, Organisation, Customer, Supplier and communication capabilities. | Credential boundary, channel verification and privacy scope. |
| Person | A business person representation, distinct from authenticated Principal. | Name, Contact and address-related values. | Organisation affiliations, Customer/Supplier roles, Projects and Tasks. | Role versus Type composition, identity matching and authority separation. |
| Organisation | A business organisation representation. | Name, Address, Contact and classification values. | People, Customers, Suppliers, Projects, Invoices and Documents. | Commercial role, duplicate identity and cross-Business sharing. |
| Money | An amount and currency representation. | Decimal amount and Currency value/reference. | Product prices, Invoice lines, Project budgets and payments. | Precision, rounding, conversion, tax and financial authority. |
| Date Range | A bounded or open-ended period. | Date/DateTime start and end values plus inclusivity semantics. | Projects, Tasks, relationships, Policies and applicability. | Open bounds, timezone, overlap and temporal query behavior. |

### Business candidates

| Candidate | Purpose | Constituent definitions | Likely relationships/reuse | Unresolved questions |
|---|---|---|---|---|
| Customer | A Business-specific commercial/customer concept. | Person/Organisation references, Contact, Address and customer lifecycle. | Projects, Invoices, Documents, Campaigns and communications. | Type versus role relationship, scope and authority implications. |
| Supplier | A provider/vendor concept for a Business. | Organisation/Person references, Contact, Address and supplier status. | Products, Services, Projects, Invoices and Documents. | Qualification, procurement behavior and shared identity. |
| Product | A thing offered, sold or otherwise managed. | Name, description, Money, classification and lifecycle values. | Suppliers, Customers, Invoices, Projects and Campaigns. | Variants, inventory, pricing behavior and external catalogues. |
| Service | A delivered or offered activity. | Name, description, Money, duration and lifecycle values. | Customers, Suppliers, Projects, Tasks, Invoices and knowledge. | Scheduling, resource allocation and delivery semantics. |
| Project | A bounded piece of work or delivery context. | Dates, Customer/Organisation references, Tasks, Documents and lifecycle. | People, Products, Services, Invoices, Knowledge and Workflows. | Scheduling, capacity, dependencies, reporting and approval behavior. |
| Task | An actionable unit of work. | Description, assignee reference, dates, status and relationships. | Projects, People, Workflows, Documents and Events. | Assignment authority, recurrence, scheduling and completion effects. |
| Document | An authored or uploaded business document. | Content/media reference, metadata, lifecycle and provenance. | Projects, Customers, Products, Invoices and Knowledge. | File storage, versioning, publication and knowledge derivation. |
| Invoice | A financial document representing a charge or obligation. | Customer, line items, Money, dates, status and source references. | Products, Services, Projects, payments and accounting integrations. | Totals, tax, numbering, issuance, cancellation, ledger and regulation. |
| Campaign | A coordinated communication or marketing activity. | Audience references, content, dates, goals, channels and lifecycle. | Customers, Products, Documents, Policies and communication tools. | Delivery behavior, consent, measurement and external channel failure. |

The candidate list demonstrates the intended distinction: definitions may describe structure and relationships, while supported platform behavior determines what the candidate can actually do. It is not evidence that every candidate is needed or that any candidate has an approved representation.

## 14. What the Existing Architecture Can Already Express

The following are supported or strongly indicated by current contracts, subject to the stated boundaries:

| Area | Current conclusion | Evidence |
|---|---|---|
| Universal representation | New business concepts can use the shared `id + type + value` model rather than a competing schema. | [Objects and Types](../architecture/objects-and-types.md#universal-primitive); [D08](../governance/decisions.md#d08---configuration-definition-extensibility). |
| Addressable reusable configuration | Configuration needing identity, reuse, provenance, history or lifecycle can be addressable. | [Objects and Types](../architecture/objects-and-types.md#addressability-and-values). |
| Business-owned model assembly | Business DNA can contain linked types, relationships, workflows, Policies, views/forms and related configuration. | [Business Model](../architecture/business-model.md#business-dna). |
| Reusable installation | A trusted release can install supported Business-scoped declarations into an existing governed Business. | [IDY-008](../implementation/idy-008-contract.md#declaration-kinds-and-identity-boundary). |
| Relationship composition | Typed relationships can express connections with endpoint, direction, cardinality and integrity semantics. | [Business Model](../architecture/business-model.md#integrity-cardinality-and-lifecycle). |
| Revision/history | Objects and definitions can retain revision context; exact revision binding is required for Operations and configuration dependencies. | [Objects and Types](../architecture/objects-and-types.md); [Operation Contract](../architecture/operation-contract.md#5-lifecycle-and-revision-binding); [IDY-008](../implementation/idy-008-contract.md#dependency-grammar-and-ordering). |
| Governed mutation | Configuration and consequential object changes can use the existing Command boundary with validation, authority, commit and evidence. | [Operation Contract](../architecture/operation-contract.md#3-mutation-boundary); [IDY-008](../implementation/idy-008-contract.md#command-and-mutation-model). |
| Generic presentation direction | Authorized View/Form definitions can project model data and actions without becoming authority. | [Views and Content](../architecture/views-and-content.md#viewui-contract). |
| No-AI operation | Human authoring and execution remain required and must function without an AI provider. | [Product Definition](../product/definition.md#ai-supported-not-ai-dependent); [AI](../architecture/ai.md#from-proposal-to-permitted-action). |

This is not a claim that all rows are implemented as a complete generic product. [Implementation Status](../implementation/status.md) records bounded evidence and remaining gaps separately.

## 15. What Remains Unresolved

The existing contracts leave a meaningful discovery space:

- Is `Object Definition` only a descriptive term for Types/configuration, or does it need a distinct semantic identity?
- If distinct, what does it own that an addressable Type, Business configuration object or Operation Contract does not already own?
- Which structures remain nested values, and which become addressable objects or relationships?
- Are composition, inheritance, extension and copying all needed, or is explicit reference/composition sufficient initially?
- Which definitions are platform-owned, Business-owned or shared through a governed release?
- Does a Business “enable” a capability by installing declarations, activating Operations, exposing Views/Forms, or a coordinated configuration state?
- Which definition revisions are compatible, and who approves adoption?
- Must instances bind to definition revisions, Type revisions, or only retain the revisions used by each mutation?
- Are existing instances migrated, revalidated, grandfathered, or left under their original definition?
- What deprecation means for new instances, edits, reads, historical inspection and dependent configuration.
- Whether a generic editor may author Type declarations, or only higher-level configuration that references platform-approved Types.
- How definition-level permissions, approvals and impact analysis differ from instance permissions.
- How recursive definitions, collection ordering, defaults, nullability and cross-object constraints are represented.
- How reusable definition packages are upgraded, rolled back, reconciled and exported without transferring authority or Business data.
- Which reports, calculations, integrations, notifications and workflows require fixed platform behavior beyond configuration.
- How a configuration proposal is represented separately from active configuration and approved change.
- Which implementation-status gaps must be closed before generic definition editing can be described as built.

## 16. Architectural Hypotheses

These are deliberately hypotheses, not decisions:

### H1: Definition is initially a role, not a new primitive
A first implementation of reusable definitions may be expressible as existing addressable Type, State, Transition, Relationship Type, View/Form, Workflow, Policy and Operation Contract objects assembled by Business configuration and IDY-008 releases. A new universal Definition Type should not be introduced unless a missing semantic responsibility is demonstrated.

### H2: Composition should prefer explicit references and typed structure
A conservative composition model would retain scalar/nested values where independent identity is unnecessary and use explicit addressable references/relationships where reuse, lifecycle, provenance, history or permissions matter. This follows existing addressability guidance but does not select collection, inheritance or extension syntax.

### H3: Reuse should preserve authority boundaries
A reusable platform release can provide content and dependencies without transferring Business ownership, authority or operational data. Business-specific refinement should create explicit Business-owned configuration/revisions rather than silently mutate a shared definition.

### H4: Exact revision binding is needed for consequential consumers
Operations already require exact revision binding, and IDY-008 dependencies require exact revisions. Definition consumers that affect validation, execution or historical explanation likely need the same discipline. Whether ordinary instances must pin definition revisions remains open.

### H5: Generic UI can be a projection, not a new authority layer
A future definition/configuration editor could be a View/Form projection over authorized configuration objects and approved Operations. It would not itself validate authority, commit mutations or define executable behavior.

### H6: “Capability from configuration” is bounded by existing engines
Configuration can assemble supported structure and behavior, but a genuinely new deterministic responsibility still requires platform-owned runtime behavior and architectural review under the seven-question test.

Each hypothesis requires a focused future discovery or implementation proof. None changes D01-D10.

## 17. Questions Requiring Substantive Architectural Decisions

| Question | Why it matters | Options to investigate | Implications | Current position | Evidence required | Status |
|---|---|---|---|---|---|---|
| What is the semantic identity of an Object Definition? | Prevents a duplicate model beside Type and configuration. | Existing Type/configuration role; distinct Definition object; limited category-specific definitions. | Affects ownership, persistence, references, UI and revision. | Do not add a primitive without a demonstrated gap. | Worked examples across Money, Project and Invoice; Type/IDY-008 fit analysis. | Open |
| What is the supported composition operation? | Determines whether definitions can be nested, referenced or extended safely. | Typed nesting; explicit references; composition; inheritance; copy/extension. | Affects validation, cycles, compatibility, reuse and migration. | Explicit references and typed structure are the conservative hypothesis. | Formal examples and invalid-case catalogue. | Open |
| What does Business enablement mean? | Prevents conflating installed data, available capability, authorization and UI exposure. | Installed declarations; active configuration; Operation/View availability; explicit capability object. | Affects Business DNA, permissions, UI and release reconciliation. | IDY-008 installs configuration but does not define one universal “enabled” object. | Business assembly scenarios and authority review. | Open |
| Who owns reusable definitions? | Reuse must not silently transfer authority or Business data. | Platform; Business; shared release with Business-bound copies; governed mappings. | Affects editing, distribution, export and change control. | Business-owned configuration and reusable release content are already supported patterns. | Ownership and cross-Business isolation cases. | Open |
| How are revisions adopted? | A newer definition can change validity or behavior. | Pin forever; explicit Business adoption; compatible auto-adoption; migration. | Affects instances, history, deprecation and rollback. | Exact revision binding is established for Operations/dependencies; broader adoption is open. | Compatibility matrix and historical read/edit cases. | Open |
| What is the definition/instance migration contract? | Structural changes can invalidate existing values. | No migration; explicit migration Operations; revalidation; grandfathering. | Affects data safety, provenance, downtime and approval. | No universal migration mechanism is evidenced. | Change-impact prototypes and failure/recovery evidence. | Open |
| What can a generic editor author? | Avoids accidental user control of platform meta-semantics. | Higher-level configuration only; constrained Type declarations; separate approved Type-authoring capability. | Affects security, usability, validation and D02/D08 boundaries. | Type/meta-type interpretation remains platform-controlled. | Permission model, review flow and invalid declaration tests. | Open |
| Which behavior remains fixed runtime code? | Prevents data definitions from becoming an unsafe executable language. | Existing Operations/Workflows only; new trusted handlers; constrained declarative behavior. | Affects engine scope, testing and release governance. | Arbitrary executable configuration is forbidden by Operation Contract and IDY-008. | Capability boundary cases, including Invoice and external effects. | Open |
| How are definition changes approved? | A valid structure is not automatically authorized or active. | Direct governed mutation; proposal/approval; release publication; Business admin workflow. | Affects drafts, active revisions, provenance and UI. | Authority/Policy/approval remain separate from Type validity. | Human review and no-AI parity flow. | Open |
| How are packages exported/imported? | Reuse must preserve identity, scope, secrets and history. | Release manifests; copy with lineage; references; no cross-Business operational export. | Affects dependency resolution, conflict handling and ownership. | IDY-008 provides a bounded release model, not a universal export model. | Cross-Business and drift/reconciliation scenarios. | Open |

## 18. Evidence and Source Map

### Canonical architecture evidence

- [D08 - Configuration, Definition & Extensibility](../governance/decisions.md#d08---configuration-definition-extensibility): settled universal extensibility boundary; does not create a new Definition primitive.
- [Objects and Types](../architecture/objects-and-types.md): universal object, addressability, Type definitions, Type-of-Type validation, scalar boundary and non-overridable validation/configuration semantics.
- [Business Model](../architecture/business-model.md): Business Graph, Business DNA, Relationship Types, integrity/cardinality/lifecycle and assembly/ownership.
- [Identity and Governance](../architecture/identity-and-governance.md): Principal/Business lifecycle, isolation, authority, approval, delegation and AI authority boundaries.
- [Operation Contract](../architecture/operation-contract.md): addressable reusable capability definitions, exact revisions, trusted handlers, forbidden executable configuration and sole Command mutation path.
- [Workflows and Automation](../architecture/workflows-and-automation.md): Workflow, Action, Action Execution, Attempt, Outcome, Effect, commit, retry/recovery and controlled execution distinctions.
- [Time and Events](../architecture/time-and-events.md): events, versions, durable history, provenance-time meaning and transition occurrences.
- [Views and Content](../architecture/views-and-content.md): model-projection UI, View/Form boundaries, interaction versus Business State and shared mutation path.
- [Product Definition](../product/definition.md): composition/extensibility levels, non-overridable foundations and seven-question architectural test.
- [AI](../architecture/ai.md): optional provider boundary, validation of every output and proposal-to-permitted-action flow.

### Configuration and implementation evidence

- [IDY-008 Reusable Business Configuration Contract](../implementation/idy-008-contract.md): release identity, declaration kinds, dependency grammar, pre-mutation validation, deterministic Command identity, Business binding, reconciliation and explicit exclusions.
- [Implementation Architecture](../implementation/architecture.md): chosen physical/runtime mechanisms, separate from semantic authority.
- [Implementation Status](../implementation/status.md): current bounded implementation evidence and limitations; it must not be read as proof that the complete universal definition runtime exists.
- [Documentation Governance](../governance/documentation.md): authority/status separation, active-document boundary and reference-document rules.

### Implementation symbols inspected as evidence only

The current runtime trace identified these surfaces as relevant evidence, not as new authorities:

| Surface | Evidence role |
|---|---|
| `app/Runtime/Store/GenericObjectRepository.php` | Generic object creation/revision and optimistic-concurrency implementation surface. |
| `app/Runtime/Store/TypeDescriptorValidator.php` | Type-of-Type descriptor and typed-value validation implementation surface. |
| `app/Runtime/Relationships/RelationshipIndexRepository.php` | Relationship indexing/traversal implementation surface; relationship meaning remains owned by Business Model. |
| `app/Runtime/Commands/CommandHandler.php` | Command identity, admission, mutation and evidence boundary implementation surface. |
| `app/Runtime/Configuration/ConfigurationInstaller.php` and related compiler/verifier classes | IDY-008 installation and reconciliation implementation surface. |
| `app/Runtime/Operations/BusinessCreationOperationHandler.php` | Governed Business creation implementation surface; Business creation is not Genesis or configuration installation. |
| Target View/Form and operation invocation surfaces | Bounded model-projection and governed invocation evidence; not a generic definition editor. |
| Focused integration/unit suites named by [Implementation Status](../implementation/status.md) | Verification evidence for bounded slices only; no generic definition-system claim. |

### Evidence limitations and contradictions

1. **Semantic contract versus implementation status:** canonical architecture documents describe the required universal model while [Implementation Status](../implementation/status.md) explicitly separates settled contracts from partial or bounded implementation evidence. This discovery uses the semantic documents for architecture and the status document for what is actually evidenced.
2. **Bounded generic surfaces versus complete definition system:** the repository contains generic object, Type validation, configuration, graph, presentation and Operation surfaces, but no evidence of a complete user-facing reusable-definition editor or universal definition lifecycle. The absence is recorded as an evidence gap, not as a new architecture decision.
3. **Configuration versus behavior:** IDY-008 supports configuration declarations and governed Commands; Operation Contract and workflow documents keep fixed handlers, authorization, execution, effects and evidence under platform control. A manifest or Type cannot be assumed to create arbitrary capability.
4. **Revision versus migration:** exact revisions and historical retention are established in relevant contracts, but a general instance migration/rebinding mechanism is not established. This is an open design space, not permission to silently rebind.
5. **Current implementation gaps:** status records bounded or incomplete areas such as broader configuration depth, policy composition and recovery semantics. Those limitations do not reopen D01-D10 and are not resolved here.
6. **Legacy application:** old marketing tables and screens are not current architecture or a migration obligation. They are excluded from evidence for this discovery under [Documentation Governance](../governance/documentation.md).

## Closing Finding

The strongest current conclusion is deliberately bounded:

> Idiosyncrasy already has enough compatible contracts to investigate reusable definitions as typed, addressable, versioned Business configuration assembled from existing Types, relationships, views/forms, workflows, Policies and Operations. The repository does not yet justify introducing a universal `Object Definition` primitive, nor does it show that valid structural configuration alone creates complete platform capability.

The next discovery step should select one or two narrow definition families and test composition, reuse, revision adoption, editable representation and behavior boundaries with positive and negative cases. That work should return to the canonical owners and explicit approval process before changing any semantic contract.