# Data-Defined Semantics Audit

Status: repository audit completed at `ac2c41d87fa4bfb21d56987da68dc2b9e8731770`
on 2026-10-18. This document records implementation evidence and a
remediation plan. It does not change the settled D01-D10 architecture or
authorize a Products & Services build.

> **Terminology note, 2026-11-02.** "Principal" in this dated audit and its recorded evidence means User (the platform identity), and is superseded terminology; the persisted Type is named Principal, but its records represent User accounts (see [legacy identifiers](architecture.md#legacy-principal-identifiers)). Dated sections are retained as evidence. This audit is a dependent implementation record, not a canonical owner.

## Batch 0 baseline freeze — 2026-10-18

This is the current documentation-only B1 baseline. The worktree was verified
on branch `main` at the recorded HEAD with 52 changed tracked paths, two
deleted tracked paths and 15 untracked paths. No existing modification or
untracked file was changed, staged, committed, pushed, deployed or discarded
by the Batch 0 inspection. No database, grant, Policy, STAGING or production
system was accessed or mutated.

The fresh read-only compliance result remains **FAIL: 12 retirement
violations across 180 scanned runtime/release files**. The count is current
gate evidence, not a count of all historical audit-register rows. Historical
15-, 13- and 18-finding snapshots below remain historical evidence and are not
silently rewritten. The 12 current findings are:

1. F-03 at `TargetRuntimeCompositionRoot`, `BusinessRecordService`,
   `BusinessPresentationProvisioningService` and `TargetHtmlBoundary`;
2. F-04 at `BusinessPresentationProvisioningService`;
3. F-05 at `BusinessPresentationProvisioningService`;
4. F-06 at `PlatformLogicDefinitionService`;
5. F-09 at `AuthorityPolicy` and `DeterministicReasoner`;
6. F-10/F-19 at dormant direct-write setup in `TargetRuntimeBoundary` and
   `TargetHtmlBoundary`; and
7. F-12 at the reachable target reconciliation route.

The seven rows above account for twelve emitted findings because F-03, F-09
and F-10/F-19 each have multiple source locations. F-01, F-02, F-07 and F-08
remain broader audit-register dependencies that are not additional rows in
this fresh static result. They remain open and are assigned to later batches.

### Exact binding contract status — approved Form ownership, 2026-10-18

The existing canonical owners settle the following implementation contract:

- All semantic Object bindings use
  `{kind: "object_reference", id: UUIDv4, revision: positive integer}`.
- The exact Object revision supplies the authoritative Object value, Type
  identity and Type revision. Runtime resolution never substitutes current or
  latest revision.
- Persisted Presentation Object `view_reference` bindings and the Business
  dashboard reference are exact. The shared resolver enforces identity,
  revision, Type compatibility, Business/platform scope, Principal authority,
  applicable usability/publication checks and fail-closed diagnostics.
- The Operation Contract settles exact Operation identity/revision for View
  Actions. `operation_ids` and name-only/current Operation lookup are not an
  approved final binding contract. Operation references do not grant
  permission; lifecycle, Policy, scope and active authority remain separate.
- Generic Object create/edit surfaces are View-driven. Their exact persisted
  View/Presentation binding supplies the editable fields; a separate Form
  Definition Object is not mandatory. The governed `object.create` and
  `object.update` Command effects remain the mutation path.
- A distinct transition Form is a Business-scoped persisted Form Definition
  Object selected only by an exact action-level `form_reference` owned by the
  persisted Presentation action/affordance. The reference is
  `{kind: "object_reference", id: UUIDv4, revision: positive integer}`.
  The action must persist compatible target Type and invocation context rather
  than derive them from labels, legacy IDs or first-match enumeration.
- A Form reference is independent of an exact persisted Operation reference.
  Actions invoking persisted Operation Contracts retain exact Operation
  identity/revision and normal lifecycle, scope, compatibility and
  authorization checks. `object.transition` remains a foundation governed
  Command effect for this migration; it is not manufactured into a revisioned
  Operation Object.
- Historical Form revisions remain immutable and addressable when authorized.
  A platform Form would require existing platform publication evidence; this
  audit does not create a Form-specific publication subsystem.
- Missing, malformed, stale, unavailable, unauthorized, cross-Business,
  wrong-scope, unpublished-when-required and incompatible references fail
  closed. Binding mutations retain expected-version, authorization,
  provenance, idempotency and immutable history requirements.

### Batch 1 implementation evidence — exact Presentation bindings

The existing Presentation action mechanism now accepts an optional exact
`form_reference` and validates the persisted target Type, target Type
revision and invocation context. Foundation `object.transition` remains a
governed Command effect; no revisioned Operation Object is manufactured for
it. Persisted Operation targets use an independent exact Object reference and
the shared exact resolver. A Form reference never grants permission.

Generic Object create/edit requires an exact persisted View identity and
revision, validates its target Type revision and derives editable fields from
the validated View projection. It continues through the governed
`object.create`/`object.update` paths. Transition Form selection no longer
enumerates Forms or selects the first match. Legacy `form_id` is not resolved
and is never runtime semantic authority; when present for compatibility it is
checked only against the persisted binding and mismatches fail closed.

Focused evidence is 33 tests/238 assertions for `Idy006BPresentationTest`,
14 tests/48 assertions for `ExactObjectReferenceResolverTest`, and 2
tests/32 assertions for `BusinessScopedViewDefinitionAuthorityTest`, all with
zero failures and errors. `OperationFoundationTest` remains red with 6 errors
in 73 tests/116 assertions, and `OperationInputResolverTest` remains red with
3 errors and 1 failure in 7 tests/6 assertions. Those failures are existing
Operation lifecycle/authority/setup blockers and prevent claiming complete
Batch 1 regression readiness. The read-only compliance audit remains FAIL
with 12 findings across 180 runtime/release files.

The consumer inventory and acceptance handoff below are the pre-Batch 1
baseline and remain useful as historical gap evidence. They do not describe
the current Presentation implementation. Batch 1 remains incomplete until
the blocked Operation regressions, required exact Operation-action coverage
and compliance findings are addressed in their appropriate scoped work.

### Frozen View, Form and Operation consumer inventory

| Consumer | Current source evidence | Required persisted authority | Batch 1 proof |
|---|---|---|---|
| `PersistedPresentationObjectProjector` collection/action bindings | Exact `view_reference` and `operation_reference` values are already traversed | Persisted Presentation Object graph | Historical exact revisions, cross-Business isolation and unauthorized dependency failures remain closed. |
| `TargetHtmlBoundary` explicit View requests | `view_revision` is accepted and passed when present; omitted explicit revision fails through `PresentationCatalog` | Persisted parent View reference or validated exact request | No omitted revision; historical View remains selected. |
| `TargetHtmlBoundary::genericObjectForm()` | Reads `BusinessRecordCatalog`, translates `view_id` and calls `presentationDefinition()` | Persisted exact View/Presentation binding; no separate Form is mandatory | Missing/incompatible binding fails; catalogue cannot reconstruct the View/Type surface. |
| `TargetHtmlBoundary::recordViewHref()` | Translates catalogue `view_id` and hard-codes revision 1 | Persisted exact View reference | Revision 2 is not silently replaced with 1. |
| `TargetHtmlBoundary::transitionFormId()` | Enumerates Business Form Definitions and returns the first matching ID | Exact action-level `form_reference` plus persisted target Type/invocation context | Exact historical Form resolution; ambiguous/unbound Forms fail closed. |
| `PresentationCatalog::form()` | Allows a null revision and uses `findCurrent()` | Exact Form reference from the owning parent | Missing/stale/newer/unauthorized/cross-Business/incompatible references fail closed. |
| `PresentationCatalog::validateOperations()` | Accepts `operation_ids` and uses current Operation lookup | Exact Operation identity/revision for View Actions | Active exact Operation resolves; retired/draft/current substitution fails. |
| Configuration JSON/profile declarations | Carry View IDs and omit complete Form/Operation exact bindings | One-way install input only; persisted Objects own runtime semantics | Persisted binding changes alter behavior without source catalogue edits. |

This inventory is an implementation map, not a new semantic model. It does not
authorize a runtime change in Batch 0.

### Batch 1 acceptance handoff

Batch 1 may begin as a separate BUILD task after the approved action-binding
schema extension is scoped and its exact persisted fixture shape is defined.
Its focused acceptance names are:

- `testFormReferenceResolvesRequestedHistoricalRevision`;
- `testFormReferenceDoesNotFallBackToCurrentRevision`;
- `testFormReferenceRejectsMissingMalformedStaleUnauthorizedCrossBusinessAndIncompatibleBindings`;
- `testGenericObjectFormRequiresPersistedExactViewAndTypeBinding`;
- `testTransitionActionResolvesExactPersistedFormReference`;
- `testTransitionActionRejectsAmbiguousUnboundForms`;
- `testTransitionActionRejectsWrongFormTypeAndTargetType`;
- `testTransitionActionRejectsIncompatibleCommandContext`;
- `testHistoricalPresentationRetainsExactViewAndOperationRevisions`;
- `testViewActionResolvesExactActiveOperationRevision`;
- `testTransitionUsesGovernedFoundationCommandEffect`;
- `testLegacyFormWithoutAuthoritativeBindingIsQuarantined`;
- the existing exact resolver tests in
  `ExactObjectReferenceResolverTest`;
- the exact Business isolation tests in
  `BusinessScopedViewDefinitionAuthorityTest`;
- the Presentation transition and action regressions in
  `Idy006BPresentationTest`; and
- the exact Operation lifecycle/dependency regressions in
  `OperationFoundationTest` and `OperationInputResolverTest`.

Batch 1 entry requires the shared resolver to remain the only Object
resolution boundary, the action-level Form binding schema to be explicit,
persisted exact bindings to exist in the fixtures, and catalogue/profile
callers to be classified as installation-only or quarantined.
Its exit requires exact historical revision preservation, Business/platform
scope and authorization checks, fail-closed malformed/stale/unavailable
behavior, no mutation on rejected bindings, syntax and diff checks, and a
fresh compliance result. Any remaining caller that cannot supply an
authoritative persisted binding must fail explicitly rather than choose a
current Object.

Batch 1 does not include Business record catalogue retirement, capability
authority migration, Logic/Workflow migration, direct-write retirement,
Products & Services configuration or Stage 3D evidence.

## Audit invariant

For every business or business-semantic definition:

> The authoritative durable representation is a governed Object, Type,
> Definition, Relationship, Operation, Logic, Workflow or Presentation Object
> in the Object database. Files may implement generic mechanisms, migrations,
> release integrity, infrastructure, tests or a one-way bootstrap operation,
> but a file must not remain the runtime catalogue, fallback or override for
> business meaning.

An installer is compliant only when all of the following are true:

1. it creates or publishes the persisted representation through the governed
   mutation boundary;
2. runtime resolution reads the persisted identity and exact revision;
3. reconciliation detects drift or uses an explicit governed migration rather
   than overwriting an authorized persisted change from stale source content;
4. missing or invalid persisted semantic data fails explicitly; and
5. changing the persisted definition changes runtime behavior without editing
   application source.

Stable UUIDs, operation names, handler keys, database connection settings,
release identities and other mechanism-level constants are not violations by
themselves. They become semantic-data violations when they select, describe or
override business Types, fields, records, relationships, rules, workflows or
presentation content at runtime.

## Verified B0 implementation evidence

The B0 exact Type-reference contract is locally implemented for the connected
AuthorityGrant target, Workflow direct-subject correlation and initial
Business-creation consumers. The canonical runtime shape is
`{kind: "object_reference", id: UUIDv4, revision: positive integer}`.
`ExactObjectReferenceResolver` validates exact Object identity and revision,
Type-of-Type compatibility, scope, authorization and applicable publication
evidence. It does not select a latest revision or infer revision 1.

AuthorityGrant descriptor revision 4 now persists `target_type_references`;
runtime readers reject missing or malformed legacy `target_type_ids`. Workflow
definitions persist `event_subject_type_reference`, and admission compares the
resolved Type Object revision with the Event subject's persisted Type binding.
Initial Business creation validates platform references under the existing
governed `business.create` bootstrap authority. After configuration installation,
Business-owned Type references are installed into the operational grant through
the existing Command pipeline. The CLI Workflow demonstrator and initialization
producers now carry exact references. `platform.type_revision` remains out of
scope and inactive.

Local evidence against the disposable database:

- Exact resolver: **13 tests / 33 assertions passed**.
- Business bootstrap: **10 tests / 213 assertions passed**.
- Workflow admission: **18 tests / 133 assertions passed**.
- Workflow validator: **21 tests / 54 assertions passed**.
- Relationship graph: **13 tests / 108 assertions passed**.
- Definition-publisher authority: **6 tests / 18 assertions passed**.
- PHP syntax: **373 files passed**; `git diff --check` passed.
- Compliance gate: **15 violations over 179 runtime/release files**, down from
  the previously recorded 18. The three retired B0 paths are bare
  AuthorityGrant Type targets, bare Workflow direct-subject Type correlation,
  and the initial Business-creation PHP Type fallback.

The compliance command now contains explicit B0 predicates for those three
consumer groups. They produce no violations in the current tree; the gate
will fail if a bare grant target, legacy Workflow subject-Type field or
`CapabilityCompositionVocabulary::PROJECT_TYPE` Business-creation fallback
is reintroduced.

The gate remains red for the independent catalogue, Presentation, Logic,
target-boundary, reconciliation and legacy capability findings listed below.
The B0 snapshot's Presentation failure was corrected in the B1 batch without
restoring a dedicated renderer or fallback; current B1 evidence is recorded
below. Production/STAGING adoption remains a separate blocker until the
authorized Type/dependent-object inventory is available. No remote database,
grant, Policy or deployment operation was performed.

## Verified B1 implementation evidence — persisted capability Definition composition

The B1 runtime composition path is now locally implemented through the
generic `DefinitionCompositionResolver` and
`DefinitionApplicationOperationHandler`. The former
`PersistedCapabilityProjector` and `CapabilityApplicationOperationHandler`
runtime paths are deleted; the persisted operation identity remains
`platform.capability-application` for compatibility, while its handler is
generic and resolves the requested Definition reference before deriving a
Business Capability Instance.

The complete standard graph used by the integration consumer is nine published
platform Definitions at revision 1:

| key | Definition Object ID | revision |
|---|---|---:|
| dashboard | `a8300000-0000-4000-8000-000000000009` | 1 |
| people | `a8300000-0000-4000-8000-000000000001` | 1 |
| products-services | `a8300000-0000-4000-8000-000000000002` | 1 |
| sales | `a8300000-0000-4000-8000-000000000003` | 1 |
| marketing | `a8300000-0000-4000-8000-000000000004` | 1 |
| operations | `a8300000-0000-4000-8000-000000000005` | 1 |
| projects | `a8300000-0000-4000-8000-000000000006` | 1 |
| finance-accounts | `a8300000-0000-4000-8000-000000000007` | 1 |
| knowledgebase | `a8300000-0000-4000-8000-000000000008` | 1 |

Each constituent Type reference is persisted as the exact
`{kind: "object_reference", id, revision: 1}` form. The migrated fixture
grants inspection for the two foundation identity Types and all 21
`CapabilityCompositionVocabulary::descriptors()` Type Object IDs; the
resolver rejects an unavailable or unauthorized constituent rather than
consulting the PHP descriptor catalogue. Definition publication evidence,
platform scope, Type binding, historical revision, cycle, depth, node and
edge limits are checked before application. Type Objects are validation
leaves for composition traversal: their persisted descriptors are validated
by the exact-reference resolver, but descriptor metadata does not consume the
Definition graph depth budget.

The migrated application consumer reads `navigation_order` from the persisted
Definition subject value and retains the existing Command, expected-version,
Business scope, provenance, publication and idempotency boundaries. Traversal
does not execute embedded Logic, Workflow or Operations. The catalogue remains
an explicit one-way publication input only.

The generic Presentation regression was corrected without a Business renderer
or authorization bypass. Its root cause was the shared Business administrator
fixture missing the exact persisted Principal Type inspection reference; the
fixture now carries that reference and generic `/objects/{id}` detail remains
the only detail surface. The capability integration test also provisions the
existing governed Business Presentation profile before checking the canonical
root redirect.

Local verification against refreshed disposable `IDY_TEST_IDY002`:

- Capability Definition application: **1 test / 103 assertions passed**.
- Presentation and graph regressions: **42 tests / 316 assertions passed**,
  with one existing warning.
- Exact-reference and installer containment regressions: **16 tests / 44
  assertions passed**.
- Installer, Definition publisher and Presentation/Logic composition
  regressions: **25 tests / 140 assertions passed**.
- Compliance gate: **13 violations over 180 scanned runtime/release files**,
  down from the B0 baseline of 15. The two retired findings are the
  capability-specific projector and capability-specific application handler;
  the gate now requires the generic composition resolver and fails if either
  legacy path returns.

The test wrapper still aborts when native Workflow inspection diagnostics are
written to STDERR. Direct PHPUnit invocation with the pinned PHP 8.3.33 and
PHPUnit 11.5.56 was used for the affected suites; the diagnostics are
reported as runner noise, not hidden test failures. Production/STAGING
adoption remains separately blocked by unavailable authorized production Type
and dependent-object evidence; no remote mutation, grant, Policy, deployment
or live migration was performed.

## Verified B1 exact Definition references and Presentation authority

The Definition application handler and Presentation runtime now use the shared
`ExactObjectReferenceResolver` for their persisted semantic references.
`DefinitionApplicationOperationHandler` receives and validates the authenticated
Principal, threads the Business context through configured Operation, View,
Form, constituent and nested navigation references, and maps resolver failure
to the existing governed operation error boundary. It does not introduce a
second resolver or execution path.

`PresentationCatalog` requires the shared resolver and no longer accepts an
optional resolver with a repository-only fallback. Explicit View Definition
lookup requires an exact revision; the former implicit `findCurrent()` path
for a supplied View ID is rejected. Persisted Presentation `view_reference`
bindings are already exact and are resolved before projection. The HTML
transition path now carries `view_revision` through the rendered form and
governed POST so the exact View binding is preserved end to end. Form-ID
resolution remains a separate legacy contract, but it is still passed through
the shared resolver and is not a Presentation Definition authority fallback.

Local verification against disposable `IDY_TEST_IDY002`:

- Exact resolver, Business-scoped View authority, graph, Presentation,
  production composition and installer regressions: **83 tests / 536
  assertions passed**, with one known Workflow inspection warning.
- Grouped Definition application proof: **1 test / 103 assertions passed**,
  with one known Workflow inspection warning.
- Final Presentation authority subset: **34 tests / 263 assertions passed**,
  with one known Workflow inspection warning.
- Changed PHP syntax checks and `git diff --check` passed.
- The compliance gate scanned **180 runtime/release files** and failed with
  **12 retirement violations**. The former optional Presentation resolver
  fallback is retired; F-03, F-04, F-05, F-06, F-09, F-10/F-19 and F-12
  remain independently open.

The exact View revision requirement exposed existing callers that supplied a
View ID without a revision. Valid persisted bindings and the focused
regression fixtures now carry `view_revision=1`; unsupported ID-only callers
fail explicitly rather than selecting the latest revision. The existing
Products & Services configuration gap and all B2/B3 catalogue migrations
remain outside this batch. No staging or production state was mutated.

## Scope and method

The audit covered:

- `app/Runtime` and `app/Release`;
- `bootstrap`, `bin`, `database` and `release`;
- `resources` and production-facing templates;
- integration, unit and HTTP acceptance fixtures;
- current architecture, implementation and governance owners; and
- the existing audit script and recorded test evidence.

Searches covered PHP constants and descriptor arrays, JSON manifests and
profiles, SQL seeds and direct object writes, Type/Definition references,
capability and record catalogues, presentation field maps, Logic and Workflow
payloads, fallback paths, provisioning/reconciliation, and runtime consumers.

The worktree was `main` at `ac2c41d`; `origin/main` resolved to the same
commit. The only pre-existing worktree change was the unrelated untracked
[`products-services-semantic-proposal.md`](products-services-semantic-proposal.md),
which was not edited or used as semantic authority. The historical
[`full-suite.log`](../../full-suite.log) records 197 tests and 934 assertions
passing; that is historical evidence, not a fresh post-audit verification.

## Executive result

The repository does **not** currently satisfy the invariant repository-wide.
The generic Type validator does read persisted descriptors, but several
runtime and provisioning surfaces still use source-file catalogues to select
business Types, fields, records, presentation graphs, Logic and Workflow
meaning. The previous `bin/audit-architectural-compliance.php` reported those
surfaces as compliant without tracing their consumers. It has now been
replaced by a fail-closed retirement gate; the current gate correctly reports
the repository as non-compliant until the backlog is retired.

The most direct confirmed runtime violations are:

1. [`BusinessRecordCatalog.php`](../../app/Runtime/Business/BusinessRecordCatalog.php)
   reads `generic-business-capability-profile.json` and controls record
   listing, creation, update, field metadata and presentation reconciliation.
2. [`BusinessPresentationProfile.php`](../../app/Runtime/Presentation/BusinessPresentationProfile.php)
   and [`CoreObjectPresentationProfile.php`](../../app/Runtime/Presentation/CoreObjectPresentationProfile.php)
   read JSON presentation catalogues during reconciliation. The bounded
   reconciliation path now preserves an existing persisted View Definition
   when it differs, but the source profile still controls bootstrap creation
   and drift comparison.
3. [`CapabilityCompositionVocabulary.php`](../../app/Runtime/Commands/CapabilityCompositionVocabulary.php)
   and [`StandardCapabilityDefinitionCatalog.php`](../../app/Runtime/Definitions/StandardCapabilityDefinitionCatalog.php)
   contain business Type schemas, capability composition, labels, constituent
   relationships and business claims that remain consumed by runtime and
   provisioning code.
4. Demonstrator and administrative paths contain business-specific rules,
   target-Type maps and direct SQL object writes outside the governed Command
   boundary.

No Products & Services record Type, persisted record Presentation/Form binding
or governed record Operation was added by this audit. The existing
Products & Services gap remains a gap.

## Confirmed findings

| ID | File and symbol | Semantic data | Classification | Runtime/provisioning evidence | Persisted authority | Risk |
|---|---|---|---|---|---|---|
| F-01 | [`CapabilityCompositionVocabulary.php`](../../app/Runtime/Commands/CapabilityCompositionVocabulary.php): `OFFERING_TYPE` through `KNOWLEDGE_ASSERTION_TYPE`, `descriptors()`, `install()` | Twenty-one business Type identities and field schemas, including required fields and reference targets | `HARD-CODED SEMANTIC DATA` | `TargetProvisioningRunner` installs it; `StandardCapabilityDefinitionCatalog`, `BusinessCreationOperationHandler`, `BusinessPresentationProvisioningService` and `WorkflowLogicIntegrationProvisioner` consume its constants; tests and fixture installers use its descriptors | STAGING snapshot confirms matching Type Objects, but these consumers do not resolve the corresponding Type identity or schema from the database; production remains unverified | **HIGH** |
| F-02 | [`StandardCapabilityDefinitionCatalog.php`](../../app/Runtime/Definitions/StandardCapabilityDefinitionCatalog.php): `all()` and helper methods | Nine capability names, labels, constituent Type bindings, relationships, navigation, claims and workflow/Logic requirements | `HARD-CODED SEMANTIC DATA` | `bin/build-spearmint-capabilities.php`, build-phase scripts and legacy tests publish or inspect values from this catalogue; the old audit script treats it as an approved source | Published Definition Objects now drive the migrated application consumer, but the catalogue remains an explicit one-way publication input and other consumers remain | **HIGH** |
| F-03 | [`BusinessRecordCatalog.php`](../../app/Runtime/Business/BusinessRecordCatalog.php) and [`generic-business-capability-profile.json`](../../database/configuration/idy-008/generic-business-capability-profile.json) | Capability/record keys, labels, Type IDs, View IDs, fields, renderers and select options | `HARD-CODED SEMANTIC DATA` | `TargetRuntimeCompositionRoot` injects it; `BusinessRecordService` uses it for list/create/update; `TargetHtmlBoundary` uses it for form metadata; `BusinessPresentationProvisioningService` uses it to create and reconcile Views and Presentation Objects | Persisted Type and View Objects exist, but the runtime first resolves the file catalogue and can recreate a changed persisted View from it | **CRITICAL** |
| F-04 | [`BusinessPresentationProfile.php`](../../app/Runtime/Presentation/BusinessPresentationProfile.php) and [`generic-business-presentation-profile.json`](../../database/configuration/idy-008/generic-business-presentation-profile.json) | Dashboard/navigation graph, labels, node identity and collection bindings | `HARD-CODED SEMANTIC DATA` | `BusinessPresentationProvisioningService::reconcile()` reads it whenever presentation reconciliation runs and persists the derived graph | Persisted Presentation Objects are created and rendered, but the source profile remains the input and can replace the graph | **HIGH** |
| F-05 | [`CoreObjectPresentationProfile.php`](../../app/Runtime/Presentation/CoreObjectPresentationProfile.php) and [`core-object-presentation-profile.json`](../../database/configuration/idy-008/core-object-presentation-profile.json) | Core record View fields, labels and Presentation Object structure | `HARD-CODED SEMANTIC DATA` | `reconcileCoreObjectPresentation()` reads the file for bootstrap and comparison; persisted drift now raises a structured diagnostic and is not updated from the file | Persisted Views and Presentation Objects exist; existing authorized View changes are preserved, but source-profile bootstrap and comparison remain to be migrated | **HIGH** |
| F-06 | [`PlatformLogicDefinitionService.php`](../../app/Runtime/Definitions/PlatformLogicDefinitionService.php): `fixture()` and `publish()` | Logic Definition payload and its definition identity | `HARD-CODED SEMANTIC DATA` | `publish()` reads `minimal-project-status-logic.json` and publishes that value through `definition.publish`; the publication path can be invoked again | A persisted Logic Definition controls evaluation after publication, but source fixture content remains the publication authority | **HIGH** |
| F-07 | [`BusinessCreationOperationHandler.php`](../../app/Runtime/Operations/BusinessCreationOperationHandler.php) and [`BusinessPresentationProvisioningService.php`](../../app/Runtime/Presentation/BusinessPresentationProvisioningService.php) | Unconditionally required Project, Person, Organisation, Workflow and execution target Types | `HARD-CODED SEMANTIC DATA` | Business creation and presentation authority reconciliation merge these Type IDs even when persisted Business authorization/configuration does not request them | Business authorization Objects exist, but source defaults force additional business vocabulary and cannot be changed by persisted configuration | **HIGH** |
| F-08 | [`WorkflowLogicIntegrationProvisioner.php`](../../app/Runtime/Workflows/WorkflowLogicIntegrationProvisioner.php) | “Project status Logic integration” label and `PROJECT_TYPE` event correlation | `HARD-CODED SEMANTIC DATA` | Optional demonstrator provisioning writes a Workflow Definition with a source-coded Project trigger | A persisted Workflow Object is created, but the source provisioner chooses its business subject Type and meaning | **HIGH** |
| F-09 | [`DemonstratorVocabulary.php`](../../app/Runtime/Demonstrator/DemonstratorVocabulary.php) and demonstrator operation handlers | Enquiry, Qualification, Decision and Project IDs, fields, states, relationships, operation behavior and rule wording | `HARD-CODED SEMANTIC DATA` | IDY-009 handlers and tests directly use the vocabulary and implement domain-specific transitions/rules | Persisted Operations, States and Objects are created, but handlers retain the business rule and field contract in PHP | **HIGH** |
| F-10 | [`TargetRuntimeBoundary.php`](../../app/Runtime/Bootstrap/TargetRuntimeBoundary.php) and [`TargetHtmlBoundary.php`](../../app/Runtime/Presentation/TargetHtmlBoundary.php) setup routes | Spearmint Business ID, membership ID, constituent Type-to-label maps and inspection/view definitions | `HARD-CODED SEMANTIC DATA` | `/admin/setup/constituent-authorization`, `/admin/setup/view-definitions` and related diagnostics contain direct SQL inserts and hard-coded business maps | These writes bypass Commands, revisions, provenance and authorization; no governed Object is the source of the setup behavior | **CRITICAL** |
| F-11 | [`bin/audit-architectural-compliance.php`](../../bin/audit-architectural-compliance.php) | Compliance assertions about catalogue reachability, fallbacks, resolver bypasses and duplicate renderers | `COMPLIANCE CONTROL` | The former script produced a false-positive success; the replacement scans runtime/release reachability and fails closed with actionable findings | The gate is diagnostic evidence, not semantic authority; it remains red until F-01–F-20 retirement criteria pass | **HIGH** |

F-01 through F-10 are confirmed violations even where the same data is also
persisted. Persistence alone is insufficient when the application source
continues to select, regenerate or override the meaning.

## Audited catalogues and dispositions

| Catalogue or source | Disposition | Reason |
|---|---|---|
| [`FoundationIds.php`](../../app/Runtime/Auth/FoundationIds.php) | `INFRASTRUCTURE` / controlled foundation bootstrap | Stable platform identity and operation-boundary constants. They are not a business catalogue, although handlers using them must remain generic and governed. |
| [`PlatformVocabulary.php`](../../app/Runtime/Commands/PlatformVocabulary.php) | `BOOTSTRAP/MIGRATION` with a runtime review required | Platform evidence Type descriptors are installed and then resolved from Objects. Stable Type identities are mechanism prerequisites; descriptor duplication must not become a business fallback. |
| [`PlatformEvidenceVocabulary.php`](../../app/Runtime/Commands/PlatformEvidenceVocabulary.php) | `BOOTSTRAP/MIGRATION` | Platform-owned Command, Attempt, Outcome, Event and provenance structure. This is foundational evidence vocabulary, not tenant business data. |
| [`PresentationVocabulary.php`](../../app/Runtime/Presentation/PresentationVocabulary.php) | `BOOTSTRAP/MIGRATION` | Presentation Type prerequisites and release integrity. It does not by itself define a Business View; F-04 and F-05 do. |
| [`RelationshipVocabulary.php`](../../app/Runtime/Relationships/RelationshipVocabulary.php) | `BOOTSTRAP/MIGRATION` | Generic relationship/node Type prerequisites loaded through an integrity-checked manifest. Business relationship declarations must still be persisted and governed. |
| [`WorkflowVocabulary.php`](../../app/Runtime/Workflows/WorkflowVocabulary.php) and [`WorkflowAuthorityBindingVocabulary.php`](../../app/Runtime/Workflows/WorkflowAuthorityBindingVocabulary.php) | `BOOTSTRAP/MIGRATION` | Generic workflow Type prerequisites and manifest verification. Business Workflow Definitions are separate persisted Objects; F-08 is a demonstrator-specific exception. |
| [`WorkflowOperationVocabulary.php`](../../app/Runtime/Workflows/WorkflowOperationVocabulary.php) | `GENERIC_RUNTIME` / platform operation mechanism | Dispatch, condition, end and reconciliation operations are platform execution vocabulary. Their handler implementation must not acquire business-specific rules. |
| [`InitializationVocabulary.php`](../../app/Runtime/Initialization/InitializationVocabulary.php) | `BOOTSTRAP/MIGRATION` plus generic initialization mechanism | User (legacy Type name Principal), Business, Person, Organisation and Definition prerequisites are foundation vocabulary. Its demonstrator workflow payloads require the same review as F-09 when they encode business meaning. |
| [`OperationVocabulary.php`](../../app/Runtime/Operations/OperationVocabulary.php) | `BOOTSTRAP/MIGRATION` / generic runtime | Operation Type validation and generic operation identity support. Business Operation Definitions must be persisted and resolved by exact revision. |
| [`BusinessCapabilityConfigurationService.php`](../../app/Runtime/Configuration/BusinessCapabilityConfigurationService.php) and IDY-008 manifests | `BOOTSTRAP/MIGRATION` only, not a runtime authority | The manifest is verified release input. `ConfigurationInstaller` records provenance and rejects drift/conflict rather than silently overwriting an authorized persisted value. It must not be used as a runtime catalogue. |
| `database/genesis/*.json` and runtime vocabulary manifests | `BOOTSTRAP/MIGRATION` | Foundation/release installation input with digest and identity checks. They are not proof that runtime behavior is database-defined; consumers must still resolve persisted Objects. |
| `release/*.json`, `TargetRelease*`, staging package files | `INFRASTRUCTURE` | Release identity, package contents, provenance and deployment controls. They do not describe tenant business semantics. |
| `tests/**`, `tests/HttpAcceptance/Harness/FixtureInstaller.php` | `TEST_FIXTURE` | Test data and expected setup. Fixtures may use stable IDs to build isolated evidence but are not production authority. |
| `bin/*` legacy marketing/projection scripts | `TEST_FIXTURE` or `BOOTSTRAP/MIGRATION` where explicitly invoked | These scripts include direct SQL and old capability catalogues. They are not acceptable production runtime mechanisms and must not be included in a target release path without governed replacement. |
| `resources/views/**` | `GENERIC_RUNTIME` where templates render supplied persisted data; stale capability setup copy is a documentation/UX defect | Templates do not define generic Object values, but text claiming “eight persisted capability entries” must not be treated as current architecture. |

## Repository-wide coverage additions

The initial findings above are extended by the following repository-wide
inventory. These entries are intentionally separated from the first confirmed
runtime catalogue findings so that foundation vocabulary is not confused with
Business semantic authority.

| ID | File and symbol/path | Classification | Evidence and disposition |
|---|---|---|---|
| F-12 | [`BusinessCapabilityConfigurationService.php`](../../app/Runtime/Configuration/BusinessCapabilityConfigurationService.php), [`ConfigurationInstaller.php`](../../app/Runtime/Configuration/ConfigurationInstaller.php), `generic-business-capability-configuration.json`, and the `/business-capabilities/reconcile` target route | `UNCERTAIN — bootstrap/migration boundary requires correction` | The installer verifies a release digest, compiles declarations and refuses settled drift, so it is a legitimate installation mechanism in isolation. The target HTTP route can invoke it repeatedly and then trigger presentation reconciliation, which leaves a source package as an ongoing semantic input. Restrict this path to explicit provisioning/migration and make normal runtime consume only persisted Objects. |
| F-13 | [`InitializationVocabulary.php`](../../app/Runtime/Initialization/InitializationVocabulary.php): `descriptors()`, `platformDefinitions()`, workflow/operation seeds | `BOOTSTRAP/MIGRATION` for foundation; `SOURCE-CODED SEMANTIC AUTHORITY` where demonstrator meaning is embedded | Person, Organisation, Definition and workflow prerequisites are controlled platform vocabulary. The same class also constructs initialization workflow and Operation values used to create Business behavior. Retain generic foundation installation; move Business-specific workflow/Operation content to persisted configuration before expanding the initializer. |
| F-14 | [`GenesisRunner.php`](../../app/Runtime/Genesis/GenesisRunner.php), [`FoundationReconciliationService.php`](../../app/Runtime/Genesis/FoundationReconciliationService.php), [`TargetProvisioningRunner.php`](../../app/Release/TargetProvisioningRunner.php) and `database/genesis/*.json` | `BOOTSTRAP/MIGRATION` | These are controlled fresh-store installation and explicit foundation reconciliation mechanisms using digests, exact revisions and retained evidence. They are not normal request-time semantic resolvers. Foundation reconciliation still depends on a source manifest and must remain restricted to the approved operator/migration boundary. |
| F-15 | [`BusinessInstanceProvisioningService.php`](../../app/Runtime/Operations/BusinessInstanceProvisioningService.php), `provision-business-instance.php`, `extend-business-presentation.php` and `spearmint-demonstrator-profile.json` | `BOOTSTRAP/MIGRATION` with embedded demonstrator data | The service is a generic orchestrator and delegates mutations through Commands, but the selected profile contains business labels, authorization targets, initialization values and Presentation graph content. This is acceptable only as explicit one-way provisioning input; it must never be consulted by normal runtime or repair an authorized persisted change. |
| F-16 | [`PlatformLogicDefinitionService.php`](../../app/Runtime/Definitions/PlatformLogicDefinitionService.php): `fixture()` and target Logic publication route | `SOURCE-CODED SEMANTIC AUTHORITY` | The generic evaluator consumes persisted Logic, but the callable publication path reads `minimal-project-status-logic.json` and can republish it. Replace this with an explicit governed Definition authoring/publication input; evaluation must keep using the exact persisted Definition revision. |
| F-17 | [`WorkflowOperationVocabulary.php`](../../app/Runtime/Workflows/WorkflowOperationVocabulary.php), [`OperationVocabulary.php`](../../app/Runtime/Operations/OperationVocabulary.php), `PlatformVocabulary`, `PlatformEvidenceVocabulary`, `PresentationVocabulary`, `RelationshipVocabulary` and `WorkflowVocabulary` | `GENERIC_RUNTIME` or `BOOTSTRAP/MIGRATION` | These classes define platform execution/evidence Type prerequisites and generic operation mechanics. Their handler keys and fixed platform identities are not Business catalogues by themselves. Any entry that embeds demonstrator names, fields or target Types must be split out and treated as F-08/F-09 rather than accepted as platform vocabulary. |
| F-18 | [`CapabilityDefinitionTypeRevision.php`](../../app/Runtime/Commands/CapabilityDefinitionTypeRevision.php), [`BusinessCapabilityInstanceTypeRevision.php`](../../app/Runtime/Commands/BusinessCapabilityInstanceTypeRevision.php), [`DefinitionApplicationOperationHandler.php`](../../app/Runtime/Operations/DefinitionApplicationOperationHandler.php); former `CapabilityApplicationOperationHandler.php` and `PersistedCapabilityProjector.php` paths are deleted | `RETIRED — B1 runtime path` | The generic Definition application path resolves published exact-revision Definitions and bounded constituents. The former capability-specific handler and projector are no longer runtime files; the persisted operation identity is retained only for compatibility. | B1 integration applies all nine published Definitions; exact references, publication, scope, cycle/budget and non-execution checks remain fail-closed; compliance rejects reintroduction of either legacy path. | Production adoption still requires authorized Type/dependent-object evidence; remaining catalogue consumers are tracked under F-01/F-02 and later batches. | No normal runtime consumer reaches a capability-specific projector or handler; all migrated applications use `DefinitionCompositionResolver` and persisted subject values. |
| F-19 | [`TargetRuntimeBoundary.php`](../../app/Runtime/Bootstrap/TargetRuntimeBoundary.php) and [`TargetHtmlBoundary.php`](../../app/Runtime/Presentation/TargetHtmlBoundary.php) private legacy setup methods | `SOURCE-CODED SEMANTIC AUTHORITY` (dormant after route removal) | The HTTP dispatch branches were removed, but private methods still contain Spearmint IDs, Type-to-label maps and direct SQL Object writes. They are no longer reachable through the target boundary, but remain source inventory and must be deleted or moved to governed operator tooling before compliance can be claimed. |
| F-20 | [`business_capability_reconcile.php`](../../resources/views/target/business_capability_reconcile.php) | `SOURCE-CODED SEMANTIC DATA` in presentation copy | The template claims that eight capability presentation entries are current even though the canonical Business model retires the capability runtime path. It does not create authority, but it can misstate the available semantic contract and must be corrected with the related route migration. |

## Consolidated migration backlog and retirement gate

This is the single dependency-ordered backlog for the remaining migration. It
consolidates F-01 through F-20; the findings remain the evidence register, while
this table defines the replacement, implementation mechanism, compatibility
boundary, tests, blockers and objective completion condition. “Retire” means
that every runtime consumer has moved, not merely that an equivalent Object
exists.

| Batch | Findings and current authority/consumers | Persisted replacement and exact contract | Generic mechanism and migration strategy | Required regression evidence | Dependencies and blockers | Completion / retirement criteria |
|---|---|---|---|---|---|---|
| B0. Foundation and Type authority | F-01; `CapabilityCompositionVocabulary` is consumed by `TargetProvisioningRunner`, `BusinessCreationOperationHandler`, `BusinessPresentationProvisioningService`, `WorkflowLogicIntegrationProvisioner`, capability definitions and fixtures. F-14/F-17 foundation vocabularies remain controlled installation inputs. | Each retained platform Type is the exact platform Type Object ID plus positive Type revision, resolved from persisted `{kind: object_reference, id, revision}` data. The Object must be `TYPE_OF_TYPE_ID`, platform-scoped, descriptor-valid and provenance/history complete. | Use `ExactObjectReferenceResolver`, `FoundationObjectRepository` and `TypeDescriptorValidator` for reads. Keep stable IDs only as one-way bootstrap/migration input. Type schema changes require the approved `platform.type_revision` Operation/Command with distinct AuthorityGrant/Policy, expected version, dependency validation and evidence. | 21-identity mapping; descriptor-only persisted validation; exact historical revision reads; missing/malformed/unauthorized Type failure; no revision-1 overwrite; immutable revision/provenance/evidence assertions. | Authorized production inventory is unavailable. Owner architecture approval exists, but the Type-revision Operation, trusted handler designation and production dependent-object evidence are not complete. | No runtime consumer reads `descriptors()` or PHP schema. All retained IDs/revisions have verified mappings; Type changes are governed and historical references remain resolvable. |
| B1. Capability Definition composition | F-02 and F-18; `StandardCapabilityDefinitionCatalog` remains a one-way publication input, while the migrated application consumer now uses persisted Definitions and exact constituent Type references. | Nine published platform Definition Objects listed in the B1 evidence section, each at revision 1; every constituent uses exact `{kind, id, revision}` references, with publication evidence and permitted platform/Business scope. No shallow Type list or capability registry. | `DefinitionCompositionValidator`, `DefinitionCompositionInspector`, `DefinitionPublicationEvidenceReader`, `ExactObjectReferenceResolver` and `DefinitionCompositionResolver`. Preserve immutable revisions, Command boundaries, expected versions, provenance and idempotency; Type descriptors are validation leaves for graph-depth accounting. | **Verified:** all nine Definitions apply through the generic handler; exact historical/missing/unpublished/unauthorized/incompatible/cross-scope references fail closed; depth/node/edge/cycle limits are bounded; traversal does not execute Logic, Workflow or Operations; Presentation and authorization regressions pass. | Local implementation is complete. Production adoption remains blocked by unavailable authorized production Type/dependent-object evidence. Remaining catalogue consumers and Business configuration are B2/B3 work, not blockers for this read-side batch. | The former projector and handler are deleted and compliance rejects reintroduction; the migrated application runtime reaches only persisted exact-revision Definition authority. |
| B2. Business configuration boundary | F-12 and F-15; `BusinessCapabilityConfigurationService`, IDY-008 manifests, `/business-capabilities/reconcile`, `BusinessInstanceProvisioningService` and demonstrator profiles can continue supplying semantic configuration after installation. | Persisted Business configuration/Definition Objects and exact Business-owned bindings, with installation provenance and expected revisions. Source packages carry only release identity, digest and one-way installation input. | Restrict configuration and demonstrator profile use to explicit provisioning/migration boundaries. Normal request paths resolve persisted Objects and exact Dashboard/View/Workflow/Operation references. Preserve idempotent installer drift refusal. | Re-entry after source-file drift; persisted edit survives reconciliation; missing/invalid configuration fails closed; Business isolation; provenance and idempotency. | B1 complete composition and B5/B6 binding contracts; current HTTP reconciliation route remains an implementation blocker. | No normal HTTP/runtime path reads a manifest/profile to select meaning; installation routes are explicit, authorized and non-runtime. |
| B3. Record schema and form authority | F-03; `BusinessRecordCatalog`, `generic-business-capability-profile.json`, `BusinessRecordService`, `TargetRuntimeCompositionRoot`, `TargetHtmlBoundary` and Presentation reconciliation select record Types, fields, labels, renderers and options. | Persisted Business record Type Objects, exact View/Form Definition revisions, exact Operation references and Business configuration bindings. `{id, type, value}` plus exact Type/View/Form/Operation revisions are authoritative. | Resolve records through persisted Business bindings, `PresentationCatalog`, exact resolver and governed `object.create`/`object.update`/Operation invocation. Retain the JSON profile only as one-way bootstrap input until all records are mapped. Do not invent Products & Services semantics. | Two-Business isolation; persisted field/schema revision changes affect list/form/rendering; missing Type/View/Form/Operation fails closed; command authorization, expected versions and provenance; no catalogue fallback. | B0 and B2; an exact persisted record-key/binding contract is not yet established. Products & Services remains an explicit semantic gap. | `BusinessRecordCatalog` is absent from the runtime composition root; every record consumer resolves exact persisted bindings; invalid/missing bindings produce diagnostics rather than PHP defaults. |
| B4. Dashboard and Presentation graph | F-04/F-05; `BusinessPresentationProfile`, `CoreObjectPresentationProfile`, their JSON files and `BusinessPresentationProvisioningService` currently bootstrap/reconcile graph content. | Persisted Business dashboard binding to one exact root Presentation Object revision, with recursive exact child/content/target references and persisted View/Form Definition revisions. | Keep a one-way fresh-Business/bootstrap installer behind explicit provisioning authority. Remove profile reads from normal reconciliation and rendering; use `PersistedPresentationObjectProjector`, `AuthorizedPresentationTargetResolver`, generic renderer and drift diagnostics. | Persisted label/field/child/binding changes survive re-entry; missing/unpublished/unauthorized/cyclic references fail closed; historical Presentation revisions remain stable; one projection path and one renderer. | B2/B3 exact bindings; fresh-install bootstrap ownership must be made explicit without making source profiles runtime authority. | No normal runtime call reaches either profile; only the persisted dashboard graph is rendered; profile files are bootstrap/migration inputs with explicit provenance. |
| B5. Logic Definition publication | F-06/F-16; `PlatformLogicDefinitionService::fixture()`, `minimal-project-status-logic.json`, target publication route and source fixture content can republish Logic. | Exact platform or Business Logic Definition Object revision with publication evidence, exact input/reference bindings and supported generic expression vocabulary. | Use governed `definition.publish`, exact resolver and `GenericLogicEvaluator`. Move authoring to explicit publication input; remove fixture loading from normal runtime and reject missing/incompatible Logic. | Persisted Logic revision changes evaluation without source edits; old revision remains stable; unpublished/unauthorized/malformed/cyclic/unsupported Logic fails closed; publication evidence is retained. | B1 Definition publication and B7 generic handler boundary; current demonstrator subject semantics are not fully separated. | No runtime or repeatable target path calls `fixture()` for semantic execution; evaluator consumes only exact persisted Logic revisions. |
| B6. Workflow and Operation bindings | F-08/F-13/F-17; `WorkflowLogicIntegrationProvisioner`, initialization workflow seeds, `WorkflowOperationVocabulary`, `OperationVocabulary`, handlers and event correlation embed Project/demonstrator meaning. | Persisted Workflow Definition, Node, Authority Binding and Operation Objects, each pinned by exact revision; Logic and Operation references are exact and Business-scoped where applicable. | Retain generic workflow/interpreter/operation vocabulary; move Business steps, triggers, subject Types and rules into persisted Workflow/Logic/Operation values. Use `WorkflowSequentialInterpreter`, `OperationResolver`, `OperationInvocationService` and governed Commands. | Exact pinning and historical execution; missing/invalid Logic/Operation/subject Type failure; commit-time authority/expected-version checks; retained Attempts/Outcomes/Events/Provenance; no inferred subject Type. | B0, B1 and B5; handler keys containing demonstrator rules require an explicit generic contract. | Workflow/Operation consumers contain no embedded Business subject/rule meaning; runtime executes only exact persisted definitions and registered generic/platform handlers. |
| B7. Demonstrator semantic rules | F-09; `DemonstratorVocabulary`, `AuthorityPolicy`, `DeterministicReasoner`, qualification/decision handlers and IDY-009 fixtures contain field, state, relationship and transition meaning. | Persisted Data/State/Relationship/Logic/Workflow/Operation Objects with exact revisions and Business scope; generic handlers receive validated persisted inputs. | Separate generic mechanism from demonstrator configuration. Migrate rules through persisted Logic/Workflow/Operation boundaries; preserve old evidence and do not infer missing semantics from handlers. | State/relationship/transition authorization; invalid state and stale-version rejection; A/B isolation; historical execution; no hard-coded rule fallback. | B5/B6 and an explicit inventory of each handler’s generic versus business-specific behavior. | Demonstrator vocabulary is not imported by production runtime handlers; all remaining demonstrator behavior is explicit persisted configuration or a documented generic mechanism. |
| B8. Business default Type selection | F-07; `BusinessCreationOperationHandler` and `BusinessPresentationProvisioningService` merge required Project/Person/Organisation/Workflow/execution Types regardless of persisted Business configuration. | Persisted Business configuration/Definition graph declares exact constituent Type and binding revisions; foundation Person/Organisation/Business identity remains controlled foundation behavior. | Read exact Business configuration and validate each required binding through existing resolver/validator; use governed Commands for changes. Remove unconditional semantic defaults; preserve only documented foundation prerequisites. | Configuration selects permitted Types; missing/invalid bindings fail closed; unauthorized Type scope rejected; Business creation remains retry-safe and provenance-complete. | B0/B2; architecture must distinguish foundation prerequisites from optional capability composition, already documented but not fully implemented. | No runtime merge introduces business Types not present in persisted authorized configuration; fresh initialization uses explicit one-way bootstrap only. |
| B9. Administrative and dormant direct-write paths | F-10/F-19; removed HTTP branches still leave private setup methods, hard-coded maps and direct SQL writes in `TargetRuntimeBoundary`/`TargetHtmlBoundary`. | No replacement semantic authority; use existing governed Command/Operation/admin tooling with exact targets, authorization, expected versions and evidence. | Delete or quarantine dormant methods and old setup views after confirming no route/release dependency. Do not add another SQL guard or preserve a parallel mutation path. | Static no-direct-write scan; route/HTTP regression; unauthorized and stale Command rejection; source/release package exclusion. | Dependency inventory only; no owner decision is required for deleting unreachable legacy code, but preserve unrelated work. | No target runtime source contains direct Object writes or dormant semantic setup maps; old routes remain unavailable and no release path packages them. |
| B10. Stale presentation and compliance copy | F-20; `business_capability_reconcile.php` claims retired capability entries are current. | Documentation/UI copy derives from the current persisted generic Object/Presentation contract or is removed with the route. | Remove obsolete template/route or render supplied persisted diagnostics only. This is not a semantic replacement. | HTTP/template regression confirms no obsolete capability claim; route absence or explicit reconciliation status. | B2/B4 route retirement. | No user-facing copy asserts a retired capability registry or fixed count as current authority. |
| B11. Foundation/bootstrap boundary | F-14/F-17 and allowed portions of F-12/F-13; Genesis, manifests, release packages and platform vocabularies are permitted only as controlled installation mechanisms. | Resulting persisted Objects, revisions, provenance and release evidence; no file remains a normal runtime resolver. | Keep foundation-only Genesis and explicit provisioning/migration commands. Enforce identity/digest/target safeguards, idempotency and no production route unless separately authorized. | Clean-store installation; drift/reconciliation; provenance; no normal-request file reads; package boundary tests. | Production deployment/evidence is a live-migration blocker, not a reason to defer local gate work. | Every retained file is classified as generic mechanism, test fixture or explicit one-way bootstrap; no bootstrap input is reachable from normal runtime semantics. |
| B12. Final compliance gate | F-11 plus retirement proof for F-01–F-20; the current audit script is fail-closed but not yet a machine-checking reachability gate. | No persisted replacement is introduced by this batch. The gate records structural proof that runtime consumers use approved generic boundaries. | `bin/audit-architectural-compliance.php` scans runtime reachability, forbidden source catalogue references, direct Object writes, resolver bypasses, duplicate renderers and stale routes. It must fail with actionable findings until all retirement criteria pass. | Gate exits non-zero for the current repository and identifies each violation; fixture-based positive/negative checks; clean exit only after the backlog is retired. | All migration batches; no production evidence required to build or run the local gate. | One command is the release-review gate. It cannot report compliance while a retired authority, fallback, bypass or duplicate renderer remains reachable. |

### Critical path and blocker separation

The implementation critical path is **B0 → B1 → B2 → B3/B4 → B5/B6 →
B7/B8 → B9/B10 → B11 → B12**. B4 can proceed locally for drift and
bootstrap-boundary work, but its normal-runtime profile retirement depends on
the exact persisted Business dashboard contract. B12 is implemented in parallel
as a fail-closed guard and remains red until the other batches retire their
sources.

B0 execution is currently blocked before implementation. The three runtime
consumers of `CapabilityCompositionVocabulary::PROJECT_TYPE` do not have a
conforming persisted Type binding to read:

- `BusinessCreationOperationHandler` has only the PHP Type ID and runs before
  the new Business has a Business-scoped membership/authority context.
- `BusinessPresentationProvisioningService` adds the PHP Type ID to an
  AuthorityGrant `target_type_ids` list; that persisted shape carries no exact
  Type revision or Type Object reference.
- `WorkflowLogicIntegrationProvisioner` writes only
  `event_subject_type_id`; `WorkflowDefinitionValidator` and
  `WorkflowAdmissionService` compare only that ID and have no subject Type
  revision contract.

The existing STAGING mapping confirms the source ID and revision 1 for the
current snapshot, but it is not a runtime binding and production remains
unverified. The generic exact resolver cannot repair these missing contracts:
it requires an exact `{kind, id, revision}` reference and an authorized
Business context. Adding a revision field, inferring a Type from a descriptor
or reading the configuration manifest at runtime would establish an
undocumented semantic contract and is not authorized by B0. No B0 runtime
consumer was changed in this session.

Implementation blockers are incomplete persisted contracts for retained Type
identities, capability constituents, record keys/bindings and demonstrator
handler semantics. They must be resolved by repository evidence or explicit
architecture-owner clarification; they are not permission to infer a registry,
Type or replacement model.

Live-migration blockers are separate: no authorized read-only production
collection route exists, production Type identity/revision/provenance/dependent
Object evidence is unavailable, and the approved Type-revision Operation,
trusted handler designation and production activation boundary are not
implemented. These prevent production changes and Type-revision activation,
but do not prevent the local B12 gate or other non-production work.

### Findings requiring explicit evidence before build

| Area | Why classification is not yet final | Required evidence |
|---|---|---|
| Configuration manifest as release input versus runtime source | `ConfigurationInstaller` detects drift, but the HTTP reconciliation surface still supplies the file to runtime code. | Prove the file is accepted only by an explicit installation/migration boundary and that normal resolution never reads it. |
| Initialization vocabulary | Platform-owned foundation descriptors and Business demonstrator initialization are currently co-located. | Inventory each `platformDefinitions()` entry and prove its owner is foundation mechanism or move it to persisted Business configuration. |
| Stable `a810...` Type identities | Existing Objects and historical fixtures use them, but current architecture retires the capability path. | Produce an exact identity/revision/provenance mapping for each retained Type or mark it unsupported; do not infer a replacement. |
| Demonstrator handler keys | The Operation resolver correctly resolves exact persisted Operations, but several trusted handlers contain Enquiry/Qualification/Project rules. | Define which behavior is generic Operation mechanism and which must be a persisted Logic/Workflow Definition before replacing handlers. |

## Stage 3A Capability Type Authority Audit

### Evidence boundary

This Stage 3A plan is documentation-only. No STAGING or production database
was mutated. An approved read-only STAGING snapshot was refreshed into the
disposable local test database solely for evidence queries. The following
evidence categories are kept separate:

- `SOURCE`: the PHP constant or descriptor declares the identity/schema;
- `TEST-PERSISTED`: an isolated fixture proves the current installer can create
  a matching Type Object;
- `PRODUCTION UNVERIFIED`: no current production Object, revision, provenance
  or dependent-Object inventory was observed; and
- `MIGRATION BLOCKER`: implementation cannot safely proceed until the missing
  evidence or governed mutation boundary is established.

The current class defines **21** capability Type identities. Historical reports
that state 15 Types are not evidence for the current class.

### Constant-to-Type mapping

All rows below are declared by the current source installer as platform-scoped
Type Objects with Object `type_id = TYPE_OF_TYPE_ID`, Type revision 1 and
`business_id = null`. The schema summary is source evidence from
`descriptors()`; the read-only STAGING snapshot confirms the same canonical
descriptor for all 21 rows, while production remains unverified.

| Constant / exact Object ID | Required fields | Optional fields or exact reference targets |
|---|---|---|
| `OFFERING_TYPE` / `a8100000-0000-4000-8000-000000000001` | `name`, `offering_kind`, `lifecycle` | `description`, `commercial_context` |
| `SALES_PROSPECT_TYPE` / `a8100000-0000-4000-8000-000000000002` | `display_name`, `source`, `status` | `contact_context` |
| `SALES_QUALIFICATION_TYPE` / `a8100000-0000-4000-8000-000000000003` | `requirements`, `fit_assessment`, `status`, `submitted_at` | none |
| `SALES_OPPORTUNITY_TYPE` / `a8100000-0000-4000-8000-000000000004` | `name`, `stage` | `expected_revenue`, `probability`, `target_close_date`, `forecast_category`, `responsible_representative`, `source` |
| `SALES_PROPOSITION_TYPE` / `a8100000-0000-4000-8000-000000000005` | `name`, `terms_summary`, `status` | `commercial_context` |
| `SALES_TYPE` / `a8100000-0000-4000-8000-000000000006` | `outcome`, `recorded_at` | `revenue_basis`, `handoff_status` |
| `PROJECT_TYPE` / `a8100000-0000-4000-8000-000000000007` | `name`, `objective`, `scope`, `status` | `start_date`, `target_date`, `outcome` |
| `MARKETING_CAMPAIGN_TYPE` / `a8100000-0000-4000-8000-000000000008` | `name`, `goal`, `status` | `audience`, `content_summary`, `channel`, `response_summary`; reference targets are Goal/Audience/Content/Response at Type revision 1 |
| `OPERATIONAL_WORK_TYPE` / `a8100000-0000-4000-8000-000000000009` | `name`, `purpose`, `status` | `exception_summary`, `handover_summary` |
| `PROJECT_MILESTONE_TYPE` / `a8100000-0000-4000-8000-00000000000a` | `name`, `status` | `due_date`, `outcome` |
| `FINANCIAL_RECORD_TYPE` / `a8100000-0000-4000-8000-00000000000b` | `record_kind`, `amount`, `currency`, `status` | `effective_date`, `source_reference` |
| `KNOWLEDGE_ITEM_TYPE` / `a8100000-0000-4000-8000-00000000000c` | `title`, `content_kind`, `status` | `content`, `applicability`, `source_reference`, `standing` |
| `MARKETING_GOAL_TYPE` / `a8100000-0000-4000-8000-00000000000d` | `name`, `desired_outcome`, `status` | `measure_basis` |
| `MARKETING_AUDIENCE_TYPE` / `a8100000-0000-4000-8000-00000000000e` | `name`, `criteria_summary`, `status` | `access_basis` |
| `MARKETING_CONTENT_TYPE` / `a8100000-0000-4000-8000-00000000000f` | `title`, `content_kind`, `status` | `body`, `source_reference` |
| `MARKETING_RESPONSE_TYPE` / `a8100000-0000-4000-8000-000000000010` | `received_at`, `response_kind` | `outcome`, `source_reference` |
| `OPERATIONAL_EXECUTION_TYPE` / `a8100000-0000-4000-8000-000000000011` | `status` | `started_at`, `ended_at`, `result_summary` |
| `OPERATIONAL_EXCEPTION_TYPE` / `a8100000-0000-4000-8000-000000000012` | `summary`, `status` | `raised_at`, `resolution_summary` |
| `OPERATIONAL_HANDOVER_TYPE` / `a8100000-0000-4000-8000-000000000013` | `summary`, `recorded_at` | `from_responsibility`, `to_responsibility` |
| `OPERATIONAL_RESOURCE_TYPE` / `a8100000-0000-4000-8000-000000000014` | `name`, `resource_kind`, `status` | `availability_context` |
| `KNOWLEDGE_ASSERTION_TYPE` / `a8100000-0000-4000-8000-000000000015` | `claim`, `source_reference`, `standing` | `applicability`, `recorded_at` |

These complete UUIDs are the exact constants in
[CapabilityCompositionVocabulary.php](../../app/Runtime/Commands/CapabilityCompositionVocabulary.php)
and must not be reconstructed from labels or abbreviated displays.

### STAGING snapshot evidence — read-only

An approved refresh of the read-only STAGING source into the disposable local
test database `IDY_TEST_IDY002` was used only for evidence extraction. No
STAGING or production mutation occurred.

The snapshot confirms for all 21 IDs:

- Object exists: **21/21**;
- Object ID equals the source constant: **21/21**;
- Object `type_id` is `TYPE_OF_TYPE_ID`: **21/21**;
- Type revision is `1`: **21/21**;
- `business_id` is `NULL`: **21/21**;
- current Object revision is `1`: **21/21**;
- descriptor canonical comparison against
  `CapabilityCompositionVocabulary::descriptors()`: **21/21 match**;
- retained `object_revisions` rows: **21**, one per Type; and
- Type revision `provenance_ref`/`command_id`: **0/21 populated**.

This confirms the current STAGING snapshot contains the source-defined Type
Objects, but it also confirms that their initial revision rows have no retained
Command/provenance identity. That is bootstrap evidence, not governed schema
publication evidence.

### STAGING dependent Object inventory

The snapshot contains:

- `PROJECT_TYPE`: 2 Business-scoped Project Objects and 12 retained Project
  Object revisions;
- no current Objects of the other 20 capability Types;
- 52 value-level references to `PROJECT_TYPE`, grouped as:
  - 2 `AuthorityGrant` Objects;
  - 36 `Command` Objects;
  - 1 Business-scoped `View Definition`;
  - 2 Business-scoped `Presentation Object` records;
  - 1 Business-scoped `Workflow Definition`;
  - 9 Business-scoped `Workflow Authority Binding` records; and
  - 1 platform `Object Definition` (`c2000000-0000-4000-8000-000000000001`);
- one `TYPE_OF_TYPE` descriptor reference for each of
  `MARKETING_GOAL_TYPE`, `MARKETING_AUDIENCE_TYPE`,
  `MARKETING_CONTENT_TYPE` and `MARKETING_RESPONSE_TYPE`, because those IDs
  occur in the persisted Campaign Type descriptor; and
- no current Business Objects, revisions or value references for the other
  16 capability Types.

The exact non-Command dependent Object IDs observed were:

| Referenced Type | Dependent Object Type | Business scope | Exact dependent IDs |
|---|---|---|---|
| `PROJECT_TYPE` | `Object Definition` | platform | `c2000000-0000-4000-8000-000000000001` |
| `PROJECT_TYPE` | `Workflow Definition` | `a20d5b62-078c-4ef4-b0ce-41027f9bc275` | `c3000000-0000-4000-8000-000000000001` |
| `PROJECT_TYPE` | `View Definition` | `a20d5b62-078c-4ef4-b0ce-41027f9bc275` | `c1f1b23d-9a45-47d7-b9aa-e8fba507299a` |
| `PROJECT_TYPE` | `Presentation Object` | `a20d5b62-078c-4ef4-b0ce-41027f9bc275` | `6f87ead0-1145-48d2-b7a0-a9c5ec78e182`, `884c7840-e7d4-43c4-8435-bd7ca32255ae` |
| `PROJECT_TYPE` | `AuthorityGrant` | `a20d5b62-078c-4ef4-b0ce-41027f9bc275` | `57956cd2-b52d-40c8-8031-720e5f06f06c`, `9551c1fe-0c80-40a2-ad0c-44ddbb77a2b2` |
| `PROJECT_TYPE` | `Workflow Authority Binding` | `a20d5b62-078c-4ef4-b0ce-41027f9bc275` | `413be1fc-5176-48a4-bb01-5dbf5df8fb69`, `47e61cc1-d5a7-438d-ad14-0b81050f7605`, `6422776b-06a3-4e19-91fe-56f2c0ae515c`, `68d3508e-8ab3-4d4b-b8d6-bec35527f7af`, `6e93a16f-0b52-4d08-bdcf-4522afc56d67`, `ae52604d-aeaa-478f-ad2a-d7cd6df56a17`, `c47f8e26-3a41-4778-bd12-2ac9c37b6f14`, `ca819661-59e6-44ec-a2d4-8d9f44ad4180`, `fd10a8a8-714a-4133-9638-f11b9c040a96` |

The 36 dependent Command Object IDs are:

```text
00eac925-3b52-47ef-87b0-2228128bd2bb
03db8ff3-d079-46d9-b1e2-44860b9034ff
03f0b19a-71f4-4c04-b295-56e0ce956646
1717ef00-20c4-4db0-969b-0dfe0b9a1934
17d5c213-30d0-484a-b45c-672828447f05
1a45e602-cb26-4a4f-80e4-e95082b3a3df
1b8ed57f-442c-4e9f-92ec-769c1061fef0
1f78ce06-afaa-4734-b82d-2f29424f03b7
33047e92-8276-4f79-870a-f2b333e3b371
3d19bf1b-64d5-4701-9d15-c84f6aa88f91
43d59240-dedd-43f1-9ac0-ae40b0a81bf2
510cf8a1-543a-4f45-90aa-bd6d64ae42d1
5a0a04f4-a0be-4d13-948c-2ed8d670727e
5d5ffd04-ebab-457d-9a6d-78070175727a
6307666f-412d-4abd-8f45-14a653b092dd
65f4f207-3a1c-48bf-8fbb-899cf2c7771b
6bfea78a-9599-469e-b0b5-7766cabbf4ab
6f0ecafc-7077-4427-83a1-ef9ffe1bc647
70d546cd-6864-48e0-8ada-8e72e7a6592b
767de8d5-89c1-4232-8b3a-dee82bec14c6
80cf1b84-9c78-4031-bd7a-b1326be09ab7
824424dc-0c2e-488a-bd95-19cb1c5c3857
899de458-b2ae-47d0-9f2a-5fdc831622ac
8f5b2da6-0f74-4899-9cc5-48b247178f27
944eb815-3f7b-45b9-a859-d8a62cef1bd6
9b6ccccc-8847-4254-a3a9-701f6a4e4ffc
9f0a0d68-6335-424d-9ab2-1ad887bcd2c9
a7e3a94d-23a6-4144-8730-e70388b57d91
a9dc07a8-fdfd-471a-a074-bfe180b1081e
b973fa5b-fb5f-404f-8531-009d5bfd8ced
cd3ed205-1349-4cdc-81b9-73e1c2f02333
d5b456da-7a6e-4fc7-ba6c-d62f86a05b37
dc67f6e0-3a73-4d82-bf2b-479f15a96bdf
ecb26b09-5d3c-4fe1-8999-32a1a8bfe572
ef38f61b-04ea-438c-889d-8add80ebe091
fe696e0a-60d8-4cae-bd4e-13c16ebca894
```

Their common semantic effect is Project-targeted command/evidence history
rather than independent Project Type definitions. They must remain in the
migration dependency inventory and must not be rewritten or rebound by a Type
migration.

### Constant-to-consumer inventory

| Consumer | Symbols/IDs used | Effect | Evidence/disposition |
|---|---|---|---|
| [`TargetProvisioningRunner.php`](../../app/Release/TargetProvisioningRunner.php): `installPlatform()` | `CapabilityCompositionVocabulary::install()` | Creates or checks all 21 platform Type Objects during target provisioning | STAGING snapshot confirms the 21 rows; production remains unverified. The earlier descriptor-drift overwrite was a critical blocker; the bounded installer-containment slice now rejects drift without rewriting revision 1. |
| [`StandardCapabilityDefinitionCatalog.php`](../../app/Runtime/Definitions/StandardCapabilityDefinitionCatalog.php) | All capability constants and cross-Type references | Builds eight source-defined Definitions, labels, relationships, navigation and claims | Legacy source catalogue used by build scripts/tests; persisted Definitions are not its authority. |
| [`BusinessCreationOperationHandler.php`](../../app/Runtime/Operations/BusinessCreationOperationHandler.php) | `PROJECT_TYPE` | Forces Project into default Business authorization target Types | Persisted grants exist after creation, but the default is source-selected. |
| [`BusinessPresentationProvisioningService.php`](../../app/Runtime/Presentation/BusinessPresentationProvisioningService.php) | `PROJECT_TYPE` plus related core Types | Forces target Types into administrator grants and derives record Presentation content | Reconciliation can source-select authority and View meaning. |
| [`WorkflowLogicIntegrationProvisioner.php`](../../app/Runtime/Workflows/WorkflowLogicIntegrationProvisioner.php) | `PROJECT_TYPE` | Writes Project-specific Workflow event correlation | Persisted Workflow is created, but source code selects the subject Type. |
| [`TargetRuntimeBoundary.php`](../../app/Runtime/Bootstrap/TargetRuntimeBoundary.php) | Project, Milestone, Person, Organisation, Knowledge Item IDs | Dormant legacy setup maps and direct-write helpers | Routes were removed in Stage 1, but source remains and must be quarantined/deleted. |
| [`TargetHtmlBoundary.php`](../../app/Runtime/Presentation/TargetHtmlBoundary.php) | All 21 IDs and labels | Dormant diagnostics/setup maps, including Campaign checks | No current dispatch path; source remains semantic inventory. |
| Legacy capability/marketing/phase `bin` scripts | All 21 constants across creation, cleanup, views, grants, validation and reports | Manual provisioning, direct SQL, diagnostics and historical verification | Test/legacy tooling only; exclude from new runtime authority. |
| [`FixtureInstaller.php`](../../tests/HttpAcceptance/Harness/FixtureInstaller.php) | All 21 constants, descriptors, fields and references | Builds isolated HTTP Objects, capability values, Logic inputs and Views | Test fixture only; does not prove deployed Object state. |
| `Idy007AVocabularyTest`, `PersonOrganisationDefinitionTest`, `DashboardPresentationIntegrationTest`, `BusinessCreationOperationHandlerTest` | Install, publish, grant and Presentation assertions | Encodes current compatibility assumptions | Isolated test evidence only. |
| `database/configuration/idy-008/*.json` | Project Type and related target IDs | Selects capability Type identities for configuration, Logic and Presentation inputs | Source configuration evidence; runtime use remains a separate violation. |

### Complete searched source-path inventory

The following paths were returned by the repository-wide constant/raw-ID
search. They are retained so a future migration cannot silently omit a
legacy verification or provisioning surface.

**Runtime and release consumers**

```text
app/Release/TargetProvisioningRunner.php
app/Runtime/Commands/CapabilityCompositionVocabulary.php
app/Runtime/Definitions/StandardCapabilityDefinitionCatalog.php
app/Runtime/Operations/BusinessCreationOperationHandler.php
app/Runtime/Presentation/BusinessPresentationProvisioningService.php
app/Runtime/Presentation/TargetHtmlBoundary.php
app/Runtime/Bootstrap/TargetRuntimeBoundary.php
app/Runtime/Workflows/WorkflowLogicIntegrationProvisioner.php
```

**Bin/provisioning, diagnostic and historical verification consumers**

```text
bin/bootstrap-demonstrator-types.php
bin/build-phase-3-configure-authority.php
bin/cleanup-old-views.php
bin/create-all-capability-instances.php
bin/create-constituent-authorization-grants.php
bin/create-marketing-application.php
bin/create-marketing-views.php
bin/debug-traversal.php
bin/delete-campaign-type-definition.php
bin/diagnose-constituent-authorization.php
bin/diagnose-marketing.php
bin/diagnose-view-configuration.php
bin/find-campaign-53.php
bin/fix-campaign-references.php
bin/fix-campaign-type-definition.php
bin/idy-009-build-database-authority.php
bin/idy-009-establish-type-definitions.php
bin/idy-009-final-validation.php
bin/idy-009-validate-database-resolution.php
bin/inspect-type-properties.php
bin/minimal-campaign-53-setup.php
bin/phase-3-configure-authority.php
bin/phase-7-complete.php
bin/phase-7-comprehensive-population.php
bin/phase-7-create-default-views.php
bin/phase-7-populate-demo-data-complete.php
bin/phase-7-populate-demo-data-final.php
bin/phase-7-populate-demo-data-v2.php
bin/phase-7-populate-demo-data.php
bin/phase-7-populate-simple.php
bin/phase-9-complete-demo-graph.php
bin/phase-9-completion-report.php
bin/phase-10-demonstrator-workflow.php
bin/phase-11-end-to-end-verification.php
bin/phase-12-deterministic-reasoning.php
bin/phase-13-authority-policy.php
bin/phase-14-provenance-tracking.php
bin/recreate-view-definitions.php
bin/update-view-fields.php
bin/validate-phase-7-acceptance.php
bin/validate-phase-7-projection.php
bin/verify-campaign-53-structure.php
bin/verify-campaign-structure.php
bin/verify-complete-implementation.php
bin/verify-phase-7-complete.php
bin/verify-phase-7-discoverability.php
bin/verify-phase-7-execution.php
bin/verify-staging-data.php
```

**Test consumers**

```text
tests/HttpAcceptance/Harness/FixtureInstaller.php
tests/Integration/DashboardPresentationIntegrationTest.php
tests/Integration/DemonstratorQualificationOperationInvocationTest.php
tests/Integration/Idy007AVocabularyTest.php
tests/Integration/PersonOrganisationDefinitionTest.php
tests/Unit/BusinessCreationOperationHandlerTest.php
```

Raw-ID searches additionally found capability Type references in the four
IDY-008 JSON configuration files, the current target boundary's dormant
diagnostic maps and historical completion/verification documents. Archived
documents and historical reports are evidence only, not migration authority.

### Persisted identity and revision mapping

The verified STAGING snapshot mapping is:

```text
source constant
  -> CapabilityCompositionVocabulary::descriptors()
  -> TargetProvisioningRunner::installPlatform()
  -> GenericObjectRepository create
     or direct SQL revision-1 overwrite
  -> Object ID = constant, Type = TYPE_OF_TYPE_ID, Type revision = 1
```

Read-only evidence confirms 21/21 matching Type Objects in the refreshed
STAGING snapshot, each at current Object revision 1 with one retained
`object_revisions` row. All 21 have matching canonical descriptors,
platform scope and Type-of-Type identity. None of the 21 revision rows has a
`provenance_ref` or `command_id`.

STAGING dependency evidence confirms:

- two Project Objects and twelve retained Project Object revisions;
- Project references from two Authority Grants, 36 Commands, one View
  Definition, two Presentation Objects, one Workflow Definition, nine
  Workflow Authority Bindings and one platform Object Definition;
- no current Objects for the other 20 capability Types; and
- Goal, Audience, Content and Response IDs occur once each inside the
  persisted Campaign Type descriptor, not as current business Objects.

Production state, deployment SHA and production dependents remain unverified.
The STAGING snapshot does not prove that the source installer is safe: its
zero-provenance revision rows and direct overwrite path remain migration
blockers.

No mapping is inferred from a constant, JSON declaration, historical report or
fixture count; the STAGING results above come from read-only queries against
the approved disposable clone.

### Direct authority findings

The current Type installer has four distinct effects:

1. creates Type Objects from PHP descriptors;
2. validates current Object identity and platform scope;
3. directly overwrites `objects.value_json` and
   `object_revisions.value_json` when the descriptor differs; and
4. leaves revision 1 unchanged as the apparent current schema.

Effect 3 destroys legitimate persisted changes and bypasses expected-version,
Command, provenance and revision semantics. It must be removed before any
capability Type migration is implemented.

### Stage 3A migration contract

The target contract is:

1. Every retained Type identity is confirmed as an exact persisted Type Object
   and positive Object revision, or explicitly marked unsupported.
2. Runtime consumers resolve Types from persisted exact references or the
   Object’s persisted Type identity; no consumer imports the PHP catalogue.
3. Type descriptors control validation. PHP supplies reusable validation and
   execution mechanisms only.
4. Schema changes create a new retained Type Object revision through a
   governed expected-version mutation. Revision 1 is never rewritten.
5. Definitions and typed references pin the exact Type Object revision they
   require. Omitted revisions fail closed.
6. Reconciliation preserves authorized persisted descriptors; source drift
   returns explicit reconciliation evidence instead of restoring defaults.
7. Release/bootstrap inputs are accepted only by explicit installation or
   migration boundaries, never by normal runtime resolution.
8. Existing IDs and history remain untouched unless the evidence mapping
   proves the retained identity; conflicts are not automatically rebound.

The current `CapabilityCompositionVocabulary::install()` violates rules 4-6
and cannot be reused as the Stage 3 migration mechanism.

### Ordered implementation and evidence plan

| Step | Dependency/work | Acceptance and rollback constraint |
|---|---|---|
| 1. Confirm mapping | Read-only inventory for all 21 IDs, revisions, provenance and dependents in each approved environment | Every ID has an exact mapping or unsupported disposition; stop on conflict, no data changes |
| 2. Confirm governed Type revision boundary | Select an existing Command/Operation mechanism for platform Type Object revisions | Stale expected versions and unauthorized mutations fail; direct SQL replacement is prohibited |
| 3. Adopt Stage 1 resolver | Identify consumers that can resolve persisted exact Type references | Missing, cross-Business and incompatible Type references fail closed |
| 4. Specify persisted bindings | Record Type Object/revision references in Definitions and supported persisted configuration | No PHP constant selects business meaning |
| 5. Migrate schemas | Replace descriptor reads with persisted Type resolution and preserve revision 1 | Persisted revision changes generic validation; historical revision remains interpretable |
| 6. Migrate runtime consumers | Remove constants from Business creation, Presentation authority and Workflow integration | Existing grants/bindings preserved; missing mapping fails closed |
| 7. Verify dependents | Inventory Definitions, Views/Forms, Workflows, Operations and Business Objects | No identity/history loss; unsupported legacy paths remain quarantined |
| 8. Retire source authority | Remove runtime imports and the direct-overwrite installer | Repository search shows no Type catalogue/fallback; rollback is release-level, never database rewrite |

### Stage 3A test/evidence plan

Before BUILD, tests must prove:

- persisted Type revision controls generic validation;
- governed Type revision changes behavior without PHP changes;
- older revisions remain usable where explicitly referenced;
- cross-Business and missing Types fail closed;
- reconciliation cannot overwrite an authorized persisted schema change;
- no runtime import or fallback to `CapabilityCompositionVocabulary` remains;
- no direct SQL Type overwrite remains; and
- all persisted Definition/Workflow/Presentation dependents retain exact Type
  identity and revision.

### Stage 3A BUILD handoff gates

Stage 3A implementation is not authorized until:

1. all 21 IDs have read-only persisted identity/revision/provenance evidence or
   an explicit unsupported disposition;
2. the historical “15 Type” discrepancy is resolved as evidence;
3. a governed platform Type-revision mutation boundary is documented and
   tested;
4. every consumer has a disposition and exact persisted replacement mapping;
5. the direct SQL overwrite behavior is removed from the approved path;
6. historical Definition/Object/authorization references are inventoried; and
7. no Products & Services, Standard catalog, BusinessRecordCatalog,
   Logic/Workflow or Presentation-profile migration is included.

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

### Installer reachability and overwrite risk

The current target provisioning path is:

```text
TargetProvisioningRunner::run()
  -> installPlatform()
  -> CapabilityCompositionVocabulary::install()
```

The installer is therefore reachable through the current target provisioning
path. If a persisted Type descriptor differs from the PHP descriptor, the
installer directly updates both the current `objects` row and revision 1 in
`object_revisions`. This is an in-place historical rewrite with no Command,
expected version, authorization, provenance or retained new revision.

Stage 3B evidence confirms the current STAGING snapshot still matches the
source descriptors, so no overwrite was observed. The source behavior remains
unsafe because a later descriptor change or persisted authorized edit could be
silently replaced during provisioning.

### Existing mutation boundary inspection

The repository does not currently establish a supported governed mutation
boundary for a platform-scoped Type Object:

- `GenericObjectRepository::revise()` can create a retained revision with
  expected-version and provenance parameters, but it is a persistence
  mechanism and does not establish caller authorization.
- `CommandHandler::handle()` routes generic `object.create`/`object.update`
  through Business scope; `business_id = null` is rejected for that path.
- Platform Command handling currently has explicit branches for
  `business.create` and `definition.publish`, not platform Type revision.
- `AuthorizationService::authorizePlatform()` authorizes only those approved
  platform operations and their target Types; `TYPE_OF_TYPE_ID` Type revision
  is not an approved platform mutation target.
- `DefinitionPublisherAuthorityInstaller` configures Definition publication
  authority only; it is not Type revision authority.

Therefore the actual repository evidence does **not** establish an existing
Command/Operation path that can safely revise a platform Type Object. This is
an unresolved implementation-contract decision, not permission to add a
special-case Type writer or bypass.

### Candidate design comparison

| Candidate | Compatibility | Security/revision implications | Decision |
|---|---|---|---|
| A. Extend the existing platform Operation/Command boundary | Matches `handlePlatformDefinitionPublish()`, `OperationResolver`, platform authorization, coordination lock and evidence creation, but requires a new approved platform Type-revision Operation identity/handler contract | Can preserve exact expected versions, platform User authority, immutable revisions, Command fingerprinting, Attempt/Outcome/Event/Provenance and atomic commit | **Recommended smallest viable design**, subject to owner approval of the new platform authority contract |
| B. Dedicated Type-revision service behind the existing Command | Viable only as an internal handler/service called by Candidate A; a separately callable service would duplicate the mutation boundary | Standalone use risks bypassing platform authorization, idempotency, evidence and coordination; no independent write path is acceptable | **Not recommended as an independent boundary** |
| C. Reuse generic `object.update` unchanged | Incompatible: generic mutation currently requires a Business context and Business-scoped authorization | Would require a platform bypass or would incorrectly treat Type-of-Type as Business data | **Rejected** |

### Required contract decision before BUILD

The canonical owner must approve the smallest extension of the existing
platform Operation/Command boundary that can:

1. authorize a platform-scoped Type Object revision;
2. require the exact Type Object ID and expected current Object revision;
3. validate the proposed descriptor through the persisted Type-of-Type
   mechanism;
4. reject incompatible descriptors or unresolved dependent references;
5. create a new immutable Object revision;
6. retain Command, Action Execution, Attempt, Outcome, Event and Provenance
   evidence;
7. preserve all historical Type revisions;
8. report source/bootstrap drift without restoring a PHP descriptor; and
9. support safe release rollback by selecting a previous persisted revision,
   never by rewriting a database row.

The extension must reuse the existing Operation, Command, authorization and
evidence mechanisms. It must not introduce a Type registry, semantic store,
parallel ledger, direct SQL writer or implicit latest-revision behavior.

### Stage 3D proposed Operation contract — not implemented

Candidate A is the recommended design: extend the existing platform
Operation/Command boundary in the same architectural pattern as
`definition.publish`. Candidate B is permitted only as an internal trusted
handler/service called by that boundary. Candidate C, unchanged generic
`object.update`, is rejected because it requires Business scope.

The proposed Operation is a new persisted platform Operation contract whose
stable Object identity and revision are assigned only after owner approval.
The proposed semantic name is `platform.type_revision`; no UUID or handler key
is assigned by this PLAN.

Proposed persisted Operation contract:

| Member | Required design |
|---|---|
| Scope | `platform` |
| Status | `active` only for the approved current Operation revision |
| Inputs | `type_object_id: uuid`, `expected_object_version: integer >= 1`, `type_descriptor: object` |
| Target | The exact Type Object ID supplied in `type_object_id`; no caller-supplied Business, User, grant, Policy, provenance or effects |
| Handler | Trusted platform adapter registered through the existing Operation handler registry; it may only interpret this contract and call the existing mutation/evidence machinery |
| Authority | Explicit platform User-bound AuthorityGrant and Policy for the new Operation, targeting `TYPE_OF_TYPE_ID`, rechecked at commit |
| Result | Resulting Type Object ID and new Object revision, retained in the existing Outcome/Event/Provenance evidence |

The proposed execution sequence is:

1. Resolve the exact persisted Operation identity/revision through
   `OperationResolver`.
2. Validate the input envelope through the existing Operation input
   mechanism.
3. Authorize the authenticated User through an explicit platform grant
   and Policy. No handler key or Type Object ID grants permission.
4. Begin the existing coordinated transaction and lock.
5. Load the exact Type Object and require `type_id = TYPE_OF_TYPE_ID`,
   `type_revision = 1`, `business_id = null` and
   `current_version = expected_object_version`.
6. Validate `type_descriptor` using the persisted Type-of-Type descriptor and
   existing `TypeDescriptorValidator` rules.
7. Validate dependent exact Type references and reject unresolved or
   incompatible required dependencies. Existing historical references remain
   pinned to their prior Type Object revision.
8. Admit the Command, Action Execution, Attempt and Provenance records.
9. Create the next Type Object revision through the existing generic
   repository with the Command/Provenance identities.
10. Record completed Outcome and Event evidence atomically, then commit.

Failure at any step rolls back the complete transaction and records the
repository-standard rejected/unknown evidence as applicable. A stale expected
version, unauthorized User, malformed descriptor, wrong Type identity,
cross-scope object, missing dependency or incompatible dependent reference
produces no Type Object or revision mutation.

The proposed Operation must not use `definition.publish`: Type Objects are
Type-of-Type Objects, not generic Definition Objects. It also must not use a
Business-scoped generic update as a platform bypass.

### Dependent Type reference contract

The Type Object's current Object revision is the exact Type revision used by
new typed Objects and typed references. Existing Project Objects, Commands,
Views, Workflows and grants that retain Type revision 1 remain historical
revision-1 consumers. A new Type revision is adopted only by a new governed
binding or Object mutation that explicitly names that revision.

The Type-revision Operation must not silently rewrite dependent Objects or
upgrade them to the new revision. If a persisted Definition or typed reference
requires a specific incompatible revision, the Operation rejects the proposal
and retains the current authority. Dependent migration is a separate
governed step.

### Legacy Stage 3C containment matrix (superseded by Stage 3D contract)

The later implementation must make `CapabilityCompositionVocabulary::install()`
an explicit installation/reconciliation adapter with these outcomes:

| Condition | Behavior |
|---|---|
| Type Object absent | Use only an approved bootstrap/migration boundary with retained installation evidence. |
| Descriptor matches | Idempotent success; no current or historical row rewrite. |
| Descriptor differs | Return source-drift/reconciliation-required evidence; do not overwrite. |
| Persisted Type invalid/incompatible | Fail closed; require explicit reconciliation. |
| Authorized schema change | Invoke the proposed platform Type-revision Operation with exact expected version. |
| Stale/unauthorized request | Reject without mutation. |
| Release rollback | Select a prior persisted Type revision or publish a governed correction; never rewrite revision 1. |

No installer code is changed in Stage 3D PLAN.

### Future Stage 3D test matrix

The implementation must later prove:

- platform Type-revision authorization and exact Type Object identity;
- expected-version and stale-version rejection without mutation;
- invalid descriptor rejection;
- immutable new revision creation;
- Command, Action Execution, Attempt, Outcome, Event and Provenance evidence;
- transaction failure rollback;
- absent-Type bootstrap;
- matching-descriptor idempotency;
- descriptor drift reporting without overwrite;
- exact dependent Type revision validation;
- preservation of Project Objects, grants, Commands, Views, Presentation
  Objects, Workflows and Authority Bindings;
- historical Type revision resolution;
- repository protection against direct revision-1 Type overwrite; and
- proof that no Business-scope bypass or parallel mutation pipeline exists.

### Legacy Stage 3C installer containment (superseded by Stage 3D contract)

| Condition | Required future behavior |
|---|---|
| Type Object absent | Use only the explicitly authorized bootstrap/migration path; create the initial Object with retained installation evidence. |
| Existing descriptor matches | Return idempotent success without rewriting the Object or revision row. |
| Existing descriptor differs | Report semantic drift/reconciliation required; never overwrite revision 1. |
| Missing, malformed or incompatible Type Object | Fail closed and require explicit reconciliation. |
| Governed Type revision requested | Use the approved platform Type-revision Operation/Command with exact expected version. |
| Stale or unauthorized request | Reject without Object, revision or evidence mutation. |
| Source descriptor changes after deployment | Treat source as drift evidence only; persisted authority remains unchanged. |
| Existing dependent references | Require exact revision compatibility before adoption; preserve all historical references. |

The installer was not modified during the Stage 3D PLAN. In the subsequent
bounded BUILD slice on 2026-10-16, the descriptor-mismatch branch was replaced
with fail-closed drift detection and persisted-descriptor validation. Matching
descriptors remain idempotent; invalid persisted descriptors fail closed; and
no current or revision-1 row is rewritten. This slice does not authorize or
implement the proposed Type-revision Operation.

### Legacy Stage 3C test plan (superseded by Stage 3D matrix)

The later BUILD must add focused isolated tests for:

- platform Type-revision authority and exact Object identity;
- expected-version and stale-version rejection without mutation;
- invalid Type descriptor rejection;
- immutable new revision creation;
- Command, Attempt, Outcome, Event and Provenance evidence;
- transaction failure rollback;
- absent-Type bootstrap;
- matching-descriptor idempotency;
- descriptor drift reporting without overwrite;
- exact dependent Type revision validation;
- Project Object, grant, Command, View, Presentation, Workflow and binding
  preservation;
- historical revision resolution;
- repository guard against direct revision-1 Type overwrite; and
- proof that no Business-scope bypass or parallel mutation path exists.

### Dependency-ordered Stage 3C BUILD plan

1. Obtain approved read-only production evidence or explicitly record
   production as unverified; preserve the verified STAGING snapshot mapping.
2. Document and approve the platform Type-revision Operation/Command boundary.
3. Add isolated tests for authorized revision, stale rejection, invalid
   descriptor rejection, provenance, historical resolution and dependency
   protection.
4. Contain the existing descriptor-mismatch branch before any governed
   boundary is available; absent Type installation remains one-way bootstrap.
   **Completed locally on 2026-10-16.**
5. Add reconciliation evidence for source drift and refuse stale source
   overwrite. Fail-closed refusal is verified locally; durable reconciliation
   evidence remains part of the future governed boundary.
6. Re-run the 21-Type mapping and dependent-object inventory.
7. Only after the boundary is proven, plan consumer adoption and eventual
   removal of `CapabilityCompositionVocabulary` runtime authority.

### Stage 3C stop conditions

BUILD must stop if:

- any Type identity, revision, provenance or dependent reference is
  unverified;
- the platform Type-revision authorization owner is not approved;
- the proposed path requires direct SQL or a new parallel store;
- a historical revision would be rewritten;
- dependent Project grants, Commands, Views, Workflows or Business Objects
  cannot be proven compatible; or
- source reconciliation would overwrite a persisted authorized descriptor.

## Stage 3D gate resolution — PLAN ONLY

### Authority approval decision

No formal owner-approval mechanism for platform Type-revision authority was
found in the current repository. The configured Definition publisher identity
and grant in
[DefinitionPublisherAuthorityInstaller.php](../../app/Release/DefinitionPublisherAuthorityInstaller.php)
authorize `definition.publish` only; they do not imply Type-revision authority.

Required owner decision:

- approve the proposed persisted platform Operation `platform.type_revision`;
- approve a distinct Type-revision AuthorityGrant and Policy targeting
  `TYPE_OF_TYPE_ID`;
- approve whether the same configured User may hold both Definition
  publication and Type-revision authority, without treating that as automatic;
- approve the trusted handler identity and release owner; and
- approve the exact scope of permitted Type Object identities and dependent
  reference checks.

The project owner approved the proposed architecture in the current session
on 2026-10-16, subject to the distinct grant and Policy, invocation and
commit-time revalidation, existing Operation/Command/evidence pipeline, no
automatic Definition publisher inheritance and no direct database or
historical-revision rewrite. This is architecture approval only; it does not
authorize implementation or production work. The exact Operation identity,
trusted handler/release designation and permitted Type Object scope remain
unrecorded beyond the proposed contract and must not be inferred.

Type-revision authority must remain distinct from Definition publication
authority even if the same User is later configured for both. Invocation
must authorize the exact Operation and recheck grant/Policy state before the
coordinated mutation commits. Unauthorized Users, stale versions and
conflicting Command identities must reject without mutation.

#### Owner decision table

| Decision | Recommended default | If approved | If rejected |
|---|---|---|---|
| Distinct `platform.type_revision` Operation | Approve Candidate A | Proceed with the existing platform Operation/Command pattern | No governed Type revision is possible; remain NO-GO |
| Distinct Type-revision AuthorityGrant and Policy targeting `TYPE_OF_TYPE_ID` | Approve | High-privilege platform Type revisions are explicit and auditable | Existing Definition publisher authority remains insufficient |
| Target Type Object scope | Permit exact supplied Type Object IDs, with descriptor/dependency validation and platform grant target `TYPE_OF_TYPE_ID` | One Operation can handle all approved Type identities without a registry | A separate approved Operation per Type would be required |
| Trusted handler | Existing Operation handler registry, with a new reviewed platform adapter | No arbitrary persisted code dispatch | No safe execution boundary |
| Definition publisher User reuse | Recommended default: not automatic; require a separate explicit grant even if the User is the same | Separation of duties remains possible and approval is attributable | A distinct configured Type-revision User must be installed |
| Commit-time revalidation | Mandatory | Grant, Policy, expected version and dependencies are checked under coordination | Operation is not safe to build |

### Actionable owner request

The project owner is asked to return an explicit decision for each row in the
table above:

```text
platform.type_revision Operation: APPROVE / REJECT
distinct Type-revision AuthorityGrant and Policy: APPROVE / REJECT
target scope: all approved Type Object IDs / explicit allowlist / REJECT
trusted handler/release owner: APPROVE / REJECT / DESIGNATE
Definition publisher User reuse: APPROVE / REJECT / DESIGNATE SEPARATE USER
commit-time grant/Policy/expected-version revalidation: APPROVE / REJECT
existing Command/evidence/provenance pipeline only: APPROVE / REJECT
```

The owner response is now recorded as an attributable current-session
decision. No delegated production operator, separate governance reference or
approved production collection route is established by the repository.
Implementation and production access remain unauthorized by this response.

### Production evidence availability

Available evidence:

- the read-only STAGING snapshot mapping recorded above;
- source and test evidence for all 21 Type Objects;
- the Project dependency inventory; and
- static installer reachability/overwrite analysis.

Production evidence not available:

- production Type Object identity, current revision and descriptor mapping;
- production Type revision provenance;
- production Project/Grant/Command/View/Presentation/Workflow dependents;
- production Definition publication evidence and Type-revision authority; and
- production provisioning/reconciliation behavior.

The repository contains release/package and health-check mechanisms, but no
approved read-only production Object inventory mechanism. `TargetRuntimeConfig`
describes target database connectivity; it is not an authorization or
read-only evidence boundary. No production query was attempted.

The current route audit established the following additional boundaries:

- `staging-registration-diagnostic.yml` and
  `staging-registration-diagnostic-remote.sh` are explicitly scoped to the
  `staging` GitHub environment and require the target database name to equal
  the designated STAGING database name. The remote helper performs bounded
  metadata and diagnostic reads, and its workflow rejects mutation tokens, but
  it is not a production route, does not inventory all 21 Types and
  dependents, and reports that the connected database account has write
  privileges rather than establishing a read-only account.
- `build-target-release.yml`, `target-release.ps1` and `target-activate.ps1`
  build, transport, verify or activate release files. They have deployment or
  activation effects and do not export persisted semantic Objects.
- `provision-target.php` accepts only `--database=staging` and can migrate and
  provision that database. `staging-provisioning-check.php` is a bounded
  read-only STAGING check, not a production inventory route.
- The legacy `discover-*`, `inspect-*`, `diagnose-*` and `verify-*` database
  scripts load target connection settings directly and are not wrapped in an
  approved production selector, read-only authorization contract or complete
  evidence schema. The database-connected set also includes mutation-capable
  scripts, so the group cannot be treated as a safe production mechanism.
- No hosting workflow or HTTP endpoint supplies the required production
  inventory. A deployment metadata file or database connection configuration
  proves neither production authorization nor read-only behavior.

The inspected mechanisms have these dispositions:

| Mechanism | Evidence capability | Mutation capability | Disposition |
|---|---|---|---|
| `bin/target-check.ps1` | Package/filesystem and static checks only | None | Not a production Object inventory |
| `bin/target-release.ps1` / activation scripts | Release transport, manifest and health evidence | Deployment/activation | Not an approved semantic database read path |
| `bin/refresh-test-database-from-staging.ps1` | Read-only STAGING snapshot copied to disposable local DB | Local disposable DB creation | Approved for STAGING evidence only; not production evidence |
| `staging-registration-diagnostic.yml` / remote helper | Bounded release, host, runtime and STAGING metadata; partial STAGING database checks | Helper has no DML, but the workflow uses a database account with reported write privileges | Explicitly STAGING-only and incomplete; cannot establish production evidence |
| Legacy `discover-*` / `inspect-*` / `diagnose-*` / `verify-*` scripts | Partial, ad hoc database reads | Several scripts in the database-connected set can mutate state | Not approved, not production-scoped and not complete |
| `TargetRuntimeConfig` | Database connection configuration | Connection capability, not an inventory operation | Not sufficient authorization or evidence contract |
| Existing HTTP runtime | Authenticated Business reads through application boundaries | May admit governed mutations | No approved production-wide Type inventory endpoint |

Required operator action is an explicitly approved, read-only production
inspection/export that returns the same Type Object, revision, provenance and
dependent-reference inventory as the STAGING evidence, without exposing
credentials or permitting mutation. The smallest acceptable capability is a
production host or database operator using a positively identified production
target and a dedicated read-only account or read-only snapshot/export boundary.
The supplied output must include the environment identity, collection
timestamp, release identity, the complete inventory schema in the separate
evidence request and an attributable read-only attestation. Until that
mechanism and authorization exist, production remains unverified.

### Actionable operator request

After the owner authorizes the collection, a designated operator must return a
non-secret evidence package containing:

1. production environment identity, collection timestamp and collection method;
2. all 21 Type Object IDs, current versions, Type-of-Type binding, scope and
   complete descriptors;
3. all historical Type revisions with `provenance_ref` and `command_id`;
4. exact dependent Object IDs and Type revisions;
5. the Project Objects and all 12 known Project revisions;
6. the two Project-related Authority Grants, 36 Commands, View Definition,
   two Presentation Objects, Workflow Definition, nine Workflow Authority
   Bindings and platform Object Definition;
7. Definition publication evidence and platform authorization configuration;
8. provisioning/reconciliation implementation identity and any evidence of a
   revision-1 overwrite; and
9. a read-only attestation identifying the query/export mechanism and stating
   that no Object, revision, grant, policy, credential or configuration was
   modified.

The operator must not provide passwords, tokens, private keys or other
secrets. The responsible operator is not established by the repository and
must be designated by the owner/operator authority.

### Go/no-go decision

**NO-GO for Stage 3D BUILD.**

The owner architecture decision and installer-containment test prerequisite
are now satisfied. Approved production identity/dependency evidence remains
unresolved, and the governed Operation/Command boundary is not implemented.

The decision changes to **GO** only after the production read-only inventory
is collected and reconciled with STAGING, the governed Operation/Command
boundary is implemented and focused-tested, and the remaining scope/handler
designations are recorded. No Type-revision implementation or production
activation should begin before those conditions are met.

## End-to-end traces

### Type and capability trace

1. `CapabilityCompositionVocabulary` declares the Type IDs and descriptors.
2. `TargetProvisioningRunner` calls `install()`, which creates or checks
   Type Objects.
3. Generic validation can later resolve a descriptor from the database.
4. Independently, `StandardCapabilityDefinitionCatalog` imports the same
   constants and uses them to compose Definitions, relationship declarations
   and capability metadata.
5. Business creation, presentation authority and workflow demonstrator code
   also imports the constants directly.

Therefore the database controls validation for some paths, but it does not
control the complete business semantic binding. Editing the persisted Type or
Definition cannot change all of those consumers.

### Record and presentation trace

1. `BusinessRecordCatalog` reads
   `generic-business-capability-profile.json` in its constructor.
2. The target composition root injects it into `BusinessRecordService` and
   `BusinessPresentationProvisioningService`.
3. List/create/update routes resolve a record key through the JSON profile
   before reading the persisted Type.
4. Presentation reconciliation derives View Definitions and Presentation
   Object graphs from the same file profiles.
5. `reconcileViewDefinition()` updates a persisted View when its value differs
   from the source-derived value.

This is an ongoing source-file override, not a one-way bootstrap. It fails
acceptance criterion 3 and does not preserve legitimate persisted changes.

### Logic trace

1. `PlatformLogicDefinitionService::publish()` reads
   `minimal-project-status-logic.json`.
2. It sends that payload through the governed `definition.publish` Operation.
3. `evaluate()` reads the persisted Definition, so evaluation is persisted
   after publication.
4. A later publication can still replace it from the file fixture.

The mutation boundary is governed, but the semantic input remains
file-authoritative. A persisted Definition revision must become the only
runtime publication/evaluation source, with any seed handled by explicit
installation or migration.

### Direct-write trace

The admin setup methods in F-10 open a PDO and insert into `objects` and
related data directly. They do not create Commands, expected versions,
Action Execution/Attempt/Outcome evidence or governed provenance. This fails
the no-bypass criterion independently of whether the inserted value also
resembles a valid Object.

## Remediation plan

### Phase 1: safe, bounded corrections

1. Replace the old audit script's hard-coded success claims with checks that
   trace runtime consumers and fail when a source catalogue is used as
   authority.
2. Remove or disable the F-10 setup routes from the target runtime. They are
   diagnostic/legacy tooling, not a current platform contract, and their
   direct writes cannot be made compliant by adding another SQL guard.
3. Add focused regression tests proving that a persisted Type/View/Definition
   revision is the value used by the generic runtime and that source files do
   not silently overwrite it.
4. Mark all legacy capability build scripts and old projection paths as
   non-release tooling until their governed replacements are complete.

### Phase 2: persisted replacement contract now documented

The implementation-ready contract is now recorded in
[Implementation Architecture — Data-Defined Semantic Authority and Exact
Binding](architecture.md#data-defined-semantic-authority-and-exact-binding-contract).
It resolves the previous gap without inventing a registry or a new semantic
Type:

- exact persisted `{object_id, revision}` references are the semantic binding;
- persisted View/Form Definitions supply target Type and field meaning;
- the Dashboard-root Presentation Object graph supplies navigation and
  presentation composition;
- generic Logic/Workflow/Operation mechanisms consume exact persisted
  definitions and revisions;
- source keys are display/authoring values only, not runtime lookup
  catalogues; and
- capability composition is a complete ordinary Definition graph, not a Type
  list or capability-specific store.

This contract is **PLANNED, NOT BUILT and NOT VERIFIED**. The historical
`a810...` Type identities, demonstrator handler meanings and the exact
migration disposition of legacy capability Objects still require data
inventory and owner approval. Those are migration evidence gates, not
permission to invent another architecture boundary.

### Phase 3: verification required after the contracts are documented

Focused tests must prove:

1. a persisted Type descriptor alone controls validation;
2. an authorized persisted Definition revision changes behavior without
   source edits;
3. a source catalogue cannot override a persisted View, Workflow, Logic or
   Operation;
4. missing/invalid persisted semantic data returns an explicit diagnostic;
5. reconciliation is idempotent and preserves authorized persisted changes;
6. expected versions, authorization, revisions and provenance remain enforced;
7. no production path writes Objects directly through PDO;
8. existing Person, Organisation, Project, Definition, Workflow, Logic and
   Presentation behavior remains within the generic Object boundary; and
9. fresh Business initialization remains governed and retry-safe.

Only after those focused checks pass should the approved runner be expanded to
the full PHPUnit suite, PHP lint, package validation, HTTP acceptance,
structure checks and `git diff --check`. No staging or production mutation is
authorized by this audit.

## Implemented safe corrections and verification

The following bounded corrections were implemented without changing the
semantic model:

- removed the target dispatch branches for legacy direct-write admin setup and
  authorization diagnostics from
  [`TargetRuntimeBoundary.php`](../../app/Runtime/Bootstrap/TargetRuntimeBoundary.php)
  and [`TargetHtmlBoundary.php`](../../app/Runtime/Presentation/TargetHtmlBoundary.php);
- removed stale setup links from the retained diagnostic implementation; and
- replaced the old hard-coded success report in
  [`audit-architectural-compliance.php`](../../bin/audit-architectural-compliance.php)
  with an initial fail-closed status command; that command is superseded by
  the static retirement gate recorded below.
- integrated `ExactObjectReferenceResolver` into
  [`PresentationCatalog.php`](../../app/Runtime/Presentation/PresentationCatalog.php)
  for exact Business-scoped View Definition revisions, and added the
  two-Business governed Presentation regression in
  [`BusinessScopedViewDefinitionAuthorityTest.php`](../../tests/Integration/BusinessScopedViewDefinitionAuthorityTest.php).
- changed
  [`BusinessPresentationProvisioningService.php`](../../app/Runtime/Presentation/BusinessPresentationProvisioningService.php)
  to fail closed with
  [`PresentationReconciliationDriftException.php`](../../app/Runtime/Presentation/PresentationReconciliationDriftException.php)
  when an existing core View Definition differs from the source profile;
  reconciliation preflights all core Views before creating any missing View,
  preserving persisted values and avoiding partial View mutation.
- replaced
  [`audit-architectural-compliance.php`](../../bin/audit-architectural-compliance.php)
  with a fail-closed static retirement gate that checks source-authority
  reachability, direct Object writes, configuration routes, exact-resolver
  bypasses, legacy capability paths, stale semantic copy and duplicate
  renderers. The gate is intentionally failing while the migration backlog
  remains open.

The private legacy setup methods remain source inventory for the later cleanup;
they are no longer reachable through the target HTTP dispatch boundary. No
database write, staging provisioning, deployment or Products & Services
implementation was performed.

Checks actually performed:

- PHP lint passed for both changed runtime boundaries and the audit command.
- `git diff --check` passed.
- Focused approved-runner suite passed: 13 tests, 748 assertions, 1 skipped.
- The full approved isolated test run completed 495 tests and 2,972
  assertions. It had one failure in the pre-existing
  `LocalRuntimeEnvironmentTest::testLoadsOnlyApprovedRuntimeNamesWithoutOverridingProcessEnvironment`:
  the test expected port `3307` and the inherited process environment supplied
  `3306`. It is unrelated to the changed files and was not altered.
- The full run also emitted existing workflow dispatch diagnostics for
  unauthorized inspection to stderr; these did not produce additional PHPUnit
  failures.
- Stage 2 focused result: 2 tests / 32 assertions passed. The related
  Stage 1/Presentation regression result was 37 tests / 223 assertions
  passed, with one warning and the same existing workflow inspection
  diagnostics.
- Core Presentation reconciliation drift result: 4 tests / 15 assertions
  passed, including matching idempotence, persisted drift preservation,
  all-View preflight/no-partial-View-mutation and unauthorized/cross-Business
  rejection.
- The related pinned PHPUnit regression group passed 47 tests / 296
  assertions with one existing warning. The approved disposable database was
  refreshed from the STAGING snapshot before the run; the existing workflow
  inspection diagnostics were emitted to stderr.
- The compliance gate was executed against 178 runtime/release PHP files and
  failed as required with 18 remaining retirement violations after excluding
  explicit staging-package provisioning input. It identified runtime
  catalogue consumers, dormant direct-write setup paths, the live
  configuration-reconcile route, the optional Presentation resolver fallback
  and legacy capability-specific paths. This is a required failing result,
  not a migration-complete claim.
- No authenticated browser acceptance, deployment or staging health check was
  performed for this audit.

## Current decision

The audit is complete and confirms multiple violations. Documentation has
recorded the invariant, evidence, exact-reference authority contract and
remediation boundary. Stage 1, the Business-scoped View Definition slice and
the bounded core View drift-preservation slice are implemented and
focused-verified within the limits above. The semantic migration remains
incomplete: capability composition, record catalogues, Logic/Workflow rules
and source Presentation profiles remain authorities; the core Presentation
profile still supplies bootstrap content and comparison input.
No manifest, fixture, legacy catalogue or historical projector has been
promoted into authority. Stage 3 requires the remaining migration evidence
and the BUILD handoff gate in the implementation architecture plan.