# Implementation Architecture

## Scope and Authority

Status: chosen initial implementation specification, with bounded implementation evidence current to 2026-09-30. D01-D10 are settled architecture. Mechanisms without recorded evidence remain specified, NOT BUILT, and unverified; bounded verified exceptions include IDY-007 Slice 1 and the Definition publication/Explorer plus simulation-only Action foundation documented in [implementation status](status.md). None of these slices certifies the full runtime or deployment.
This document owns physical implementation planning, dependency boundaries, and evidence requirements, not conceptual definitions.
This document selects concrete mechanisms under the approved semantic contracts; it does not execute setup, change a database or deploy the platform.
There is no requirement to preserve old data, domain tables, APIs, selected-client behavior, or administrator hierarchy.
No migration or compatibility layer is required by this architecture.
Documentation authority and changes follow [documentation governance](../governance/documentation.md); lineage belongs to the [source map](../governance/source-map.md).

## Canonical Dependencies

| Implementation concern | Definition owner |
| --- | --- |
| Addressing, type definitions, typed values and validation | [Objects and types](../architecture/objects-and-types.md) |
| Relationship integrity and business-specific configuration | [Business model](../architecture/business-model.md) |
| Meanings of rules, policies, constraints, goals and decisions | [Semantics](../architecture/semantics.md) |
| Events, historical identity, recorded and effective time | [Time and events](../architecture/time-and-events.md) |
| Knowledge, source authority and provenance | [Knowledge](../architecture/knowledge.md) |
| Structural filtering, indexes and authorized context assembly | [Retrieval](../architecture/retrieval.md) |
| Definitions, executions, actions, automation and scheduling | [Workflows and automation](../architecture/workflows-and-automation.md) |
| Users (authenticated accounts), isolation, permission and approval enforcement | [Identity and governance](../architecture/identity-and-governance.md) |
| Model projections, forms, navigation, content and media | [Views and content](../architecture/views-and-content.md) |
| Delivery, adapters, discovery and external failures | [Communication and integrations](../architecture/communication-and-integrations.md) |
| Measurement, suggestions and improvement outcomes | [Analytics and evolution](../architecture/analytics-and-evolution.md) |
| Optional inference and validated model output | [AI](../architecture/ai.md) |

The [composition and extensibility rules](../product/definition.md#composition-and-extensibility) govern generic Object composition; “capability” is product language, not a current runtime layer.
An engine denotes reusable execution responsibility, not a mandatory service, process, PHP class, or storage subsystem.
The fourteen responsibilities do not require fourteen software units or a microservice topology.

## Data-Defined Semantic Authority and Exact Binding Contract

### Status and scope

Status: chosen implementation contract. Stage 1 exact-reference resolution,
the Business-scoped View Definition vertical slice and the Batch 1
Presentation Form binding slice are implemented and focused-verified; all
catalogue migrations remain not built. This section resolves the authority gap recorded in
[the data-defined semantics audit](data-defined-semantics-audit.md) without
creating a new D-number, registry, store, semantic database, configuration
ledger or mutation path. It defines the smallest conforming mechanism in the
existing universal Object, Definition, Type, Revision, Authorization,
Operation and Command boundaries.

The contract is deliberately narrower than a generic module loader. PHP may
implement validators, bounded resolvers, projectors, evaluators, trusted
handler adapters and release/bootstrap mechanics. PHP must not provide the
business catalogue that selects a Type, record, capability member, field,
rule, Workflow, Logic expression or Presentation graph at runtime.

### Authority vocabulary

The following meanings are implementation terms under the canonical owners;
they are not additional semantic roles or persistence models:

| Term | Contract |
|---|---|
| Semantic Object | An ordinary persisted Object whose value carries Data, Logic, Workflow, Presentation or Configuration meaning. |
| Semantic Definition | An ordinary Definition Object or existing typed definition Object whose complete value describes the applicable composition and dependencies. A name or shallow Type list is not sufficient. |
| Exact reference | `{kind: "object_reference", id: <UUIDv4>, revision: <positive integer>}`. Both identity and revision are mandatory. |
| Binding | A persisted value in a parent Object, such as `Business.presentation.dashboard_ref`, a Presentation child reference, a `view_reference`, a Definition semantic input, a Workflow node binding or an Operation identity. It is not a PHP map from a human key to an Object. |
| Semantic key | A persisted label or local key used for display or human authoring only. Runtime resolution never maps a business key through a PHP catalogue; the persisted binding supplies the exact Object reference. |
| Handler mechanism | A generic, platform-owned executable adapter selected from an already registered Operation handler mechanism. A handler key identifies code that interprets a contract; it does not contain the business rule or business record catalogue. |

### Capability Definition Type revision evolution

The Capability Definition Type
(`7a4f6b8c-3d2e-4f10-8a11-223344556690`) retains its historical revision 3
descriptor exactly. Its canonical descriptor digest is
`894ef3c523d5394ee1d90840ca751d2a1c37a90d7261498c2874135c1391267d` and it
does not require `navigation_order`. The current descriptor adds the
`navigation_order` property as revision 4; its canonical digest is
`7ede8432e75229b5d7fddeb1068fb3bd14f8519b943a2753182c6a2930d43726`.

The approved local migration candidate appends revision 4 only when the
persisted Type object is exactly revision 3 with the historical descriptor.
It uses the existing coordination lock and `GenericObjectRepository::revise`
path, preserves the Type identity and immutable revision-3 history, and is
idempotent when revision 4 is already current. Existing Definition Objects
that reference revision 3 remain at revision 3; new Definitions from the
current catalogue bind revision 4. No existing Definition or `platform.type_revision`
is rebound automatically. Any revision-3 mismatch, unsupported current
revision or missing prerequisite fails closed.

This revision-evolution change is local review evidence only. It has not
been deployed, reconciled or executed against STAGING; a separately
authorized rollout must verify the exact persisted predecessor and dependent
object inventory first.

### Resolution algorithm

Every runtime entry point that consumes semantic data follows this sequence:

1. Obtain an exact persisted reference from an authorized parent Object or an
   explicit request that is itself validated against the persisted binding.
   A missing revision, "latest" sentinel, filename, profile key or fallback
   Type ID is invalid.
2. Load that exact Object revision through the existing Object repository.
   The resolver checks that the returned Object ID, revision, Type ID, Type
   revision and Business scope match the binding and the applicable owner.
3. Authorize the read in the active User and Business context before
   exposing the value or traversing its dependencies. Platform-owned
   Definitions additionally require the existing publication evidence and
   configured definition-inspection authority.
4. Validate the Object value using its persisted exact Type revision and the
   applicable semantic validator. Definition composition inspection is
   bounded, recursive and non-executing.
5. Resolve each independent dependency through another exact reference,
   applying the same scope, authorization, Type/revision and publication
   checks. An ambiguous query, unresolved reference, unauthorized reference,
   incompatible Type, invalid revision or cycle is a diagnostic failure.
6. Dispatch only to the generic mechanism for the semantic role. The
   mechanism consumes the persisted value and exact dependencies; it does not
   consult a source catalogue or synthesize missing meaning.
7. Retain the exact identity/revisions and resolution outcomes in the
   existing Command, Action Execution, Attempt, Outcome, Event and
   provenance evidence where the operation is executable.

The existing `ConfigurationRuntimeIdResolver` remains an installation-time
translation for portable release declarations only. It is not a runtime
semantic resolver and must not be used to turn a source-file key into
authoritative meaning after configuration has been installed.

### Generic role bindings

| Role or concern | Existing generic mechanism | Required authority rule |
|---|---|---|
| Type/Data | `FoundationObjectRepository`, `TypeDescriptorValidator`, `AuthorizedObjectReader` | Resolve the exact Type Object/revision from the database; validate values from that descriptor; never use a PHP schema as fallback. |
| Definition | `DefinitionPublicationOperationHandler`, `DefinitionPublicationEvidenceReader`, `DefinitionCompositionValidator`, `DefinitionCompositionInspector` | Publish/revise complete platform Definitions through `definition.publish`; require publication evidence for the exact revision; inspect without executing. |
| Capability composition | Universal Definition Object graph and exact constituent references | Do not use `CapabilityCompositionVocabulary`, a Type list, a registry or a capability-specific store as authority. The complete recursive Definition graph and exact revisions are authoritative. |
| Business record and form | Existing Business-scoped View/Form Definition Objects, persisted Presentation action bindings, `PresentationCatalog`, `PresentationTypeResolver` | Generic create/edit surfaces are View-driven and require an exact persisted View/Type binding; a distinct transition Form is selected only by an exact action-level `form_reference`. No `BusinessRecordCatalog` or source profile may select records at runtime. |
| Presentation | `PresentationObjectProvisioningService`, `PersistedPresentationObjectProjector`, `AuthorizedPresentationTargetResolver`, generic renderer | Start at the exact Business dashboard reference and traverse exact persisted Presentation Object revisions. Persisted labels, fields, children and bindings control output. |
| Logic | `GenericLogicEvaluator` | Evaluate the exact persisted Logic Definition revision using only its supported generic operations and exact inputs. A missing, unauthorized or incompatible dependency fails closed. |
| Workflow | `WorkflowDefinitionValidator`, `WorkflowSequentialInterpreter`, `WorkflowExecutionValidator` | Pin exact Workflow, Node, Logic and Operation revisions in persisted Workflow data. The interpreter does not infer a domain subject Type or embed a business branch. |
| Operation | `OperationResolver`, `OperationInvocationService`, `TrustedOperationHandlerRegistry` | Resolve exact persisted Operation identity/revision, validate inputs and authority, then call a registered generic/platform handler. A handler is not permission and cannot provide a hidden business catalogue. |

This table describes reuse of existing mechanisms, not a request to create
separate repositories for each semantic role.

### Authority and scope rules

- Platform-owned Definition Objects have `business_id = null`, are readable
  only through the existing publisher/definition-inspection boundary and must
  have exact publication evidence before another Definition can reference
  them.
- Business-scoped View, Form, Workflow, Operation, Presentation and Data
  Objects have the authenticated server-resolved Business scope. A reference
  to another Business, to a platform object without the required authority or
  to an Object with a mismatched Type is rejected.
- A persisted Presentation action may own an optional exact Form Definition
  reference when the action requires a distinct transition Form. The Form
  reference is independent of an exact persisted Operation reference. The
  action must persist the compatible target Type and invocation context; the
  runtime must not derive either from Form labels, legacy IDs or first-match
  enumeration. Foundation `object.transition` remains a governed Command
  effect for this migration and is not promoted to a revisioned Operation
  Object.
- A client may request an Object or Definition identity, but it cannot supply
  Business scope, User, authority, provenance, executor identity or
  effects. The runtime derives those from authenticated context and persisted
  governance.
- A binding update is a governed Object mutation with an expected current
  revision. It is not an in-memory cache refresh and not a source-profile
  reconciliation.

### Runtime behavior and failure contract

The runtime must distinguish `unavailable`, `ambiguous`, `unauthorized`,
`incompatible`, `invalid`, `unpublished`, `cycle`, `budget_exhausted` and
`stale_revision` outcomes. It must return the repository-standard diagnostic
or controlled Operation/HTTP failure for each condition. It must not:

- choose the first matching Definition;
- default an omitted revision to `1` or latest;
- regenerate a missing View, Type, Workflow or Presentation Object from a
  PHP/JSON catalogue during normal request handling;
- scan Form Definitions and select the first matching Form;
- continue with a hard-coded business rule when persisted data is absent; or
- treat a label, graph connection, release digest or manifest declaration as
  authority, publication evidence or Object identity.

### Publication, revision and consumption

`definition.publish` remains the platform Definition publication boundary. A
create establishes a new Definition Object identity and revision 1; a revise
requires the exact expected current Object revision. Business-scoped semantic
Objects are created/revised by the existing governed `object.create` and
`object.update` Command effects with the same expected-version and provenance
requirements.

Consumers persist and use the exact revision they were authorized to bind.
Changing a Definition or View creates a new revision; it does not mutate
historical meaning. A new binding may adopt the new revision through its own
governed mutation. Existing Workflow executions, Presentation bindings and
historical evidence remain pinned to their previous revisions. No consumer
silently follows "current" when an exact revision is required.

### Bootstrap, installation and reconciliation

Foundation Genesis may establish only the documented platform prerequisites.
Release manifests and configuration packages may carry one-way installation
input, release identity, integrity digest and migration provenance. They are
not runtime semantic catalogues. Installation proceeds only through the
existing governed Command/Operation boundaries and records the resulting
Object identities and revisions.

After installation:

1. ordinary request handling resolves only persisted Objects/Definitions;
2. a source package is never consulted to render, validate, execute or select
   business meaning;
3. reconciliation first reads the persisted exact binding;
4. an authorized persisted change is preserved;
5. a missing required Object, source digest drift or incompatible persisted
   value returns `reconciliation_required` or an explicit failure; and
6. a migration may revise/adopt data only through an explicit, authorized
   migration Command with expected versions, retained provenance and
   idempotent evidence.

The current `BusinessCapabilityConfigurationService`,
`BusinessPresentationProfile`, `CoreObjectPresentationProfile`,
`BusinessRecordCatalog` and `PlatformLogicDefinitionService::fixture()` do
not yet meet this boundary because target runtime paths still read source
files. They remain migration inputs to be retired, not approved mechanisms.

### Resolution and execution dependency diagram

```text
authenticated User + server-resolved Business
                    |
                    v
       persisted parent Object / binding
       exact {object_id, revision}
                    |
                    v
       FoundationObjectRepository.findRevision()
                    |
                    +--> scope + Type/revision + publication evidence
                    |    + authorization + semantic validation
                    |
                    v
        bounded exact dependency traversal
                    |
       +------------+-------------+------------------+
       |                          |                  |
       v                          v                  v
 Presentation projector     Logic evaluator     Workflow/Operation
 + generic renderer         + evidence          resolver/interpreter
       |                          |                  |
       +--------------------------+------------------+
                                  |
                                  v
        governed Command / Operation / evidence boundary
```

No edge in this diagram points to a PHP catalogue, JSON profile, manifest
default or inferred business Type.

### Chosen vertical slice: Business-scoped persisted View Definition

The first proof is a Business-scoped persisted View Definition bound by an
exact Presentation reference and rendered through the existing generic
Presentation path. It is the smallest useful slice because the repository
already has all required mechanisms:

- a governed Business-scoped View Definition Object;
- `PresentationCatalog::presentationDefinition()` with exact ID/revision,
  target-Type validation and Business scope;
- `AuthorizedPresentationTargetResolver` for exact `view_reference`;
- `PersistedPresentationObjectProjector` and the renderer-neutral output;
- `object.create`/`object.update` Commands, expected versions, authorization
  and retained provenance; and
- existing focused Presentation and Definition tests.

The slice must not use `BusinessRecordCatalog`, either presentation profile
loader or a new Products & Services Type. Its test setup creates equivalent
minimal View Definition and Presentation Object values for two Businesses
through the existing governed path. It then:

1. binds each Business to its own exact View Definition and Presentation
   Object revision;
2. resolves and renders both through the generic target resolver/projector;
3. revises only Business A's View Definition through an authorized
   `object.update` Command and updates A's exact binding through another
   governed Command;
4. proves A's changed persisted label/field is observable, B remains
   unchanged, and revision 1 still returns the historical value;
5. rejects missing, omitted, stale, cross-Business, unauthorized and
   incompatible references without fallback; and
6. verifies Command, revision, provenance and authorization evidence.

This proves database-controlled semantic behavior and Business isolation
without introducing a new business Type, handler, registry or demo record.
The Stage 2 implementation integrates `ExactObjectReferenceResolver` into
`PresentationCatalog` for exact View Definition revisions. Focused evidence is
recorded in
`BusinessScopedViewDefinitionAuthorityTest`; the slice is implemented and
focused-verified. Logic/Workflow and capability-composition slices depend on
this exact-binding proof but are not silently included in it.

### Ordered migration plan

| Stage | Scope and dependencies | Affected sources/data | Tests, risks and acceptance |
|---|---|---|---|
| 1. Exact resolver contract | Implement the bounded exact-reference helper using existing repositories, authorization and validators. No new store or registry. | New generic resolver boundary plus `AuthorizedObjectReader`, `DefinitionPublicationEvidenceReader`, `PresentationCatalog`; no data migration. | Unit tests for omitted/mismatched revision, scope, publication, ambiguity, cycle and failure codes. Security review must confirm platform/Business isolation. |
| 2. View Definition vertical slice | **Implemented and focused-verified.** `PresentationCatalog` delegates exact View Definition identity/revision validation to Stage 1, then retains its distinct target-Type/field/operation validation. | `PresentationCatalog`, `TargetRuntimeCompositionRoot`, `PersistedPresentationObjectProjector`, governed two-Business fixture; no Products & Services data. | `BusinessScopedViewDefinitionAuthorityTest`: 2 tests / 32 assertions. Existing Stage 1/Presentation regression run: 37 tests / 223 assertions, 1 warning. Stage 3 remains gated by catalogue migration evidence. |
| 3. Capability Type vocabulary | Replace runtime consumers of `CapabilityCompositionVocabulary`; retain stable existing Type Objects only as migrated data where justified. | `CapabilityCompositionVocabulary`, `BusinessCreationOperationHandler`, `BusinessPresentationProvisioningService`, `WorkflowLogicIntegrationProvisioner`, legacy grants/fixtures. | Migrate through governed Type/Definition installation; validate exact persisted Type revisions. Risk: changing historical IDs or grants. Acceptance: altering a persisted Type/Definition changes generic behavior and no PHP schema is consulted. |
| 4. Capability composition | Replace `StandardCapabilityDefinitionCatalog` publication/inspection with complete persisted Definition graphs and exact constituent references. | Build-phase scripts, legacy capability handlers/projector and Definition publication inputs; existing persisted legacy objects remain untouched unless explicitly mapped. | Recursive bounded composition, publication evidence, exact identity/revision and no shallow Type list. Risk: historical catalogue is incomplete; stop on unresolved constituent identity. |
| 5. Record and demonstrator data | Remove `BusinessRecordCatalog`; resolve record Views/Forms/Types from persisted Business Presentation/Configuration bindings. Replace demonstrator-specific record rules only where a generic Operation/Logic/Workflow contract exists. | `BusinessRecordService`, target boundary, `BusinessRecordCatalog`, generic capability profile, `DemonstratorVocabulary` and handlers. | A/B Business isolation, field/schema changes through persisted definitions, missing binding failures and command provenance. Risk: no documented persisted record-key contract; do not invent one. |
| 6. Logic and Workflow bindings | Remove fixture publication from normal runtime; pin Logic/Workflow/Node/Operation revisions from persisted objects. Keep generic evaluator/interpreter mechanisms. | `PlatformLogicDefinitionService`, `WorkflowLogicIntegrationProvisioner`, `InitializationVocabulary` demonstrator portions, workflow validators/interpreter. | Governed publish/update changes behavior, exact old revisions remain stable, missing Logic/Operation fails closed. Risk: handler keys may encode demonstrator meaning; generic handler boundary must be explicit first. |
| 7. Presentation profiles | Stop runtime profile loading and overwrite reconciliation. Consume the persisted Dashboard-root and View/Presentation Object graph only. | `BusinessPresentationProfile`, `CoreObjectPresentationProfile`, `BusinessPresentationProvisioningService`, source JSON profiles. | Persisted Presentation changes survive re-entry/reconciliation; source-file drift returns explicit reconciliation evidence and never overwrites. Risk: existing fresh Business bootstrap needs a one-way installation boundary. |
| 8. Bootstrap and migration | Constrain Genesis/release/configuration files to fresh-install or explicit migration input; preserve IDs, revisions, provenance and unrelated Businesses. | `GenesisRunner`, `FoundationReconciliationService`, `TargetProvisioningRunner`, `BusinessCapabilityConfigurationService`, `ConfigurationInstaller`, manifests and CLI boundaries. | Idempotent clean installation, explicit drift/reconciliation state, no direct SQL Object writes, no normal HTTP source-file authority. Security risk: release operator privilege must remain separate from Business authority. |
| 9. Authority removal and repository proof | Delete or quarantine obsolete source catalogues and hidden fallbacks only after replacement coverage. | Legacy bins, dormant setup methods, stale template copy, tests and audit script. | Repository search finds no runtime semantic catalogue/fallback; full targeted and baseline suites pass with uncontaminated test DB settings. No compliance claim until evidence is recorded. |

Each stage is separately reviewable. A failure or unresolved contract stops that
stage without promoting a manifest, fixture or historical catalogue into
semantic authority.

### Stage 3A capability Type authority plan

Stage 3A is **PLAN ONLY** and is recorded in the
[audit findings register](data-defined-semantics-audit.md). The current
`CapabilityCompositionVocabulary` class defines 21 capability Type identities
and schemas. Its installer is not a conforming migration mechanism: when a
persisted descriptor differs, it directly updates the current Object and
revision 1 through PDO, bypassing expected versions, Commands, provenance and
history.

Before any Type consumer is migrated, each identity must have read-only
evidence for its persisted Object, current revision, descriptor, provenance
and dependent Definitions/Objects/Views/Workflows/Operations. Isolated test
installation is not evidence of target or production state. The historical
repository reports that mention 15 Types must be reconciled with the current
21-constant source inventory.

The planned migration preserves verified Object identity and history, adopts
the Stage 1 exact-reference resolver for consumer reads, uses persisted Type
descriptors for validation and requires a governed platform Type-revision
mutation boundary for schema changes. A missing, incompatible or unmapped
identity fails closed. No Type registry, semantic key lookup or direct SQL
overwrite is permitted.

Stage 3A remains blocked until the mapping and governed Type-revision boundary
are documented and tested. It does not include
`StandardCapabilityDefinitionCatalog`, `BusinessRecordCatalog`,
Logic/Workflow rules, Presentation profiles or Products & Services.

The descriptor-mismatch branch of
`CapabilityCompositionVocabulary::install()` is now contained: matching
persisted descriptors are idempotent, invalid persisted descriptors fail
closed, and source descriptor drift is rejected without rewriting the
current Object or revision 1. This local implementation does not authorize
Type revision or replace the required governed platform Operation.

### Stage 3C governed Type-revision boundary — PLAN ONLY

Stage 3C is blocked by a verified implementation gap. The current provisioning
path reaches `CapabilityCompositionVocabulary::install()` through
`TargetProvisioningRunner::installPlatform()`. The previous installer could
rewrite the current Object and revision 1 directly through PDO when
descriptors differed; the bounded containment slice now rejects that drift
without mutation.

The existing generic persistence mechanism
`GenericObjectRepository::revise()` supports expected versions, immutable
revisions and provenance parameters, but it is not itself an authorization
boundary. `CommandHandler` generic Object mutation requires Business scope,
while platform handling currently covers only `business.create` and
`definition.publish`. `AuthorizationService::authorizePlatform()` has no
approved platform Type-revision operation targeting `TYPE_OF_TYPE_ID`.

No existing governed Command/Operation path for platform Type revision was
verified. Stage 3C therefore requires an owner-approved extension of the
existing platform Operation/Command boundary before BUILD. That contract must
authorize the exact Type Object, require the expected Object revision, validate
the persisted Type-of-Type descriptor, create retained Command/evidence/
provenance and preserve historical revisions. It must not create a registry,
parallel store, direct SQL writer or special Type mutation bypass.

The approved dependency order is: confirm production mapping; approve and
test the governed Type-revision boundary; contain the unsafe installer;
re-run dependency evidence; then adopt exact Type references and migrate
consumers. Any unverified identity, missing authority owner, direct SQL path,
historical rewrite or unresolved Project dependency stops BUILD.

### Stage 3D gate resolution — PARTIALLY DECIDED, PLAN ONLY

The project owner approved the proposed Type-revision architecture in
principle on 2026-10-16 and supplied a partial decision record on 2026-10-21.
The approved-in-principle direction preserves Presentation/View Definition
revision 1 and appends revision 2, preserves Capability Definition revision 3
and appends revision 4, keeps `target_type_revision` optional in Presentation
revision 2, and excludes the separate Presentation Object Type.

The intended Operation is `platform.type_revision`, candidate ID
`9f4f6b8c-3d2e-4f10-8a11-223344556702`, revision 1, with trusted handler key
`platform.type-revision`. Its proposed allowlist is limited to the
Presentation/View Definition Type Object
`8a4f6b8c-3d2e-4f10-8a11-223344556690` and Capability Definition Type Object
`7a4f6b8c-3d2e-4f10-8a11-223344556690`. The candidate Type-revision
AuthorityGrant and Policy IDs are respectively
`b3000000-0000-4000-8000-000000000003` and
`b3000000-0000-4000-8000-000000000004`.

These values are proposed contract values, not evidence that the Operation,
grant or Policy exists or that the identifiers are globally conflict-free.
The partial decision does not authorize implementation or production work.

The approved-in-principle mechanism requires a separate Type-revision grant
and Policy, the existing Operation/Command/authorization/evidence pipeline,
commit-time grant, Policy and expected-version revalidation, coordination and
target locking, no automatic Definition Publisher authority inheritance, no
direct database or historical-revision rewrite, and two independently atomic
idempotent Commands: Presentation revision 1 to 2 followed by Capability
revision 3 to 4. Existing View Definitions remain bound to revision 1; new
View Definitions may use revision 2; no Definitions, Views or Presentation
Objects are automatically rebound.

The intended existing-target invocation is a separate bounded authenticated
CLI based on the `bin/reconcile-foundation.php` safeguards. It must verify
STAGING identity, authenticate the explicit User, invoke the Operation
through the existing Command path, avoid direct repository writes and never
invoke empty-target provisioning.

The configured Definition publisher identity and grant authorize only
`definition.publish`; they do not authorize platform Type revision. The
partial decision still requires the decision owner/delegated authority,
trusted handler/release designation, designated Type-revision User,
collision-checked final identifiers, exact CLI/credential contract, event and
reason-code names, diagnostic output/workflow and any additional conditions
to be recorded before implementation.

The approved read-only STAGING snapshot supplies the 21-Type and Project
dependency evidence. Production identity, provenance, dependents,
publication evidence, Type-revision authority and provisioning behavior remain
unverified. No approved read-only production Object inventory mechanism was
found, and no production query was attempted. The route audit also confirmed
that the remote registration diagnostic is explicitly STAGING-only, release
and activation tooling has deployment effects rather than inventory semantics,
and the legacy database scripts lack a production selector, read-only
authorization contract and complete evidence schema. The database connection
configuration is not an authorization boundary.

Decision: **NO-GO for Stage 3D BUILD**. The gate changes only after owner
approval is recorded, an approved production inventory reconciles with
STAGING, the governed boundary is implemented/focused-tested and installer
containment tests pass.

Installer containment is now focused-tested locally. Production evidence and
the governed Type-revision boundary implementation remain outstanding.

The smallest next operational capability is an authorized production host or
database operator run of a read-only inventory against a positively identified
production target, using a dedicated read-only account or read-only
snapshot/export boundary. It must return the complete Type, revision,
provenance and dependent-reference package specified by the
[Stage 3D production evidence request](stage-3d-production-evidence-request.md)
and must not be combined with deployment, provisioning, reconciliation or
mutation.

### BUILD handoff gate

Implementation may begin only when all of the following are true:

1. this plan is accepted as the implementation mechanism under the existing
   canonical semantic owners;
2. the vertical-slice tests and exact-reference error contract are agreed;
3. the persisted record/View/Form binding shape is explicitly approved;
4. the generic handler boundary distinguishes platform mechanism from
   business meaning, with no demonstrator-specific handler required for the
   first slice;
5. the migration inventory maps every retained legacy ID to an exact
   persisted Object/Definition or marks it intentionally unsupported;
6. bootstrap/reconciliation ownership is restricted to explicit installation
   or migration, not normal target runtime;
7. staging remains read-only and the approved isolated test refresh is
   available with `IDY_TARGET_DB_*`/port contamination checks; and
8. focused acceptance criteria can be run without Products & Services data or
   any direct database write;
9. the complete Type identity/revision/provenance/dependency mapping is
   verified for every approved environment; and
10. the governed platform Type-revision Operation/Command boundary is approved
    and focused-tested before any installer containment or Type migration.

## Persisted Presentation Object Mechanism

### Generic Semantic Composition

The universal Object/Definition model also carries a generic data-defined semantic
composition contract. A Definition may declare one of the semantic roles `Data`,
`Logic`, `Workflow` or `Presentation` and may bind named semantic inputs through
typed constituents. Each input declares its expected Type descriptor, cardinality,
required/optional status and either an inline typed value or an exact
`object_reference` with a positive revision.

This is an extension of Definition value validation, not a Logic-specific
persistence model. `DefinitionCompositionValidator` validates the role, input
identity, type compatibility, cardinality, exact references, inline values and
existing recursive composition rules. It does not execute operations. Logic
evaluation, Presentation-to-Logic consumption and Workflow execution remain later
runtime work.

The approved presentation direction extends the existing Business-scoped View/Presentation Definition mechanism with recursive persisted Presentation Objects. A Presentation Object is an ordinary persisted Object with Presentation semantic role, governed by the generic Object, Revision, Relationship and Authorization mechanisms. It is not a PHP rendering descriptor or a second persistence model.

The persisted owner is the exact Business-scoped Presentation Definition/View referenced by the presenting Object or Business presentation binding. The Definition may opt into exact `presentation_object_refs`; each reference identifies an exact persisted Presentation Object revision. Parent objects define structure or containment and child objects define presentation content.

The implementation sequence is:

```text
exact Presentation Definition/View
    ↓
exact persisted Presentation Object revisions
    ↓
authorized recursive traversal
    ↓
Object/value binding and authorization
    ↓
renderer-neutral runtime element tree
    ↓
generic delivery renderer
```

The implemented projector defines generic element identity, kind, role, content source, children and order for the persisted vertical slice. It resolves every persisted Presentation, content and target Object reference through `ExactObjectReferenceResolver`, which composes `AuthorizedObjectReader` with exact Type/value and Definition publication validation. Missing, unauthorized, invalid, incompatible, unpublished, unavailable and cyclic branches are suppressed without duplicating business data or mutating persistence. Traversal has no arbitrary presentation depth limit; cycle detection and persisted graph termination are the safety boundary.

The existing `PresentationCatalog`, `ExactObjectReferenceResolver`, `AuthorizedObjectReader`, `PersistedPresentationObjectProjector`, Operation/Command/Event mechanisms, User Presentation Preferences and generic Business presentation configuration are the implementation dependencies. Exact Object/View target validation is performed by the authorized Presentation target resolver and concrete routes are serialized only by `HtmlRenderer`. Generic user preferences use revision 2 of the existing preference Type with exact context/Object references and a deterministic Object identity derived from the User, Business and reference tuple; reads re-authorize both exact references before applying a preference. Generic order delivery carries its Presentation Object reference per item. Type content continues to use exact ordinary Object references to platform Type Objects. No new presentation persistence layer, registry, Capability-specific Type, Presentation Instance content model or PHP presentation configuration system is authorized.

This mechanism is **implemented for the current bounded slice**. The persisted Presentation Object vertical slice is implemented and focused-verified through `presentation_configuration.presentation_object_refs`, including recursive traversal, exact revision resolution, authorization-aware projection, Object/value binding, cycle suppression and shared generic delivery. Generic recursive collection, exact authorized Object/View navigation, non-executing governed Operation action exposure, semantic layout defaults, sparse user preference overrides and derived six-column **outer** delivery packing now use `RenderablePresentation.elements`. The bounded slice does not certify that recursive content is separated from that outer packing policy; that gap is recorded in [implementation status](status.md#presentation-object-architecture-audit-2026-10-22). The generic HTML renderer delivers only persisted `RenderablePresentation.elements`; `collections[]`, `items[]` and `fields[]` remain non-authoritative compatibility data for unmigrated internal callers and are not rendered or made inspectable.

Full Business Presentation reconciliation also derives persisted Business-scoped
View Definitions and Presentation Object graphs for configured record Types
from the authoritative generic capability profile. Business context selection
invokes this same governed reconciliation, so a freshly provisioned Business
does not depend on a capability URL or an in-memory-only Presentation
fallback. Generic layout preferences use the existing exact context/Object
references for these collection and detail Presentations.

### Presentation display-scope mechanism

The persisted Presentation Object value may declare one `display_scope`
vocabulary value: `standalone_only`, `standalone_and_embeddable` or
`embeddable_only`. This is semantic Presentation configuration, not a
preference, a navigation label, a route hint or a CSS concern. Omitted values
on legacy objects are read as `standalone_and_embeddable`; newly authored
profiles must include the value explicitly.

The delivery boundary supplies exact references selected for the current page
surface or level. The projector applies display scope only to those initial
references. Recursive `children[]` traversal does not apply independent
selection filtering, so an explicitly referenced embeddable child remains
available inside its parent. Governed provisioning rejects standalone-only
children and embeddable-only roots, while retaining exact Object revision,
Business-scope, authorization and cycle validation. Direct Presentation Object
routes are independent selection and use the same admission rule.

This mechanism intentionally does not introduce a candidate registry,
composition store, semantic Type, user preference or capability-specific
renderer. `presentation_surface` remains derived projection metadata: it
describes how the current delivery request entered the graph and is not an
authoritative scope declaration. `navigation.navigable` remains menu
eligibility only. Outer six-column packing, Compact/Regular/Expanded
derivation, nested surface delivery and revision-2 layout preferences are
unchanged.

### Bounded workflow execution mechanism

The bounded workflow runtime reuses the existing generic Object repository,
Business-scoped Operation declarations, `OperationInvocationService`,
`CommandHandler`, `WorkflowDispatchLeaseService` and fixed workflow evidence
participants. `WorkflowSequentialInterpreter::step()` is the runtime step
surface: it requires the current dispatch lease, resolves the exact pinned
Workflow Definition and Node revisions, resolves the execution subject, and
invokes the governed workflow Operation for the condition or terminal result.
An expression with `kind: logic_reference` carries an exact Logic Definition
Object ID and positive revision; it is evaluated by `GenericLogicEvaluator`
against the pinned subject and the execution Business. The Operation handler
rechecks the same condition before the conditional commit, so interpretation
does not become an alternate mutation path.

This mechanism is **implemented as a bounded slice** and is assembly-wired
through `TargetRuntimeCompositionRoot::workflowInterpreter()` and
`TargetRuntimeCompositionRoot::workflowRunner()`. A settled generic Command
now invokes the runner for each committed Event after its transaction commits;
rollback paths never dispatch an Event. The runner admits matching workflows,
claims the dispatch lease, steps the interpreter within a budget and reloads
the persisted terminal evidence. It does not
claim a general worker, scheduler, queue, wake/recovery loop, retry/replay
engine, parallel execution, human approval wait, compensation or external
effect execution. Admission remains event/trigger-key based and idempotent;
lease, expected-version and authority/policy checks remain the authoritative
commit boundary.

### Reusable provisioning boundaries

`PresentationObjectProvisioningService` is the reusable mutation boundary for
data-defined Presentation Object graphs. It accepts a Business-scoped profile
of ordinary Presentation Object values and exact child/content references,
rejects duplicate identities, missing revisions, unauthorized references and
cycles, then submits the complete creation set through governed
`object.create` Command effects. It returns exact root and descendant
identities and does not render, interpret labels or create a presentation
store.

`BusinessInstanceProvisioningService` is the application orchestration boundary
for an authenticated operator profile. It composes `business.create`,
IDY-008 installation, resolver-derived Business Types, initialization,
profile-defined generic data/workflow/logic mutations and
`PresentationObjectProvisioningService`. It owns no domain Type IDs,
relationship semantics, SQL, renderer logic or named navigation branches.
The CLI boundary is limited to operator authentication, profile selection,
confirmation and non-secret evidence output.

The provisioning composition creates one Dashboard Presentation Object root
after Business creation and associates that root with the Business through the
generic exact-reference/relationship mechanism. It then creates the recursive
descendant PO graph. The Business creation Operation does not construct or
retain a collection of Presentation Objects. Dashboard direct children are
projected as candidate navigation only when their persisted, data-defined
configuration marks them navigable; the runtime does not know their labels.

Ordinary browser-created Businesses use the data-defined
`generic-business-presentation` profile. The profile contains only one
Dashboard root, one navigable Overview child and one literal Overview title;
it contains no Business-specific authorization, initialization, capability or
Workflow data. `BusinessPresentationProvisioningService` applies this profile
to an existing Business through `PresentationObjectProvisioningService` and a
governed Business update Command. The authenticated
`/business-presentation/reconcile` boundary is idempotent and is also invoked
after normal browser Business creation. This lifecycle step is deliberately
separate from configuration installation, Business initialization and optional
demonstrator provisioning. Profile node identities are deterministic
Business-scoped UUIDs derived by the profile loader, so the same Business can
be repaired without sharing Presentation Object identities with another
Business. Reconciliation first extends the active Business administrator
authority grant with the Presentation Object Type when that target is absent,
using the same governed update boundary; no authority row is inserted
directly. New Business creation grants include this generic Presentation target
from the outset.

### Provisioning failure semantics

Provisioning crosses several independently governed Command boundaries and is
not one database transaction. Business creation itself is atomic within its
governed operation. If a later phase fails, the Business and any earlier
durable effects remain, and the service records one governed Event Object with
`event_kind: business.provisioning.failed`, the Business identity, failed
phase in the Event's governed `transition_id`, command identity and
timestamps. A successful run records
`business.provisioning.completed`; the service does not emit both outcomes for
one attempt. The resulting Business is recoverable/reconcilable state, not
silently rolled back state. The phase-level integration test is the evidence
for this contract.

## Observed Runtime

- The target entrypoint is [target/index.php](../../target/index.php), with target-local rewrite rules and `App\Runtime` services.
- [bootstrap/autoload.php](../../bootstrap/autoload.php) provides the application namespace loader used by the target runtime and CLI tools.
- The former marketing application, controllers, old schema, and old setup utilities have been removed; selected historical observations remain in the legacy implementation reference.
- The repository has a focused PHPUnit suite and a canonical runner that refreshes its disposable database from staging; this does not certify the full runtime. There is no general worker runtime or dynamic module loader.
- PHP and MariaDB describe the chosen target mechanism. This is an implementation choice, not a compatibility obligation inherited from the removed application.

Operational configuration details are retained in [security and operations](security-and-operations.md), without exposing credentials.
The old schema and setup runner are historical implementation artifacts, not a bootstrap specification for universal objects.

## Target Release Boundary

The public target package is bounded by the reviewed release definition and its canonical manifest; the separate internal staging-provisioning package is bounded by its own manifest and required operator paths. The internal package includes the no-network Communication runtime classes but is not the public deployment artifact. Package tests and the read-only target check are recorded in [implementation status](status.md#target-release-foundation-evidence).

The target release is defined by the reviewed [release definition](../../release/target-release.json), not by a historical transfer inventory. [TargetReleaseDefinition](../../app/Release/TargetReleaseDefinition.php) resolves only the approved target runtime and target presentation patterns, rejects unsafe paths and links, and requires the derived paths to match the reviewed snapshot. [TargetReleaseManifest](../../app/Release/TargetReleaseManifest.php) records normalized paths, byte counts and SHA-256 values in canonical JSON. Its identity also contains GitHub authority, repository, exact full commit SHA and non-secret build identity, so the derived release ID and artifact digest cannot be detached from the source commit.

The current source resolution is recorded in the canonical manifest and includes exact-revision Definition validation/publication, the shared generic Object Presentation renderer and persisted-state projector, server-resolved Operation input handling, the no-network `send_email` Provider and handler, runtime vocabulary, initialization classes, core-object Presentation provisioning, target assets and User confirmation-delivery classes. Provisioning-only publisher installation, Genesis material and platform-opening manifests remain outside the public runtime package. The reviewed release definition remains the sole source boundary; release tooling remains outside the target payload except for explicitly reviewed runtime paths.

Target-local execution uses `IDY_TARGET_*` database variables and may override the session directory only to an absolute, non-shared local path. The guarded local launcher uses `var/target-sessions-local`; production deployment, activation and database mutation are separate operational steps and are not implied by manifest generation or local checks.

The operator release mechanism is [bin/target-release.ps1](../../bin/target-release.ps1). It consumes, rather than creates, a GitHub-bound directory artifact and reports its deterministic operator phases: local preflight, package verification, production connection, staging/upload, remote verification, blocked activation, and final release result. It verifies the manifest-declared paths, canonical manifest, release ID, artifact digest and exact GitHub provenance before one recursive SCP operation transfers the package to a release-specific non-active `.releases/<release-id>-staging` directory. Remote manifest paths, byte counts, hashes, manifest identity and provenance remain verification requirements. Authentication and failure diagnostics retain the existing non-secret controls; strict host-key verification remains mandatory. Atomic activation and rollback are not specified by the current production layout, so the command remains blocked after verified staging.

The non-deploying [GitHub Actions workflow](../../.github/workflows/build-target-release.yml) checks out `${{ github.sha }}`, writes only non-secret provenance, validates the release boundary, creates the package and publishes it as a verifiable artifact. No production credential or deployment step is present. The former direct-upload script was retired; only the GitHub-bound package path is authoritative.

STAGING provisioning remains an internal operator concern. [StagingProvisioningPackage](../../app/Release/StagingProvisioningPackage.php) includes only the runtime classes needed by the CLI, the shared `bin/runtime-migrate.php` and STAGING provisioning CLI, runtime migrations and provisioning-only Genesis/platform-opening manifests. It is not part of the public runtime package and is not built, published or consumed by the GitHub deployment workflow. `bin/staging-deploy.sh` deploys the public application package and performs health verification only. Production provisioning is deferred; the generic target runtime and identity preflight remain internal reusable abstractions, not an active operational environment.

The explicit [STAGING provisioning command](../../bin/provision-target.php) accepts only `--database=staging`. It uses `IDY_STAGING_DB_NAME` when supplied, otherwise the configured target database name, then requires a valid non-production-looking identity and verifies the selected PDO database against that identity. It requires an empty database and executes the migration -> foundation Genesis -> platform vocabulary -> platform-opening sequence with migration release identity `IDY-STAGING`. Production provisioning is deferred and has no active CLI selector.

## Initial Runtime Structure

The first definition-driven initialization slice reuses this modular-monolith mechanism: platform-owned Definition objects are resolved by revision, Business-scoped Workflow Definitions/Nodes and Workflow Executions carry initialization progress, and explicit requirement input reaches the existing Operation/Command boundary. It does not add a User/Business schema, a second workflow state machine or a direct-write UI exception. The bounded slice is not evidence that general Definition adoption, recursive State propagation or the complete workflow runtime is implemented.

**Settled semantic contract:** one universal semantic runtime, initially a modular monolith and distribution-ready by contract. Durable authority, identity and execution meaning do not depend on a process boundary.

**Chosen implementation mechanism:** PHP 8.3.33 with PDO and the `pdo_mysql` driver, MariaDB 10.5.26/InnoDB, a first-party PSR-4-style autoloader and an explicit composition root. No application framework or Composer is used. Maintain one deployment unit with separate HTTP controllers, runtime application services, persistence adapters and server-rendered presentation. Use the existing `app/` layering conventions with a dedicated `App\Runtime` namespace for the new pipeline; do not wire old direct-SQL controllers into it. Exact tested patch versions belong in the build evidence, not in an assumed hosting inventory.

The composition root supplies database transactions, typed-object validation, Business-context resolution, authority/Policy evaluation and a single Command service. HTTP/API, workflow, CLI and AI proposal adapters call that service; repositories are not public mutation endpoints. Read-only object inspection uses permission-aware retrieval. Explicit registration of supported type validators, action handlers and view renderers is sufficient; no dynamic loader, broker, microservices or vector database is required.

**Current implementation status:** the bounded `App\Runtime` foundation is implemented and evidenced, including the first-party autoloader and composition root, the PDO/MariaDB runtime boundary, typed object/revision persistence, the governed Command service and bounded authorized retrieval. The IDY-005 through IDY-010 evidence recorded in [implementation status](status.md) covers only those bounded slices; broader runtime coverage, generic dependency resolution, complete workflow recovery and universal capability coverage remain unbuilt or unverified. Source reuse is not conformance evidence.

## Layer Responsibilities

Preserve the separation of HTTP handling, business orchestration, persistence and presentation in the chosen runtime.

| Boundary | Responsibility | Exclusions |
| --- | --- | --- |
| HTTP/controller | Parse requests, validate transport shape, establish authenticated context, call application behavior, select response | SQL, policy definitions, business orchestration |
| Service/application behavior | Apply model validation and authorization, orchestrate actions and repository calls | Rendering, direct database queries, provider-specific payload formatting |
| Repository/storage adapter | Scoped reads/writes, prepared queries, structured results, approved persistence mapping | Business policy decisions, HTTP/session-dependent authorization shortcuts |
| Presentation | Resolve the applicable binding/configuration, render authorized projections and interaction state through the common Object Presentation contract | Copying business data into presentation state; treating hidden controls as access enforcement |
| Integration adapter | Translate supported capabilities and remote responses | Owning an alternative business model or bypassing core validation |
| Worker, if introduced | Execute already-authorized work under explicit runtime and retry semantics | Assuming a queued payload grants permanent authority |

Prefer constructor injection where practical and an explicit composition boundary for dependencies.
Services may coordinate other services; avoid circular orchestration and hidden global state.
The existing database singleton is an observation, not a required new-platform dependency pattern.

## Physical Model Mapping

**Settled semantic contract:** [core object model and authority](../architecture/core-object-model-and-authority.md) supplies the cross-cutting object, definition, derived-State and authority invariants. [Objects and types](../architecture/objects-and-types.md) owns the primitive and authoritative durable state; [time and events](../architecture/time-and-events.md) owns coherent required history. The physical schema implements these meanings.

**Chosen implementation mechanism:** a fresh dedicated database, not the old marketing schema. Use opaque UUIDv4 addresses represented as ASCII `CHAR(36)` with binary comparison, unsigned integer versions and typed JSON values. Keep references as object IDs plus explicit revision numbers when historically bound. Store UTC microsecond timestamps and explicit timezone names for business scheduling. Where a domain contract requires an effective interval, represent that interval physically as a half-open interval; effective intervals are not universal fields of every object or revision. Reject absent/invalid type references and unsupported type features.

| Physical structure | Purpose and constraint |
|---|---|
| `objects` | Primary key `id`; type ID and type revision; Business ID where scoped; current version; typed JSON value. Current durable state, not a cache. Bootstrap platform definitions are explicitly platform-scoped, not publicly readable by default. |
| `object_revisions` | Unique `(object_id, version)`; retained typed value/type reference, recorded time and provenance reference. Current row and new revision change coherently. Historical references resolve here, subject to access/retention. |
| `relationship_index` | Derived endpoint/type/direction fields keyed by the canonical Relationship object's ID. Update transactionally for initial queries; never infer authority or truth from index membership. |
| `command_keys` | Unique Command identity; canonical Command object reference, User/Business binding and request fingerprint (the User binding uses the legacy identifier for the User). Prevent duplicate semantic admission across processes; no separate business Command identity. |
| `runtime_coordination` | One coordination row used for short transaction-scoped mutation serialization in the small demonstrator. This is a database lock, not authoritative business state or an in-memory mutex. |
| `credentials` | Protected User reference (a legacy identifier for the User) and password hash, separate from generic object projections/exports. Authentication metadata can be addressable without exposing secrets. |

Types, State definitions, Business, membership, authority, Policy, Decision, Relationship, Assertion, Command, Action Execution, Attempt, state-transition occurrence, provenance, workflow and view definitions are all typed addressable objects. The support tables are physical mechanisms, not alternate logical foundations. Each type identifies its applicable State definitions; the subject's State value references an addressable definition rather than using an unqualified primitive label as semantic identity. Labels/codes remain primitive values and no mandatory universal State enum is introduced. Transition records reference before/after State definitions with historically relevant revision context under the [State identity contract](../architecture/objects-and-types.md#state-identity).

Derived State may be calculated on demand or materialized in a durable/read-optimized representation, but the object graph and applicable definitions remain authoritative. A constituent or relationship change must invalidate or recompute affected containing conditions rather than rely on a manually maintained parent status. Materialized state is evidence of a derivation, not an independent authority.

Start with indexes on `(business_id, type_id, id)`, relationship endpoints/type and revision identity. Queries use stable ID cursor pagination, default 50 and maximum 100 results, with authority filters before disclosure. Query authoritative records directly; no async search index is needed. Type revisions explicitly declare properties, scalar/nested value validation, endpoint constraints and allowed states/transitions. The initial validator supports direct definitions and explicit references; unsupported inheritance/composition is rejected, never guessed. Existing instances retain their type revision until an explicit validated upgrade Command.

Independent relationships are objects; scalar properties remain typed values. Ordinary data removal clears or replaces current data without destroying object identity, dependent relationships or required history. The demonstrator should retire rather than hard-delete objects, preserving authorised historical references; any explicit destruction path requires a separate governed contract. Store new Assertions for new accounts; change standing through recorded transitions. Files use opaque handles outside the public web root; begin with manual text/source-reference capture, not automated document extraction. Meaningful export uses a versioned JSON manifest with authorised objects/revisions, dependency references and explicit missing/inaccessible dependencies; secrets are excluded and conflicting imports are rejected.

**Current implementation status:** bounded migrations and physical structures for typed objects, retained revisions, relationships, governed Commands and related evidence exist, with bounded typed validation and authorized retrieval evidenced in [implementation status](status.md). These slices do not constitute universal or full capability implementation: broader object categories, generic traversal, complete retrieval coverage and wider validation remain unbuilt or unverified. The remaining table and DDL details here are implementation specifications for the broader model, not a claim that every described capability is complete. SQL and DDL must remain compatible with MariaDB 10.5.26; the plan's MariaDB compatibility boundary defines the allowed mechanism.

## Transactions and HTTP Contracts

**Settled semantic contract:** [Command/Action execution](../architecture/workflows-and-automation.md#commands-executions-attempts-and-recovery) requires stable identities, explicit Attempts, safe-repeat semantics and explicit Unknown/Reconciliation. [Commit](../architecture/workflows-and-automation.md#action-preconditions-and-commit-boundary) rechecks current authority, Policy and versions; required state/history commit coherently.

**Chosen implementation mechanism:** one injected `CommandHandler` service. Where a reusable business capability is invoked, adapters supply an exact Operation Contract identity and revision, which resolves the approved handler semantics before producing the Command. The resulting Command carries its operation identity, targets, expected versions and typed payload. The server supplies authenticated User, authorised Business and source/technical-executor context; payload claims cannot grant authority. See the [Operation Contract](../architecture/operation-contract.md) for the semantic boundary; it does not replace CommandHandler.

1. Authenticate, validate transport shape and establish permitted Business context before exposing or admitting work. Resolve any exact Operation Contract identity and revision, then canonicalise the semantic request by sorting object keys recursively while preserving array order and scalar types; hash the encoded request with SHA-256. Include the resolved operation identity/revision, targets, versions, payload, User and Business binding, excluding transport metadata.
2. In a short transaction, lock `runtime_coordination`, validate admission authority, and insert the unique Command key plus addressable Command, Action Execution and initial Attempt/provenance. A duplicate with matching fingerprint refers to existing work; mismatched content is a conflict. Recheck result visibility before disclosing existing status. Concurrent duplicate delivery does not create another semantic operation or automatically another Attempt.
3. For local execution, lock the coordination row in another short transaction, reload authoritative state and governance dependencies, and perform the full validation/authority/Policy checks. All governance/configuration mutations use this same lock and pipeline, preventing a concurrent grant/revocation race during final validation. This deliberately serial initial mechanism retains optimistic expected-version checks and works across processes sharing the database.
4. Apply updates with `WHERE id = :id AND version = :expected_version`, incrementing the version. Zero updated rows is stale/incompatible, never last-write-wins. Validate and mutate all affected objects in one transaction; record new revisions, addressable transitions, provenance, required history and successful Command/Attempt result in that transaction. Any required write failure rolls back business effects and success evidence together.
5. The standalone handler owns its transaction. A participating handler detects the caller-owned transaction and creates a generic savepoint after admission/idempotency state and before governed mutation. Success keeps effects and evidence in the caller's transaction. Governed rejection rolls back mutation to the savepoint, then records rejected Outcome/Attempt evidence in that same transaction. Infrastructure failure rolls back to the savepoint, then records generic unknown/reconciliation evidence in that same transaction. The handler never begins or commits a nested transaction; the outer owner decides durability. If admission cannot be durably recorded, perform no consequential effect.

The same ownership rule applies to `SecurityAuditWriter`: it starts, commits and rolls back only when no transaction is active. Participating audit rows join the caller transaction and disappear with an outer rollback. Savepoint settlement is generic platform behavior; it does not depend on workflow Operations or dispatch participants.

Generic Commands and trusted Operation plans may carry an optional typed `resource_claim` commit predicate. The predicate is recursively canonicalised and fingerprinted as part of the Command contract. A server-owned allowlist resolves its kind to a configured guard; callers provide only resource, worker, fencing-token and expiry values, never tables, columns, SQL, callbacks or expressions. The shared `CommandHandler` resolves that guard under the existing `runtime_coordination` transaction and passes its trusted condition into the generic repository's expected-version `UPDATE`, where the database evaluates the claim state and UTC expiry at the guarded mutation boundary. A missing, replaced, mismatched or expired claim affects zero target rows, rolls back the attempted revision, and follows the normal rejected Command/Outcome/evidence path. Commands without a predicate retain the existing mutation behavior. Claim writers must use the same coordination lock; this is a reusable platform primitive and workflow dispatch is only a future consumer. It does not make external systems transactional.
6. If commit acknowledgement is lost, query the durable Command result on a fresh connection. Return the established result only when conclusive; otherwise report Unknown/Reconciliation. Never treat an exception after possible commit as proof of rollback. Do not repeat unsafe work to discover whether it succeeded.

External calls never run while holding the transaction lock. Persist an execution claim/Attempt and recheck dispatch authority immediately before invoking the bounded adapter with a deterministic idempotency key only where supported, then record observed outcome. Later revocation must not suppress evidence of effects already attempted. Possible remote acceptance followed by timeout stays Unknown; no automatic repeat of an unsafe external effect. Recovery uses an explicit authorised reconciliation Command and evidence. Initial external behavior is a fake test adapter, not live publishing. Required event records commit with state; later dispatch uses durable execution records as pending work.

Use `POST /commands` for mutation and `GET /commands/{id}` for authorised status, with existing safe form submission/AJAX patterns. Return `401` for authentication required, `403` for established-but-denied authority, `422` for invalid payload, `409` for stale versions or Command identity/content mismatch, and `202` with explicit `unknown`/`reconciliation_required` for unresolved admitted work. Successful terminal results return `200` with Command/result/transition references. Infrastructure rejection before admission returns `503` without claiming execution. Hide inaccessible object existence through consistent not-found/denied behavior. Correlation IDs are not authority; redact internal errors and secrets.

**Current implementation status:** the bounded shared Command handler, deduplication and transaction/history pipeline used by the verified admission slice exists. User registration and confirmation are bounded pre-authentication admission Operations (`principal.register` and `principal.confirm`, legacy identifiers for User registration and confirmation) executed through this governed Command boundary; `CommandHandler` owns the outer transaction and `PrincipalAdmissionService` (legacy class name) participates in it. Broader mutation coverage remains outside this milestone. Old routes are not compatibility contracts and are not permitted alternative writes into the new store. PHP/MariaDB compatibility and deployment prerequisites remain separate evidence requirements. No broader application or database behavior is claimed by this architecture document.

**Platform governance foundation status:** the runtime has an explicit platform/business scope value object, exact platform AuthorityGrant and Policy lookup, scope-aware Command fingerprint inputs, a trusted `business.create` plan handler and explicit composition-root registration. Migration `0010_platform_governance_scope` permits nullable platform Command/Event Business scope while retaining one idempotency mechanism. The bounded platform `business.create` path is implemented and behaviorally verified in the focused evidence recorded in [implementation status](status.md), including one atomic transaction for Command/admission evidence and Business bootstrap effects. Broader platform security and deployment certification remain outside that evidence.

**Normal Business-creation boundary:** The platform-scoped `business.create` capability follows the same Operation Contract -> server context -> typed validation -> CommandHandler -> evidence boundary, but its initial authority is resolved at platform scope because no target Business exists yet. The server supplies the authenticated User and generated Business identity; the caller cannot supply authority, Membership, grant, Policy or Business scope as authorization. The operation's Business, initial Membership, AuthorityGrant object(s), Policy and required provenance/history must commit atomically. The exact platform authority source, Operation Contract revision/handler registration, grant inventory, Policy configuration and any event name not already fixed by the Event contract remain implementation/configuration dependencies.

## Identity and Business Context

**Settled semantic contract:** [identity and governance](../architecture/identity-and-governance.md) separates authentication, actual actor, Business context, membership, authority and technical executor.

**Chosen implementation mechanism:** server-side PHP sessions with `password_hash`/`password_verify`, regenerated session IDs after authentication, Secure/HttpOnly/SameSite cookies, CSRF checks on browser mutations and durable rate limiting. Membership and scoped AuthorityGrant objects link Users (the legacy Principal Type) to Business and allowed operations/targets. Every request resolves current membership; consequential commit rechecks the current grant and Policy context. Initial navigation offers only authorised Businesses; selection is not a grant. Business/Organisation/Person identity is not implicitly authentication identity. Normal runtime admission is the separate User registration and confirmation lifecycle; no legacy admin bypass is permitted.

The first UI has login/logout, Business selection, typed object list/detail, declared operation forms, revision/transition/provenance inspection and Command status. Use server-rendered view definitions with an allowlisted field/renderer registry, existing visual tokens and small JavaScript enhancements. All mutations submit Commands; expose denied, stale, failed and unknown states honestly. No separate frontend store becomes authoritative. Session and credential controls are detailed in [operations](security-and-operations.md#initial-runtime-controls).

**Current implementation status:** the bounded User (persisted as the legacy Principal Type) membership binding, Business context and model-driven target surface are implemented and focused-verified. Broader identity coverage and the complete Surface UI remain unbuilt. No subscription, entitlement, billing, Licensed/Guest or activation enforcement is implemented; all Businesses are currently treated as active (intended future architecture: [subscriptions and entitlements](../architecture/subscriptions-and-entitlements.md); PRR-063).

### Legacy Principal Identifiers

**Settled semantic contract:** there is no separate Principal concept; the platform identity and authority subject is the User ([identity and governance](../architecture/identity-and-governance.md), [owner-correction note](../governance/decisions.md#unnumbered-cross-cutting-correction---user-replaces-principal)).

**Chosen implementation mechanism (documentation only; no code, database, Genesis or STAGING change):** the existing persisted Type is named Principal, but its records represent User accounts. Principal is a legacy implementation identifier, not a current architectural concept or a separate identity Type. No new User object or second identity model is introduced, and the existing Principal objects (for example the Stuart Mayne record) are Users; any future change is a rename, not a migration to a new model. The legacy identifiers remain until a separately authorized migration is designed:

| Artifact | Legacy identifier | Note |
|---|---|---|
| Type and Definition | Type named Principal with `principal_kind` (`database/genesis/idy-003.json`); the Principal Definition and `principal_initialization` workflow | Genesis manifest digests depend on these. `principal_kind` is likely redundant if every User is a human account (open question). |
| Membership and AuthorityGrant values | `principal_id` | Types use `additionalProperties: false`, so a rename needs governed Type revisions, which are blocked by Stage 3D (PRR-002). |
| Retained evidence | `principal_id` in Command, Attempt, Provenance, Event and authority-binding vocabulary (`idy-005-vocabulary.json`, 007C) | Immutable history; never rewritten. |
| Tables | `principal_identities`, `principal_confirmation_challenges` (migration `0012_principal_admission.sql`) | Protected identity boundary. |
| Operations | `principal.register`, `principal.confirm`, their handler keys and `idy-platform-opening-effects.json` | Exact Operation names and revisions. |
| Configuration | `submitter_principal_id`, `reviewer_principal_id`, `responsible_principal_id` (`database/configuration/idy-008/demonstrator.json`) | Business-scoped configuration. |
| Code and tests | About 1,400 code and 690 test references (counted 2026-11-02) | Class, method and variable names. |

**Future work, not authorised:** an identifier reconciliation (Type revisions, Operation renames, column and code renames, vocabulary and manifest regeneration, and retained-evidence aliasing) requires a separately authorised migration design and the Stage 3D decision (PRR-002, PRR-061). The Relationship Type `c2000000-0000-4000-8000-000000000106`, named Person to Principal, would be reframed as a Business-scoped User-to-Person link under the privacy rules in [identity and governance](../architecture/identity-and-governance.md#user-account-and-person-profile). Documentation runs ahead of code here: this is a surfaced implementation gap, not a reason to rename. Implementation status: documented only; no migration is built or verified.

## Authority and Policy Mechanism

**Settled semantic contract:** [Policy composition](../architecture/semantics.md#composition-and-conflict-resolution) is explicit and governed; otherwise an authorised human resolves conflicts. Policy relationships alone grant neither precedence nor exception authority.

**Chosen implementation mechanism:** versioned typed Policy objects with explicit scope, effective interval, conditions and composition references. Implement a small allowlisted expression interpreter supporting typed equality, membership, numeric comparisons and Boolean `all`/`any`/`not`; no `eval`, arbitrary code or AI interpretation. Unknown/missing input is not a successful condition. Initial policy configuration requires current membership, an explicit target/operation grant, valid expected version and any declared approval.

Evaluate configured composition rules and store an addressable determination containing inputs, Policy versions and rationale. When no rule resolves a conflict, stop effects and create a scoped review Decision request. The review form records the authorised person's determination; it cannot grant missing authority, suppress type validation or automatically create a global override. Exceptions and delegation are explicit typed arrangements with authoriser, scope, period, conditions and provenance, checked again at commit. Initial configuration allows no onward delegation unless explicitly declared.

Approval and materialised-validation reuse compare exact target/proposal, Policy and input revision dependencies, scope and validity state. A mismatch requires a new determination in the initial implementation rather than speculative reuse. This conservative mechanism does not broaden meaning or invalidate underlying Validation merely because a materialised determination expires.

**Current implementation status:** the evaluator, scoped review surface and declaration library are not built. The first workflow uses bounded human approval and deterministic operations, not an autonomy-tier product.

## Async Work and Extensions

There is no general job processor to invoke simply by creating a class or adding a directory.
Workflow definition, workflow execution, event, trigger, schedule, job, automation, action and outcome must remain distinct; use their canonical owners rather than defining them here.
The initial workflow interpreter stores WorkflowExecution objects with pinned definition revision, input references, current node, dependency references, Action Executions and results. Support sequential transitions, explicit conditions, local mutation Actions, human approval and waits; refuse unsupported node types. Dependency resolution must distinguish resolved, legitimately absent, unresolved, incompatible and execution-failure conditions; unresolved input must pause or invoke an explicit resolution path rather than fabricate data. A guarded database claim identifies worker and attempt. The current bounded runtime dispatches synchronously from the post-commit Command path; no CLI dispatcher or general worker is present. A future dispatcher, if separately built, must share the same Command service and governed claim boundary.
The bounded IDY-007 Slice 1 implementation uses the Business-owned `workflow_dispatch` Operation for claim, release and the five-target lease-bound finalization boundary. Its fixed `WorkflowDispatchCommandParticipant` maintains only the derived dispatch/lease projection in the same governed Command transaction; `workflow_end` remains the semantic Operation for pinned end-node outcomes. The source now also implements the contract-defined `workflow_reconcile` Operation, expired-lease quarantine and bounded safe-resume/reconciliation participation. Wake processing, a general dispatcher and automatic retry/replay remain unimplemented.
Use a 60-second renewable execution lease for local work; an expired claim is fenced and, in the documented future recovery extension, is quarantined through a governed reconciliation Operation before any repeat. It is not permission to resend an unknown external effect. Safe resume requires durable proof that no consequential Operation or unresolved Command remains; current node and step count are insufficient. Local safe-repeat recovery reuses the stable semantic Command identity only after explicit reconciliation and current authority/dependency checks, retaining each actual retry Attempt. The current synchronous path has no automatic retries of unknown external operations and no mandatory broker. Cancellation and recovery remain governed capabilities, not direct state edits. Log worker identity, claim, heartbeat, safe error classification and reconciliation references without credentials.
Long-running HTTP handlers are not a substitute for that design, but moving current remote calls requires an explicit implementation change.

The old module examples describe intended registration, not a working loader. Use explicit action/adapter registration in the composition root; dynamic discovery is unnecessary.

Initially support explicit UTC wake times and human-decision waits, not a recurrence language. For local-time input require a named timezone and reject nonexistent or ambiguous daylight-saving times until the user supplies an unambiguous instant. An overdue one-time wake makes the same execution eligible for rechecked continuation, not a new Command. Limit one dispatcher pass to 100 steps; a detectable or runtime-discovered cycle or exhausted bound records a suspended/review-required result with causal evidence. Stable eligible-time/ID ordering is an implementation choice, not business precedence. Recurrence, priority optimization and bulk catch-up are unsupported operations rather than implicit defaults.
Adapters may advertise operations such as connect, draft, publish, delete or fetch metrics according to actual support.
Do not require every adapter to implement every old publishing operation or create module-owned domain tables.
Resolve new capability needs through types, relationships, configuration and workflows before adding reusable execution behavior.

## Controlled Bootstrap

**Settled semantic contract:** foundation-only [genesis](../architecture/objects-and-types.md#controlled-genesis), followed by a separate deterministic platform opening/release. Genesis is not an ongoing privilege bypass, a second pseudo-Genesis or generalized IDY-008. There is no special first Business; Spearmint is the first demonstrator.

**Chosen implementation mechanism:** a restricted CLI initializer for a fresh isolated new-runtime database. An immutable versioned manifest assigns stable foundation addresses. Within a controlled transaction, insert and validate only the generic object/revision prerequisites, Type-of-Type semantics, minimum foundational Type descriptors and required Genesis occurrence/ledger vocabulary. Record manifest digest, technical installation/release provenance and created foundation object/revision references coherently. Re-running the same manifest verifies existing identity/digest and performs no duplicate creation; conflicting, populated or partly foreign stores are refused. The implementation must not create a human User (legacy Type name Principal), credential, Business, Membership, Business AuthorityGrant, Business Policy, owner, superuser, permanent administrator, customer View or human runtime actor.

The technical installation identity is provenance only, never a User, credential, session, actor or authority grant. It cannot authenticate, authorize `business.create`, impersonate a User or issue continuing authority. Platform opening is a separate deterministic release/configuration that installs the identity-lifecycle Operation descriptors and trusted handlers, confirmation/onboarding rules, the platform `business.create` Operation, active platform Policy and technical release evidence. It creates no human state or continuing authority and is not generalized IDY-008.

After platform opening, normal runtime is `registration -> confirmation -> authentication -> bounded onboarding -> business.create`. Create Spearmint Design as a distinct Business through that ordinary governed operation, with explicit grants rather than inferred sharing. Install the bounded [Spearmint configuration](../product/roadmap.md#generic-business-scoped-demonstrator) only after the Business exists and retain its configuration provenance. No existing setup script is the new Genesis or platform-opening command.

IDY-008 configuration releases are reusable content packages applied to an existing authenticated Business context. A release digest identifies the release content, not a tenant, and a release must not embed a production Business ID, User ID or authority bootstrap. The current IDY-008 scaffold remains tenant-bound and is recorded in [implementation status](status.md) as later implementation work; this documentation does not change that code.

**Normal Business creation boundary:** The post-opening `business.create` capability is a platform-scoped governed operation, not Genesis provisioning, external tenant provisioning, a generic `object.create` alias or Business-scoped administration. It creates the Business and its initial governance through the ordinary Command boundary. That governance is one active Membership for the initiating User, an active Business-scoped allowing inspection grant/policy for `platform.inspect_foundation` targeting only Business Type, and an active Business-scoped allowing configuration-install grant/policy for `platform.install_configuration` targeting `TYPE_OF_TYPE`. The creator can initially inspect only the newly created Business and can invoke the existing IDY-008 installer; these objects do not create permanent ownership, an immutable administrator, a fixed hierarchy or an unrestricted superuser. `platform.inspect_foundation` is ordinary governed Business-scoped inspection, not Genesis inspection.

**Implementation/configuration dependencies:** the platform-level authority used before a Business context exists, the exact active Operation Contract revision and trusted handler, the concrete grant operation/target-Type inventory, the initial Policy configuration and any Business-creation Event name not already established by the Event contract. The implemented bounded path generates the Business identity and resolves the User server-side, rejects client authority claims, applies existing Command idempotency and commits all required Business/governance/evidence state atomically. Focused evidence and remaining limits are recorded in [implementation status](status.md); this does not claim broader security or deployment certification.

**Platform Definition publication (BUILD scope):** `definition.publish` uses the universal `OBJECT_DEFINITION_TYPE`, Candidate A exact Object references, and bounded non-executing validation specified in [Objects and Types](../architecture/objects-and-types.md#generic-definition-payload-and-reference-contract). It creates or revises one Definition Object at an explicit Type revision and expected Object version and atomically records availability for the exact resulting revision with existing Command/evidence/provenance mechanisms. The owner User, grant and Policy boundary is specified in the [Identity and Governance contract](../architecture/identity-and-governance.md#platform-definition-publication-authority) and [publisher configuration mechanism](security-and-operations.md#definition-publication-authority-configuration). No bootstrap CLI, Genesis authority, authority-management Operation, publication store or Business application path is involved.

**Action execution (BUILD scope):** An Action is provider-independent semantic meaning; an exact Operation Contract supplies its governed executable contract. Declared parameter sources resolve server-side through authorized reads. An external Action with no local target authorizes against the exact Operation Object ID using the existing Business Grant/Policy model, represented by the Operation Type and `target_operation_ids`; the exact current revision and authority are rechecked under the coordination lock. Operation Type descriptor revision 2 adds optional `execution_kind` and `authority_subject` without changing revision-1 Contracts. The existing CommandHandler records a no-effect Command (`effects=[]`) and atomically retains Action Execution, Attempt, simulated Outcome, Event and Provenance; its fingerprint binds Operation ID, revision, validated inputs and source references. The trusted no-network `send_email` Provider reports simulated/not-sent and does not persist raw recipient or message content. Live providers, credentials, async external execution and broad settings UI are deferred.

**Current implementation status:** foundation-only Genesis conformance and the deterministic platform-opening release/effect mapping remain unchanged. `TargetProvisioningRunner` owns the explicit post-owner publisher grant/Policy configuration mode. The working tree implements the generic Definition Type history matrix and governed publication/configuration boundaries. The canonical target runtime uses ordinary Objects, Definitions, Operations, Relationships and recursive Presentation Objects; retained Capability-named descriptors/projectors are historical compatibility material and are not registered in the current runtime. PHP diagnostics, descriptor tests, release validation and the staging-derived disposable clone rehearsal pass. The generic Business Presentation correction was deployed to STAGING by release workflow run 343 from commit `e5778e23c019b44855afeb94eeba6c2109fb5049`; authenticated browser verification observed the existing Spearmint Design Business resolve its persisted Dashboard and Overview navigation. Focused status, evidence and remaining limits are recorded in [implementation status](status.md).

**Presentation vocabulary provisioning:** the platform-owned Presentation Object
Type is installed by the established target provisioning runner and by the
idempotent runtime-vocabulary reconciliation command. The authenticated
Business Presentation reconciliation boundary also ensures this platform
vocabulary is current before creating tenant-scoped Presentation Objects, so
an existing Business can recover from a target that missed vocabulary
installation. This is platform vocabulary configuration, not a
Business-specific registry or a shortcut around the governed Object Commands.
Business Presentation profiles remain data-defined; their Dashboard and child
Presentation Objects are created or revised only through the governed
Business-scoped Command path after the platform vocabulary is present.

**Bounded functional Business surface:** the generic presentation profile may
declare persisted navigation entries for product capability labels without
creating a capability-specific runtime subsystem. The current bounded profile
represents all eight catalogue labels, gives People and Projects internal
workspace destinations, and explicitly marks the other six surfaces as
presented but not record-operational in this increment. The People and
Projects workspaces use the existing platform Person, Organisation and Project
Types, authorized Business-scoped reads and generic Object create/update
Commands. Their persisted list/detail views are installed through the
Business-scoped configuration installer; workspace actions are only successful
when the governed Command settles.

## Universal Definition and Action Foundation Plan

This is the chosen implementation plan for the settled contracts in [Objects and Types](../architecture/objects-and-types.md#generic-definition-payload-and-reference-contract), [Identity and Governance](../architecture/identity-and-governance.md#platform-definition-publication-authority), [Operation Contract](../architecture/operation-contract.md#platform-definition-publication), [Workflows and Automation](../architecture/workflows-and-automation.md), and [Communication and Integrations](../architecture/communication-and-integrations.md). The explicit external Action authority target is now settled and the bounded Definition/`send_email` foundation is implemented as recorded in [status](status.md). This plan creates no new architecture decision and does not reopen any settled contract.

### Scope and Constraints

Use the existing universal Object/revision model, governed platform AuthorityGrant and Policy Objects, trusted Operation handlers, Command mutation boundary, and retained Action Execution/Attempt/Outcome/Event/Provenance evidence. Capability Definitions and Business Capability Instances are retired from the current runtime architecture. Historical implementation detail below is retained as lineage only; new provisioning uses ordinary Business, Data, Workflow, Logic and Presentation Objects.

Keep every retained Definition Type descriptor and its existing consumers working. Installation classifies histories only by their exact stored descriptor values and fails closed on any unknown history. For the retained strict Initialization descriptor at revision 1, append the optional-workflow Initialization descriptor at revision 2 and the generic Definition descriptor at revision 3. For the older relaxed Initialization revision 1 and generic Definition revision 2 history, preserve both and append the generic descriptor at revision 3. If relaxed revision 1 is present without revision 2, append the generic descriptor at revision 2, then revision 3. Revision 2 is never reassigned a different meaning. New Initialization Definitions use the retained Type revision whose exact descriptor is the optional-workflow Initialization descriptor; existing Objects and Type revisions are never rewritten. Generic published Definitions use exact Type revision 3. The Capability Definition subject Type revision 2 is likewise immutable; append its revision 3 with exact references to generic Definition Type revision 3, and have new Capability Definitions bind to that subject Type revision. Publication availability is derived only from successful evidence for the exact Object revision. The generic Definition foundation adds no publication table, universal publication status, capability-specific store/registry or schema migration; the separately approved Application uses the retained Business Capability Instance Type revision and existing Operation/Command boundary. Live providers, provider credentials, asynchronous external delivery, broad settings UI, authority-management Operations, and publisher reassignment remain excluded.

### Completed Implementation Sequence (Original Planned Detail)

**Progress as of 2026-09-30: all five bounded implementation stages below are complete.** The numbered descriptions preserve original implementation planning detail; they are not pending work or authorization for another feature build. The actual publisher installer resides in [DefinitionPublisherAuthorityInstaller](../../app/Release/DefinitionPublisherAuthorityInstaller.php) and is included in the internal provisioning package; Genesis and platform-opening artifacts were not changed. Current focused evidence and limits are in [implementation status](status.md#generic-platform-definition-publication-boundary).

1. **Bind and install the initial publisher.** Add `IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID` (legacy identifier for the publisher User) to [TargetRuntimeConfig](../../app/Runtime/Bootstrap/TargetRuntimeConfig.php) using its existing environment loader. Add a narrow installer under `app/Runtime/Configuration/`, invoked through a separate guarded post-owner configuration mode in [TargetProvisioningRunner](../../app/Release/TargetProvisioningRunner.php) and [bin/provision-target.php](../../bin/provision-target.php). Require the configured UUID to resolve to the already-existing active project-owner User (legacy Type name Principal) and verify the selected database identity and current platform foundation/opening. Under the existing coordination boundary, idempotently install only the direct platform `definition.publish` AuthorityGrant targeting `OBJECT_DEFINITION_TYPE` and its matching active platform Policy using existing descriptors and generic Object persistence. A missing identity or partial/conflicting objects fail closed. Include implementation files in the internal provisioning package allowlist as needed. Do not change Genesis or the immutable platform-opening artifact.
2. **Validate complete Definitions.** Add a `DefinitionCompositionValidator` under `app/Runtime/Definitions/` and register it through the existing [TypeSemanticValidatorRegistry](../../app/Runtime/Store/TypeSemanticValidatorRegistry.php) in [TargetRuntimeCompositionRoot](../../app/Runtime/Bootstrap/TargetRuntimeCompositionRoot.php) and applicable installation/test compositions. Keep the existing Definition Type revision intact and add its generic retained descriptor revision in [InitializationVocabulary](../../app/Runtime/Initialization/InitializationVocabulary.php). Validate the subject Type and exact Type revision, recursively validate inline typed values, and resolve each `object_reference` only at its exact Object ID/revision. Derive referenced Type identity/revision from that retained Object revision. Check requiredness, compatibility, access and exact publication availability for separately addressable Definition dependencies. Reject cycles; permit repeated non-cyclic references; enforce depth 6, 100 unique Object revisions and 200 reference edges. Inspection/validation must not execute Workflow or Logic.
3. **Publish through the governed platform Operation.** Add `definition.publish` identity and handler registration through [FoundationIds](../../app/Runtime/Auth/FoundationIds.php), [OperationVocabulary](../../app/Runtime/Operations/OperationVocabulary.php), [OperationSemanticValidator](../../app/Runtime/Operations/OperationSemanticValidator.php), [OperationResolver](../../app/Runtime/Operations/OperationResolver.php) and the existing trusted handler registry. Add a focused publication handler. Extend [AuthorizationService](../../app/Runtime/Governance/AuthorizationService.php) to authorize only explicitly supported platform Operations and reuse direct grant plus matching Policy checks. Add a narrow platform invocation path to [OperationInvocationService](../../app/Runtime/Operations/OperationInvocationService.php) and [CommandHandler](../../app/Runtime/Commands/CommandHandler.php). Require an exact Operation revision, caller-owned security fields rejected, and current grant/Policy plus expected Object version rechecked at commit. Atomically create/revise only the Definition and retain evidence/provenance identifying the exact resulting Object revision.
4. **Inspect persisted Definition compositions.** Extend existing platform evidence descriptors/settlement through a retained descriptor revision where needed so successful publication evidence names exact `(object_id, resulting_object_revision)`. Persist the Definition Presentation binding through the existing Business Presentation provisioning path and inspect each authorized Definition through `/objects/{id}` and the shared generic Presentation renderer. Recursive composition inspection remains a bounded service concern; it must not create a Definition library route, special renderer or alternate URL family. Report unresolved, inaccessible, incompatible, cyclic and truncated results without leaking protected existence. The User allowlist remains an authorization boundary for platform Definitions, not a library-route presentation gate.
5. **Run Actions through Operation contracts with simulation only.** Extend [OperationVocabulary](../../app/Runtime/Operations/OperationVocabulary.php), [OperationSemanticValidator](../../app/Runtime/Operations/OperationSemanticValidator.php) and [OperationInputValidator](../../app/Runtime/Operations/OperationInputValidator.php) compatibly for the documented parameter sources: explicit user input, current Object, related Objects, Business configuration/context, another Action, or trusted programmatic invocation. Resolve non-user values server-side through authorized reads and exact revisions; presentation transports values but does not resolve them. The Operation Type revision 2 descriptor adds optional `execution_kind` and `authority_subject` while retaining revision 1. Authorize an external Action against the exact Operation Type/Object ID through the existing Business AuthorityGrant and Policy Objects, and recheck the exact current Operation revision plus authority under the existing coordination lock. Reuse the Command identity/fingerprint boundary and existing Action Execution/Attempt/Outcome/Event/Provenance Objects; a simulated external Action has no local mutation effects. Register one trusted no-network `send_email` Provider/handler in [TargetRuntimeCompositionRoot](../../app/Runtime/Bootstrap/TargetRuntimeCompositionRoot.php), record an explicit simulation/not-sent result, and never label it remote acceptance, sent or delivered. Include new runtime files in the reviewed public target release boundary; keep provisioning-only configuration code in the internal provisioning package.

### Verification and Remaining Scope

Focused implementation and package evidence is recorded in [implementation status](status.md#generic-platform-definition-publication-boundary) and [target release evidence](status.md#target-release-foundation-evidence). It includes the Definition validator/publication/Explorer, publisher installer, server-side input resolution, exact Operation-identity authorization, simulation-only `send_email`, package guards and read-only public target resolution. These bounded slices are not full-runtime or deployment certification.

An earlier IDY-010 HTTP attempt stopped in historical IDY-008 fixture setup because `capability_derivation.definition_revision` was absent from the retained Type descriptor; this is historical and superseded by v3 removal of those capability declarations. The current IDY-009 fixture now uses governed Definition publication and Application. Its local HTTP-wrapper result is not counted as authoritative verification because that wrapper sourced from local `idiosyncrasy_dev`; staging-refreshed PHPUnit verification is blocked by the configured loopback staging-source guard. See [implementation status](status.md#capability-definition-and-application-build) for exact evidence and limitations.

## Canonical Object Presentation Boundary

`/objects` is the only object presentation URL family. It resolves authorized
User, Business, Person, Organisation, Project and other core Objects
through the same Object/revision, Type/Definition, Presentation Object,
projection and renderer pipeline. Platform-scoped User and Business roots
remain protected by explicit self/current-membership scope rules; their
platform scope does not create a second object model.

The global `/objects/{id}` route is the only persisted Object detail and
Presentation entry point. Definitions, Logic, Workflow, Presentation,
User, Business and Business-derived objects all resolve through the same
authorized Object, Type, Definition, persisted Presentation and governed
Command/Operation pipeline. Capability routes, library routes and
semantic-role routes are not registered and must not be replaced with
compatibility redirects. Genuine process endpoints (authentication,
Business selection/creation, initialization, reconciliation, command and
operation invocation) may remain only when they do not present or mutate an
ordinary Object through a parallel path. Any new feature must preserve this
boundary and add regression coverage against bespoke presentation routes.

## Presentation Layout Implementation Boundary

The generic Presentation implementation has one outer layout mechanism and
one recursive rendering path. `LayoutPackingEngine` owns only the six-column
arrangement of the current page-surface Presentation Objects. It owns
permitted outer spans, effective positions and rows; it does not own the
content layout inside a Presentation Object.

Each grid-level Presentation Object is rendered inside its own generic
surface. Recursive child Presentation Objects, field content and repeated
record content remain inside that surface and must not receive the parent
outer-grid position/span metadata. The HTML renderer may serialize the
surface and internal layout, but it must not infer business semantics or
perform authorization.

The implementation verifies the outer six-column packing and governed
order/span/height preferences. The generic projector applies that packer only
to the current page-surface list; recursive content is delivered through an
independent content grid inside each PO surface. The generic User Presentation
Preference Type remains revision 2 and has no internal-content-column
preference. Compact/Regular/Expanded delivery and one-/two-/three-column
internal content are derived from the effective outer span; responsive
adaptation may reduce the effective count without rewriting the persisted
outer preference or the Presentation Object graph.

## Implementation Acceptance

The [roadmap](../product/roadmap.md#first-executable-milestone) defines the executable milestone. [Invariant tests](development.md#invariant-test-specification) prove authority, concurrency, coherent history, repeatability and recovery using isolated MariaDB 10.5.26/InnoDB fixtures. PHP/MariaDB compatibility and deployment prerequisites must be executed and recorded before claiming full-runtime or production VERIFIED status; focused component verification is limited to the evidence in [status](status.md). No application or database changes are part of this documentation integration.