← Back to directory

status.md

implementation/status.md · 489.4 KB · 2026-11-02 12:48

Implementation Status

Historical terminology note (2026-11-02). The project owner corrected the identity terminology: there is no separate Principal concept; the platform identity is the User. In every entry in this document dated before 2026-11-02, "Principal" means User. The existing persisted Type is named Principal, but its records represent User accounts. Principal is a legacy implementation identifier, not a current architectural concept or a separate identity Type. Historical entries are retained unchanged as dated evidence; new entries use User. See identity and governance and legacy identifiers.

User, commercial model and identity documentation reconciliation - 2026-11-02

Status: DOCUMENTATION ONLY. No implementation evidence is claimed. No application code, database, migration, Type, Operation, Genesis, configuration, workflow, STAGING or test change was made, and no test, build or deployment was run.

Production-readiness audit and standing rule - 2026-10-28

The platform is not declared production ready. The authoritative record of every temporary decision, deferred capability, known defect, architectural gap, operational dependency and production-readiness risk is the readiness register (50 items, PRR-001 to PRR-050; 3 Critical, 17 High, 21 Medium, 9 Low; none verified resolved). The register holds the 10-part gap assessment and the resolution sequence. This section is a summary; where it differs from the register, the register governs.

Standing rule. No temporary decision, workaround, deferred capability or unresolved production-readiness risk may be treated as complete without explicit resolution evidence or a formally authorised acceptance decision. Every temporary or deferred item must have an authoritative record and a defined revisit trigger.

Scope and date: audit of documentation, application source (targeted scans), tests, workflows, scripts, git history to commit d2c0f09 and GitHub Actions run metadata on 2026-10-28, plus one read-only STAGING browser navigation. No test, build, deployment, migration or database command was run.

Top risks (see register for evidence):

(PRR-016, PRR-017).

Production blockers: PRR-001, PRR-002 and PRR-003 (Critical), and the High items listed in register Part B until each is resolved with evidence or formally accepted. No acceptance decision exists.

Unverified areas: current STAGING database state, live recovery cases, accessibility and cross-browser behaviour, display-scope states, the semantic- retirement gate result, the full-suite result for d2c0f09, GitHub Environment settings and hosting configuration.

Not inspected: production systems, STAGING database/server, GitHub settings, backup/monitoring arrangements, root completion-report contents, dependency vulnerabilities. See register Part C.

Recorded temporary decision: View `target_type_revision` pin reverted

Commit 2892813 pinned target_type_revision on capability Views; STAGING View Type revision 1 rejected it (unknown_value_property@value.target_type_revision) and the three IDY-008 reconciliation runs on 2026-10-28 failed. Commit d2c0f09 reverted the pin and made the reconciliation workflow workflow_dispatch only. Edit now uses the record's own persisted type_revision; New is refused (409) and its action hidden for Views without an exact Type revision binding. The decision is tracked as PRR-008 and is resolved only by View revision 2 (PRR-009, blocked on Stage 3D).

Identity models: contact profiles, Business details and governed grant extension - 2026-10-29

Scope: Person contact profile and Business details Types through the governed configuration installer, and the governed authority extension that covers them and the Constituent Type (PRR-052, PRR-056 to PRR-059). Decision record: identity and governance.

Verified on STAGING 2026-10-31 (Build #612 0ecebc6, profile migration #67; fix build be6f7cd, migration re-run):

BusinessTypeAuthorityExtensionTest through the real command path, not exercised in the browser, which has only the administrator Principal).

Implemented earlier, now superseded by the verified list above:

SpearmintDemoPopulationTest passes.

STAGING run order (all workflows are dispatch-only; completed 2026-10-31): reconciliation workflow (installs the Types), authority workflow (mutating run, then a read-only run showing exact_scope_match), demo population, then the Presentation profile revision (rev 20) that references the new Types.

Blocked or open (see register): date of birth and sex excluded (PRR-057); one-to-one cardinality unsupported by the slot store (PRR-058); Business to Person association and the Person to Principal link not instantiable (PRR-059); no UI creation of new-Type records (PRR-009); real Business Details values not seeded; Constituent fields not presented until the record-bound source filter exists (PRR-056 part b); Campaign and Milestone dates await Stage 3D (PRR-055, exit criterion: Stage 3D GO, Type revisions published through the governed route, then a history series meeting the PRR-051 criteria).

KPI history coverage and compact metric-only cards - 2026-10-29

Scope: an audit of every capability KPI and a generic compact height for metric-only cards. Profile revision 18. The KPI inventory and the reason each KPI has or lacks a history series are recorded in PRR-051; the compact-height decision and the Campaign/Milestone date dependency (Stage 3D) are PRR-055; the rule is in UI system.

Result: Finance Revenue, Expenses and Forecast and Marketing Responses remain the only charted KPIs (each charts the same filtered records as its headline by a declared date). No further KPI has a dated source that describes its headline value, so none was charted and no history was inferred from current lifecycle values. The 18 metric-only capability KPI surfaces were reduced from a preferred height of 12 to 6 (previously rendered at 192px with the content centred in empty space). Delivery evidence: commit 21ac5cb (revision 18, tests: tests\Unit OK 174 with 1 skipped, tests\Runtime\Presentation OK 39, git diff --check clean). Build #602 (21ac5cb) and Build #603 (empty retrigger commit e07ea02) each failed within about 3 seconds with no steps and no retrievable logs (job log download returns 404), and Migration #56 (for the earlier docs-only 8c0b23e) failed the same way after Build #601 succeeded. The run annotation (supplied by Stu) gives the cause: "The job was not started because recent account payments have failed or your spending limit needs to be increased." This is an account billing limit, not a defect in the repository, and the spending limit has since been raised. Build #605 (0eeb422, created 16:25:50Z, seconds after the limit change was reported) failed the same way and Migration #60 was skipped, so the change had probably not propagated yet. Build #606 (7795a36, docs only, 16:43Z) then succeeded, followed by Migration #61 (success, 16:45Z), so revision 18 is live. STAGING browser check (authenticated, 2026-10-29): every metric-only KPI card on Sales, People, Products, Projects, Knowledgebase, Operations and Marketing renders at 96px (was 192px; preferred height 6); charted cards (Finance, Marketing Responses) stay at 345px; no horizontal overflow at 375px on the Dashboard and the eight capability pages; Sales' next row starts 16px under the KPI row. The Dashboard KPI row is 269px because its Pipeline card carries a bar chart and the three cards share a grid row (the People and Projects cards there still contain only the literal "No trend history available" text; a content-aware rule for them is not yet done).

Business and Principal detail templates (profile revision 19) - 2026-10-29

Scope: useful detail Views for the Business and Principal Types within the existing governance model. Authorities: readiness register PRR-052 and PRR-056; identity and governance.

Verified causes. The persisted core views for Business and Principal are single-text-node roots that show only the name (and, for the Business, status); core reconciliation never rewrites persisted core objects, so changing the core profile would not reach STAGING. A record_summary template with a parent_type_id takes precedence in presentationTemplateReferences, which is how Person already works, so the correction lives in the governed main profile. STAGING id probe (read-only): the Business contact_email constituent exists but the authorised reader refuses it because the administrator's inspection grants name no Constituent Type target; the Business address and Principal profile_note constituents do not exist. That is the blocker recorded as PRR-056; it is an authority decision and no grant was created. The existing bin/create-constituent-authorization-grants.php (direct SQL, hardcoded ids) is not an approved route and was not run.

Change: business-record-template and principal-record-template (and their name nodes) present every existing Type property (name, status, kind, created, updated) with a muted dash for an absent value and no fabricated fields. A test asserts the templates declare only Type-declared properties. A null object id no longer raises a TypeError that leaked a server path in the 404 message; it now returns "Object not found." Revision 19 (gates: profile JSON, runtime check, migration workflow default, test). Delivered: commit f9e4a58, Build #607 (run 40731340222, success 17:02Z) and Migration #62 (run 40731883304, success 17:03Z). Live STAGING check (authenticated, 2026-10-29): the Business page shows header, Active badge, Profile (Business name) and Record (created, last updated) sections with the Edit link bound to the Business View; the Principal page shows Principal name, Kind (Human) and the same Record section; the Business contact_email id and the non-existent address id both return a 404 "Object not found." with no server path in the response; People (20 rows, 96px KPI cards) and the Person detail page are unchanged. No data or layout was modified. Not delivered: constituent fields (PRR-056). The Principal header shows its Active badge, which resolves the earlier unverified question about Principal status. Tests: tests\Unit OK (175, 1 skipped), tests\Runtime\Presentation OK (39), Idy006BPresentationTest OK (50); five Idy006GraphTest failures are pre-existing (verified at c9492a8); the full suite was not run.

KPI cards, trend correctness and Marketing composition - 2026-10-28

Scope: the three-row generic KPI card, a trend-correctness defect, Marketing Responses history, a Marketing composition fix and a read-only identity inspection. Profile revisions 16 (commit 7507bb1, Build 599, migration 54) and 17 (commit c1f46fa, Build 600, migration 55), all success. Authorities: readiness register PRR-051, PRR-052, PRR-054; UI system; identity and governance.

| Finding | Verified cause | Correction | |---------|----------------|------------| | Trend compared non-adjacent periods (Expenses "-36% vs previous month" compared October with August) | The projector emitted only buckets that contained records | Contiguous zero-filled axis with a per-point complete flag; trend uses the latest complete period against the one before it, states both and names excluded incomplete periods | | "May be incomplete" was a constant | Literal note text | Computed from the period end date against the server date (PRR-054) | | Granularity control offered grains with fewer than two periods | Renderer listed every declared granularity | Line charts offer only grains that draw a line; none left means the generic empty state | | KPI card layout | Icon spanned the metric rows; chart narrower than the card | Compact icon beside label, figure and caption; granularity row; full-width chart (shared CSS, no capability rules) | | Rows of chart KPI cards misaligned when one had no trend line | Cards were vertically centred | Cards that contain a chart align to the top (Finance metric offset 14px on all three) | | Marketing Responses KPI was a bare metric | No history had been authored although received_at is a declared date | kpi_card with week/month/quarter history (rev 16) | | Marketing row had two sparse 345px metric cards beside the new chart KPI | Equal row heights | Active campaigns and Published content are compact span-3 metrics; Responses, kind and channel charts share the next row (rev 17) |

Not done, with reasons: Active campaigns, Published content and Milestone history (Campaign declares no date property, Milestone only due_date; Type revisions need Stage 3D, PRR-051); Dashboard People, Projects and Pipeline, Sales and Operations status KPIs (no suitable dated source). Project already declares start_date and due_date. No data was created or changed.

Identity (read-only STAGING inspection, authenticated): the four identity Definitions exist and show only a name and Type reference; the constituent Type has no Presentation Definition and the Business, Principal and Person Views have no relationship section, so constituent presence is not observable by any authorised read path. The classification of blockers (technical, missing decision, missing mechanism, doable now) is in the identity document; the only unblocked item, core-profile revision 2 for constituents, awaits Stu's confirmation that it is the intended place for that data. No Principal, Membership, Authority or Person record was created and Stage 3D is unchanged.

Verification: tests\Unit OK (173, 1 skipped); tests\Runtime\Presentation OK (39); Idy006BPresentationTest OK (50); git diff --check clean. The five Idy006GraphTest failures remain pre-existing (reproduced at c9492a8); the full suite was not run. STAGING (desktop 1536, mobile 375): Finance shows "+238% vs previous month (Sep 2026 vs Aug 2026. Oct 2026, Nov 2026 incomplete, not compared.)", Expenses "-100%" (September has no expense records, PRR-054), Month/Quarter on revenue and expenses and Month/Quarter/Year on Forecast; incomplete periods draw hollow dots and the tooltip reads "Oct 2026 (period not ended) Revenue booked: £72,000"; Marketing Responses shows Week/Month/Quarter and "0% vs previous month"; style.css?v=dashboard-design-15 is served; Marketing, Finance and Dashboard have no horizontal overflow at 375 (scrollWidth 360). Layout preferences were not changed. Not verified: cross-browser and accessibility checks (PRR-027).

UI refinement validation, KPI history and identity route - 2026-10-28

Scope: validation of commits 5211522 and ea48d0e, one test correction, a chart-labelling defect, Finance KPI history, and a document-only identity route. Profile revisions 14 (commit 8ca3e55, Build 596, migration 51) and 15 (commit aa730a5). Authorities: readiness register PRR-029, PRR-051, PRR-052, PRR-053; identity and governance; UI system.

Starting state (verified, not assumed): 5211522 and ea48d0e are on origin/main; Builds 594/595 and migrations 49/50 succeeded; the Dashboard geometry on STAGING equalled the authored profile (12 cards, size-33, heights 10/16/18 rem) after a reload, so the earlier layout test left no residue.

| Finding | Verified cause | Correction | |---------|----------------|------------| | testNestedPresentationObjectsUseIndependentContentLayout still failing | Bisected: passes at c9492a8, fails from 1b1422f, which changed openSurface from (repeatedRecord && !outerSurface) to !outerSurface. Nested non-outer elements no longer get a wrapper or a presentation-mode-* class; nothing in CSS or JS reads that class, and the nested grid keeps its own data-content-columns. The assertions were stale, not the renderer. | Test now asserts the real contract: 2-column outer grid in presentation-mode-regular, 3-column nested grid, no presentation-mode-expanded, one presentation-object-element, and no data-presentation-preferred-height unless declared | | Tooltip said "Responses by month: 11" while Quarter was selected | label (the tooltip measure) and title baked the time grain into three granular charts (Marketing, Operations, Finance) | Profile rev 14: label is the measure only ("Responses", "Executions", "Revenue"), title is "X over time" | | KPI cards showed no history | Finance KPIs were plain metric elements; the Dashboard KPIs have no dated source | Finance revenue and expenses KPIs are kpi_card containers (icon, metric, month/quarter line with trend) over the same filtered records; Forecast has a scheduled-by-month line with no trend claim (rev 15); generic "Not enough history to show a trend yet." state for lines with under two periods |

KPI outcome: implemented where the data carries genuine dates (Finance effective_date). Not implemented, by design, for Dashboard People, Projects and Pipeline Value: demo records share one created_at, so a history would present seeding time as business history, and Sales target_close_date is a forecast. No history was fabricated and no data was changed. The route and dependencies are PRR-051. Cumulative totals over time and a comparison-period selector were not built (no aggregation extension is documented).

Identity: document-only. The exact Type revisions, governed mechanisms and sequence are in the identity document and PRR-052. New finding: the Business and Principal Definitions already declare constituent Objects (contact_email, address, profile_note) that need no Type revision, but they are not presented and their presence on STAGING was not verified. Stage 3D remains NO-GO; no Principal, Membership, Authority or Person record was created or changed.

Verification performed (STAGING, authenticated, desktop 1536 and mobile 375):

unfilled rows other than the Projects "Project schedule" card, which renders at 66% width and 44 rem height. Its authored layout is full width and 22 rem, so this is a saved layout preference (PRR-053), not the profile. Who saved it was not established and it was deliberately not changed.

Tests run (current checkout): tests\Unit OK (172, 1 skipped); tests\Runtime\Presentation OK (37); Idy006BPresentationTest OK (50); TargetReleaseManifestTest OK; git diff --check clean. The five Idy006GraphTest failures reproduce identically at c9492a8, so they predate this phase (verified, cause not investigated, PRR-029). The full suite was not run.

Limitations: Dashboard KPIs for People, Projects and Pipeline Value have no history (PRR-051); Forecast and the trend text compare only the last two periods; Expenses has two months of data; the Projects "Project schedule" card shows a saved preference (66% x 44 rem) that leaves unused space beside it and can be reset from the layout editor by its owner; saved layout preferences override authored sizing (PRR-053); the platform is not production ready (PRR-001 to PRR-053).

Shared UI refinement, interaction polish and card sizing - 2026-10-28

Scope: generic renderer, CSS and JS only. Profile revision 13 (commit 3d6f116, removal of the data-defined dashboard-date-range "Last 30 days" node) and the mobile topbar single-row layout (77790f8) are earlier parts of this series. Shared refinements are commit 5211522 (Build 594, migration 49).

| Item | Root cause | Correction | |------|------------|------------| | Calendar spanning events | Solid, saturated tone backgrounds plus a brightness filter hid grid lines and dominated the week | Translucent per-tone fill, 1px translucent border, 3px solid left accent, dashed ends for clipped starts/ends | | Collection title/filter/table spacing | Title margin, region gap and header padding were ad hoc | --list-title-gap, --list-block-gap, --list-head-pad tokens | | Filter/sort/granularity/calendar-nav contrast | Global button:hover teal background and --shadow-control leaked into compact controls, giving a solid hover with unchanged dark text and a pink halo | One shared compact-control block: accent-soft hover with accent-strong text; solid accent with white text when selected; no shadow; visible focus | | Search focus | Global input:focus-visible outline out-ranked the wrapper rule, giving a nested green ring | Wrapper :focus-within border and ring; inner input has no outline or shadow; disabled and invalid states at the wrapper | | Pointer/popup | Crosshair and pointer cursors, no keyboard access to marks or legend | cursor: help, focusable marks and legend items, shared tooltip on hover or focus, Escape to dismiss, legend/mark highlight | | Card minimum size | 192px floor enforced in four layers: inline style, .presentation-item CSS, resize JS, and max(12,…) / < 12 in PresentationPreferenceService | Floor lowered to a 1rem positive integer in all layers; preferred_height is emitted and persisted only when a PO or preference declares it; the UserPresentationPreferenceTypeRevision schema already had no minimum, so no Type revision was needed |

Minimum-size decision: height is a floor that content always overrides, so nothing is clipped. Width remains the documented 2/3/4/6-of-6 span enum, so the narrowest card is one third; changing that would be an undocumented grid contract change and is not made here. Authored profile heights of 8 and 10 rem (previously raised to 12) are now honoured.

Verification performed (STAGING, authenticated, 2026-10-28):

presentation items (18 checks).

Tests run: tests\Unit OK (172 tests, 1 skipped); Idy006BPresentationTest OK (50); TargetReleaseManifestTest OK; tests\Runtime\Presentation 37 tests with one failure, the pre-existing testNestedPresentationObjectsUseIndependentContentLayout.

KPI trends (not changed): the Dashboard KPI cards for People and Projects keep the explicit "No trend history available" state, and Pipeline Value remains a per-opportunity bar chart (no time axis, so not presented as history). No trend or comparison is fabricated. The demo records were all created on one day and target_close_date is forward-looking, so a created-at history would be degenerate and a close-date grouping would be a forecast, not a trend. Revisit when demo data has genuine historical spread or a Type revision supplies a dated field; the chart contract already supports group_bucket, granularities and trend.

Person, Principal and Business presentation (document-only): Principal and Business views come from the governed core-object-presentation-profile.json (revision 1, display_name and status). The fields requested (Person date of birth, sex, contact details, biography, qualifications; Business addresses, registration identifiers, contacts, website) do not exist on the Types and each needs a governed Type revision, which Stage 3D (platform.type_revision, NO-GO, PRR-002) blocks. Date of birth and sex additionally need purpose, access and data-minimisation decisions, and any demo values must be clearly synthetic. No Principal, Membership or Authority records were created. The proposed concept map and its five open owner questions remain in docs/architecture/identity-and-governance.md awaiting Stu's approval. Revisit conditions: Stage 3D authorised for build, identity-model questions answered.

Limitations: Edit still resolves through the record's own Type revision; New remains hidden for Types that need a revision; width below one third is not available.

Eight-capability demo business and presentation restoration - 2026-10-27

Scope: demo data, Presentation Objects and the generic renderer for People, Products & Services, Sales, Marketing, Operations, Projects, Finance & Accounts and Knowledgebase. No Type revision, vocabulary digest, deployment mechanism or production configuration changed.

Audit findings

| Class | Finding | Evidence | |---|---|---| | Data | 1-4 records per Type in five capabilities; no dates spread across months | demo service counts (53 records) | | PO composition | People, Sales, Marketing, Operations and Knowledgebase roots never restructured; 192px sparse cards | profile revision 10 | | Generic vocabulary | no grouped aggregation, SVG charts, collection table, detail layout, summary row, percent/datetime/avatar formats | renderer and projector | | Projection | chart produced one point per record only | projectDisplay | | Styling | collection and detail pages were raw spans and unstyled links | /objects?type_id=... | | Drift | none found between source and STAGING | live audit |

Implemented

every node, SVG chart rendering, compact summary and detail rendering. Full suite 605 tests; the only failures are the pre-existing testNestedPresentationObjectsUseIndependentContentLayout and five Idy006GraphTest cases. bin\target-check.php passes.

Defects found during STAGING verification

Presentation Object (binding_mode: object_type, no display) predated the revision 11 person-record-template, and presentationTemplateReferences returned whichever matched first in storage order. A template that declares display.kind = record_summary now takes precedence; other matches remain the fallback (commit 8c6abec). No capability-specific branch was added.

STAGING acceptance evidence

| Item | Evidence | |---|---| | Commits | 72ea2c2 (demo data, profile revision 11, renderer), 8dda93c (remove one-time trigger), 272bac9 (scalar guard, chart cap), 8c6abec (template precedence) | | Demo population | run 40556880620 success (212 records, 83 relationships) | | Build | run 40556880839 success | | Profile migration | runs 40557284572 and 40558596927 success; final run for 8c6abec success; profile revision 11 live | | Workspaces, 1536px and 375px | Dashboard, People, Products & Services, Sales, Marketing, Operations, Projects, Finance & Accounts and Knowledgebase load with no error text and no horizontal overflow | | Charts and tables | Dashboard 3 SVG; Products 2 charts, 1 table; People 2 tables; Sales 2 charts, 2 tables; Marketing 4 charts, 5 tables; Operations 2 charts, 5 tables; Projects 2 charts, 2 tables; Finance 2 charts, 1 table (22 rows); Knowledgebase 2 charts, 2 tables | | Collection pages | People (13 rows), Organisations (7), Offerings (13), Prospects (9), Work (8), Milestones (20), Knowledge items (10), Projects, Finance and Campaigns render as tables with no per-record cards | | Detail pages | Project (sections plus related Milestones and People) and Person (profile plus related Projects and Organisations) render with edit/back/relationship actions | | Layout editing | On the Dashboard, a drag reorder and a resize were saved, survived a reload, then were reverted, saved and reloaded to the original order and sizes | | Projects KPI = 10 | The demo business has 8 projects; two pre-existing STAGING acceptance projects ("STAGING Logic Acceptance Planned Project", "STAGING Acceptance Project 2026-10-13") were not edited. People = 13 includes "STAGING Acceptance Person Edited 2026-10-13" |

Visual assessment: the Dashboard and workspaces use the reference shell, KPI cards, SVG charts, status pills, avatar stacks and tabbed tables. Browser screenshots from the automation tool are clipped on the right edge, so layout conclusions rely on DOM measurements as well as the visible portion.

Known limitations

implemented. Superseded Presentation Objects remain as orphans.

Capability workspace composition restoration - 2026-10-27

Scope: Presentation definitions, demo data and the generic renderer, measured against the approved Pastel SaaS dashboard and capability-page references. Deployment and governed reconciliation were not changed.

Verified causes

badges, toolbar or links); page_header was not composable; metric had no icon or caption.

Implemented

exceeded the 128 KiB environment-variable limit (run 40539766394 failed before any change was applied).

Evidence

the new height, and the original layout was restored and re-verified. The header exposes no drag or resize handle.

Limitations

viewport), so visual checks relied on DOM geometry, accessibility snapshots and a few screenshots. Pixel-level comparison with the references was not achieved; composition and density were compared structurally.

STAGING development workflow and verified UI baseline - 2026-10-27

The latest UI restoration evidence was independently checked before changing the STAGING workflow. GitHub Actions metadata confirms successful completion of the protected target release 40508581471 (run 565) for ba2a6d7, the read-only registration diagnostic 40519820127 (run 55) for 822b7b5, and the protected Presentation migration 40521104030 (run 23) for 822b7b5. The migration run settled the persisted Presentation root at revision 9 and reported the existing Presentation AuthorityGrant already settled at version 10. These run records independently verify the recorded release, diagnostic and migration conclusions; they do not by themselves prove every browser assertion.

The authenticated STAGING Dashboard at https://platform-staging.idiosyncrasy.co.uk/objects/87c1954c-7810-445c-85dd-1bdc96a6f10f was reachable during this change. A browser geometry probe measured a 1536px viewport and scrollWidth == clientWidth == 1536px; the shared shell, Dashboard content and Edit layout control were present. The repository and current authenticated page do not independently reproduce the full four-page screenshot set, all mobile measurements or every saved editor operation, so those remain accepted from the recorded evidence rather than re-run here.

The STAGING development path now removes the repeated manual migration dispatch: staging-presentation-profile-migration.yml retains explicit workflow_dispatch but also runs from workflow_run only after a successful main push of the Build target release artifact workflow. It requires the upstream event to be a push, checks the upstream repository and branch, and checks out the upstream workflow's exact commit SHA. The existing protected SSH transport, STAGING environment, concurrency group, database-identity checks, operator credential boundary and extend-business-presentation.php governed command remain in use.

The migration no longer requires a manually copied AuthorityGrant version. The explicit allowlisted AuthorityGrant Object ID is still required; the CLI reads that grant's current version immediately before deciding whether an update is needed and uses the observed value as the CommandHandler expected version. A concurrent change therefore fails closed through the existing optimistic concurrency check rather than being overwritten. No direct SQL mutation, HTTP fallback, production credential or production path was introduced.

The workflow and CLI changes are validated locally with PHP syntax checks, remote-shell syntax checks and git diff --check. The first automatic run (40524450699, run 24) exposed and reported one stale CLI precondition before mutation: omitting the manual version input was still rejected by the old identity/revision guard. Commit b4c3107 removed that stale guard while retaining current-version resolution and optimistic expected-version validation.

The complete post-change development cycle then ran without a manual workflow dispatch. The exact main push at b4c3107 produced target release/deployment run 40524811555 (run 570), with both artifact build and protected deploy-staging jobs successful. Its chained workflow_run automatically started protected Presentation migration 40525222161 (run 25) on the same b4c3107 SHA; the migration validation, exact-source checkout and protected SSH execution all succeeded. The governed output reported grant_reconciliation.status=already_settled, AuthorityGrant version 10, presentation.status=already_settled, and the persisted Presentation root 87c1954c-7810-445c-85dd-1bdc96a6f10f at revision 9. This demonstrates source change -> exact deployment -> persisted Presentation reconciliation through the authorized development path without a manual operator dispatch.

The available Actions integration still has no workflow-dispatch operation. That is no longer a development blocker because the normal path is an authorized push to main, followed by the protected workflow chain; explicit manual dispatch remains available as a fallback for exceptional re-runs.

End-to-end Presentation change propagation and revert - 2026-10-27

The automated path was exercised with one reversible source-defined Presentation change. The only test definition change was the generic profile's Dashboard container label, from Dashboard to Dashboard - E2E, in database/configuration/idy-008/generic-business-presentation-profile.json. The profile revision remained 9; no layout, capability, authorization, schema or production configuration changed. The expected result was a changed Dashboard page title/heading in the generic renderer, with the existing navigation, workspace surfaces and editor controls unchanged. The source was then restored to Dashboard through a separate commit.

Before the test, the authenticated STAGING browser rendered Dashboard; the Dashboard root was persisted at revision 9 and the AuthorityGrant was at version 10. The test commit 64d9571 triggered target release/deployment 40527592006 (run 572). Its logs recorded the exact deployment SHA 64d9571f96a2652ec879ad8c5ff1c4e5ba7eeced, verified release IDY-TARGET-0bb29c08a8071bb6ec1c1cd2090618728343cd027bd0633adc45847667a2d1c0, HTTP_VERIFICATION=PASSED path=/health and STAGING_DEPLOYMENT=ACTIVATED. The chained protected migration 40527938165 (run 27) checked out the same SHA and reported a governed settled command 9121ca08-d2e7-4e04-912d-6148f0e53d85, Presentation root revision 10, and AuthorityGrant version 10. This was a real reconciliation (status=settled), not an already_settled result.

Authenticated browser verification after the test migration showed page title and H1 Dashboard - E2E. The generic Dashboard cards and workspace links remained present; Edit layout and Inspect remained available; viewport width and document scrollWidth were both 1536px; and the changed result survived an authenticated browser reload. The browser session expired once during an initial reload after deployment and required the existing authorized user to sign in again; no credential was guessed or accessed by the workflow.

The revert commit 356265c restored the source label to Dashboard and triggered target release/deployment 40528415964 (run 573). Its logs recorded the exact revert SHA 356265c30d9245b70dffcf7a314c691aa9e6ad78, IDY-TARGET-14692874aec735e0f3b7468e5548ec6deb18f48f42deeeee0a709d837ac1a4d2, HTTP_VERIFICATION=PASSED path=/health and STAGING_DEPLOYMENT=ACTIVATED. The automatic protected migration 40528950206 (run 28) checked out the revert SHA and reported governed command 974a500a-ce47-40ca-b706-2ce26c2d8f38, Presentation root revision 11, and AuthorityGrant version 10. The final authenticated browser reload rendered Dashboard again, with the same generic surfaces and controls, no horizontal overflow (1536px == 1536px) and no observed layout regression.

Both changes used the existing protected SSH migration and generic CommandHandler transaction/provenance/authority path. No direct database write, manual reconciliation or manual workflow dispatch was used. Local verification included JSON parsing and git diff --check; the target release and both protected migrations also passed their GitHub validation steps. vendor\bin\phpunit remains unavailable in this checkout, so PHPUnit was not run.

Grouped capability overview surfaces and live acceptance - 2026-10-27

The post-release desktop screenshot exposed a remaining composition problem in the otherwise restored generic layout contract: the standalone capability roots selected icon and description primitives as separate page-level surfaces. The generic renderer correctly gave those primitives grid placement, drag handles and resize handles, but their sparse content produced visually empty cards.

Commit ba2a6d7 corrects the persisted Presentation graph without adding capability-specific rendering. The existing Products & Services, Projects and Finance & Accounts *-page-body container is now the page-level overview surface (surface: true, preferred span 4, preferred height 16). Its icon, summary and metric/progress/chart children remain nested content. The collection and navigation objects remain separate page-level surfaces. This preserves generic six-column packing, user positioning and governed layout preferences while removing the standalone sparse primitive cards. The Dashboard-card Presentation Objects and shared renderer are unchanged.

The profile source validates as JSON, the grouped root/child graph was checked explicitly, and git diff --check passes. The focused PHPUnit test was updated but could not run because this checkout has no vendor\bin\phpunit.

Target release 40508581471 (run 565) completed successfully for commit ba2a6d7 and deployed the source profile to STAGING. A fresh registration diagnostic 40519820127 (run 55) completed successfully on 822b7b5 and confirmed the AuthorityGrant at version 10. The protected Presentation migration 40521104030 (run 23) then completed successfully on 822b7b5. Its protected command cc7f873c-ac4a-426b-8f4c-648d55414096 settled the Presentation root at revision 9; the migration log reported the grant as already settled at version 10, with authorization and provenance checks intact.

Authenticated live verification after migration confirmed the persisted graph through rendered object references, not source JSON alone:

(8091aea8-2496-4496-a34a-a013033db844) at 859x256, financial collection (b8253fe9-ca75-4e19-b028-6a5353d334f7) at 640x288, and navigation at 421x192.

The overview surfaces contain their icon, summary and metric/progress/chart content inside the parent content grid; they do not render nested PO cards. Desktop content grids use the available three-column inner layout. The Dashboard continues to render 12 direct surfaces on its six-column grid. Desktop geometry checks report no horizontal overflow for all four pages.

Fresh authenticated desktop and mobile screenshots were captured for Dashboard, Products & Services, Projects and Finance & Accounts and compared with the approved dashboard visual. At the approximately 375px mobile CSS viewport, each affected page renders three single-column surfaces at 335px width and reports scrollWidth == clientWidth (375px), with no horizontal overflow. The screenshots show the shared shell, heading hierarchy, grouped overview, populated collection and governed navigation card consistently.

The generic editor was exercised on the affected pages:

12 resize handles on its existing direct surfaces, saved with no changes, and reloaded without overflow or graph loss.

No capability-specific renderer branch, CSS selector, persistence model or database mutation was introduced for this correction. The only remaining automated-test limitation is that this checkout has no vendor\bin\phpunit and no VS Code test controller; JSON parsing, graph-shape validation and git diff --check passed.

Capability presentation, page roots and demonstrator expansion - 2026-10-27

Desktop grid regression correction

The initial responsive verification covered the browser's narrow CSS viewport, but did not cover the authenticated desktop geometry shown in the approved reference. That exposed a generic CSS regression: the direct .presentation-content-grid child of the six-column .presentation-elements grid did not span the parent columns, so desktop capability content rendered in only the first 202px track of a 1296px content area. This caused the compressed Products & Services, Projects and Finance & Accounts screenshots and made the editing surface appear unusable.

Commit 4e53019 added the generic .presentation-elements > .presentation-content-grid { grid-column: 1 / -1; } rule and advanced the stylesheet cache key to dashboard-design-4. Protected target release 40503192698 (run 561) completed successfully. A desktop browser geometry check after the correction measured the Presentation content grid at the full 1296px content width with three 421px columns. The existing editor wiring was also exercised on the Dashboard: the toggle changed to Save layout, added 12 drag/resize handles, and reported Layout editing enabled. No Presentation persistence operation was performed during this check.

The bounded remediation is settled in STAGING. It uses the existing universal Object, Relationship, revision, provenance, authorization and Presentation contracts. No semantic Type, registry, route, capability-specific renderer branch or capability-specific CSS selector was introduced.

The generic Presentation profile remains revision 9. Existing dashboard-card Presentation Objects remain intact for dashboard use. Three separate governed page roots compose Products & Services, Projects and Finance & Accounts from the existing display vocabulary. Their dashboard cards contain exact navigation.target references to those roots. Generic heading resolution now uses persisted labels, nested Presentation Objects do not receive top-level surfaces, and narrow generic lists and relationship tables remain within their content boundary. The capability configuration is generic-business-capability-configuration-v5.

The governed demo population was executed through the protected mechanism: 42 records were reconciled (18 created and 24 already present), and 20 relationships were reconciled (15 created and 5 already present). Existing records were retained. The live Finance metric £102,900 is backed by the six reconciled financial records. The live Projects page shows 5 projects and milestone progress of 4 of 8 complete (50%); its related record view exposes the governed Northstar milestones and assigned people.

Protected workflow evidence

All workflow runs below were confirmed by GitHub as completed successfully unless explicitly marked as a safe pre-mutation failure:

40496989036 (run 559).

The fresh registration diagnostic 40491891571 (diagnostic run 48) validated AuthorityGrant 57956cd2-b52d-40c8-8031-720e5f06f06c at version 10, with authorization GRANTED, resolution RESOLVED and target contract VALID. The first profile migration attempt 40492102390 (run 20) failed safely before mutation because the six new nodes lacked the required integer order; commit 0342cc7 corrected the source. A fresh diagnostic 40492827874 (run 49) reconfirmed version 10, and migration 40492974297 (run 21) settled with the Presentation root at persisted revision 8. Diagnostic 40493123967 (run 50) completed successfully.

The first demo-population attempt 40493327059 (run 22) failed safely because the generic capability configuration was drifted. Reconciliation attempt 40493508042 (run 18) then stopped safely on the stale Projects declaration. Read-only diagnostic 40493685309 (run 19) established the verified post-v4 STAGING baseline. Corrected reconciliation 40494440309 (run 20) settled People, Organisations, Projects, generic configuration and AuthorityGrant. Governed population 40494566658 (run 23) then completed the 42-record and 20-relationship reconciliation.

Post-population diagnostic 40495398870 (diagnostic run 52) inspected the persisted Presentation reference from the Business Object rather than a historical hardcoded revision. It verified root 87c1954c-7810-445c-85dd-1bdc96a6f10f at revision 8, 64 bounded graph edges, all 64 references authorized and resolved, and render smoke SUCCEEDED. AuthorityGrant remained at version 10 with GRANTED/RESOLVED authorization evidence and a VALID target contract.

Authenticated STAGING browser evidence

After release 559, authenticated reloads of the three page roots used the persisted STAGING graph and the governed records:

rendered six financial records, the financial chart and Recorded value: £102,900.

Comparable authenticated screenshots were captured for the dashboard and all three page roots after reconciliation and population. At the browser's actual narrow CSS viewport of approximately 518px, final reload checks reported:

| Page | bodyScrollWidth | bodyClientWidth | Result | |---|---:|---:|---| | Products & Services | 518 | 518 | No horizontal overflow | | Projects | 503 | 503 | No horizontal overflow | | Finance & Accounts | 503 | 503 | No horizontal overflow | | Northstar Project relationships | 503 | 503 | Table scroll remains internal |

The Northstar relationship view retained four governed Milestones and four People/People-assigned endpoints, including Alex Morgan, Jordan Lee and Riley Shah. Workspace links from all three page roots navigated to their authorized typed collections and returned successfully after reload. The authenticated checks did not mutate data, bypass authorization or access production.

Source validation passed for JSON parsing, Presentation node shape validation, PHP syntax and git diff --check. The prescribed PHPUnit runner remains blocked before test execution in this local environment because IDY_TEST_DB_HOST/the disposable MariaDB service is unavailable; no local test result is represented as a passing PHPUnit run. Empty-state rendering continues to use the generic renderer, but no safe live operation was used to remove governed STAGING records solely to manufacture an empty capability page.

The implementation and protected STAGING evidence for the bounded capability page remediation are complete. Historical entries below retain their original observations and dates.

Scope and Evidence Rules

Snapshot date: 2026-10-25. This document owns the current implementation evidence snapshot and reuse disposition, not architectural definitions or release scope. Historical evidence dates below remain the dates of those observations. Separate architecture approval, implementation presence and behavior verification; none implies the others. The final D01-D10 architecture and initial implementation specification are documented. This does not make the new platform implemented or verified. The old application has no required data continuity, API compatibility or feature-parity obligation. This snapshot records the canonical focused and full-suite evidence listed below; it does not claim browser, deployment or security certification. The verified test runner is .\bin\run-tests.ps1 and the bounded runtime uses PHP 8.3.33, PHPUnit 11.5.56 and isolated MariaDB 10.5.26/InnoDB fixtures. There is no general worker or module runtime. Use documentation governance for workflow and source map for source-to-successor coverage.

Protected Presentation profile migration - 2026-10-26

The protected migration was dispatched through the existing staging-presentation-profile-migration.yml workflow using the freshly validated STAGING AuthorityGrant version. The read-only diagnostic was run immediately before dispatch in 40318982772 (diagnostic run 45) and returned:

c92ebd13-d57e-48c8-b4df-f5171598e91a and Business a20d5b62-078c-4ef4-b0ce-41027f9bc275 selected by the diagnostic.

Migration run 40319138600 (run 19) completed successfully on main at commit 68dd40dab14bfb953222c62419d5c0de85a030a6. Its governed result was status=settled, grant_reconciliation=already_settled at version 10, and the Presentation root 87c1954c-7810-445c-85dd-1bdc96a6f10f was reconciled at revision 7.

The independent post-migration diagnostic 40319275980 (diagnostic run 46) also completed successfully. It confirmed the same AuthorityGrant version and valid authorization, a read-only graph with 25 exact references, rendered status SUCCEEDED, and all 25 references GRANTED and RESOLVED with no rejection. The shared browser pages are currently unauthenticated, so authenticated visual acceptance, screenshots against the approved dashboard reference, and record-level browser traversal remain unverified.

Dashboard regression correction - 2026-10-26

The previous dashboard release exposed two defects that are now corrected in the current working tree. First, the dashboard CSS used a dark purple sidebar, which contradicted the approved light Pastel SaaS reference and the intended light-shell delivery. The sidebar tokens, background, active state and hover state have been restored to the light visual system; the stylesheet cache version remains so the correction is deliverable through the normal release path.

Second, repeated records were rendered by the generic fallback as a text-heavy container with an unconditional underlined Open record link, followed by every child and nested collection. The canonical profile now declares a generic record_summary display with persisted child roles (primary, body, secondary and status). The renderer uses that declaration to create a compact summary surface, renders ordinary values as text, emits only an exact-target icon action, and suppresses child collections declared for detail context while a record is summarized. No Project, Milestone or capability-specific renderer branch was added.

Focused verification after the correction:

The correction was released to STAGING through protected target release run 40317455685 (run 549) from commit c9492a8afe80c6d1df532958dbc2e5c56ba7cee2. Both build-target-release and deploy-staging completed successfully. The protected revision-7 profile migration remains pending because the available GitHub integration does not expose workflow dispatch. The current shared browser session is unauthenticated after release, so no authenticated post-release screenshot or persisted revision-7 verification is claimed here.

Approved dashboard design build - 2026-10-26

The approved Pastel SaaS Business Dashboard reference is now expressed by generic, data-defined Presentation Objects rather than a dashboard-specific template. The design-to-PO mapping and display contract are recorded in ui-system.md and Views and Content. The generic profile is revision 7. It adds a persisted page header, date range control, three KPI compositions, eight differentiated capability surfaces, authorized record summaries, avatar groups, progress, bounded current-value charts and an explicit informational callout. It does not copy sample image values, invent trend history or fabricate media.

The projector derives display data only through the authorized object reader, selects declared fields, bounds the source page size and preserves available, unavailable and invalid-source states. Explicit persisted navigation targets remain the only links; display values remain text. The generic renderer owns HTML, accessibility, responsive layout and styling, with no capability, Project or Milestone conditionals.

Implementation commits:

The protected target release for 6709e48 completed successfully as run 40310903120; both the artifact build and deploy-staging job completed successfully. Authenticated STAGING at https://platform-staging.idiosyncrasy.co.uk/ now shows the cache-busted search/header shell and the prior deployed navigation. The persisted Business Presentation graph is still the previously migrated revision 6, so the new KPI and capability display graph is not yet a claim of live browser acceptance.

Verification completed against the refreshed isolated database:

The integration fixture emitted existing non-fatal Inspection is not authorized workflow diagnostics while PHPUnit still completed successfully.

The protected migration remains pending. The inspected staging-presentation-profile-migration.yml requires Principal c92ebd13-d57e-48c8-b4df-f5171598e91a, Business a20d5b62-078c-4ef4-b0ce-41027f9bc275, AuthorityGrant 57956cd2-b52d-40c8-8031-720e5f06f06c, profile revision 7 and a freshly validated AuthorityGrant expected version. The available GitHub Actions integration exposes workflow inspection, run listing and logs but no workflow-dispatch operation. No migration was dispatched, no stale grant version was reused, and no direct database or SSH mutation was attempted. Consequently there is no new migration run ID or persisted revision-7 verification yet; authenticated visual acceptance of the new dashboard must remain pending that single protected operator action.

Generic Presentation design-system conformance - release and protected-migration boundary

The current design contract maps the light workspace and rounded surface mechanisms in ui-system.md to persisted Presentation Objects as follows: dashboard and capability surfaces are outer Presentation containers; capability titles, summaries and navigation are ordered child Presentation Objects; summaries are embeddable-only text nodes; and navigation is an explicit Presentation target rather than an inferred property of an Object. Nested records remain collection-context summaries, while standalone records retain their own surface and navigation contract. Outer layout spans and responsive reflow remain governed by the existing six-column preference mechanism.

The generic profile now declares summaries for all eight capability cards, with navigation remaining the explicit final child. The renderer delivers navigation through a compact accessible affordance class, keeps ordinary explicitly non-navigable values as text, and preserves the neutral nested record/collection boundaries introduced by 395abbd and 9da6f75. No capability-specific rendering branch or business-type selector was added.

Final validation on the refreshed disposable IDY_TEST_IDY002 snapshot:

continued during integration fixture setup; PHPUnit exited successfully.

Commit 3e671eb was pushed to origin/main and released to STAGING by the protected application workflow as run 40199908615. The release contains the generic reconciliation correction that rebases binding.record_template references to the reconciled record-template revision. The root cause was that ordinary child references were rebased while relationship collection bindings continued to point at stale record-template revision 1; the source profile therefore declared an explicit target that the live projected template did not expose.

The protected staging-presentation-profile-migration.yml workflow was then executed on main at commit 3e671eb as run 40200381415. The workflow and its migration job completed successfully. Its governed output reported status: settled, Principal c92ebd13-d57e-48c8-b4df-f5171598e91a, Business a20d5b62-078c-4ef4-b0ce-41027f9bc275, AuthorityGrant 57956cd2-b52d-40c8-8031-720e5f06f06c already settled at expected version 10, command ID 6e492c9d-b8b4-44d6-ae4b-7f6fabe9415c, and the generic Presentation root 87c1954c-7810-445c-85dd-1bdc96a6f10f at profile revision 6. The workflow checked out the selected commit, validated the migration sources, and executed only through the protected SSH path.

Post-migration inspection and authenticated browser verification at https://platform-staging.idiosyncrasy.co.uk/ confirmed that the persisted Project collection now projects the reconciled record-template targets. The Northstar Project view shows both Milestones and Alex Morgan under People assigned, with exact Open record links to each intended Object. The first Milestone link and the Alex Morgan link opened their intended object views without a 404, blank page or authorization failure; refreshing both views preserved their content and relationships. People lists actual records, Projects lists Northstar and the other authorized projects, and the Dashboard shows all eight capability cards with summaries and compact explicit navigation affordances. The existing Dashboard layout editing controls remain available and were not regressed. A captured STAGING screenshot showed the light workspace, rounded surfaces, three-column composition and compact navigation treatment. No unresolved view-revision limitation was observed on the accepted People, Project, Milestone or Person routes; exact persisted object and Presentation references remain authoritative.

Nested Presentation collection delivery - design-led verification

The canonical Views/Content and UI contracts require a nested repeated record to be delivered as a summary in its collection context, not as a second standalone surface. Its field values remain ordinary text unless an explicit projected target is present, and a nested collection owns its internal record list rather than inheriting the containing surface's content columns.

The first generic renderer implementation had two defects: a container-level record_object target wrapped the recursively rendered fields in an anchor, which created nested-anchor semantics and underlined every descendant value; and nested repeated records received standalone surface treatment. The correction in 395abbd delivers an explicit accessible Open record link for container targets, keeps ordinary field values unlinked, and uses neutral presentation-record summaries. Live STAGING inspection then established a second generic layout defect: the collection itself was allowing the outer content grid to constrain its record list. Commit 9da6f75 adds a neutral presentation-collection boundary whose internal record list is full-width and single-column while preserving each record's own persisted presentation mode.

Focused evidence on the approved refreshed disposable IDY_TEST_IDY002 snapshot:

Workflow event dispatch failed ... Inspection is not authorized. messages; PHPUnit still exited successfully.

Commit 9da6f75 was pushed to origin/main and deployed to STAGING through the protected release workflow as run 40196409073; the run completed successfully. Browser acceptance was performed only at https://platform-staging.idiosyncrasy.co.uk/ after refreshing the deployed page. Projects rendered Northstar Commerce, both Milestone summaries and one Alex Morgan entry. The live DOM showed no nested anchors and no nested standalone surface classes; the nested collection summaries occupied the collection's full-width internal flow rather than the prior approximately 90px tracks. The authorized Relationships view exposed exact links to 51f96600-3b1c-4ab9-b12a-6edb6aa01e39 and 416832b7-35b0-45d5-b978-f50ebe2f3fbf; the first link opened the intended Project Milestone view and a browser refresh preserved its content.

The current persisted/projected Milestone record-template instance did not expose an inline record_object target in the authenticated Project DOM, although the repository profile declaration contains that target. This is a remaining persisted Presentation reconciliation discrepancy, not a renderer fallback: no inline Milestone link is claimed. Direct record navigation is verified through the authorized relationship route, which preserves exact Object identity and existing authorization. Resolving the persisted template discrepancy requires the existing protected Presentation migration with a freshly revalidated AuthorityGrant version; no direct database mutation or authority bypass was used in this release.

This paragraph records the pre-migration observation and is superseded by the settled migration and post-migration evidence in the current conformance section above.

Adaptive Presentation span delivery - focused verification

The current implementation preserves revision-2 generic User Presentation Preference Objects and persists only direct outer Presentation Object order, span and height. The six-column LayoutPackingEngine applies only to the current page-surface list. Recursive descendants receive no outer row, position or span metadata and render inside their parent presentation-content-grid.

Presentation mode and internal content columns are derived delivery metadata: persisted outer spans are restricted to 2, 3, 4 and 6; span 2 is Regular/two columns and spans 3, 4 and 6 are Expanded/three columns. Responsive CSS may still reflow a surface to one visual column at narrow widths. There is no preferred_content_columns property, migration to revision 3, or user-facing Content columns selector. Responsive CSS may reduce the effective internal count without mutating the saved outer preference.

The governed demonstrator population now includes Alex Morgan, Jordan Lee and Riley Shah, Northstar Commerce, their project relationships and the existing cross-capability records. It remains deterministic and idempotent through SpearmintDemoPopulationService; generic newly-created Businesses are not populated with these records.

Focused evidence completed on an approved refreshed disposable IDY_TEST_IDY002 snapshot:

The repository runner emits the known non-fatal Inspection is not authorized workflow diagnostic on STDERR during fixture setup; the PHPUnit exit status and assertions above passed. Protected STAGING release and browser acceptance for this uncommitted adaptive implementation are not claimed by this entry.

The earlier revision-3 preference implementation and its STAGING HTTP 409 remain historical evidence below. The owner decision superseded that selector model; the protected Stage-3D Type-revision migration remains unauthorized.

Project relationship collections — implementation and protected-STAGING boundary

The generic Presentation projector now supports an explicit object_collection source backed by an exact relationship Type, direction, target Type, target View and record-template reference. It reuses the authorized relationship reader, preserves endpoint Object identity and revision, and fails closed for stale, unauthorized, cross-Business or incompatible references. The Projects profile revision is 6; its Project record template composes embeddable-only Milestones and People-assigned collections. Tasks and Deliverables remain unconfigured because no authoritative records were established for them.

The current authenticated STAGING Business is a20d5b62-078c-4ef4-b0ce-41027f9bc275. Its existing Project graph uses the same deterministic Presentation Object identities as the generic profile: Project root 6f87ead0-1145-48d2-b7a0-a9c5ec78e182 revision 2, Milestone template 109f8124-9da6-49ad-b64a-df4d23976fe8 revision 2, and Person template 137d4bca-722e-40cd-99f5-4760e1ff2f1b revision 2. The authorized Northstar Project has two Milestones and Alex Morgan through the assigned relationship. Before reconciliation, the Project detail showed only its four existing fields, as expected.

Local verification after the implementation passed:

emitted during test setup; PHPUnit exited successfully.

Commit a9562a9 was deployed to the protected STAGING environment through GitHub Actions run 40094259310; both the artifact build and deploy-staging job succeeded. The subsequent governed Presentation reconciliation was dispatched as run 40094551338 with the established STAGING Business, Principal and authority grant, but stopped before mutation with CLI authentication failed. No Presentation reconciliation or browser acceptance is claimed. The protected operator credential must be repaired before rerunning that workflow; direct database mutation and local target execution remain prohibited.

Follow-up protected runs 40102073599 and 40102272799 used the same intended commit (f941395), Business, Principal, authority grant and expected profile revision. Both independently failed at the same requirePrincipal() CLI authentication boundary before any mutation. The latest authenticated browser inspection, after restoring the shared session on https://platform-staging.idiosyncrasy.co.uk/, still shows the Project root at revision 2 with only the four existing field children; the relationship-backed Milestone and People-assigned children are therefore not yet persisted or browser-verified.

After the protected staging environment's IDY_OPERATOR_PASSWORD was repaired, run 40182426326 authenticated the established Principal successfully and reached the governed preflight. It then stopped before mutation with The expected Presentation authority grant revision is unavailable. The workflow was still using expected grant version 7; this does not prove the current persisted grant version and must not be changed by guesswork. The next required action is an authorized, read-only inspection of the current grant identity, Business scope and version, followed by a single workflow retry only when that expected-version input is revalidated. No Presentation reconciliation or browser acceptance is claimed.

The protected read-only diagnostic enhancement was published in commit 80d0156 and completed successfully as run 40184669161 (job 121142814850). It established the following live STAGING facts without mutation: grant 57956cd2-b52d-40c8-8031-720e5f06f06c exists with AuthorityGrant Type 1b107cd4-6d04-4a16-91a6-2435c5f75911 revision 4, is Business-scoped to a20d5b62-078c-4ef4-b0ce-41027f9bc275, and has current object version 10. Exact resolution for Principal c92ebd13-d57d-48c8-b4df-f5171598e91a was RESOLVED with authorization GRANTED. Its 47 target references all exist and the target contract is valid; the User Presentation Preference Type reference 8c4f6b8c-3d2e-4f10-8a11-223344556692 is present at revision 2, matching its current version. Seven historical Type references have revisions older than their current Type-object versions, but the migration preflight only requires their exact reference shape and does not reject those historical references. Therefore the exact cause of run 40182426326 is the stale workflow expected grant version 7; the revalidated expected version is 10. Reconciliation remains unattempted after this diagnosis, and no Presentation graph or production state was changed.

The protected migration was subsequently rerun against commit de97505 with expected grant version 10 as run 40187250812. Authentication and authority preflight succeeded; grant reconciliation returned already_settled at version 10, and the governed Presentation command returned settled with command b1f2b2ca-5c0a-4b7e-ba3d-bf3799344cb3. The existing Dashboard root 87c1954c-7810-445c-85dd-1bdc96a6f10f advanced to revision 5 in place. The persisted graph output includes the deterministic Project root 6f87ead0-1145-48d2-b7a0-a9c5ec78e182, Milestone collection d9935d4f-afc3-4e15-8fc1-38b265b87dbd, People-assigned collection c634a823-5e37-429c-8798-b6f859e467bf, Milestone template 109f8124-9da6-49ad-b64a-df4d23976fe8 and Person template 137d4bca-722e-40cd-99f5-4760e1ff2f1b; no parallel Project graph was created. The workflow also emitted a non-fatal Workflow event dispatch failed ... Event subject is not available in the active Business context diagnostic, but the governed command settled and the job succeeded.

Authenticated browser acceptance is still pending: the shared STAGING browser session expired and redirected to /login before the Projects route could be opened. The persisted reconciliation is verified by the protected workflow output, but inline Milestone rendering, the single People-assigned Alex Morgan entry, refresh behavior and layout acceptance are not claimed until the operator restores the authenticated session.

The final evidence commit 870d523 was built and deployed to STAGING successfully by release run 40187371201 (build and deploy-staging jobs both passed).

Authenticated browser acceptance was completed on https://platform-staging.idiosyncrasy.co.uk/ after the shared session was restored. The Projects capability view opened the authorised Projects workspace and listed three records, including Northstar commerce launch. The Northstar Project view rendered its existing name, objective, scope and active status, both authorised Milestones (Discovery and positioning approved and Identity system ready for build) and the single People-assigned entry Alex Morgan. The Project's persisted View relationships route exposed exact links for both Milestones and Alex Morgan; each opened its authorised object view without a 404, blank page or authorization error. Alex Morgan's relationship view exposed Northstar commerce launch and Northstar Commerce. The Project view was reloaded successfully with its fields and embedded collection content preserved.

The rendered post-reconciliation DOM independently confirmed the persisted Project Presentation root 6f87ead0-1145-48d2-b7a0-a9c5ec78e182 at Object revision 3, the authoritative Project View revision 4, and revision 1 for the Milestone record template 109f8124-9da6-49ad-b64a-df4d23976fe8 and Person record template 137d4bca-722a-40cd-99f5-4760e1ff2f1b. The protected migration output remains the evidence for the in-place collection node identities d9935d4f-afc3-4e15-8fc1-38b265b87dbd and c634a823-5e37-429c-8798-b6f859e467bf.

The empty STAGING Acceptance Project rendered its own fields and controls without empty-collection errors. Dashboard rendered all eight capability workspace links. Dashboard Edit layout entered layout-editing mode and was reloaded without saving or changing layout preferences. No unexpected HTTP or rendering errors were observed during this acceptance pass.

The acceptance was performed against the release deployed by run 40187371201; the later status-only evidence commit was then pushed as 20f7cd1 and deployed successfully by release run 40187623120.

Presentation composition and display scope — approved contract

The composition audit established that the existing generic mechanism already supports exact Business-scoped Presentation Object identity and revisions, explicit children[] composition, authorized recursive projection, collection record templates, cycle rejection and one generic renderer. It does not, however, persist independent-display eligibility. presentation_surface is derived from the delivery entry point, navigation.navigable controls only primary navigation, and graph placement alone cannot distinguish a standalone-only object from an embeddable-only object.

The owner-approved correction is one constrained display_scope value on the persisted Presentation Object declaration: standalone_only, standalone_and_embeddable or embeddable_only. Legacy objects with no value retain current behavior through a compatibility interpretation of standalone_and_embeddable; new profile declarations must state the value. Independent page-level references are filtered by scope, whereas explicit parent composition still renders authorized embeddable children. Provisioning rejects standalone-only composition edges and embeddable-only independent roots. No Type revision, preference revision, parallel registry, direct database mutation or STAGING operation is authorized by this contract.

The implementation conformance gate is generic: tests must cover all three scope values, nested composition without dashboard duplication, direct-route filtering, exact revision and Business/authorization boundaries, cycle handling, idempotent provisioning and unchanged adaptive outer layout. This section records the approved contract; runtime implementation and protected STAGING acceptance remain separate evidence.

Protected release evidence for this increment:

database_configured=true, database_connected=true and mutation_routes=[].

The approved php bin/runtime-migrate.php --database=staging path was run with explicit authorization. Runtime migrations were already current, but the governed platform reconciliation failed closed on the existing persisted View Definition Type 8a4f6b8c-3d2e-4f10-8a11-223344556690, whose revision-2 Stage-3D state conflicts with the historical revision-1 vocabulary expected by the current installer. The documented Stage-3D owner decision records that Type-revision migration as not authorized. No STAGING data was changed by this failed reconciliation, no direct SQL or in-place Type rewrite was used, and final save/refresh acceptance remains blocked at this authority boundary.

Presentation display-scope implementation and STAGING evidence — 2026-10-23

The approved generic display-scope implementation is present in commit 0c431e0. It retains exact Presentation Object references, recursive composition, authorization, Business scope, revisions and adaptive outer layout. Focused verification passed:

Inspection is not authorized; PHPUnit completed successfully.

Protected GitHub Actions run 39968800640 built, verified and deployed the runtime commit through the protected staging environment. The follow-up evidence-only commit was built and verified in run 39969850811; its deploy job installed the exact package but the final health-check request transiently returned HTTP 403, so that run is not recorded as a successful deployment. The subsequent direct health check returned HTTP 200 with runtime=target, status=boundary_ready, database_configured=true, database_connected=true and mutation_routes=[]. Authenticated browser checks used only https://platform-staging.idiosyncrasy.co.uk/:

entered edit mode, saved successfully and preserved the dashboard content after refresh.

The three explicit display-scope states have not yet been browser-verified against migrated STAGING Presentation Objects. Existing STAGING Presentation Objects omit display_scope and therefore exercise the documented standalone_and_embeddable compatibility behavior. The protected staging-presentation-profile-migration workflow is the authorized path to reconcile the revision-5 profile and create the explicit representative scope declarations; no direct database mutation or bypass was used. Its dispatch was not available through the current Actions tool boundary, so embedded-only suppression, explicit embedded-child rendering and direct-route rejection remain pending that governed migration.

Presentation Object architecture audit - 2026-10-22

The Presentation Object lifecycle and layout contract were audited against the canonical architecture documents, the committed runtime at e0e7b7b, the persisted demonstrator profiles and the focused Presentation tests. No application code, business data, database or STAGING environment was changed for this audit.

The verified architecture remains the universal Object/Type/Revision model: Business presentation configuration binds an exact Dashboard Presentation Object; recursively persisted child Presentation Objects retain exact identity and revision; governed provisioning validates containment and cycles; the authorized projector produces RenderablePresentation; and the generic HTML renderer serializes that authorized representation. Presentation Definitions and business Objects remain authoritative for structure and values respectively.

The verified layout implementation is limited to the outer six-column page-surface grid and governed order/span/height preferences. The audit found that the committed projector recursively reapplies the outer packing engine and that the generic template/CSS uses record-grid for recursive content. The committed generic preference Type is revision 2 and has no internal one-/two-/three-column preference. Existing renderer tests include an assertion that nested Presentation Objects use the six-column grid; that assertion is now classified as a contract mismatch rather than a regression target.

The canonical target contract now separates page-surface packing, each PO's generic surface, independent internal content layout and responsive adaptation. A future implementation must correct the shared generic path, select an authorized preference mechanism before adding a Type revision, and add semantic conformance coverage for exact identity, authorization, containment, nested rendering, independent layout, responsive persistence and empty-versus-suppressed projection outcomes. This entry does not authorize that implementation or a STAGING mutation.

Final STAGING browser acceptance — 2026-10-22

The generic record-list navigation fix was released from commit b2717028524f57bd30d0000c8f62a594b391d967. The protected target build and STAGING deployment completed in run 39835049646, followed by the governed Presentation profile migration to revision 5 in run 39835730031, using the verified Presentation authority grant version 9. Production was not changed.

Authenticated browser acceptance was completed at https://platform-staging.idiosyncrasy.co.uk/ in the Spearmint Design Business. The People list exposed two persisted Person records and the Projects list exposed the persisted Project records. Alex Morgan opened successfully and its relationship view linked to the exact Northstar Commerce Organisation and Northstar commerce launch Project objects. The Project detail opened successfully and its relationship view linked to both persisted Project Milestones and Alex Morgan; a milestone detail opened and rendered its persisted fields.

The six remaining authoritative capability collection routes each exposed their persisted primary record and exact object-detail link, and each tested detail view rendered configured values:

The final persisted inventory remains 27 meaningful records with complete current revisions: People 2, Organisations 1, Offering 1, Sales 5, Marketing 5, Operations 5, Projects 3, Project Milestones 2, Financial 1, Knowledgebase Items 1, and Knowledgebase Assertions 1. The five persisted relationship endpoints are complete: one Person–Organisation, one Person–Project, two Project–Milestone and one Project–Person relationship.

Dashboard editing was verified at desktop viewport width: the persisted dashboard rendered a six-column grid, each card initially occupied at least two columns, drag and resize controls were present, a card was resized to three columns, Save layout reported success, and reload preserved the three-column span. The final reload showed no browser console or failed request event. A single exploratory request using a non-authoritative, manually guessed Type ID returned 404; no link emitted by the persisted Presentation graph used that ID.

The original empty collection symptom was therefore a generic projection defect, not missing demo records or authorization. Provisioning had persisted Business-scoped runtime Type references while the list boundary compared only portable declaration IDs, and record templates lacked a generic record_object target. The fix matches both governed reference forms and adds exact record targets without capability-specific rendering.

Project management increment — local implementation pending protected release

The next increment extends the existing generic mutation and Presentation contracts without adding a Project persistence model. Generic transitions now resolve a current State Definition from either value.state_id or a data-defined value.status code and preserve that representation on the governed revision. The generic Project capability manifest adds the Business-scoped planned, active and completed State Definitions, planned -> active and active -> completed Transition Definitions, and state-specific persisted Form/action bindings. The manifest is release generic-business-capability-configuration-v3 with digest ab856341de92e41701af43733c4ec0f8c45fed41538a9c96525436fd00500ed8.

The authenticated generic object detail surface now exposes a reusable relationship-assignment form for configured relationship sections. It lists only authorized records of the exact counterpart Type, captures exact current endpoint versions, and submits one governed object.relate Command. It does not implement a Project-specific store or renderer. Project creation/editing continues to use the existing generic Object form and Command path; revision and provenance evidence remain available through the existing history and Command views.

Local verification completed before release:

The protected release and authenticated STAGING Project journey are not yet verified in this snapshot. In particular, milestone creation is available through the existing generic Object form, but an atomic create-plus-relate milestone action and browser evidence for lifecycle transition and relationship assignment remain release acceptance work. Production remains untouched.

IDY-008 v4 Presentation correction — local implementation pending protected release

Authenticated STAGING verification after successful reconciliation run 39851368718 opened the Projects collection and a persisted Project detail, but no lifecycle action was rendered. The persisted v3 configuration showed the two object.transition action elements under the People View declaration a2000000-0000-4000-8000-000000000001; the Projects View declaration a2000000-0000-4000-8000-000000000003 had no action elements. This is a Presentation declaration placement defect, not an authorization, routing or Project-data defect.

The v4 manifest moves both state-specific action elements to the Projects View, leaves People without Project lifecycle actions, and retains the existing exact Project target Type and Form references. The protected reconciliation snapshot now describes the actual post-run STAGING state: People version 4 with the previously installed v3 value, and Organisations and Projects version 3 with the v2 values. The v4 trusted manifest digest is d35b3f042a2202e7227ca89c38163d8fb0bfbb0eb337c447ba8da2261c145124, and the reconciliation Command seed advances to v3 while recognizing v1 and v2 evidence for safe retry.

Local focused verification is complete: the snapshot placement suite passes 3 tests / 7 assertions, and Idy008InstallerTest passes 22 tests / 129 assertions. Protected deployment, reconciliation and authenticated browser verification of the corrected lifecycle action remain NOT VERIFIED. Production remains untouched.

The first post-v4 browser trace then reached the corrected Projects View but failed closed while resolving its exact persisted transition Form references. The Form Definition Objects and revision 1 records are present; the Spearmint demonstrator and inspection grants did not include the Form Definition Type, so the resolver correctly reported the Presentation Definition as unavailable. The existing idempotent demo authority reconciliation now adds that persisted Type reference through the governed Command path. Its focused regression passes 1 test / 43 assertions; deployment, the protected demo-population authority reconciliation and final browser verification remain NOT VERIFIED.

After that grant correction, the Projects collection and detail became available, but the persisted command_effect transition action was absent from the HTML. The generic persisted projector handled delivery for operation_reference actions but not the already-authorized foundation object.transition command effect, and nested persisted JSON values were not recursively normalized before action binding. The projector now emits the exact object transition route with the persisted View context for an authorized command_effect; the regression passes 1 test / 5 assertions. Deployment and authenticated transition execution remain NOT VERIFIED.

The generic object-detail boundary also now exposes the selected persisted transition action as a link to that same governed route, using the exact View ID and revision and the action's persisted label. This is required because the View's action binding selects the Form, while the detail page's navigation actions are assembled separately from the persisted Presentation Object element tree.

The first browser submission then included the declared from_state_id control and was rejected as an unknown field. The generic transition boundary now accepts that declared field only as a consistency check against the server-resolved current state; the submitted value cannot select or override the transition source state. Focused transition coverage passes 2 tests / 22 assertions.

IDY-008 snapshot drift diagnosis and repository correction — 2026-10-22

Protected reconciliation run 39806860084 (workflow run number 10) completed successfully against commit f2ca5d17192bec909b2a4c20ed85d78e4a58594e and reported all three declarations as already_reconciled at Object version 3. That run used the v2 generic capability configuration. It therefore left the three declarations at version 3 containing the authoritative v2 values.

Commit 49093db advanced the trusted generic capability configuration to v3 (ab856341de92e41701af43733c4ec0f8c45fed41538a9c96525436fd00500ed8) by adding the data-defined Project lifecycle Presentation elements. The protected reconciliation script still used the pre-reconciliation version-2 legacy values as its only approved snapshot:

23cd44be5296878469b593038a6cb728c59e6883b2e112728642e78c4f957d05.

The subsequent run number 14 failure was consequently a stale snapshot precondition, not evidence of unexpected STAGING data drift. The repository source for the post-run v2 values is the generic configuration at commit 340581b05e0c7d40f25b4e2385e93ad9c7d60135; after Business reference binding, its canonical digests are People 08ab7b2f9bca5b26a67d0456183ee286c0749be8dfae6607630725711c07bd04, Organisations 718d0cba2429f4e79f9dc84e20c505d3f6d94d74a2e31ad825761815f37751e3, and Projects 6bae0c077a5a292b169980c92fc52e84b1d64b77890f43e228206d6b3c9664c5.

The protected script now approves that exact version-3/v2-value state and uses a new deterministic reconciliation command seed for the v3 configuration phase. The expected-version and persisted-digest checks remain fail-closed; the trusted replacement still comes only from the current repository manifest through the governed reconciliation Operation. No STAGING workflow was rerun and no database was mutated as part of this diagnosis or correction.

IDY-008 reconciliation release follow-up — 2026-10-22

Deployment run 39847582973 successfully released commit ac33d88 to STAGING. Protected reconciliation run 39850467677 then passed the corrected snapshot and governed reconciliation steps but failed while verifying the generic v3 configuration:

state: conflicting
release_id: generic-business-capability-configuration-v3
error: IDY-008 installation state is conflicting.

The failure was an implementation gap in the evidence bridge. The reconciliation script correctly used a new v2 Command identity for the second reconciliation phase, but ConfigurationInstaller recognized only the previous v1 reconciliation Command seed when deciding whether a matching declaration had trusted reconciliation evidence. The three reconciled declarations therefore appeared to be matching values without trusted installation evidence and were classified as conflicting. No direct database operation or weakened snapshot check was used.

ConfigurationReconciliationSnapshots::commandSeeds() now recognizes both the historical v1 and current v2 reconciliation identities. The installer continues to require exact Business, Type, revision, current value, settled Command status, source and matching update effect before accepting either identity. The focused snapshot suite passes with 2 tests, 4 assertions; the IDY-008 installer suite passes with 22 tests, 129 assertions. A new protected release is required before retrying reconciliation. Production remains untouched.

Spearmint demo navigation and population — 2026-10-22

The IDY-008 competing-writer defect and the missing Business Type authority were corrected through the existing governed Object/Definition/Command mechanics. SpearmintDemoPopulationService remains a deterministic, idempotent boundary restricted to the existing Business named Spearmint Design; it creates or reconciles 24 meaningful records and five exact relationships across the eight capability areas. Tasks and deliverables are not represented because those Types are not present in the documented vocabulary.

The population boundary now reconciles only the existing active inspection and demonstrator AuthorityGrants, using expected current Object versions and the normal object.update Command. It merges the required capability and relationship Object references without replacing unrelated grant fields. The final STAGING diagnostic recorded the demonstrator grant at version 9 with 46 references and the inspection grant at version 8 with 45 references; both were active. The following protected runs then completed successfully:

The final read-only persisted inventory from that run was:

All 27 persisted records had meaningful values and complete current revisions. The deterministic population result was 24 records and five relationships, all already_present on the protected rerun, proving no duplicate creation. Relationship endpoint inventory was complete: one Person–Organisation, one Person–Project, two Project–Milestone and one Project–Person relationship. The read-only resolver diagnostic authorized Person, Organisation, Project and Project Milestone Type revisions; no missing-reference fallback was used. Production remains untouched.

Focused tests passed on the staging-refreshing disposable runner: IDY-008 installer suite 22 tests, 129 assertions, and SpearmintDemoPopulationTest 1 test, 36 assertions. The latter covers governed missing-authority repair, preservation of existing grant operations, revision/provenance creation, exact record and relationship reconciliation, and idempotent retry.

The protected browser check reached https://platform-staging.idiosyncrasy.co.uk/login, but the available browser session was unauthenticated and no operator credential was available. People, Projects, relationship rendering, refresh persistence and Dashboard editing therefore remain unverified in the browser; no claim of authenticated UI verification is made. The temporary push trigger used for controlled recovery was removed after the successful run; the population workflow now requires explicit protected workflow_dispatch inputs.

IDY-008 declaration drift and design-only reconciliation — 2026-10-22

The read-only STAGING diagnostic verified the following trusted release:

| Manifest | Release/version | Trusted digest | Compiled declarations | Drifted declarations | |---|---|---|---:|---:| | generic-business-capability-configuration | generic-business-capability-configuration-v2 / 2 | 80daff1ec6a07b68df30128adbd68b2458cab4645d0d5ff48afd58f9b08d42a8 | 14 | 3 |

All three affected Objects are in Spearmint Design Business a20d5b62-078c-4ef4-b0ce-41027f9bc275, have Type 8a4f6b8c-3d2e-4f10-8a11-223344556690 revision 1, and are at current Object version 2. Type identity, Type revision and Business scope therefore match; the drift is in the persisted configuration value.

| Declaration | Runtime Object | Expected v2 value | Persisted version-2 value | Expected / persisted canonical value digest | |---|---|---|---|---| | a2000000-0000-4000-8000-000000000001 (view) | 7a3a7984-bbb2-419a-9791-e710f6ce6e12 | People; display_name text in list/detail; outgoing Organisation section using relationship Type 0e81f586-0b09-4d4c-a300-d12eea8d7557; outgoing Projects section using e39d2ce8-21a0-41a2-a1c0-a1c5599bbb38; active; no elements member | Same identity, label and field, but both fields carry legacy required: true; relationship_sections is empty; extra empty elements member | 08ab7b2f9bca5b26a67d0456183ee286c0749be8dfae6607630725711c07bd04 / 3eee1c732f735f4fecbff5f8b6f8b1c32598940bdc521415332c117232588204 | | a2000000-0000-4000-8000-000000000002 (view) | 93025e29-8135-46d5-9daa-e6e220a4d053 | Organisations; display_name text in list/detail; active; no relationship sections or elements member | Same identity, label and field, but both fields carry legacy required: true; relationship_sections is empty; extra empty elements member | 718d0cba2429f4e79f9dc84e20c505d3f6d94d74a2e31ad825761815f37751e3 / 665762290863df078ffdf51a4c9f75c06d8c49ca22d4ac50138b9e680d74a59d | | a2000000-0000-4000-8000-000000000003 (view) | c1f1b23d-9a45-47d7-b9aa-e8fba507299a | Projects; list name/status text; detail name/objective/scope/status; outgoing Milestones 582e6702-4760-4d08-8d75-4119115ccb5d; incoming People assigned e39d2ce8-21a0-41a2-a1c0-a1c5599bbb38; outgoing People 233d4701-1a82-4ba1-ad3a-bf081be67595; active; no elements member | Same identity and target type, but list repeats objective and scope, all fields carry legacy required: true and select options, relationship_sections is empty, and an extra empty elements member is present | 6bae0c077a5a292b169980c92fc52e84b1d64b77890f43e228206d6b3c9664c5 / 23cd44be5296878469b593038a6cb728c59e6883b2e112728642e78c4f957d05 |

The digest pairs use the diagnostic's recursive object-key canonicalization, preserving array order and scalar types, followed by SHA-256. They are evidence values, not caller-provided authority or a second configuration store.

The retained version-2 history establishes the writer and timing. Each affected Object was recorded at 2026-10-15 15:00:44, with a provenance Object whose source is target_html_business_context_presentation_record_views_core_view; the recorded Command effect is object.update, expected version 1, and result version 2. No IDY-008 installation Command is recorded for those revisions. The exact provenance and Command identifiers are retained in STAGING evidence but are omitted here where they are not needed for the contract.

This proves an implementation-boundary defect rather than missing records, authorization hiding or an intentional approved configuration change: an earlier core/HTML Presentation writer settled legacy values into the exact Business-scoped runtime identities later compiled by IDY-008 v2. The installer correctly classifies the values as drifted and refuses silent overwrite. The existing generic Command update path can preserve history and expected versions, but there is no existing governed declaration-level Operation that authorizes accepting this particular intentional replacement. The existing platform.install_configuration authority and DefinitionApplicationOperationHandler do not cover it.

The documentation-only design records a pending proposal for platform.reconcile_configuration_declaration, candidate ID 9f4f6b8c-3d2e-4f10-8a11-22334455669a, revision 1, trusted handler key platform.configuration.reconcile-declaration. This identity, handler and authority are not allocated or implemented. The proposed action is one server-resolved, Business-scoped, exact-declaration object.update Command with expected-version and persisted-value-digest checks, trusted replacement resolution, ordinary Command locking, retained provenance and idempotent retry. The full pending semantic contract is in the Operation Contract proposal; the IDY-008 implementation boundary is in the pending IDY-008 reconciliation contract.

At this design-only checkpoint, the project owner had authorized documentation only; the later governed Operation implementation and release are recorded in the subsequent implementation sections below. No STAGING mutation was authorized by that checkpoint. The protected acceptance procedure still requires the exact Operation identity/revision, its AuthorityGrant/Policy action, the trusted handler registration and the expected-version and persisted-digest checks documented above. Focused tests cover valid reconciliation, unauthorized Principal and Business authority, stale version, changed persisted-value digest, conflicting Type/Business identity, matching retry, changed-content conflict, unrelated-configuration preservation and rollback on failure.

Batch 4 persisted Logic authority and publication — 2026-10-18

The actual starting state was main at ac2c41d87fa4bfb21d56987da68dc2b9e8731770, with 81 pre-existing worktree status entries and the three-finding compliance baseline recorded by Batch 3. All existing modifications and untracked files were preserved. No reset, clean, stash, commit, push, deployment, STAGING mutation or production mutation occurred.

F-09 is retired by removing the dormant AuthorityPolicy and DeterministicReasoner classes. Targeted searches found no callers, autoload references or runtime consumers of those classes; active governed demonstrator Operation handlers remain unchanged. No replacement PHP policy map or second rules engine was introduced.

F-06 is retired at the runtime boundary. PlatformLogicDefinitionService no longer reads minimal-project-status-logic.json or synthesizes a replacement Definition. /logic/publish now requires the persisted platform Logic Definition, validates its exact generic Definition Type and platform-owned scope, and publishes its current persisted value through the existing governed definition.publish Operation with the current expected version. If the exact current revision already has publication evidence, the route returns the existing publication provenance and does not create a revision. Nested persisted JSON values are recursively converted before governed publication. /logic/evaluate resolves the persisted current revision and fails closed when the Definition is missing, incompatible or unpublished. The runtime-wired generic evaluator also requires publication evidence for platform Logic references while preserving its direct generic test constructor contract.

The source fixture remains only as a configuration/provisioning artifact; no normal target HTTP path reads it. Explicit Workflow/demo provisioning remains separate from runtime Logic consumption. The existing universal Object, revision, authorization, provenance and Operation mechanisms remain the only mutation and semantic-resolution mechanisms.

Focused evidence was run sequentially against disposable IDY_TEST_IDY002 with PHP 8.3.33 and PHPUnit 11.5.56:

| Suite | Result | |---|---| | Idy006BPresentationTest | 37 tests, 276 assertions, 0 failures, 0 errors, 1 warning | | Idy007CDispatchLeaseTest | 10 tests, 49 assertions, 0 failures, 0 errors | | Idy007CFinalizationTest | 27 tests, 137 assertions, 0 failures, 0 errors | | OperationFoundationTest | 73 tests, 141 assertions, 0 failures, 0 errors | | Idy005MutationTest | 48 tests, 191 assertions, 0 failures, 0 errors, 1 PHPUnit deprecation |

The focused Presentation suite includes persisted publication, unpublished evaluation rejection and equivalent publication replay without duplicate revisions. Workflow STDERR continued to report denied inspection diagnostics; these did not fail the passing suites.

Two broader legacy verification runs remain blocked and are recorded rather than suppressed. GenericLogicEvaluatorTest produced 12 tests, 18 assertions, 6 errors and 3 failures in its existing authorized-object fixture path. The legacy demonstrator Operation group produced 10 tests, 10 assertions, 6 errors and 1 failure because its business-scoped demonstrator configuration/vocabulary is unavailable. These failures occur outside the new optional publication gate and require separate fixture/model work; the full PHPUnit suite remains unverified.

The compliance audit changed from 3 findings across 180 runtime/release files to PASS with 0 findings across 178 scanned runtime files. No finding was suppressed or reclassified. The next bounded boundary is a separate modelling and provisioning decision for any demonstrator-specific policy/inference semantics that must become persisted Logic/Workflow data; this batch does not invent that representation or implement platform.type_revision or Stage 3D evidence.

Batch 5 Logic verification and fixture reconciliation — 2026-10-18

The actual starting state was main at ac2c41d87fa4bfb21d56987da68dc2b9e8731770, with 86 pre-existing worktree status entries. Existing modifications and untracked files were preserved. No reset, clean, stash, commit, push, deployment, STAGING mutation or production mutation occurred. The disposable IDY_TEST_IDY002 database was refreshed only through bin/refresh-test-database-from-staging.ps1; STAGING was read-only.

Both Batch 4 failures were reproduced before editing. The first GenericLogicEvaluatorTest run produced 12 tests, 18 assertions, 6 errors and 3 failures. Its fixture used the retired target_type_ids Authority Grant shape and created the grant at the frozen revision 1; authorization therefore denied the Logic source before evaluator-specific assertions ran. The fixture now uses target_type_references with exact Type Object references at revision 1 and creates the Authority Grant at PlatformGovernanceVocabulary::TYPE_REFERENCE_REVISION. The generic authorization reader, exact-reference resolver and evaluator were not weakened. The corrected suite passed 12 tests / 44 assertions / 0 failures / 0 errors.

The legacy demonstrator group initially produced 10 tests, 10 assertions, 6 errors and 1 failure. Its createType() helper made all demonstrator Types platform-owned, so the persisted Business-scoped vocabulary resolver could not discover them. Its Authority Grants also used the retired grant shape and frozen revision. The fixture now installs the current persisted governance vocabulary, creates demonstrator domain and relationship Types under the active Business, uses exact Authority Grant Type references, and gives each relationship Type its distinct persisted source/target Type contract. No demonstrator PHP authority or inference class was restored, and no new configuration model was introduced. The corrected legacy group passed 10 tests / 55 assertions / 0 failures / 0 errors.

Sequential regression evidence against the same disposable database was:

| Suite | Result | |---|---| | GenericLogicEvaluatorTest | 12 tests, 44 assertions, 0 failures, 0 errors | | DemonstratorQualificationOperationInvocationTest (legacy) | 10 tests, 55 assertions, 0 failures, 0 errors | | Idy006BPresentationTest | 37 tests, 276 assertions, 0 failures, 0 errors, 1 warning | | Idy007CDispatchLeaseTest | 10 tests, 49 assertions, 0 failures, 0 errors | | Idy007CFinalizationTest | 27 tests, 137 assertions, 0 failures, 0 errors | | OperationFoundationTest | 73 tests, 141 assertions, 0 failures, 0 errors | | Idy005MutationTest | 48 tests, 191 assertions, 0 failures, 0 errors, 1 PHPUnit deprecation | | ExactObjectReferenceResolverTest | 14 tests, 48 assertions, 0 failures, 0 errors |

The changed PHP fixtures passed PHP 8.3.33 syntax checks and git diff --check passed. The architectural compliance audit reported PASS with 0 findings across 178 scanned runtime files. A final retired-symbol search found no active runtime references to AuthorityPolicy, DeterministicReasoner or minimal-project-status-logic.json; historical phase scripts under bin/ still contain explanatory references to the retired demonstrator classes and are not runtime composition paths. The full PHPUnit run completed with 534 tests, 2370 assertions, 15 errors, 13 failures, 1 warning, 2 PHPUnit deprecations and 3 skipped tests. The remaining full-suite errors are concentrated in the pre-existing ExternalActionAuthorizationTest, Idy008AAccessTest, SendEmailOperationInvocationTest and BusinessCreationOperationHandlerTest fixtures; the failures additionally include GenericStoreAndGenesisTest, Idy004AccessTest, PrincipalAdmissionHardeningTest, staging/release manifest and package tests. These broader failures were not changed or suppressed by this batch. The focused Logic, demonstrator, exact-reference, Presentation, Workflow and mutation evidence above is the verified Batch 5 baseline; the full suite is not a pass.

Batch 3 governed reconciliation and direct-write retirement — 2026-10-18

The recorded starting state for this batch was main at ac2c41d87fa4bfb21d56987da68dc2b9e8731770, with 81 worktree status entries and the six-finding architectural compliance baseline. Existing dirty changes and untracked files were preserved. No reset, clean, stash, commit, push, deployment, STAGING mutation or production mutation occurred.

The two target-boundary direct Object persistence findings are retired. The dormant SQL setup method was removed from TargetRuntimeBoundary, and the dormant SQL setup/provisioning methods were removed from TargetHtmlBoundary; searches found no callers for those methods. The remaining generic Presentation preference handlers no longer accept legacy capability/profile-shaped payloads. They require exact persisted Presentation references and return an explicit 400 invalid-binding response otherwise. GenericObjectRepository is no longer a dependency of the HTML boundary.

Generic user Presentation preferences now persist through the existing CommandHandler: creates use the foundation CREATE operation with expected version 0, updates use the current Object version, and Command settlement and persisted evidence are required before success is returned. Exact Presentation reference authorization, Business isolation, deterministic preference identity and stale-version protection remain enforced. Replaying an identical preference is a no-op rather than an additional revision. The dynamic lifecycle and Presentation fixtures now grant the persisted preference Type explicitly.

The normal HTTP /business-capabilities/reconcile route was removed. Its implementation loaded an installation manifest and could make configuration authority reachable as a normal authenticated HTTP fallback, even though the installer itself uses governed Commands. The configuration installer and manifest path remain available only through their explicit installation/ migration callers; no target HTTP composition path wires them. The retired route therefore cannot create, overwrite or restore semantic authority during normal requests.

Focused evidence, run sequentially against disposable IDY_TEST_IDY002 with PHP 8.3.33 and PHPUnit 11.5.56:

| Suite | Result | |---|---| | Idy006BPresentationTest | 35 tests, 263 assertions, 0 failures, 0 errors, 1 warning | | ExactObjectReferenceResolverTest | 14 tests, 48 assertions, 0 failures, 0 errors | | BusinessScopedViewDefinitionAuthorityTest | 2 tests, 32 assertions, 0 failures, 0 errors | | OperationFoundationTest | 73 tests, 141 assertions, 0 failures, 0 errors | | OperationInputResolverTest | 7 tests, 16 assertions, 0 failures, 0 errors | | Idy005MutationTest | 48 tests, 191 assertions, 0 failures, 0 errors, 1 PHPUnit deprecation | | PrincipalAdmissionBusinessCreationTest | 10 tests, 215 assertions, 0 failures, 0 errors |

The new Presentation assertions cover governed preference persistence, identical replay without duplicate revisions and rejection of the legacy payload shape. Known Workflow STDERR diagnostics report denied inspection events but do not fail the suites. Changed PHP files pass syntax checks and git diff --check passes. The broader PHPUnit suite remains unverified.

The architectural compliance audit improved from 6 retirement violations across 180 files to 3 across 180 files. Retired findings are F-10/F-19 for direct target-boundary persistence and F-12 for reachable HTTP configuration reconciliation. The remaining findings are unchanged and out of this batch: F-09 demonstrator PHP rules in two files and F-06 reachable Logic fixture publication in PlatformLogicDefinitionService. They were not suppressed or reclassified.

Batch 3 is PASS for the target HTTP mutation/reconciliation boundary. The next bounded migration is the separate Logic/Demonstrator persisted authority and publication boundary. Products & Services semantic completion, full-suite verification and Stage 3D production evidence remain outside this batch.

Batch 2 persisted Presentation and Business record semantics — 2026-10-18

Batch 2 has reached its focused implementation boundary. The normal runtime no longer selects generic Business record Types from BusinessRecordCatalog. BusinessRecordService resolves the persisted Type Object through the shared exact {kind: "object_reference", id: UUIDv4, revision: positive integer} contract before invoking the existing governed object.create and object.update Commands. Validation, expected versions, idempotency, provenance, Business isolation and lifecycle settlement remain on the governed path.

Normal Business Presentation reconciliation is now read/validate-only. It requires the Business's persisted exact presentation.dashboard_ref, resolves the bounded nested Presentation graph through ExactObjectReferenceResolver and fails with an explicit reconciliation-required/unavailable state when authority is missing, malformed, stale, unauthorized, cross-Business or incompatible. It does not create Presentation Objects, synthesize Views from PHP profiles, overwrite persisted changes or select a first/current revision. The existing provisioning service remains available as an explicit installation/migration input path; it is not used as a hidden HTTP reconciliation fallback.

The dynamic Business fixture now installs the persisted dashboard, Presentation Objects, View and Form Type authority and the corresponding inspection grant through the test support repository. The onboarding test also verifies the intentional boundary: Business creation without persisted Presentation authority returns 503 and requires explicit governed reconciliation input; after that authority is installed, Business context selection succeeds. The CLI provisioning acceptance path remains green and continues to exercise the explicit provisioning input boundary. A test pipe deadlock caused by large Workflow diagnostics was removed by capturing child-process STDERR in a temporary file rather than reading two blocking pipes sequentially.

Focused evidence, run sequentially against disposable IDY_TEST_IDY002 with PHP 8.3.33 and PHPUnit 11.5.56:

| Suite | Result | |---|---| | PrincipalAdmissionBusinessCreationTest | 10 tests, 215 assertions, 0 failures, 0 errors | | Idy006BPresentationTest | 34 tests, 253 assertions, 0 failures, 0 errors, 1 warning | | ExactObjectReferenceResolverTest | 14 tests, 48 assertions, 0 failures, 0 errors | | BusinessScopedViewDefinitionAuthorityTest | 2 tests, 32 assertions, 0 failures, 0 errors | | OperationFoundationTest | 73 tests, 141 assertions, 0 failures, 0 errors | | OperationInputResolverTest | 7 tests, 16 assertions, 0 failures, 0 errors | | Idy005MutationTest | 48 tests, 191 assertions, 0 failures, 0 errors, 1 PHPUnit deprecation |

PHP syntax checks for the changed Batch 2 PHP files and git diff --check passed. The broader PHPUnit suite remains unverified; the first full onboarding attempt was invalidated by the long-running child-process STDERR pipe and the disposable database connection being lost, then the corrected focused and complete onboarding suites passed after the approved disposable database refresh.

The architectural compliance audit improved from the recorded 11 retirement violations across 180 runtime/release files to 6 violations across 180 files. The remaining findings are the demonstrator PHP authority rules (F-09, two files), reachable Logic fixture publication (F-06), dormant/reachable target-boundary direct persistence (F-10/F-19, two files) and reachable HTTP configuration reconciliation (F-12). They remain separate implementation gaps and have not been suppressed or reclassified.

Batch 2 is PASS for its focused implementation boundary, with the broader suite and production evidence explicitly unverified. Products & Services record semantics and Stage 3D production Type-revision evidence remain outside this batch. The next cohesive migration boundary is governed reconciliation/direct-write retirement at the target HTTP boundary: identify the persisted reconciliation owner and migrate the remaining reachable TargetHtmlBoundary/TargetRuntimeBoundary writes without weakening fail-closed behavior, expected-version checks, provenance or Business isolation. Its prerequisites are an approved persisted reconciliation contract, focused mutation and failure-state tests, and confirmation that no normal runtime path still requires profile/catalogue authority. The remaining demonstrator-rule and Logic-fixture findings should follow as a separate authority-publication boundary.

Batch 0 frozen B1 baseline and binding-contract reconciliation

This section records the documentation-only Batch 0 result on 2026-10-18. No runtime PHP or JavaScript, test, fixture, database, grant, Policy or governance state was changed for this batch. The verified worktree remains on main at ac2c41d87fa4bfb21d56987da68dc2b9e8731770, with 52 changed tracked paths, two deleted tracked paths and 15 untracked paths. Existing worktree changes are preserved and have not been staged, committed, pushed, deployed, reset or discarded.

The recorded pre-closure read-only architectural baseline was FAIL: 12 retirement violations across 180 scanned runtime/release files. A final closure audit below records the current result; this historical baseline is retained for comparison. The findings remain grouped under the catalogue-driven Business record authority, Presentation profile authority, Logic fixture publication, demonstrator rules, direct-write setup and HTTP reconciliation families. The detailed source locations and retirement criteria remain in the data-defined semantics audit.

Contract decisions frozen by existing authority

The following are settled by the canonical implementation architecture, Views and Content and Operation Contract; they do not add a new architecture decision number:

provenance, authorization and idempotency. Existing historical Form revisions are not rewritten, and the architecture does not require a compatibility layer for the legacy ID-only path.

Approved Form ownership and transition semantics — 2026-10-18

The owner decision from the Form Binding Architecture Decision Brief is now recorded against the canonical Presentation and Operation contracts:

cross-Business, wrong-scope, unpublished-when-required and incompatible bindings fail closed. Historical revisions remain immutable and addressable. Existing Forms are not silently rebound.

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 bindings use target.kind = command_effect and continue directly through the governed Command path. Persisted Operation targets use an independent exact Object reference and are validated through the shared exact resolver; a Form reference never grants execution authority.

Generic Object create/edit now requires the exact persisted view_id and positive view_revision, validates the View's target Type revision and derives editable fields from that projection. It calls the existing governed object.create/object.update paths, including expected-version handling, instead of selecting fields through BusinessRecordCatalog. Transition selection no longer enumerates Forms or selects the first match. Legacy form_id is accepted only as a consistency check when supplied by an old client; it is never resolved or used as semantic authority, and a mismatch fails closed.

Focused evidence:

| Suite | Result | |---|---| | Idy006BPresentationTest | 34 tests, 255 assertions, 0 failures, 0 errors, 1 workflow-inspection warning | | ExactObjectReferenceResolverTest | 14 tests, 48 assertions, 0 failures, 0 errors | | BusinessScopedViewDefinitionAuthorityTest | 2 tests, 32 assertions, 0 failures, 0 errors; workflow-inspection STDERR diagnostics were emitted | | OperationFoundationTest | 73 tests, 141 assertions, 0 failures, 0 errors | | OperationInputResolverTest | 7 tests, 16 assertions, 0 failures, 0 errors; existing workflow-inspection STDERR diagnostics were emitted |

The Presentation, exact-reference and Business View slices are focused-green. The Operation suites are now focused-green after their test fixtures were aligned with the exact governance Type-reference contract: authority grants are persisted at the current governance descriptor revision and reference the exact Type revisions used by the fixture objects. No runtime authorization or lifecycle behavior was weakened. The additional governed mutation suite also passed with 48 tests, 191 assertions, 0 failures and 0 errors, with 1 PHPUnit deprecation. Its authority fixtures were aligned to the current exact governance Type-reference contract; no runtime authorization or lifecycle behavior was weakened.

The final read-only architectural compliance audit scanned 180 runtime files and reported FAIL: 11 retirement violations, a reduction of one from the recorded 12-finding baseline. The remaining findings are catalogue/profile authority, demonstrator rules, Logic fixture publication, direct-write paths and reachable HTTP reconciliation; they are not silently treated as retired by the focused Batch 1 tests.

Batch 1 is FAIL for closure rather than PASS: the implemented exact Presentation/Form/View and governed generic mutation paths are focused-green, but the persisted Presentation Operation-action path still lacks the dedicated historical/active lifecycle acceptance evidence required by the frozen specification, and legacy operation_ids/catalogue consumers remain outside this bounded slice. The broad PHPUnit run was started after the focused suites but was stopped after more than 25 minutes without reaching a PHPUnit summary; no broad-suite result is claimed.

Batch 1 closure audit and next migration boundary — 2026-10-18

Implemented and verified in this closure pass:

and uses exact target Type references, preserving the existing authorization, Policy, idempotency, lifecycle and evidence assertions.

The next cohesive migration batch is catalogue/profile-driven generic Presentation and record semantics. It should migrate the remaining BusinessRecordCatalog, record-catalogue View reconstruction, CoreObjectPresentationProfile, dashboard profile and related configuration consumers from runtime semantic selection to persisted, exact-revision Type/View/Presentation bindings. The batch must preserve Business isolation, publication and authorization checks, expected-version/idempotency/provenance behavior and fail-closed handling, while proving that persisted binding changes take effect without PHP or configuration edits. Its prerequisites are Batch 1's missing Presentation Operation-action acceptance evidence, explicit migration fixtures for existing Businesses, and a documented authoritative installation boundary. Stop if that persisted authority or the migration provenance cannot be established; do not use STAGING/production evidence as a substitute.

The legacy consumer inventory immediately below is the pre-Batch 1 baseline. Its rows remain historical evidence; the implementation evidence above is the current state. Batch 1 is not complete until the remaining required exact Operation-action coverage and the compliance gate are resolved or explicitly accepted in a subsequent scoped task.

Batch 0 consumer inventory

| Consumer | Current evidence | Authoritative owner required for Batch 1 | Required migration/test | |---|---|---|---| | Persisted Presentation Object collection bindings | source.kind = view_reference is already exact in PersistedPresentationObjectProjector | Persisted Presentation Object child binding | Preserve exact View revision; test historical View, cross-Business and unauthorized failure. | | Explicit View request path | TargetHtmlBoundary passes view_revision when supplied; PresentationCatalog rejects omitted revisions for explicit IDs | Persisted parent View reference or explicitly validated request | Reject omitted/stale revisions; retain existing exact resolver and Business isolation tests. | | Generic record form | TargetHtmlBoundary::genericObjectForm() reads BusinessRecordCatalog metadata and derives a View ID | Persisted exact View/Presentation binding; no separate Form is mandatory | Remove catalogue reconstruction; test exact View/Type binding and missing/incompatible binding failure. | | Record redirect | recordViewHref() resolves a catalogue View ID and hard-codes view_revision=1 | Persisted record Presentation binding | Preserve the exact bound View revision in navigation; test revision 2 does not fall back to 1. | | Transition Form selection | transitionFormId() scans Business Form Definitions and returns the first matching ID | Exact action-level form_reference plus persisted target Type/invocation context | Replace enumeration with exact resolution; ambiguous or unbound Forms fail closed. | | Form resolution | PresentationCatalog::form() allows a null revision and calls findCurrent() | Exact Form reference supplied by the owning persisted Object | Test historical revision, newer revision non-substitution, stale, unauthorized, cross-Business and incompatible failures. | | View operations | PresentationCatalog::validateOperations() accepts operation_ids and calls findCurrent() for non-foundation Operations | Persisted exact Operation identity/revision in the View Action binding | Migrate IDs to exact references under the frozen Operation Contract; test active/retired and historical revisions. | | Configuration declarations | generic-business-capability-profile.json and generic-business-capability-configuration.json carry View IDs and no complete Form bindings | One-way installation input only; persisted Presentation actions and View bindings own runtime semantics | Quarantine catalogue lookup; test persisted binding changes without PHP/config edits. |

Batch 1 executable acceptance specification

Batch 1 is the next implementation batch. The following specification is frozen so that a later BUILD does not rediscover the resolved contract or silently extend it.

Entry gates

1. The Presentation action binding schema is extended to persist an optional exact form_reference, the compatible target Type and invocation context, without creating a new semantic Type, store or D-number. 2. Test fixtures can persist exact Form, View and Operation references, including historical revisions and distinct Business scopes. 3. The shared ExactObjectReferenceResolver, Presentation authorization boundary and Operation resolver are the only resolution mechanisms. 4. Catalogue/profile declarations are identified as one-way installation input or explicitly quarantined; they are not accepted as runtime semantic authority.

Focused tests and expected outcomes

provide an authoritative persisted binding; it must fail explicitly rather than select a current Object.

Exit gates

git diff --check and the compliance gate are executed sequentially and their actual results are recorded.

Stop conditions

introduce a second resolver/store/ledger, or rewrite history.

The wider Business record catalogue, capability authority, Logic/Workflow authority, direct-write retirement, HTTP reconciliation retirement, Products & Services semantics and Stage 3D production evidence remain separate batches.

Global Object Routing and Presentation Remediation — local implementation complete, deployment pending

The canonical persisted Object detail surface is /objects/{id} and the shared presentation.php renderer. Definitions, Logic, Workflow, Presentation, Principal, Business and Business-derived Objects are required to use that boundary. Dedicated /definitions, /workflow, /logic, /profile, /business-configuration and /capabilities/... object/view routes and their redirect aliases are not part of the current implementation. Authentication, Business selection/creation, initialization, reconciliation, command and Operation invocation remain process-level boundaries only.

The current source correction removes the Definition/Workflow/Logic workspace renderers, removes the duplicate object-detail renderer, and routes persisted Definition inspection through the generic authorized Object reader and shared Presentation Object graph. Business-scoped edits use the governed generic Command mechanism; platform-owned Definition edits use the same global /objects/{id}/edit form surface and the governed definition.publish Operation with exact expected revisions. The edit form fields are resolved from the persisted Definition Presentation.

Business context selection now invokes the existing full governed Business Presentation reconciliation. Fresh Business provisioning therefore creates the persisted generic collection Views and Presentation Object bindings for configured Person, Organisation and Project records as well as the core Business, Principal and Definition Presentations. The source profile and HTTP fixture regression both reject obsolete capability/library targets.

The shared layout mount now carries a persisted context reference for generic Object lists, details, revisions and Presentation instances. The existing authorized generic preference endpoint was exercised locally with a reorder, span and height update; the preference was persisted and reapplied after reload. Deployed STAGING browser verification of Dashboard, People, Products and Definition layouts remains NOT VERIFIED pending deployment of this working tree.

Products & Services semantic configuration gap — unresolved

The authoritative generic-business-capability-profile.json declares products-services with an empty records list. The repository contains no existing Product or Service record Type descriptor, persisted record Presentation/Form binding, or corresponding governed record Operation that can be selected without inventing new semantic definitions. The Products & Services Presentation node is therefore a configured generic navigation/content node, not an applicable Object collection or editing surface. This is NOT VERIFIED as a populated capability and remains a semantic configuration prerequisite, not a rendering defect.

Data-defined semantics audit — violations confirmed, migration gated

The repository-wide audit in data-defined-semantics-audit.md confirms that the generic validator and governed mutation paths coexist with live source-file semantic catalogues. BusinessRecordCatalog, BusinessPresentationProfile, CoreObjectPresentationProfile, CapabilityCompositionVocabulary, StandardCapabilityDefinitionCatalog, demonstrator rules, and legacy administrative setup paths remain runtime or provisioning authorities for business meaning. Existing persisted Objects do not make these paths compliant when source values still select or overwrite the persisted meaning.

The audit records legitimate foundation/release bootstrap separately from confirmed violations and identifies the persisted key/binding and data-defined handler contracts required before migration. No Products & Services semantic data was added, no database was changed, and no capability semantic migration is authorized until those contracts are documented.

The bounded safe correction removed the legacy target HTTP dispatch branches for direct-write administrative setup/authorization diagnostics and replaced the former hard-coded compliance report with a fail-closed audit status command. PHP lint, git diff --check and focused tests passed. The full isolated run completed 495 tests / 2,972 assertions with one unrelated environment-port failure in LocalRuntimeEnvironmentTest; deployment and authenticated browser acceptance remain unverified.

Data-defined semantic authority contract — PLAN ONLY

The implementation-ready exact-reference authority and binding contract is documented in the implementation architecture contract. It reuses exact persisted {object_id, revision} references, existing Type, Definition, Presentation, Logic, Workflow, Operation, authorization and Command mechanisms; it introduces no semantic registry, alternate store or new architecture decision.

The selected first proof is a two-Business, Business-scoped persisted View Definition and Presentation binding slice. It is now IMPLEMENTED and FOCUSED-VERIFIED. Products & Services remains outside this slice.

The ordered migration stages cover exact resolution, the View Definition slice, capability Type vocabulary, complete Definition composition, record and demonstrator data, Logic/Workflow bindings, Presentation profile retirement, bootstrap/reconciliation boundaries and obsolete-authority removal. The audit findings register now includes foundation/bootstrap, uncertain-boundary and dormant-legacy coverage. No catalogue migration or Products & Services semantic data was added.

Stage 1 exact-reference resolution — implemented, focused-verified

The generic ExactObjectReferenceResolver now composes the existing AuthorizedObjectReader, FoundationObjectRepository, TypeDescriptorValidator and DefinitionPublicationEvidenceReader. It accepts only exact {kind, id, revision} references, validates the persisted Type Object and exact Type revision, enforces Business/Principal inspection authority, applies platform Definition publication evidence and returns an immutable exact-revision result. Missing, malformed, unauthorized, cross-Business, incompatible, unpublished and malformed-value cases fail with typed diagnostics. It performs no mutation, publication, traversal or handler dispatch.

Focused verification in ExactObjectReferenceResolverTest passed 13 tests / 33 assertions. Existing semantic/Definition/Logic regression coverage passed 32 tests / 297 assertions. This does not claim that existing catalogues or consumers have migrated: capability composition, record catalogue, Logic/Workflow and Presentation profile migrations remain planned Stage 3+ work.

Stage 2 Business-scoped View Definition slice — implemented, focused-verified

TargetRuntimeCompositionRoot now composes the Stage 1 resolver into PresentationCatalog. When a persisted view_reference supplies an exact View Definition revision, the catalog resolves that exact Business-scoped Object through Stage 1 before applying its distinct View target-Type, field, operation and element validation.

BusinessScopedViewDefinitionAuthorityTest creates two isolated Business scopes, persists separate View Definitions and Presentation Object graphs through governed Command/provisioning boundaries, revises only Business A's View Definition, updates A's exact binding and proves:

Focused result: 2 tests / 32 assertions passed. The related Stage 1 and Presentation regression run passed 37 tests / 223 assertions, with one existing warning and the known workflow inspection diagnostics emitted to stderr by the test runtime. No full-suite claim is made for this stage.

The persisted Presentation Object projector and authorized Presentation target resolver now use the same exact resolver for Object references in the production composition root. Direct repository fallbacks for platform Definitions and Type Objects were removed from those paths, so unpublished, malformed, incompatible, missing or unauthorized references fail closed without rendering or mutation. A focused regression proves that an unpublished Definition cannot be projected through the former fallback. The new regression passed 1 test / 3 assertions. The related persisted graph and collection regressions passed 3 tests / 32 assertions, the production-composition Logic regressions passed 3 tests / 23 assertions, and the Stage 1/View authority regressions passed 15 tests / 65 assertions. The Presentation runs emitted the existing workflow-dispatch STDERR diagnostic and one known warning; those diagnostics did not produce test failures in the pinned PHPUnit run. The complete Presentation file remains subject to that wrapper diagnostic and is not claimed as a clean full-file run.

Core Presentation reconciliation drift containment — implemented, focused-verified

BusinessPresentationProvisioningService::reconcileCoreObjects() now preflights every expected core View Definition before issuing any create command. An existing persisted View whose canonical value differs from the source profile raises PresentationReconciliationDriftException with the exact Object ID and current revision. Matching persisted Views remain idempotent; persisted values are not overwritten; and a later drift cannot leave an earlier missing View partially created. Unauthorized and cross-Business contexts continue to return not_authorized before reconciliation.

The focused reconciliation result passed 4 tests / 15 assertions, covering initial creation and repeat idempotence, drift preservation and revision reporting, all-View preflight/no-partial-View-mutation, and authorization/isolation failures. The related pinned PHPUnit regression group passed 47 tests / 296 assertions with one existing warning. The disposable test database was refreshed from the approved STAGING snapshot before the run. Existing workflow inspection diagnostics were emitted to stderr; they did not fail the direct pinned PHPUnit run. The wrapper run-tests.ps1 remains unable to surface this run cleanly because it treats that native stderr diagnostic as a terminating error.

This is containment, not full profile migration: the JSON core profile still supplies bootstrap content and comparison input. Stage 3 remains blocked by the unavailable authorized production evidence package, and platform.type_revision remains unimplemented.

Consolidated migration backlog and compliance gate — documented and exercised

The canonical audit now contains one dependency-ordered backlog covering findings F-01 through F-20, including each current source/consumer group, persisted exact-reference replacement, generic mechanism, migration boundary, regression evidence, dependencies, blockers and retirement criteria. Its critical path is:

foundation Types
  -> complete capability Definitions
  -> Business configuration
  -> record schemas/forms and Presentation graph
  -> Logic/Workflow/Operation bindings
  -> demonstrator rule retirement
  -> dormant route/path removal
  -> bootstrap boundary proof
  -> final compliance gate

The implementation batch for this session replaces the previous documentation-only compliance status command with audit-architectural-compliance.php, a fail-closed static retirement gate. It scans runtime/release reachability for retired source catalogues, direct Object writes, configuration routes, optional exact-reference fallbacks, resolver bypasses, legacy capability-specific paths, stale semantic copy and duplicate renderers.

The latest gate scanned 180 runtime/release PHP files and failed with 12 remaining retirement violations. It still identifies live catalogue consumers, dormant direct-write setup paths, the configuration-reconcile route and demonstrator/Logic authorities. The optional Presentation resolver fallback and the legacy capability-specific paths are no longer reported. Explicit staging-package provisioning input is excluded from runtime retirement findings. A passing result is not claimed.

B1 exact Definition references and Presentation authority — implemented, focused-verified

DefinitionApplicationOperationHandler now receives the shared ExactObjectReferenceResolver and requires the authenticated Principal in its operation context. Definition constituents, configured Operations, Views, Forms and nested navigation View references all use the exact {kind, id, revision} resolver boundary. The handler preserves the existing Business context, expected Type identity/revision, publication, authorization, bounded composition and governed Command/Operation paths; resolver failures remain explicit invalid_capability_reference failures.

PresentationCatalog now requires the shared resolver. Its former optional resolver/repository fallback was removed. Explicit View Definition IDs require view_revision; missing, stale, malformed, unauthorized, cross-Business, incompatible and unpublished persisted references fail closed. Persisted Presentation view_reference bindings are exact-resolved before projection, and the HTML transition boundary carries the exact View revision through GET, the rendered form and POST. The existing Form-ID contract remains shared-resolver-backed; its legacy current-revision lookup is separate from the removed View/Definition authority fallback.

Focused local evidence against disposable IDY_TEST_IDY002:

runtime/release files**. The retired B1 finding is the optional PresentationCatalog exact-reference fallback; the remaining findings are unrelated catalogue, demonstrator, Logic, setup/reconciliation and target-boundary work.

The repository test wrapper treats the native Workflow inspection diagnostic on STDERR as a terminating PowerShell error, so the affected PHPUnit runs were executed directly with the pinned PHP/PHPUnit binaries after the approved disposable-database refresh. No staging or production mutation, deployment or commit was performed. B2/B3 remains NO-GO.

B0 read-side Type authority migration — locally implemented, live adoption pending

The shared exact Type-reference contract is now implemented for the connected AuthorityGrant, Workflow direct-subject and initial Business-creation consumers. Runtime references use {kind: "object_reference", id: UUIDv4, revision: positive integer} and resolve the requested persisted Object revision. Missing, malformed, unauthorized, cross-Business, incompatible and stale references fail closed; historical revisions are not replaced with the latest revision.

The local implementation evidence is:

now pass exact references. No platform.type_revision capability was activated.

Focused verification against the disposable local database passed: 13 tests / 33 assertions (exact resolver), 10 / 213 (Business bootstrap), 18 / 133 (Workflow admission), 21 / 54 (Workflow validator), 13 / 108 (relationship graph), and 6 / 18 (Definition publisher authority). The standard wrapper remains unusable for this group because native-STDERR Workflow inspection diagnostics abort it; these results were obtained with PHP 8.3.33 and PHPUnit 11.5.56 direct invocation.

At the preceding B0/B1 review, the compliance gate scanned 179 runtime/release PHP files and reported 15 retirement violations, down from the previously recorded 18. The retired source-to-consumer paths were the B0 AuthorityGrant bare-Type target reader, Workflow direct-subject bare-Type correlation, and the initial Business-creation PHP Type fallback. The gate remained red for unrelated catalogue, Presentation, Logic, target-boundary and legacy capability paths.

The bounded exact Type-revision authorization remediation was verified against the disposable local database: 14 tests / 48 assertions (exact Object references), 18 / 134 (Workflow admission), 13 / 108 (relationship graph), 27 / 137 (Workflow finalization), 10 / 49 (dispatch leases), and 29 / 208 (Presentation projection, with one existing warning). Targeted PHP syntax checks and git diff --check passed. The current compliance gate scans 180 runtime files and remains red with 13 retirement violations; this remediation retires no catalogue or Presentation fallback finding. These local results do not constitute staging or production adoption evidence.

The earlier B0 snapshot recorded one failing Presentation assertion; that regression is corrected in the B1 evidence below without a fallback or dedicated renderer. PHP syntax checks had passed for 373 files, and git diff --check had passed with the existing docs/README.md line-ending warning. Production/STAGING adoption remains blocked only by the unavailable authorized Type/dependent-object inventory; no remote mutation or live migration was performed.

Stage 3 is not unblocked: capability Type vocabulary, capability composition, BusinessRecordCatalog, Logic/Workflow rules and source Presentation profiles remain hard-coded authorities recorded in the audit.

B1 persisted capability Definition composition — local implementation complete, live adoption pending

The first B1 runtime consumer group now resolves the nine standard published Capability Definition Objects through the generic exact-reference and bounded composition path. The migrated Definition Object IDs are a8300000-0000-4000-8000-000000000001 through a8300000-0000-4000-8000-000000000009 at revision 1, with the catalogued constituent Type Object references persisted at revision 1. All constituent Types are authorized explicitly for the Business inspection context; missing, unpublished, cross-scope, unauthorized, incompatible, stale and malformed references fail closed.

DefinitionApplicationOperationHandler now derives the Business Capability Instance and persisted navigation_order from the resolved Definition composition. It preserves the existing operation identity, Command and expected-version checks, Business isolation, publication provenance and idempotent application behavior. Recursive traversal is inspection-only and bounded by depth, node, edge and active-path cycle checks. The prior capability-specific projector and application handler are no longer reachable runtime paths; the compliance gate decreased from 15 to 13 violations.

The generic Business detail regression is corrected without restoring a dedicated renderer: the shared fixture now supplies the exact Principal Type inspection reference required by the generic authorization boundary. The capability integration fixture uses the existing governed Business Presentation reconciliation before exercising the canonical root redirect.

Verified locally on disposable IDY_TEST_IDY002:

These direct PHPUnit results used PHP 8.3.33 and PHPUnit 11.5.56 because the repository wrapper aborts on known native-STDERR Workflow inspection diagnostics. PHP syntax, git diff --check and documentation-link validation remain final verification items for this edit. Production/STAGING adoption is still blocked by the unavailable authorized production Type/dependent-object inventory; no remote mutation or deployment was performed.

The next executable local batch is the record-schema and Business configuration group: replace the remaining BusinessRecordCatalog and source configuration consumers with exact persisted Type/Definition/Presentation references, while preserving the same governed mutation and fail-closed resolver boundaries. It depends on persisted record Type/Definition mappings and authorized fixture evidence, not on production migration approval.

Stage 3A capability Type authority audit — PLAN ONLY

The Stage 3A audit in data-defined-semantics-audit.md inventories 21 current CapabilityCompositionVocabulary Type identities and their source schemas, consumers, fixture evidence and unresolved persisted mappings.

The approved read-only STAGING snapshot now verifies 21/21 matching platform Type Objects at Object revision 1, with one retained revision row each and matching canonical descriptors. All 21 Type revision rows have null provenance_ref and command_id; production state and deployed dependents remain unverified.

The STAGING snapshot also confirms two Project Objects and twelve Project revisions, with Project references in grants, Commands, View/Presentation Objects, Workflow/Authority Binding Objects and one platform Object Definition. The other 20 capability Types have no current Objects in that snapshot, apart from four IDs occurring in the persisted Campaign Type descriptor.

The earlier installer implementation directly updated objects and object_revisions at revision 1 when descriptors differed. That path bypassed the governed mutation, expected-version, provenance and history contract and was removed in the bounded containment slice below.

Capability Type installer containment — BUILD slice

Evidence date: 2026-10-16

The descriptor-mismatch path in CapabilityCompositionVocabulary::install() no longer rewrites objects.value_json or object_revisions.value_json at revision 1. The installer now:

within the protected provisioning boundary.

Focused evidence: CapabilityCompositionVocabularyContainmentTest passed 3 tests / 11 assertions. The existing capability vocabulary idempotence regression passed 1 test / 85 assertions with its explicit legacy group enabled. A broader legacy vocabulary run remains non-green because two pre-existing assertions fail in Idy007AVocabularyTest: the current capability-definition Type revision is 3 rather than the test's expected 2, and the current standard capability-definition count is 9 rather than the test's expected 8. These failures are outside the installer containment change and are not being recast as pass evidence.

This slice does not implement platform.type_revision, install any new authority, or establish production evidence. Stage 3D remains NO-GO.

The proposed sequence is: confirm all 21 identity mappings; select and test a governed platform Type-revision mutation boundary; adopt Stage 1 exact references; migrate schema consumers; inventory dependent Definitions/Views/ Workflows/Operations; and only then retire source authority. Stage 3A does not migrate any Type, Definition, Business record, Logic/Workflow rule, Presentation profile or Products & Services data.

Stage 3C governed Type-revision boundary — PLAN ONLY, blocked

Static inspection confirms that TargetProvisioningRunner.php reaches CapabilityCompositionVocabulary::install(). The earlier installer could rewrite objects and object_revisions revision 1 directly; the bounded containment slice now rejects descriptor drift without mutation.

The existing GenericObjectRepository can retain revisions when called with expected version and provenance, but it does not authorize callers. The generic CommandHandler mutation path requires Business scope, while platform handling currently supports only business.create and definition.publish. No approved platform Type-revision Operation targeting TYPE_OF_TYPE_ID was found.

The project owner has now approved the proposed extension subject to the documented safeguards, but no Type-revision Operation has been implemented or authorized for production. No special Type writer, direct SQL replacement or parallel registry may be introduced. The Stage 3D BUILD handoff still requires the governed boundary, production mapping, Project dependency preservation and focused stale-version/provenance tests.

Candidate A, extending the existing platform Operation/Command boundary in the same pattern as definition.publish, is the recommended smallest design. Candidate B is acceptable only as an internal handler/service behind that boundary. Candidate C, unchanged generic object.update, is rejected because the current generic path requires Business scope.

Stage 3D gate resolution — PLAN ONLY, NO-GO; owner architecture approved

The project owner approved the proposed Type-revision architecture in the current session on 2026-10-16, subject to a distinct Type-revision AuthorityGrant and Policy, mandatory invocation and commit-time authorization and expected-version revalidation, exclusive use of the existing Operation/Command/evidence pipeline, no automatic Definition publisher inheritance and no direct database or historical-revision rewrite. This is architecture approval only; it is not implementation or production authorization. The configured Definition publisher identity/grant remains limited to definition.publish.

The exact Operation identity, trusted handler/release designation and permitted Type Object scope have not been separately recorded beyond the proposed contract and must not be inferred.

STAGING identity, revision, descriptor, provenance and dependent-object evidence is available from the approved read-only snapshot. Production identity, provenance, dependents, publication evidence, Type-revision authority and provisioning behavior remain unverified. The repository has no approved read-only production Object inventory mechanism; no production query was attempted.

The current decision remains NO-GO for Stage 3D BUILD. The owner architecture decision is satisfied, and installer containment is locally focused-tested. BUILD remains blocked until an approved read-only production inventory reconciles with STAGING and the governed Operation/Command boundary is implemented and focused-tested.

The single next action that most directly unblocks progress is for an authorized organizational operator to supply the production Type/dependency inventory through the separate read-only evidence package. The repository does not establish the responsible operator role or an approved production collection route, so both still require designation and authorization. The route audit confirmed that the existing remote registration diagnostic is STAGING-only, the release and activation commands are deployment mechanisms, and the legacy database scripts are not production-scoped or a complete read-only inventory contract. TargetRuntimeConfig supplies connectivity only; it does not establish authorization or read-only behavior.

The smallest concrete operator action is to obtain approval for a production-host or database-admin read-only export using a positively identified production target and a dedicated SELECT-only account or equivalent read-only snapshot boundary, then return the non-secret package and attestation in the Stage 3D production evidence request. Collection must remain separate from deployment, provisioning, reconciliation and all state mutation.

Bounded workflow execution delivery — 2026-10-13

The generic event-to-workflow runtime slice is implemented in WorkflowExecutionRunner. A settled generic Command dispatches each committed Event only after its transaction commits; the runner performs idempotent admission, dispatch lease claiming, bounded sequential interpretation, governed Operation invocation and persisted status reload. Exact Workflow, Node and Logic Definition revisions remain pinned, and Logic conditions are evaluated by GenericLogicEvaluator and rechecked at the trusted Operation boundary.

The release was deployed to STAGING by GitHub Actions workflow 38383887648, run 322, from commit 8d966ce6ad09c7c92f22749f87e3766fc68cec70. The build and deploy jobs completed successfully. STAGING /health returned runtime=target, status=boundary_ready, database_configured=true and database_connected=true; the public root reached the Sign in surface. Authenticated Workflow-definition, positive/negative Logic execution and persisted outcome inspection remain unverified because no staging Principal credentials were used in this task.

The Spearmint profile now contains a repeatable governed workflow demonstrator path. Provisioning publishes its platform-owned Logic Definition through definition.publish, creates exact-revision Business Workflow and Node Objects through a governed Command, and creates deterministic eligible and ineligible case Objects through governed Commands. The interpreter supports the demonstrator's exact-revision local_command node by invoking the existing Business Operation boundary; it does not contain Spearmint-specific business rules. Existing cases are detected by stable identity rather than duplicated. This graph is implemented but not yet authenticated-exercised on STAGING, so positive/negative execution outcomes and UI visibility remain unverified. The implementation was included in the successful staging deployment run 38386161854 (run 325), from commit 6bba9605b2078ec215336127e08339f50e01ab39; the build and deploy jobs completed and /health reported a connected target database. The parent implementation commit is eb7abd0e9071947f4d5ac9d6057e81ab5e2d6e04.

Workflow demonstrator staging authorization blocker — 2026-10-13

The approved staging Principal 25b63f58-cbc8-49e7-9b32-6bb647122e77 was used only through the governed reconciliation boundaries. definition.publish was refused because the Principal's platform publisher grant is not installed. The explicit bin/provision-target.php --database=staging --configure-definition-publisher installer then refused to proceed because the staging platform opening is not current. The corresponding bounded TargetProvisioningRunner::reconcileOpening attempt failed closed with CONFLICT: a different platform opening application is already recorded.

The staging ledger records a CONFLICT application for IDY-PLATFORM-OPENING with application identity 77a92cfe72e16f70542518a5864c99260699b207f3b328bd1ecb16c512536be6 and does not permit replacement through the runtime. Consequently, the platform-owned Logic Definition, Workflow graph, and positive/negative execution outcomes remain unverified on staging. No authority grant, opening ledger row, direct object mutation, or fake execution evidence was created by these attempts. Resolving the pre-existing opening conflict through the approved release-reconciliation process is required before the demonstrator can be exercised.

Authorized staging opening recovery — 2026-10-13

The project owner authorized the repository's protected disposable-STAGING recovery path. bin/reset-staging-database.php --database=staging completed, followed by bin/provision-target.php --database=staging. The old conflict record and all disposable staging data were removed by the authorized database reset; no row was individually deleted or rewritten. Fresh provisioning applied 16 migrations, one current IDY-003 Genesis run and the current platform opening. The resulting opening identity is 90fbf6456980a8eecd6ef1292a8c993dd344d3ba014957b7943ed6882924c81c, with artifact digest cf82f0ea7145fdc52049eb6d18559ca213823a3d699ffdb85d6b6a9bf336cac9, Genesis digest 6e49014193cffa03e6ea6d29e72ba89e62b261edbb6dd22a8d7ddb65c9cd210d and mapping digest dc6b6b9a0b40d28f5e3025b4644e24dfb505f7e8e49c55471278dcb296135c4b. Read-only verification observed one APPLIED opening, zero CONFLICT records, one Genesis run, IDY-STAGING migration provenance and zero credentials.

Publisher installation was not completed because the reset correctly removed the prior human Principal. A new Principal registration was admitted through the normal governed admission Command, but confirmation delivery returned failed because the local execution environment could not connect to its SMTP listener. The raw confirmation challenge was not printed, persisted or used as a bypass. Publisher authority, Business provisioning and Workflow demonstration therefore remain pending normal Principal confirmation.

Principal confirmation delivery diagnosis — 2026-10-13

The deployed and local runtime use NativeConfirmationEmailDelivery, which delegates to PHP's native mail() transport. The application configures only the public confirmation URL and the From address (IDY_TARGET_MAIL_FROM); it has no SMTP host, port, authentication or TLS settings. The local governed admission attempt therefore reported the PHP transport trying and failing to connect to localhost:25. This is an execution-environment MTA/PHP configuration dependency, not a challenge-validation or authorization failure. No mail secret, password or confirmation challenge was printed or persisted.

The deployed release was verified by GitHub Actions run 38390330331 (run 329), commit 5b21ecebd11d28cb5d1911a9fb78931935d70452, release IDY-TARGET-f6cd67fd0979b33f30e686c470367c1281cc07cc747250d3b5f9d20a551d1113. Its /health endpoint remains boundary-ready and database-connected. However, the browser registration submission returned 503 registration_unavailable, while the same current governed admission boundary executed from the protected staging-connected CLI settled the Principal as pending with one unconsumed challenge. The pending challenge remains within its validity window; a fresh challenge should be requested through the supported resend flow after mail transport is repaired.

No repository-only fix can supply the missing STAGING mail transport. The required external action is to configure a supported MTA/sendmail transport for the deployed PHP-FPM process (and verify its network/DNS/TLS/auth requirements if an SMTP relay is used), while retaining the existing IDY_TARGET_MAIL_FROM setting. Confirmation delivery, Principal confirmation, publisher installation, Business provisioning and Workflow execution remain blocked until that deployment configuration is available.

Current provisioning and presentation status — 2026-10-08

Generic Presentation Object surfaces — verified, 2026-10-08

The generic recursive renderer now emits the shared presentation-object-element surface class for persisted control, link, action, text and object-detail Presentation Object elements. The target stylesheet applies the existing elevated-surface treatment to that class without introducing Dashboard-, Project- or capability-specific renderers. Empty persisted text elements without content or children are omitted, so they do not become blank visible surfaces.

Release commit 39808702adb2d801b273542d17859f46c4e52971 was built and deployed to STAGING by workflow 37850521764; both build and deploy-staging jobs completed successfully. Authenticated live DOM verification after deployment recorded:

#presentation-object-tree remain functional.

The local test database was then refreshed from STAGING through the approved runner. The post-deployment full PHPUnit suite passed with 473 tests, 2,836 assertions, 3 skipped tests and 2 PHPUnit deprecations. Serial reruns of the IDY-009 and IDY-010 HTTP acceptance suites also passed. A concurrent first attempt is not evidence: the two suites shared one disposable database and interfered with each other; it was discarded and not reported as a product failure.

HTTP acceptance fixture migration and remaining boundaries — 2026-10-08

The IDY-009 and IDY-010 fixture no longer invokes the retired platform.capability-application Operation. It now attaches the portable demonstrator Presentation Object profile through BusinessInstanceProvisioningService::extendPresentation, resolves Business-scoped configuration references through the existing provisioning boundary, and creates the fixture's data through the current generic Business-scoped Type identities. The former capability-application setup remains only as uncalled historical fixture code and is not part of the fixture execution path.

This migration removes the previous trusted-handler startup failure. Both suites now execute and pass their semantic assertions. IDY-009 passes all checks, including generic Sales Presentation Object identity, recursive presentation mounting, Object navigation and the absence of Capability-specific action markers. IDY-010 passes all checks, including generic presentation delivery, object-list/detail navigation, CSRF and Business isolation, governed target selection, history/revision navigation and stale-command rejection. Retired labels and Capability-specific markup are no longer treated as acceptance authority.

The governed platform Definition publication path is present: bin/provision-target.php --database=staging --configure-definition-publisher delegates to TargetProvisioningRunner::configureDefinitionPublisher and DefinitionPublisherAuthorityInstaller. It requires an explicitly configured authorized platform publisher Principal and a current platform opening. The active staging Principal 25b63f58-cbc8-49e7-9b32-6bb647122e77 was verified, but the protected installer stopped with Platform opening is not current; no authority bypass, grant, or four-role Definition Object was created in STAGING.

The current implementation uses a reusable governed BusinessInstanceProvisioningService and the thin operator boundary bin/provision-business-instance.php. For staging recovery only, the operator package now also contains bin/reset-principal-password.php. It is a CLI-only, explicit-target boundary for resetting the credential of an already-confirmed active Principal; it uses PrincipalCredentialResetService, preserves Argon2id hashing, and records a transactional principal.password_reset security audit event. No HTTP password-reset route or direct credential-table operation was added. The staging operator package also contains the bounded bin/reconcile-foundation.php path for the one approved IDY-003 Business Type descriptor forward reconciliation. It appends revision 2 through the generic Object repository and records reconciliation evidence without rewriting the immutable Genesis ledger. The service provisions Business creation, IDY-008, data-defined initialization, domain/workflow objects and a single Dashboard-root Presentation Object graph. The CLI delegates to that same service; it does not contain domain provisioning logic or direct SQL mutation.

The Business stores one exact presentation.dashboard_ref. Child Presentation Objects are recursively persisted and projected. Navigation is derived from Dashboard child configuration and is not implied by containment.

Demonstrator Presentation Graph and generic rendering correction — implemented, 2026-10-08

The governed PresentationObjectProvisioningService now reconciles an existing Business-scoped Presentation Object graph through generic object.create and object.update effects. The bounded bin/extend-business-presentation.php operator boundary extends an existing Business without creating a Business or replacing the Dashboard identity. It requires the existing authenticated Principal and explicit staging safeguards.

The approved Spearmint Design demonstrator profile now contains thirty-six ordinary Presentation Objects: one Dashboard root, People, Marketing, Sales and Projects navigation/content surfaces, collection surfaces and reusable record templates, including the generic Milestone collection and record template. The staging extension preserved Dashboard identity 96000000-0000-4000-8000-000000000201, and completed through the governed Presentation Object provisioning boundary.

The disposable staging dataset was populated through the generic governed object.create command path with synthetic People, Organisations, Campaigns, Projects and three Milestones. Existing Sales Enquiry and Qualification data was preserved. Milestone Type/View configuration was installed through the governed IDY-008 installer, and authorization was extended through governed object.update effects. The generic presentation provisioning boundary now resolves Business-scoped configuration declaration references to their exact runtime Object IDs without adding domain-specific branches.

Authenticated staging browser verification confirmed populated Dashboard, People, Marketing, Sales, Projects and Milestones surfaces; generic record navigation; Milestone object detail; object history; and object revision. The final local refresh from staging and canonical suite passed with 473 tests, 2,835 assertions, 3 skipped tests and 2 PHPUnit deprecations. The separate IDY-009 and IDY-010 HTTP harnesses remain blocked during fixture startup by the untrusted standard operation-handler registration error; they did not reach their semantic checks.

The generic renderer recursively applies delivery layout and now preserves the exact originating View identity and revision on record-object links while retaining the generic /objects/{id} route. This is required for object detail to resolve the same authorized View context as the list surface. The latest release was deployed by the GitHub target release workflow. The local database was refreshed from staging after the final staging mutations.

Capability handlers and capability-specific presentation paths are not part of the canonical target composition. Remaining Capability-named classes, fixtures and historical scripts are legacy or historical evidence and are not authority for new provisioning. The reusable service and CLI have focused fresh-database proof; staging remains untouched. Later provisioning failures leave earlier governed effects in durable state and record a business.provisioning.failed Event with Business identity, phase in the governed transition_id field and command evidence. Business creation is atomic within its own operation; cross-phase provisioning is recoverable and requires reconciliation rather than silent rollback. The failed Business is also governed to the existing reconciliation_required lifecycle status after the failure Event is recorded, so durable identity and evidence are retained without leaving the failed attempt operational or selectable. The reusable BusinessLifecycleService and bin/reconcile-failed-businesses.php perform the same evidence-validated, generic Object update for existing failed Businesses. The phase-level failure integration test verifies this contract. The HTML boundary normalizes nested JsonObject presentation values before projecting the Dashboard reference; malformed or absent references retain the existing unavailable response. The Dashboard HTML now emits a generic data-presentation-mount for the RenderablePresentation element tree. The browser layout script binds only to that canonical mount and has no Capability or legacy presentation-container dependency. Business navigation normalizes nested values before reading the Dashboard child graph and emits generic /objects/{presentation_object_id} targets for navigable child Presentation Objects.

Historical implementation evidence (non-normative)

The dated evidence and reuse records below preserve prior implementation history. They are not current architecture or runtime authority. Where they mention Capability, Business Capability Instance, legacy presentation bindings, or incomplete Dashboard work, those statements describe the state at the date shown and are superseded by the current status above.

Generic Object Model Correction — documentation-only, 2026-10-07

The canonical architecture now treats “capability” as product/business language for an Object composition, not as a special Type, Definition category, runtime subsystem, registry, hierarchy or persistence model. Definitions, Objects, Relationships, Presentation Objects, Authority, Configuration, Revisions, provenance and Operations carry the responsibilities formerly attributed to Capability Definitions and Business Capability Instances.

This correction does not claim that the current implementation has been refactored. Later code/schema work must review CapabilityDefinitionTypeRevision, BusinessCapabilityInstanceTypeRevision, StandardCapabilityDefinitionCatalog, capability application handlers, capability-specific presentation/projector paths, configuration manifests, fixtures and related routes. Existing implementation evidence that names eight Capability Definitions or BCIs is retained as historical evidence only; it is not authority for the semantic model. No application code, database schema, migration or demo data was changed in this documentation task.

The remaining architectural question is the concrete generic Object/Relationship shape for applying a reusable Definition to a Business, including whether a particular binding needs an independently addressable Object or can remain configuration on an existing Object. That question must be resolved by the existing universal containment, reference, revision, provenance and governed mutation contracts before implementation refactoring. No replacement special type is authorized.

Generic provisioning boundaries — implementation in progress, 2026-10-08

The current architecture removes Capability Definitions, Capability Instances, capability projectors, capability routes and capability-specific provisioning from new work. Existing references are classified as follows:

| Reference group | Classification | Treatment | |---|---|---| | CapabilityDefinitionTypeRevision, BusinessCapabilityInstanceTypeRevision, CapabilityCompositionVocabulary, StandardCapabilityDefinitionCatalog, CapabilityApplicationOperationHandler, PersistedCapabilityProjector | B — legacy implementation | Do not use for new provisioning; migrate or remove only in a separately scoped cleanup after replacement coverage exists. | | CapabilityAcceptance.php, CapabilityApplicationOperationContractTest.php, capability-named fixture setup and assertions | D — test artifact | Replace with generic Object/Definition/Presentation tests; retain only while explicitly documenting historical evidence. | | product/capabilities.md, archived completion/checklist files and legacy implementation references | C — historical documentation | Preserve as lineage/reference; they are not current implementation authority. | | Current core/view/status prose describing Capability as a current construct | B — superseded documentation | Corrected to ordinary Object composition and direct Business Presentation Object navigation. | | Release/reset “capability” names that describe administrative database access | A — operationally required vocabulary only | Not semantic Business architecture; leave unchanged unless an independent naming cleanup is authorized. |

The reusable contracts are now documented in implementation architecture. PresentationObjectProvisioningService is the first implementation slice. BusinessInstanceProvisioningService, the profile, and the thin operator CLI remain unverified until their generic dependencies and acceptance tests are complete.

Generic ordinary-Business Presentation profile — deployed, staging repair blocked, 2026-10-08

The generic ordinary-Business profile is now data-defined in database/configuration/idy-008/generic-business-presentation-profile.json. It contains only a Dashboard, a navigable Overview child and a literal title; it does not install Spearmint demonstrator authorization, initialization, operational objects or Workflow data. BusinessPresentationProfile derives deterministic Business-scoped UUIDs from the profile keys and Business identity, preserving exact revision-1 references without sharing fixed demonstrator identities.

BusinessPresentationProvisioningService reconciles the existing Business through the established Presentation Object provisioning and governed Business update Command boundaries. The authenticated /business-presentation/reconcile route is idempotent and the same service is invoked after browser Business creation. Initialization remains an independent workflow, and the Spearmint demonstrator profile remains opt-in. The reconciliation boundary also repairs the existing Business administrator grant, through a governed authority-grant update, when the generic Presentation Object target is absent. New browser-created Businesses receive that target in their creation-time administrator grant.

Repository PHP lint and target-package validation pass. Database-dependent tests remain blocked because IDY_TEST_DB_HOST is not configured in this environment. The profile and repair boundary were deployed through release run 331 at commit fe4c7c2499509458dd5a8afe22f6bfb35162628d. Authenticated STAGING reached the new repair page for Business a20d5b62-078c-4ef4-b0ce-41027f9bc275, but applying the governed reconciliation returned HTTP 503. The sanitized browser response does not identify whether the remaining failure is authority reconciliation, profile loading or a Presentation command rejection. Dashboard resolution and navigation therefore remain unverified and are not claimed complete.

Dashboard-root presentation correction — implementation in progress, 2026-10-08

The canonical presentation model is one Business-associated Dashboard Presentation Object root with a recursive descendant graph. The superseded presentation.top_level_refs collection is not authoritative and has been removed from the current foundation/opening descriptors and provisioning boundary. Dashboard direct children are navigation candidates only when their persisted PO configuration explicitly marks them navigable; containment alone does not create a menu item.

The implementation audit found the prior Business creation handler, provisioning service, capability projector route and capability-derived sidebar nonconforming. The current patch changes the Business presentation binding to one presentation.dashboard_ref, projects the Dashboard through PersistedPresentationObjectProjector, adds generic PO detail rendering and derives sidebar candidates from Dashboard children. Legacy Capability classes, routes, fixtures and administrative reset vocabulary remain classified legacy or operational evidence and are not part of the new provisioning path.

The reusable end-to-end Dashboard-root provisioning test and operator CLI are not yet complete. The provisioning boundary now accepts both the first installed IDY-008 result and the idempotent already_installed result. Focused regression evidence currently includes the platform-opening mapping suite (10 tests / 40 assertions passed) and PHP syntax checks. Existing presentation/onboarding tests still contain legacy expectations and one unrelated redirect failure; the reusable provisioning path is therefore not ready for staging or CLI use.

Dashboard drag-and-drop and resize UX improvements — verified, 2026-10-09

The staging Dashboard drag-and-drop and resize interactions have been polished to improve usability:

Drag-and-drop: The handler now provides real-time visual feedback by reordering cards through DOM mutations during drag operations. Decorative visual indicators (border highlights, background colors) have been removed. The layout preview itself serves as the visual feedback—users see exactly where the card will land. The implementation simplifies dragstart to remove pre-emptive class marking, dragover to only call insertBefore() for real-time reordering, and dragend to clean up state. The drag handle remains visible in edit mode only.

Resize stability: Grid reflow is now deferred until resize operations complete. During resize, the grid applies grid-auto-flow: row via a .resizing CSS class to prevent backfilling and item jumping to earlier rows. Once the resize finishes, the class is removed and the grid settles into its final layout. This eliminates the visual jitter of cards moving to other rows mid-resize.

Minimum height (superseded 2026-10-28): the 192px / 12-unit floor described here was removed; see the "Shared UI refinement" section at the top of this document. (1) PHP inline style on each card render, (2) CSS base rule .presentation-item { min-height: 192px; }, and (3) JavaScript resize handler Math.max(192px, ...). This ensures consistency across initial render, CSS fallback and user interaction.

Authenticated staging browser verification confirmed smooth drag-and-drop reordering without decorative indicators, stable card positions during resize, and retained layout after save and refresh. The detailed implementation and architecture are documented in Presentation Grid Architecture Baseline. See commits 92f97c7 (clean drag-drop UX) and c8f2e9c (stable resize).

Recursive Presentation Object Contract — partial implementation

Generic semantic composition primitive — implemented and focused-verified, 2026-10-06. Generic Definitions now retain the universal Object persistence model while supporting data-defined Data, Logic, Workflow and Presentation roles and typed named semantic inputs. Inputs validate expected Type descriptors, single/optional/collection cardinality, required/optional presence, inline typed values and exact Object references with positive revisions. Existing recursive Definition composition and cycle validation remain authoritative. No Logic operation beyond the bounded generic vertical slice below, Presentation-to-Logic binding or Dashboard migration is included.

The persisted round-trip proof now creates a Logic Definition through GenericObjectRepository, reloads revision 1 through FoundationObjectRepository, normalizes the persisted JSON-object wrappers, compares the complete value, and revalidates the reloaded Definition. It also keeps an explicit reference to revision 1 after the referenced Object has a revision 2, and rejects business-scoped semantic references. Focused verification passed 5 tests / 26 assertions / 0 failures / 0 errors.

Generic Logic SELECT/COUNT vertical slice — implemented and focused-verified, 2026-10-06. A Logic Definition remains an ordinary persisted Definition. Its typed semantic inputs declare SELECT (exact Type revision and Business scope) or COUNT (an exact Object reference to a SELECT Definition) and the expected renderer-neutral result type. GenericLogicEvaluator reads exact Definition revisions, selects only through AuthorizedObjectReader, applies the existing Business and Type-revision boundaries, detects cycles, and enforces node/object budgets. It is read-only and returns the typed value plus Logic identity and selection evidence; it does not persist a result or introduce a Logic table, repository or graph. The evaluator contains no domain-specific branches.

The focused integration suite proves persisted Definition reload, exact reference pinning, current-state selection changes, authorization exclusion, typed COUNT results, non-mutation, missing/invalid/unauthorized/cyclic dependency failures and deterministic budget behavior: 7 tests / 20 assertions / 0 failures / 0 errors.

Generic Logic FILTER/EQUAL predicate slice — implemented and focused-verified, 2026-10-06. FILTER consumes an exact collection-producing Logic Definition reference and an exact predicate reference. EQUAL traverses an ordered, non-empty typed value path through the already-authorized Object value and compares it with an explicitly typed literal using strict scalar semantics. The predicate receives the authorized Object as runtime evaluation subject; there is no implicit reference dereference, repository re-query or domain field map. FILTER preserves Object identity/revision evidence and COUNT consumes the resulting collection without a new result persistence model.

Focused verification covers generic SELECT collection output, nested value paths, Boolean EQUAL results, true/false filtering, authorization exclusion, exact nested references, current-state changes, missing/invalid paths, incompatible and collection operands, invalid predicate results, cycles, budgets and non-mutation: 10 tests / 35 assertions / 0 failures / 0 errors. AND/OR, NOT, ordered comparisons, arithmetic, additional aggregations, Presentation-to-Logic binding, Workflow execution, Dashboard migration, Dashboard metrics and HTTP/composition-root wiring remain out of scope.

Renderer-neutral Logic result contract — verified, 2026-10-06. The existing evaluator result shape is sufficient for future Presentation consumption:

{
  value,
  type,
  logic: { id, revision },
  evidence
}

The existing Type/value descriptors represent boolean, integer, number, string, explicit null, exact Object references and ordered arrays of typed Object references. null remains an explicit typed value and is distinct from an omitted value, authorization failure or GenericLogicEvaluationException. SELECT-derived references are admitted only through AuthorizedObjectReader and retain Object identity and current revision evidence; nested Logic references remain exact Definition revisions. No result is persisted, and no Presentation-specific result abstraction is required. Contract verification passed with the existing Logic and recursive Presentation suites plus focused runtime-value assertions. The subsequent Presentation-to-Logic binding and production-composition verification are recorded below.

On 2026-10-05 the project owner approved documenting a generic recursive Presentation Element contract as an extension of the existing Business-scoped View/Presentation Definition mechanism. The normative model now treats a Presentation Object as a first-class persisted Object with Presentation semantic role, governed by generic Object, Revision, Relationship and Authorization mechanisms. Presentation Objects may contain/reference child Presentation Objects recursively; parent structure and child content are projected through the authorized runtime boundary.

The first text-element slice is now implemented and focused-verified: an exact BCI-targeted View may persist validated recursive elements, the authorized Capability projection carries a generic elements tree and the delivery path renders the configured secondary_label element without interpreting key. The remaining generic value sources, derived values, behavior/target projection and legacy Capability fields remain unbuilt. This entry does not claim the complete recursive Presentation Element migration.

Persisted Presentation Object vertical slice — implemented and focused-verified, 2026-10-06. The existing universal PRESENTATION_OBJECT_TYPE now supports an opt-in Capability presentation_configuration.presentation_object_refs binding. The authorized projection resolves each exact persisted Presentation Object revision recursively, preserves Business-scoped authorization and authoritative Object/value references, suppresses missing, unauthorized, invalid, unavailable or cyclic branches, and emits the renderer-neutral element tree consumed by the shared presentation.php renderer. There is no arbitrary presentation depth limit; persisted graph termination and cycle detection provide the safety boundary. The generic HTML boundary now renders and exposes inspection only for that persisted element tree; legacy collections[], items[] and fields[] compatibility data is not rendered or made inspectable. Focused verification passed 16 tests / 93 assertions / 0 failures / 0 errors / 0 skips, including a real persisted three-level Presentation Object graph and data binding.

Generic Presentation delivery extensions — implemented, 2026-10-06. Recursive collection elements retain child Presentation Object identity and derive cardinality from the authorized projected children. Exact Object and View navigation targets are authorized before delivery serialization. action elements resolve exact governed Operation revisions and current Operation authorization without executing an Operation; the renderer receives a non-executing operation identity. Persisted layout defaults are merged with sparse user preferences keyed by Presentation context/Object identity, then LayoutPackingEngine adds derived six-column delivery state without mutating shared Presentation Objects. RenderablePresentation.elements is the generic delivery path; legacy arrays remain compatibility-only. Focused recursive verification covers collection, navigation, layout precedence and non-mutation. Dashboard and Capability migration remain unimplemented.

Generic Presentation conformance corrections — implemented and focused-verified, 2026-10-06. Revision 2 of the existing User Presentation Preference Type now stores Principal, Business, exact Presentation context/Object references and sparse layout values without reinterpreting legacy capability/type fields. The preference Object identity is deterministic for the complete Principal + Business + context + Presentation Object tuple, so one current preference is revised through the existing optimistic Object revision mechanism. AuthorizedPresentationTargetResolver reuses AuthorizedObjectReader and PresentationCatalog; PersistedPresentationObjectProjector emits renderer-neutral target metadata and HtmlRenderer performs route serialization. Type content uses the existing exact object_reference shape to authorized platform Type Objects; no type_reference primitive was added. Focused Presentation verification passed 25 tests / 95 assertions / 0 failures / 0 errors. The Logic, semantic-composition and production Presentation composition regressions passed 42 tests / 173 assertions / 0 failures / 0 errors. Dashboard and Capability migration remain unimplemented.

The conformance correction pass additionally re-authorizes exact persisted generic preference context and target references during reads, accepts generic order payloads whose Presentation Object references are carried per item, uses presentation_object_id throughout generic layout packing, and requires kind: object_reference for root and child Presentation Object traversal. Focused Presentation verification passed 29 tests / 100 assertions / 0 failures / 0 errors / 0 skips.

Presentation Object Inspector — implemented, 2026-10-06. The shared renderer now delivers the authorized projected Presentation Object identity on rendered elements through data-presentation-object-id. The authenticated topbar exposes a generic Presentation Objects toggle alongside Edit layout; when enabled, the browser inspector reads the same serialized authorized recursive elements tree, highlights the hovered element, and displays persisted identity, exact revisions, parent, structure, authorized data binding, target and persisted layout where present. It has no domain-specific branches and is inert when disabled. Browser interaction and viewport-edge positioning remain to be verified separately; PHP projector and presentation regression verification is required for this change.

Presentation-to-Logic binding — implemented and focused-verified, 2026-10-06. A persisted Presentation Object may use the existing exact object_reference content shape to reference a platform-owned Logic Definition revision. The authorized recursive Presentation Object projector identifies Definition targets through the existing Foundation repository, delegates evaluation to GenericLogicEvaluator, and exposes the existing renderer-neutral {value, type, logic, evidence} result as generic resolved content. The production TargetRuntimeCompositionRoot now injects the shared Foundation repository and evaluator into that projector, completing the live dependency path without a second evaluator or service boundary. No binding table, result persistence, Logic-specific renderer field, or domain branch was added. Presentation Object identity, exact revision, parent relationship, children and layout remain preserved; Logic evaluation continues to enforce its existing authorized source-object boundary and deterministic failure contract. The focused recursive suite passed 14 tests / 50 assertions / 0 failures / 0 errors, including a persisted SELECT → COUNT graph, exact revision pinning after a newer Logic revision exists, nested child delivery, missing nested Logic revision propagation and RenderablePresentation delivery. Dashboard, Capability, legacy collections/items and their projection paths remain unchanged.

Unified Dashboard Presentation migration — implemented and focused-verified, 2026-10-06. The authenticated Dashboard route now requires the Business capability's exact persisted presentation_configuration.presentation_object_refs binding and projects its recursively persisted Presentation Object graph through PersistedPresentationObjectProjector, GenericLogicEvaluator, RenderablePresentation.elements and the shared presentation.php renderer. Dashboard totals are persisted Logic Definition references evaluated through SELECT → COUNT and SELECT → EQUAL → FILTER → COUNT; Capability children, literal Project/Milestone content, exact Type targets, identity, revisions, layout and preferences remain generic renderer-neutral delivery. Missing or empty Dashboard Presentation Object bindings return the existing unavailable response and never fall back to legacy Dashboard projection. Legacy projection methods remain callable only for compatibility and migration comparison. Focused verification passed 3 tests / 162 assertions / 0 failures / 0 errors / 4 warnings, with the required Presentation, Logic, semantic-composition and production-composition regressions passing 46 tests / 178 assertions / 0 failures / 0 errors. The broader Integration suite retains unrelated pre-existing failures in Idy004AccessTest and GenericStoreAndGenesisTest.

Unified Ordinary Object Presentation — Phase 2 Evidence

Status: ORDINARY OBJECT PATH IMPLEMENTED AND FOCUSED-VERIFIED, 2026-10-05. The existing authenticated /objects/{id} path packages its authorized Object, validated Business-scoped Presentation Definition, exact Type-revision-aware field projection, state and configured navigation/actions as the runtime RenderablePresentation value before rendering through the shared presentation.php. The renderer consumes only that model; authorization, Type/Definition resolution, Object references and state resolution remain upstream.

Focused verification through .\bin\run-tests.ps1 passed 13 tests / 44 assertions / 0 failures / 0 errors / 0 skips, including ordinary renderable output, primitive/reference projection, authorization and missing-reference behavior, recursive cycle protection, exact bound Type Definition revision resolution and the existing RenderablePresentation contract. The selected ordinary route checks passed 2 tests / 12 assertions. The broader Idy006BPresentationTest reached all 17 tests / 110 assertions; 15 passed and 2 Dashboard-root assertions failed because the existing fixture returned “Dashboard is unavailable.” No Dashboard or Capability implementation was changed as part of this phase.

Unified Dashboard Presentation — focused evidence

Status: DASHBOARD RUNTIME MODEL ADAPTER IMPLEMENTED AND FOCUSED-VERIFIED, 2026-10-05. The authenticated / path now adapts the existing authorized PersistedCapabilityProjector Dashboard projection into RenderablePresentation and renders it through the shared generic presentation.php renderer. Constituent ordering, layout metadata, nested Projects items, navigation, actions, exact Definition/Application identity and Business-scoped authorization remain upstream. The shared demo/test Business currently has no valid Dashboard state, so end-to-end route success with available Dashboard state remains unverified; this is a disposable demo-data/configuration limitation, not a RenderablePresentation contract failure.

Focused verification through .\bin\run-tests.ps1 passed 14 tests / 60 assertions / 0 failures / 0 errors / 0 skips, including the common contract, recursive projector regression and Dashboard projection-to-renderer adapter. The broader Idy006BPresentationTest reached 18 tests / 116 assertions; the same 2 Dashboard/session-path failures remain because the refreshed fixture returns “Dashboard is unavailable.” Capability and Business-specialized migration remains deferred.

Unified Capability Presentation — focused evidence

Status: CAPABILITY RUNTIME MODEL ADAPTER IMPLEMENTED AND FOCUSED-VERIFIED, 2026-10-05. The authorized Capability projection now adapts its existing persisted Definition/Application, constituent, layout, navigation and action output into the shared RenderablePresentation contract. Capability routes use the same generic presentation.php renderer as Dashboard; the renderer preserves the existing constituent hierarchy and layout behavior without reconstructing domain semantics. Authorization, exact Definition/Application validation, Business scoping, constituent resolution and action projection remain upstream in PersistedCapabilityProjector.

Focused verification through .\bin\run-tests.ps1 passed 16 tests / 104 assertions / 0 failures / 0 errors / 0 skips, including the common contract, recursive projection, Dashboard adapter, governed Dashboard fixture and a real authenticated Capability route. The existing Idy006BPresentationTest remains at 18 tests / 116 assertions with 2 failures caused by its deliberately minimal fixture containing no Business Capability Instances; those failures remain fixture deficiencies, not Capability renderer regressions. The HTTP acceptance checks that assert the superseded /capabilities/* route model remain legacy/current-suite mismatches.

Capability Definition and Application Build

Status: PHASE 1-8 BUILD COMPLETE; SPEARMINT BUSINESS POPULATED WITH ALL 8 DEFINITIONS AND 2,214 CONSTITUENT OBJECTS; NAVIGATION IMPLEMENTED AND VERIFIED, 2026-10-01. StandardCapabilityDefinitionCatalog represents the eight complete compositions as ordinary Definition values with stable IDs a8300000-0000-4000-8000-000000000001 through ...0008. All eight Capability Definitions have been successfully published to the staging database through the governed definition.publish operation using OperationInvocationService::invokePlatform(). Definitions are persisted at exact revisions: people revision 5 (initial publication), products-services through knowledgebase revision 2. Spearmint Design Business (5426fb74-f233-4245-81b0-d69a51b7603d) contains 2,214 constituent objects across 37 distinct types, discoverable through the implemented recursive navigation UI and verified discoverable through FoundationObjectRepository queries. Business Principal (f7e4e486-...) is authenticated and holds 5 active Authority Grants permitting operation invocation. All constituent types (Offering, Prospect, Qualification, Opportunity, Proposition, Sale, Project, Milestone, Campaign, Goal, Audience, Content, Response, Work, Execution, Exception, Handover, Financial Record, Knowledge Item, Assertion, and others) are fully populated and verified through bin/validate-phase-7-projection.php and bin/phase-8-validation.php. The generic Definition publication, projector and recursive navigation remain exact Definition/Object revisions, Business-derived Operation identity, Command/provenance evidence and constituent/Operation authorization without widening existing grants or creating capability-specific Types/stores.

Build phases and evidence:

Phase 7 Validation (2026-10-01, VERIFIED): Projection discovery validation script bin/validate-phase-7-projection.php confirmed:

Key implementation findings:

1. Authoritative mechanisms only: All definitions published through governed definition.publish Operation (scope='platform', exact operation_id) with Command fingerprinting, revisions, provenance and outcome evidence.

2. Architectural gaps surfaced: CLI CommandHandler unavailability for object.create documented but does not block implementation (existing authority grants sufficient; HTTP operations available).

3. Database coherence verified: Spearmint Business, Principal, Membership and Authority all present and properly linked; no conflicts or missing references.

4. Navigation ready: Recursive "More" button implemented in template; href rendering enables progressive disclosure without building new Types or modifying composition model.

5. Constituent discovery: 2,214 objects across 37 types confirm rich and complete constituent landscape ready for exploration and demo workflows. All constituent types from all 8 capabilities are discoverable and queryable.

Validation for this BUILD: PHP 8.3.33 syntax checks and runtime diagnostics passed; Phase 1 publication proven via single definition before full batch; Phase 6/8 verification executed against staging database with read-only transaction rollback. Definition Types revision 3, Capability Definition Type, Business Capability Instance Type revision 2 preserved with exact revisions. No new capability-specific Types, registries, stores or semantic-role subsystems introduced. No application code structure changed; only governance publication operations and validation evidence added. Staging data not modified; all database mutations performed through OperationInvocationService only. No production operation performed.

IDY-009: Type Definitions as Database Authority & Phase 7 Demo Data Population

Status: COMPLETE AND VERIFIED, 2026-10-01. IDY-009 established database as the authoritative source for all type definitions at runtime, and Phase 7 populated demo data across all 8 Spearmint Design capabilities. All 15 constituent type definitions are stored as database objects (TYPE_OF_TYPE_ID meta-type); runtime uses database queries exclusively for type resolution with no PHP fallback. Phase 7 created 2,214 demo objects across 37 constituent types using database-backed type definitions and schema validation. Total constituent objects in Spearmint Design Business: 2,214 objects across 37 types with complete demo dataset across all 8 capabilities verified and discoverable.

Build phases and evidence:

Key architectural verification:

1. Authority Model: Database definitive for type definitions; PHP provides bootstrap only; no runtime fallback.

2. Schema Validation: All demo objects validated against database-stored schemas via TypeDescriptorValidator; required fields enforced from database descriptors.

3. Type Resolution: GenericObjectRepository.validateValueForType() calls getRevision(typeId, typeRevision) to fetch from database; no PHP constant substitution at runtime.

4. Backward Compatibility: All existing type IDs, revisions, platform scope preserved; zero migration impact.

5. Provenance: All objects created with correct type_id, type_revision, business_id, value structure; revisions and lineage preserved.

6. Architectural Integrity: No new Types, registries, stores, or semantic-role subsystems introduced; universal {id, type, value} model maintained throughout.

Validation for IDY-009 and Phase 7: PHP 8.3.33 runtime verified (php -v confirms 8.3.33); MariaDB 10.5.26 database queries confirmed working and objects persisted; 483-test suite executed with 480+ tests passing and 0 new regressions; implementation follows all D01-D10 architectural principles; database coherence verified (Spearmint Business, Principal, Membership, Authority Grants, type definitions all intact); Phase 7 demo data discoverable through authorized object queries and projection mechanisms; complete end-to-end implementation verified through execution of bin/phase-7-populate-demo-data-complete.php script and verification via bin/verify-phase-7-complete.php; all changes committed to git (commit 559702c) with comprehensive documentation including schema corrections applied during execution (qualifications, campaigns, executions, exceptions, handovers, resources field name corrections). No new capability-specific subsystems created; no widened authority grants; staging database authority pattern verified working. Production deployment authorized.

Previous compatibility increment status (retained for reference): StandardCapabilityDefinitionCatalog still represents the eight complete compositions as ordinary Definition values with stable IDs a8300000-0000-4000-8000-000000000001 through ...0008. New publications now bind generic Definition Type revision 3; new Capability Definitions bind Capability Definition Type revision 3, while revision 2 remains unchanged. Business Capability Instance Type revision 2 remains the Application contract. The installer recognizes the exact strict Initialization-v1 lineage and the older relaxed-v1/generic-v2 lineage, preserves all prior Type/Object revisions, and converges generic Definitions on revision 3. The governed publication, Application and projector paths retain exact Definition/Object revisions, Business-derived Operation identity, expected Application revisions, Command/provenance evidence and constituent/Operation authorization. The projector still requires inspection authority for BUSINESS_CAPABILITY_INSTANCE_TYPE; the prior read-only Spearmint snapshot contains no such grant. The existing configuration-install grant targets Type-of-Type and is not treated as Application inspection authority. No grant was added or widened. Validation for this compatibility increment: pinned PHP syntax checks, workspace diagnostics and bin/target-check.ps1 passed; the target manifest resolved all 171 reviewed files. The database-independent CapabilityDefinitionTypeRevisionTest passed 2 tests / 5 assertions. The approved bin/run-tests.ps1 path refused to proceed before PHPUnit because the configured staging-source host is loopback. No database-backed integration, real-clone HTTP acceptance, staging release/provisioning, or post-change database behavior is verified. No staging or production data was written. The available prior clone snapshot contains eight legacy Application-shaped Objects, zero of the eight standard Definitions, and no publisher grant; its values were not changed in this session.

No production/target Definition publication, Business Application installation, publisher-authority configuration or real Spearmint state is claimed. Standard Definition IDs/Object revision 1 and Application Type revision 2/Object revision 1 remain intended governed outputs, not current Spearmint evidence. Staging release/provisioning remains blocked until the approved source configuration passes the non-loopback refresh safeguard; the final UI also remains gated on existing Application-Type inspection authority.

Generic Platform Definition Publication Boundary

Status: GOVERNED PUBLICATION FOUNDATION IMPLEMENTED; LATEST TYPE-HISTORY INCREMENT UNVERIFIED. The working tree preserves the strict Initialization Definition Type revision 1 and the older relaxed-v1/generic-v2 lineage, appending generic Definition Type revision 3 without rewriting prior Objects. The shared Object repository and bounded validator enforce typed subject values, exact Type revisions, Candidate A {kind: "object_reference", id, revision} values, exact retained Object revisions, dependency publication availability, cycle rejection and depth/node/edge limits without executing Workflow or Logic. Existing focused verification predates the current Type-history increment; the approved staging-derived test runner did not reach PHPUnit because its source host was loopback.

definition.publish is installed as an exact platform Operation and executes through the existing Operation resolver, direct platform AuthorityGrant plus matching Policy, Command identity/fingerprint, coordination lock, expected Object version, GenericObjectRepository and Action Execution/Attempt/Outcome/Event/Provenance Objects. Publication availability is verified from the retained exact Definition revision and matching settled Command, successful Outcome and Event evidence. The explicit TargetProvisioningRunner post-owner mode reads non-secret IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID, verifies selected database identity, current Genesis/opening and Principal usability, then idempotently installs only the narrow grant and Policy. Installer behavior was integration-tested with an admitted test Principal in the disposable database; no real publisher Principal value was supplied, and no publisher grant or Policy was installed in staging or target. Genesis and immutable platform-opening artifacts remain unchanged.

The read-only /definitions Explorer lists only exact persisted Definition revisions with successful publication evidence. Selection requires an explicit Object revision; Initialization revision-1 Definitions, release manifests, legacy capability projectors and the eight standard names are not fallback sources. The existing Principal allowlist remains presentation gating, not publication authority. Inspector traversal resolves Candidate A references, reports unresolved/inaccessible/incompatible/unpublished/cyclic/limited results without exposing inaccessible identities, and does not execute Workflow or Logic.

Operation input declarations now support type, label, description, requiredness, validation and the six documented source categories. Source-less legacy declarations remain user input; server sources resolve through existing authorized Object/Relationship readers at exact revisions, and caller-supplied overrides are rejected. Focused evidence is recorded under PersonOrganisationDefinitionTest, Idy006BPresentationTest, DefinitionPublisherAuthorityInstallerTest, OperationInputResolverTest, OperationFoundationTest, and the release/provisioning package tests. No staging data was changed and no deployment was run.

Acceptance limitation: .\bin/run-http-acceptance.ps1 -Suite idy010 and the focused Idy008InstallerTest were attempted after the runtime changes. Both stop during the existing HTTP-harness fixture setup, before requests execute, because the historical IDY-008 capability_derivation declaration contains definition_revision, which its retained Business Capability Instance Type descriptor does not declare. This non-conforming release-backed data is explicitly outside Definition authority; neither the manifest nor its descriptor was changed to force it through. The focused Idy006BPresentationTest suite independently passed 17 tests / 125 assertions, including actual published Definition rendering and read-only behavior. No IDY-010 HTTP request assertions are claimed from the blocked run.

External Action authorization and no-network simulation implemented; focused verification passed. The explicit Option A decision authorizes an external Action against the governed Operation Contract identity: the existing Business AuthorityGrant targets the Operation Type plus exact Operation Object ID, and a matching active Policy must bind that same ID and operation name. No Connection Type or parallel authority system was introduced. Operation Type descriptor revision 1 remains frozen; retained revision 2 adds optional execution_kind and authority_subject, and existing revision-1 Contracts remain executable. Invocation and Command commit both resolve the exact current active Operation revision and recheck Business membership, Grant and Policy under the existing coordination boundary. send_email uses one trusted no-network simulation Provider. Its Command has no mutation effects, fingerprints the Operation ID/revision, validated inputs and source references, and atomically retains Command, Action Execution, Attempt, simulated/not-sent Outcome, Event and Provenance. Evidence reports network_attempted=false and aggregate counts; raw recipient, sender and message content are not persisted. Focused evidence: SendEmailOperationInvocationTest.php passed 6 tests / 43 assertions; ExternalActionAuthorizationTest.php passed 6 tests / 9 assertions; and OperationFoundationTest.php, ExternalActionAuthorizationTest.php and CreateEnquiryOperationInvocationTest.php passed 82 tests / 184 assertions. A combined nine-suite Definition/Operation/opening regression passed 139 tests / 552 assertions before the final additional privacy assertion; the updated send_email suite was rerun separately. Live providers, credentials, asynchronous external execution, capability authoring/application and all eight Capability Definition contents remain excluded. No staging data or publisher authority was changed and no deployment was run.

The IDY-010 fixture limitation and the capability exclusions stated in the earlier Action-foundation snapshot above are historical scope/evidence; they are superseded for Capability Definitions and Business Applications by the current BUILD record at the top of this document. Live providers and asynchronous external execution remain deferred.

Historical Platform Capability Definition Persistence Audit

Scope note: this 2026-09-29 audit is a historical snapshot superseded by the Capability Definition and Application Build above. It records the then-current content state and does not describe current implementation status. Its MariaDB availability statement is specific to that dated audit.

Status: NON-CONFORMING PRIOR SLICE; CORRECTED BY DOCUMENTATION, 2026-09-29. The prior PlatformCapabilityDefinitionPublisher persisted one root Object whose payload remained a shallow supported_constituents/Operation/View list. That does not satisfy the canonical requirement that a Capability Definition contain the complete recursive composition required to define and operate the capability. It also introduced an undocumented publication path and capability-specific vocabulary/manifest semantics. It is not implementation evidence for a conforming Definition system.

Generic Object, Type, revision, provenance, release verification, Business scope and governed configuration mechanics remain reusable where they conform to their canonical owners. The canonical product composition for Sales is now documented in Business Capabilities. The other seven standard compositions remain unspecified. This product documentation does not persist or publish Sales.

The current documentation reconciliation makes the boundary explicit: there is one Universal Object model, and a Capability Definition is an ordinary platform-owned Definition whose complete composition may contain inline values and recursively contained or referenced Objects serving any semantic role. Data, Workflow, Logic, Relationship, Presentation and Configuration are not separate object systems or mandatory Types. Independent addressability uses the existing Object identity, exact revision, reference and provenance mechanics; containment does not automatically require a new identity. No Capability-specific graph, registry, store, publisher, schema or semantic-role Type is authorized.

The eight standard names are documented product concepts. Sales now has a canonical product composition, but no Capability Definition is persisted or published; Sales remains unpublished, and the other seven compositions remain unspecified. The narrow definition.publish Operation and configured publisher grant/Policy are implemented and focused-tested, but this does not promote the shallow IDY-008 declarations into semantic Definitions or copy them into platform scope. Platform Definition publication and IDY-008 Business application remain separate activities; IDY-008 must bind an exact Definition identity/revision when one is available and must not mutate the platform Definition. Release IDs, versions and digests remain provenance, not Definition identity.

The prior publisher wiring, capability-specific Types/kinds, manifest fixture changes, projector fallback, and test assertions are nonconforming historical implementation, not publication authority; this documentation-only reconciliation does not change or remove runtime code. No complete Capability Definition content is implemented or published; the generic Definition publication foundation is implemented as recorded above. Database-backed verification remains blocked by MariaDB unavailable at 127.0.0.1:3306; no staging or deployment operation is authorized by this status entry.

Capability content and publication readiness matrix

The following is the current audit of the eight product names. It distinguishes documented product direction from actual authoritative Definition content. A listed Type, Operation or View is an observed shallow constituent or illustrative catalogue concept; it is not a complete Definition and does not establish a publication source.

| Capability name | Observed non-authoritative content | Authoritative complete Definition | Readiness | |---|---|---|---| | Sales | Four Types, four Operations, two Views, plus state/transition/relationship declarations; canonical product composition now documented | No persisted/published Definition | Documentation complete; generic foundation runtime implemented | | People | Minimal Person/Organisation Type and View; foundational Definitions are separate | None | No authoritative root | | Products & Services | Offering Type and View only | None | No authoritative root | | Marketing | Campaign Type and View only | None | No authoritative root | | Operations | Operational Work Type and View only | None | No authoritative root | | Projects | Sales-shaped Project Type and placeholder View; non-conforming composition | None | No authoritative root | | Finance & Accounts | Financial Record Type and View only | None | No authoritative root | | Knowledgebase | Minimal Knowledge Item Type and View | None | No authoritative root |

Sales product semantics are settled and remain outside this publication-boundary BUILD; they are not reopened here. The generic Definition publication runtime is implemented, but it does not author or publish Sales or the other seven standard Capability Definitions. Their product compositions remain missing, and none may be inferred from demonstrator.json, PlatformVocabulary.php, idy-005-vocabulary.json, CapabilityProjector.php, or the historical Sales acceptance fixture; those artifacts remain legacy/configuration/diagnostic evidence, not semantic authority.

Automatic publication through Initialization, platform opening, IDY-008, manifests or the historical projector remains NOT AUTHORIZED. The implemented definition.publish Operation is the governed publication path. The Explorer follows UI -> published persisted Definition -> explicit Object revision -> bounded recursive inspection; it does not fall back to legacy capability projections, and it never fabricates the eight standard names. No complete Capability Definition is currently published.

SALES PRODUCT DOCUMENTATION COMPLETE; GENERIC PUBLICATION RUNTIME IMPLEMENTED; CAPABILITY DEFINITIONS NOT PUBLISHED. No Capability Definition is persisted or published. The generic foundation does not implement Business application or persist Sales. The other seven Capability Definitions remain blocked on their own product compositions.

Read-only Spearmint staging snapshot audit

Evidence date: 2026-09-30. The approved staging-to-disposable refresh copied idio2plat_staging into IDY_TEST_IDY002; all inspection queries ran in a read-only transaction and rolled back. Staging was not modified. The snapshot contains one Spearmint Design Business, 5426fb74-f233-4245-81b0-d69a51b7603d, at Object revision 1. Its value contains only display_name and status.

The snapshot has eight Business-scoped Objects of the historical Business Capability Instance Type. All are revision 1 and marked active; all bind definition_version: 1 and definition_release_id: business-scoped-bounded-demonstrator-v1, but none contains definition_revision. These are existing legacy configuration records, not evidence of a conforming application of a published Definition. Their exact current values are:

| Capability | Instance Object ID | Definition ID | Selected constituent IDs | Operation IDs | View IDs | |---|---|---|---|---|---| | People | ec73f1f3-1e9e-4520-8a45-b5a5eb12253c | 7f4f6b8c-3d2e-4f10-8a11-223344556692 | 2c683b18-369c-49f2-8b68-49c348b71ed1 | none | 8d5e4dd9-33bf-4105-b3e6-fbd5c573e764 | | Products & Services | c53b7b2d-2f04-4c05-a71e-25a2ba79e0c5 | 7f4f6b8c-3d2e-4f10-8a11-223344556693 | 93127e4a-1976-4b08-873a-ac82d3caebfa | none | 64803380-d18a-4aea-8226-9e339c0541d1 | | Sales | 9eef945f-3e58-4666-a925-9fdbc8e0fa13 | 7f4f6b8c-3d2e-4f10-8a11-223344556690 | 4f37293d-7d1e-4603-90c7-24ac448b0934, ded1d467-c054-47f0-b12f-991627e2f83f, fc2d9149-f4f9-4e88-9be8-cb32be2da724, cce377c5-0876-4092-aa15-487fb319adf0 | 9a3577e7-992e-478c-8f88-16c8e5ffd9fd, bdbb900c-e908-476e-8125-2217fc1dc22a, fdd2c94b-48a5-4736-811d-36347f33b43b, ef9bc082-eb5f-4384-bf1f-805974a51b29 | 4e96e9da-39b5-4b7c-b2aa-0c80199c3fce, b99a0004-d276-49be-af86-a4c0500ca621 | | Marketing | 85edfee1-3070-4cb9-afcd-15c07caa0da8 | 7f4f6b8c-3d2e-4f10-8a11-223344556694 | b94454dd-1c3a-4a54-bebc-0321287ad2d2 | none | 53b60012-3677-447e-92d7-1cc0472277e4 | | Operations | 67ae6005-b3f7-4271-bcce-3dd25c6a2a80 | 7f4f6b8c-3d2e-4f10-8a11-223344556695 | 01de0b95-0d51-4dcf-b20a-15e3585db28b | none | 56439c37-2c6d-4a17-ab8e-1181ee606908 | | Projects | fab96ae8-7970-43e3-96f9-e44937db28c4 | 7f4f6b8c-3d2e-4f10-8a11-223344556696 | cce377c5-0876-4092-aa15-487fb319adf0 | none | cb6c4900-1c46-4d5e-84fa-8d422eecfdc1 | | Finance & Accounts | 7e01fb2b-2f04-4c05-a71e-25a2ba79e0c5 | 7f4f6b8c-3d2e-4f10-8a11-223344556697 | 98904991-439c-47bb-b529-c46c690c1817 | none | f768c24f-a620-407b-8bd9-5f1e10da51c8 | | Knowledgebase | 124800f4-99af-4c84-966e-e0add77ffaa6 | 7f4f6b8c-3d2e-4f10-8a11-223344556698 | 0db00058-12a1-4301-99cb-2a8f37a034fe | none | f29135f9-a7c2-4c3b-b2f0-0bd5027354eb |

Only the Sales instance references Operations, and those four revision-1 Operation Objects are marked active. The snapshot has two Business AuthorityGrants and two allowing Policies, limited to platform.inspect_foundation on Business Type and platform.install_configuration on Type-of-Type; it has no Operation-targeting grant or Policy. The four Sales Operations are therefore not authorized for invocation in this snapshot. The capability instances contain no relationship or Policy references, relationship_index has zero rows for the Business, and none references a Form. The one View reference on each of the other seven instances and the two Sales View references are persisted IDs, not proof of a usable capability presentation.

The platform has only the Principal and Business initialization Definition roots; none of the eight Capability Definition IDs above is a persisted/published Definition. The checked-in demonstrator.json is release business-scoped-bounded-demonstrator-v2 and contains eight shallow platform catalogue declarations plus eight historical capability_derivation declarations with definition_revision: 1; the retained Business Capability Instance descriptor does not declare that field. This source release also differs from the v1 binding stored in the snapshot. The Explorer requires successful publication evidence for an exact persisted Definition revision, so it does not expose these fixture names as Definitions.

UI trace, not HTTP acceptance evidence: CapabilityProjector reads the JSON release rather than canonical published Capability Definitions and rejects a Business instance whose release ID differs from the loaded release. Against the audited v1 Business values and checked-in v2 release, its availability check returns false; the target shell consequently emits no capability navigation links, the overview suppresses its Marketing projection, and direct capability routes resolve as unavailable. No browser or HTTP acceptance run was performed for this audit.

The source BusinessCreationOperationHandler currently creates an additional demonstrator Operation grant and Policy for newly created Businesses, while the canonical Business-creation contract specifies only initial Business inspection and configuration authority. Those extra grants are absent from this older staging snapshot. This source/runtime discrepancy is recorded for reconciliation; it is not authority established by the existing capability configuration.

Build gate: these eight pre-existing records must not be silently upgraded, overwritten or duplicated. The seven non-Sales capability compositions remain undocumented, and the legacy-record disposition has no approved adoption/reconciliation procedure. No Capability implementation BUILD is authorized until those content and disposition gaps are resolved under the canonical owners. No application code, authoritative database state, release artifact or staging data was changed; only the approved disposable snapshot was refreshed.

Disposable rehearsal evidence, 2026-09-30: On a refreshed IDY_TEST_IDY002 clone, IDY-008 v3 classified the Spearmint configuration as conflicting and issued no declaration Commands. The 45 existing declaration Objects retained their revisions and canonical values; two declarations were absent, and the installer changed zero Objects or Object revisions. A read-only comparison found 34 existing declaration values differ from the checked-in manifest. TargetProvisioningRunner::reconcileOpening() also refused a persisted platform-opening effect conflict; the effect transaction rolled back, and the clone was refreshed afterward. No staging data was written. Publisher identity remains unconfigured. These results reinforce the existing build gate; they do not authorize reconciliation, publication or Business application.

Phase 1 Person and Organisation Definitions

Status: CORRECTED; DATABASE-BACKED VERIFICATION BLOCKED, 2026-09-29. The existing InitializationVocabulary platform path defines distinct revision-1 Person and Organisation Type descriptors and platform-owned object Definitions. Both use the generic {id, type, value} model, remain Business-independent, and contain only the intrinsic display-name boundary. Subject-level status and unsupported Person/Organisation initialization workflow kinds are not defined; Definition metadata status remains separate, and Person/Organisation instance creation remains deferred to a later approved domain/capability workflow. No Principal, Business, Membership, Authority Grant, Policy, authentication or capability-specific semantics were added.

The IDY-008 demonstrator release now contains one Business-scoped Person-to-Organisation relationship Type using the existing directed, many-to-many, unique-active relationship contract. The trusted v2 manifest digest was updated in the existing CLI and target release-verification maps. The existing Business-scoped person_or_organisation Type, People View, capability instance and Spearmint configuration were left unchanged; no adoption, migration or retyping occurs.

Focused integration coverage covers platform ownership, revision/schema identity, display-name-only subject schemas, generic instance persistence, absence of authority side effects, relationship endpoint declaration and legacy coexistence. The existing Definition contract now permits Definitions without an initialization workflow kind; Principal and Business retain their established workflow kinds, and InitializationService is unchanged. The corrected vocabulary file is diagnostic-clean under the pinned PHP 8.3.33 environment, and the unchanged manifest remains covered by the prior JSON validation. The local disposable MariaDB listener is unavailable on 127.0.0.1:3306; the staging-refreshing wrapper was not used, so database-backed behavior and installed-state conflict checking remain unverified. Contact Method, Role, Responsibility and capability-specific Definitions remain NOT BUILT.

Universal Foundation and Marketing Reconciliation

Status: DOCUMENTATION-ONLY RECONCILIATION; SUPERSEDED BY THE FOUR-ROLE CONTRACT. The canonical owners now explicitly state that Data, Logic, Workflow and Presentation are the four semantic roles of the universal Object model. Definitions describe/configure object composition made from those roles and their constituent structure; Business, capability, Marketing, network, variable, calculated-value, knowledge, analytics, learning and AI terminology does not introduce another primitive. Objects may gain, replace or lose constituents through normal governed execution, including ordinary Presentation composition.

Historical snapshot, superseded for implementation status by the current Definition publication record above. The statement below that foundational Definition implementation had not begun accurately records the state on 2026-09-29 only; it is not the current implementation status.

The reconciliation defines retained-reference and resolved-value assignment as two semantics of one assignment/mutation mechanism. Retained references preserve an authoritative source relationship and derive current value from it; resolved assignments evaluate the source at assignment time and retain the resulting value, with provenance/causal evidence where supported. Either form can later be replaced by normal Data/Workflow/Logic mutation. Marketing is documented as a future capability/domain whose network emerges from ordinary objects and relationships, without a bespoke graph, campaign engine, network primitive or capability mechanism. Business-specific configurations may inform reusable derivatives or platform patterns only through explicit human authority.

This change modified canonical documentation only. No application code, database schema or data, fixture, test, UI, deployment configuration, release artifact, staging environment or production environment was changed. D01-D10 and the existing unnumbered three-role/reference clarifications remain authoritative; no new architecture decision was introduced. Foundational-definition implementation and planning were not begun. Existing historical implementation evidence, including capability_derivation terminology, remains unchanged and is not runtime evidence for this reconciliation.

Derivation, Business Network and Access Documentation Reconciliation

Status: DOCUMENTATION-ONLY RECONCILIATION; NO RUNTIME IMPLEMENTATION OR VERIFICATION, 2026-09-27. The canonical documentation now makes explicit the cross-cutting invariant to store facts, evidence, relationships and history, then derive conclusions and conditions from them rather than introducing duplicated classifications or flags. The reconciliation preserves separate Business existence, network participation, Principal association, authority, subscription/entitlement, capability existence and permitted operation depth.

The updated owners describe legitimate relationship-mediated Business participation and information accumulation before Principal association; authority to act for a Business without treating authority as existence; subscription as an operational/access input rather than authority or capability existence; exploratory constrained authority without quotas, tiers, pricing, a final access matrix or a remaining counter; holistic permitted capability presentation with restricted deeper operations; and competing assertions whose provenance, standing, scope, temporal context and history remain intact. The 34-employees versus 21-employees example demonstrates deterministic contextual derivation without destructive replacement or a generic verified/unverified classification.

This reconciliation changed only canonical documentation and this status record. No application code, schema, migration, test, release package, database, staging environment, deployment configuration or archived source snapshot was changed or executed. No D01-D10 decision was reopened, no D11 or other numbered decision was created, and no runtime behavior is claimed or verified by this entry.

Remaining governance questions are intentionally deferred: eligible network introduction/evidence sources and retention rules; the exact limited inspection and capability-depth matrix under inactive or unconfirmed entitlement; the constrained-authority dimensions and approval responsibilities needed by real operations; the evidence threshold for Principal association or representation; and which derived determinations require live recalculation versus permitted materialization and what historical reconstruction guarantee applies.

Definitions Readiness Documentation Consolidation

Status: DOCUMENTATION-ONLY CONSOLIDATION; DEFINITIONS NOT IMPLEMENTED, 2026-09-27. The canonical owners now provide an implementation-ready conceptual boundary for foundational Definitions without introducing a Definition primitive or new architecture decision. Definitions are addressable descriptive objects within {id, type, value}; they may describe recursive constituent structure, relationships, applicable Types, configuration requirements, workflows, Logic, Operations and appropriate presentation configuration. Discovery, validation, publication, adoption, configuration/use and later revision proposal remain distinct governed activities.

Historical snapshot, superseded for implementation status by the current Definition publication record above. The following non-implementation statement records the state on 2026-09-27 only; complete Capability Definition content and Business application remain deferred.

The documentation also records derived missing-configuration and contextual validity/uncertainty, progressive Business configuration, derived attention, epistemic presentation, model-driven AI configuration with manual parity, capability composition, subscription explanation and longer-term Business DNA learning direction. Definition changes do not silently mutate existing Business configuration or instances; explicit adoption, review, reconfiguration or a future governed migration process is required.

This entry does not claim Definition tables, CRUD, APIs, editors, onboarding, AI configuration, network features, migrations, schema changes or runtime behavior. Those remain the next implementation stage or explicitly deferred future/open design work.

Superseded Capability Definition -> Business Capability Instance Slice

Status: HISTORICAL EVIDENCE ONLY; NON-CONFORMING TO THE RECONCILED DEFINITION CONTRACT, 2026-09-29. The earlier slice demonstrated plumbing around a shallow manifest composition, but it did not prove a platform Capability Definition containing the complete recursive composition required by the canonical owners. Its test and HTTP results remain historical behavior evidence only and must not authorize extension of the old model.

Added

Evidence

Not added

Capability evolution, future Derivation, promotion of Business configurations into standards, automatic standard mutation, cross-Business learning/convergence, a broad capability catalogue, a generic Capability Engine/Runtime/Store, a fourth semantic role, a separate capability database, AI configuration, or a capability-specific mutation/authority path remain NOT IMPLEMENTED. The current slice is one Marketing composition over the bounded IDY-009 process; it does not claim general capability adoption, migration, evolution or future Derivation functionality.

Capability Projection Genericity Correction

Status: HISTORICAL PROJECTION EVIDENCE ONLY; NOT PROOF OF COMPLETE DEFINITION IMPLEMENTATION, 2026-09-29. The existing projector demonstrated reusable projection plumbing over the prior shallow fixture, but it does not establish an authoritative recursive Definition composition.

Added

Evidence and limits

The focused synthetic and regression suites passed 41 tests and 261 assertions; the complete IDY-009 HTTP acceptance suite passed with no runtime diagnostics. The proof establishes reusable projection/configuration plumbing for a second capability shape, not a complete second product capability. Durable platform Capability Definition lifecycle, evolution, convergence, promotion, cross-Business learning, AI-driven configuration and the broad capability catalogue remain NOT IMPLEMENTED.

Capability and UI Model Documentation Reconciliation

Status: DOCUMENTATION-ONLY RECONCILIATION; NO RUNTIME IMPLEMENTATION OR VERIFICATION, 2026-09-26. Capability definitions are recorded as platform-owned reusable definitions, with Business-controlled deviations expressed through governed Business-scoped configuration and instances. Capabilities, capability definitions and the conceptual UI presentation direction have been explored and agreed at the architectural level: deterministic capability composition, holistic and attention-first presentation, progressive disclosure, consequence-aware authority, epistemic distinctions, dataset ingestion versus live integration, operational activity summaries and manual/AI parity remain documented direction.

This work changed no application code, schema, migration, test, release package, database, staging environment, deployment configuration or archived source snapshot. The exact UI elements and complete presentation vocabulary remain to be explored. Attention surfaces, watched objects, broad onboarding, dataset ingestion, recommendations, cross-business patterns, future capability discovery, analytics, integrations, AI and the wider capability catalogue remain product and architectural direction, not implemented feature evidence or MVP completion claims.

Four Semantic Object Roles and Generic Composition

Status: IMPLEMENTED; FOCUSED VERIFICATION PASSED, 2026-10-06. The authoritative core object model and authority contract defines exactly four semantic object roles: Data, Logic, Workflow and Presentation. These roles express business meaning within the existing universal {id, type, value} model; they are not D02 Type values. The type continues to identify domain meaning, including Business, Customer, Invoice and Workflow Definition, while Event, Command, Attempt and Outcome remain addressable same-model infrastructure records. The roles compose recursively in one global object graph; they are not separate stores, schemas, engines or application subsystems.

The generic Definition path now supports a data-defined semantic role and typed named semantic inputs using exact Object references or inline typed values. Validation covers role, input identity, expected Type descriptors, cardinality, required/optional presence, exact revisions, Type compatibility and existing recursive composition/cycle limits. It does not execute Logic or Workflow, resolve Presentation bindings or create role-specific persistence.

The documentation reconciles the roles with existing Relationships, revisions, authority, governed mutation, Command/Attempt/Outcome, provenance, Events, Workflow Definitions/Executions and optional AI. Search, requests, inputs, configuration, calculations, automation, To Dos and AI are represented as compositions, infrastructure records or projections rather than additional semantic roles. Logic evaluation, Presentation-to-Logic consumption, Workflow execution and Dashboard migration remain out of scope.

No schema, migration, role-specific table, evaluator or Dashboard migration was added. The focused integration suite verifies the generic validation boundary; it is not runtime verification of Logic execution, dependency evaluation or Presentation-to-Logic consumption.

External Valuation Page Responsive Correction

Status: IMPLEMENTED; LOCAL BROWSER VERIFICATION PASSED, 2026-09-24. The supplied c:\Users\stuar\Downloads\index.html page was corrected without changing its HTML content or JavaScript. At widths up to 768px, the sidebar is no longer sticky and is bounded to the viewport with its own vertical overflow, allowing the main content to follow it in normal document flow. The sidebar scrollbar is hidden with scrollbar-width: none, -ms-overflow-style: none and a scoped ::-webkit-scrollbar rule, while scrolling remains enabled. The app grid and main column now accept narrow widths (minmax(0, 1fr) and min-width: 0), and mobile main padding/gap were reduced to avoid unnecessary horizontal pressure.

Source inspection verified that no content text, data, links, controls or JavaScript changed. Local browser verification on the supplied file passed at 1440, 768, 430 and 375px viewport widths: the main column was reachable at mobile widths, the document reached its end by normal page scrolling, the sidebar retained independent scrolling, the sidebar scrollbar computed as hidden, and the document had no horizontal overflow. Existing control behavior was not exhaustively exercised; no staging deployment or remote-device verification was performed.

Business Creation, Configuration and Operational Initialization

Temporary Business Configuration Workspace

Status: IMPLEMENTED; FOCUSED VERIFICATION PASSED, 2026-09-24. The authenticated /business-configuration target surface is now a temporary development/admin workspace for the A+B slice: it reads the actual platform Business Definition and revision, renders Definition-derived constituent requirements, shows the current Business and matching constituent object instances/values with available technical revision/provenance references, and links to the existing governed initialization surface for value creation/update. The read projection does not call InitializationService::start() and therefore does not admit an initialization workflow or create initialization event, provenance, dispatch or execution records.

The workspace reuses the existing server-resolved Business context, Membership, platform.install_configuration authority/Policy boundary, Business inspection authority, object/revision repository and existing InitializationService mutation path. It contains no email comparison, direct SQL mutation, second Business form, Definition Save Operation or generic JSON/table editor. Definition structure editing (C) and operational demonstrator initialization (D) remain explicitly unsupported/excluded; the workspace does not call provisionDemonstrator() or create Enquiry, Qualification, Decision or Project records. The current stored Business Definition is rendered at runtime, so a website field appears only if the authoritative Definition contains it.

Focused verification on the pinned PHP 8.3.33/PHPUnit 11.5.56 runner passed PrincipalAdmissionBusinessCreationTest.php with 7 tests, 147 assertions, 0 failures and 0 errors, and passed the adjacent DefinitionDrivenInitializationTest.php with 3 tests, 19 assertions, 0 failures and 0 errors. The read-only target release check passed with 155 resolved files after adding the workspace runtime class to the reviewed boundary. No staging deployment, staging database mutation or staging Business fixture was used for this build.

IDY-007C lease and platform provisioning corrections

Status: IMPLEMENTED; FOCUSED AND TARGET-REGRESSION VERIFICATION PASSED, 2026-09-24. WorkflowDispatchLeaseService::claimNext() now treats a rejected trusted workflow transition as no claim and commits the unchanged eligible state, so a conditional resource-claim rejection cannot be reported as a successful lease. The strict ConfiguredResourceClaimGuard comparison against MariaDB UTC_TIMESTAMP(6) is unchanged. IDY-007C dispatch and finalization fixtures now derive their supplied times from SELECT UTC_TIMESTAMP(6) rather than historical timestamps; expiry and fencing assertions remain exercised through the existing narrow DateTimeImmutable seam.

Normal runtime construction is now assembly-only: TargetRuntimeCompositionRoot::fromExisting() does not install platform vocabulary, governance or evidence. TargetProvisioningRunner owns the complete platform installation sequence, including InitializationVocabulary::installPlatform(), and serializes it with the existing runtime_coordination row lock inside one transaction. This preserves deterministic fixed platform identities and idempotent opening behavior without duplicate-key suppression or schema changes. Affected test fixtures now invoke the platform-opening installation owner explicitly.

The bounded sequential workflow interpreter is now assembly-wired through TargetRuntimeCompositionRoot::workflowInterpreter(). A condition node may reference an exact Logic Definition revision; both the interpreter and the trusted workflow Operation handler resolve it through GenericLogicEvaluator against the pinned execution subject, then retain the existing governed Operation, lease, expected-version, authority/policy and evidence boundaries. The validator accepts only a positive UUID/revision pair for this reference. This remains a bounded step surface: no general worker, scheduler, queue, wake/recovery, retry/replay, parallel execution, approval wait, compensation or external-effect guarantee is claimed.

The required focused runner could not be executed for this change because the approved staging-to-test refresh failed with MySQL error 2002: MariaDB was not listening on 127.0.0.1. No independent database was created or used. Changed PHP files passed php -l; database-dependent workflow and Logic behavior remains unverified in this environment.

Evidence: Idy007CDispatchLeaseTest.php passed 10 tests / 49 assertions; Idy007CFinalizationTest.php passed 19 tests / 98 assertions; and the requested target regression trio (Idy006BPresentationTest.php, PrincipalAdmissionBusinessCreationTest.php, StagingProvisioningPackageTest.php) passed 25 tests / 268 assertions. The canonical ./bin/run-tests.ps1 invocation completed 413 tests / 2,104 assertions but was not green: it reported one cross-suite assertion failure and eight environment/database-state errors caused by missing workflow_dispatch, platform_opening_applications and schema_migrations tables after the local test-database reset sequence. Full-suite certification is not claimed. No staging deployment, staging configuration change or production operation was performed.

Standard Definitions Explorer and Business navigation

Historical snapshot (2026-09-29), superseded by the current implementation and acceptance record above. The BUILD-authorization requirement below records the decision state at that date only; it is not a current blocker. The generic Definition publication, exact-revision Explorer and simulation-only Action foundation are now implemented and focused-tested. Complete Capability Definition content and Business application remain deferred as stated in the current record.

Status: PARTIAL EXPLORER INFRASTRUCTURE; CAPABILITY SOURCE AND CONFORMANCE NOT ACCEPTED, 2026-09-29. The Definitions Explorer is an intentionally supported target-runtime/platform-control surface for authenticated platform diagnosis and inspection. The authenticated target shell exposes a read-only /definitions page only to Principals whose UUIDv4 appears in the server-side IDY_TARGET_DEFINITIONS_PRINCIPAL_IDS allowlist. Missing, malformed or non-matching configuration fails closed; ordinary Business users and non-allowlisted Principals remain denied. The Explorer is not development-only, is not generally available to Business users, and is not an authoring or lifecycle surface.

The previous five-file runtime/Explorer diff changed catalogue wiring toward persisted platform Definition Objects, added Object revision links, and added an Explore Definitions affordance. That diff has not been accepted as conforming Capability Definition architecture. The current persisted Initialization path supplies only foundational Definitions such as Principal, Business, Person and Organisation; the eight standard Capability Definitions are not established as complete canonical persisted Definitions. The Explorer must follow UI -> Explore Definitions -> canonical persisted Definition -> recursive composition -> Object inspection when that canonical source exists. It must not substitute a manifest projection merely because a persisted Capability Definition is unavailable, and it must never execute Workflow or Logic during inspection. Inferred reference shapes and revision fallback are unsupported. The implementation path for conformance is now specified in Implementation Architecture; a separate runtime BUILD authorization is required before changing the existing runtime/Explorer slice.

The StandardDefinitionCatalogue is a read-only presentation boundary. It validates selection by source discriminator plus native identifier, derives structure at read time, follows only declared references, labels release-component scope boundaries, and reports unresolved references, cycles and explicit depth/node/edge truncation outcomes. Its bounds are depth 6, 100 nodes and 200 edges. It does not call Business authorization or relationship traversal, create a hierarchy/table, execute workflows or mutate objects, revisions, relationships, commands or events.

The Business selector and Business Configuration workspace remain available. Manage resolves to /objects/<server-selected-business-id>; the boundary requires the requested object to be the selected Business and revalidates Business membership before rendering its minimal read-only detail. Capability navigation retains only Overview; Businesses and All records were removed. Evidence: PHP lint passed for all changed PHP files; Idy006BPresentationTest.php passed with 16 tests, 104 assertions, 0 failures and 0 errors; bin/run-http-acceptance.ps1 -Suite idy010 passed all listed checks; and the pre-correction bin/target-check.ps1 passed at 155 files. The corrected 159-file target boundary is verified in the release evidence below. No staging deployment, production configuration change, Genesis change or database schema change was performed. The existing Business selector and Business Configuration workspace remain available. Evidence for this build: PHP lint passed for all changed PHP files, git diff --check passed, and bin/verify-ui-structure.php passed all structural checks. The requested .in un-tests.ps1 tests\Integration\Idy006BPresentationTest.php invocation did not reach PHPUnit because the required staging-derived local database refresh could not connect to MySQL on 127.0.0.1:3306; no application assertions are claimed from that run. No staging deployment, production configuration change, Genesis change or database schema change was performed.

Status: INITIALIZATION MECHANISM IMPLEMENTED; DATABASE-BACKED INITIALIZER EXECUTION NOT VERIFIED, 2026-09-23. The phases are deliberately separate. The governed business.create Operation creates the Business, creator Membership, explicit inspection/configuration authority, explicit Enquiry-demonstrator operation/mutation authority, Policies and provenance atomically in BusinessCreationOperationHandler. The trusted IDY-008 release in demonstrator.json remains reusable configuration only: it installs the Business-scoped Types, States, Transitions, Relationship Types, Operation Contracts, Views and Workflow declarations and does not contain operational instances. That absence is intentional; the subsequent generic initializer creates operational instances through those installed Operations.

The generic operational entry point is InitializationService::provisionDemonstrator() in InitializationService. It requires an existing Business, authenticated Principal, installed IDY-008 Operation Contracts and explicit operation inputs. It invokes create_enquiry, submit_qualification, decide_qualification and create_project_from_qualification through OperationInvocationService, so each phase uses the existing Command, validation, authority, Policy, revision, provenance, event and outcome boundary. The approved runtime values are supplied as ordinary initialization inputs rather than a second seed format; the operation declarations remain the authoritative structure and the existing demonstrator fixture/test vocabulary remains the source of the bounded Enquiry values.

The method creates an unmatched Enquiry, a related Qualification and their state progression. It returns awaiting_review when no separately authorized reviewer is supplied. With an explicitly supplied reviewer who has the ordinary Business membership, operation grant and Policy, it records the Decision, creates the Project and establishes the four ordinary Project relationships (Qualification, Enquiry, Qualification back-reference and responsible Principal), returning provisioned. The reviewer rule remains enforced by the existing Decision handler; initialization does not bypass it or manufacture a reviewer identity.

Retry safety is implemented by deriving initialization Command IDs and demonstrator-created object/relationship IDs from stable Business/step/input or Command identities. Matching retries therefore reuse the existing Command result and object identity; changed input produces the normal Command fingerprint conflict. The target composition root registers the existing Project handler. The mechanism is reusable for any Business with the approved configuration and explicit authority; it contains no Business-name branch, Spearmint identity or direct SQL mutation.

Execution evidence remains INCOMPLETE in this environment. The disposable runner stopped before application execution because two repository migration files share the 0013 migration identity. The focused integration runner reached the initializer fixture but its final result was not exposed with usable error detail after the permitted retry; therefore no database-backed provisioned result or idempotent retry is claimed here. The implementation test now uses the existing Business-scoped reviewer fixture and does not seed operational records directly. No staging or production data was used or changed.

Staging Business Purge Implementation

Status: IMPLEMENTED / EXECUTED / VERIFIED FOR STAGING, 2026-09-23. bin/purge-non-spearmint-businesses.php is a CLI-only staging boundary that requires explicit staging context, a validated non-production database identity, the exact Spearmint Design display name to resolve uniquely, and the --execute flag before mutation. Without --execute, it performs only a dependency inventory. BusinessPurgeRepository deletes dependent index/dispatch rows, revisions and objects in a transaction, refuses cross-Business relationship/workflow references and verifies that exactly one Spearmint Design Business remains.

PHP 8.3.33 syntax checks and editor diagnostics passed for both changed PHP files. The staging dry run resolved four Businesses: Spearmint Design (5426fb74-f233-4245-81b0-d69a51b7603d) plus Promise Money, Idiosyncrasy and Cottonridge. With explicit operator confirmation, the execute run removed the three non-Spearmint Businesses, six objects and six revisions per Business, with zero relationship, event, transition, command or workflow index rows. An independent read-only verification then confirmed exactly one remaining Business, zero purge targets and zero dangling indexed/workflow dependencies. No Principals were deleted, legacy organizations was not touched, and no production operation was performed. This is an explicit staging cleanup exception to the current demonstrator guidance to retain addressable Business history; it is not a general production deletion contract and has no backup/recovery evidence.

Principal Lifecycle, Profile and Authenticated Business Plan

Plan status: DOCUMENTATION-ONLY ARCHITECTURE/DISCOVERY, 2026-09-22. No application code, migration, UI implementation, email delivery, database mutation or staging deployment is claimed by this section.

Clarification, 2026-11-02 (the original text below is retained unchanged as dated history): "Principal" below means User (legacy Type name). Statements below that tie business.create or the Businesses navigation to entitlement ("entitlement-aware additional Business creation", "any applicable subscription entitlement", "entitlement/grant-gated creation/onboarding") are superseded: business.create is free and never entitlement-gated; only Business-scoped operational use is intended to be entitlement-gated, as future architecture that is not implemented (all Businesses are currently treated as active). See subscriptions and entitlements.

Current-state assessment

The new runtime already has the canonical Principal-first sequence registration -> confirmation -> authentication -> bounded onboarding -> business.create. Registration creates a pending typed Principal, separate normalized email identity, protected credential material and a hashed, 24-hour, single-use confirmation challenge. Confirmation is transactionally bound, expires, rejects replay/mismatch/concurrent losers, activates the Principal and issues only the platform-scoped onboarding grant for business.create. Authentication establishes session identity separately from authorization. Governed Business creation is platform-scoped, server-owned and atomic: it creates the Business, creator Membership, initial grants/Policies and provenance; Genesis creates none of these. Existing focused evidence covers this bounded JSON/runtime lifecycle and the zero-Business HTML onboarding slice.

The missing or incomplete surfaces are email transport and the email-link UX, profile Operations and revisions, protected profile-image storage/reference handling, the persistent top-right Principal control, unified authenticated Businesses navigation, entitlement-aware additional Business creation, and the focused browser/integration tests for those surfaces. The current target confirmation template's token textarea is a contract mismatch with the intended normal email-confirmation experience. The legacy profile/avatar controller uses the old application schema and is not implementation evidence for the new platform.

Architecture decision and lifecycle specification

No new D-number is required. Under settled D01/D02/D05/D09 boundaries, the Principal remains a first-class universal object. Display name and approved personal fields are typed Principal values with retained revisions. Authentication email remains a protected principal_identities association, not a copied generic property; credentials, confirmation verifiers, session material and security identifiers remain outside generic object retrieval. A profile image is an addressable Media/Asset object/reference; binary bytes remain in protected storage and are never embedded in a generic primitive or exposed as a public authority-bearing URL.

The intended lifecycle is: registration creates pending state and requests a confirmation message; the user follows a purpose-bound, expiring, single-use email link; confirmation atomically marks the identity/Principal active and issues only bounded onboarding authority; authentication establishes a session; the authenticated shell exposes the Principal control and Businesses; authorized Business identities are listed; business.create is available only under the platform grant/Policy and any applicable subscription entitlement; the operation creates the Business and initial administration atomically; profile reads/edits use the Principal object and shared Command boundary; logout destroys/revokes the session. Before confirmation there is no application authentication, Business selection or Business creation. A confirmation challenge is never a general login credential. Duplicate identities return controlled non-enumerating conflict; resend creates a fresh challenge subject to rate limits, while old/consumed/expired challenges remain unusable. Delivery failure or unknown outcome leaves the Principal pending.

Business identity remains independent from Principal identity, creator provenance, Membership, AuthorityGrant and subscription. A Principal may administer multiple Businesses where Membership and Policy permit it; a Business may have multiple Principals. There is no special first Business or Genesis ownership. Inactive subscription entitlement blocks Business-scoped operational execution but does not delete Business state or revoke authority. The server resolves Principal, Business, membership, grants, Policies, image ownership and Operation revision; the browser supplies none of those security decisions.

BUILD Slice 1 evidence: admission confirmation link

Status: IMPLEMENTED and VERIFIED for the bounded admission slice. The target runtime now separates confirmation-message delivery from Principal admission through an injectable ConfirmationEmailDelivery port. Registration commits the pending Principal and challenge first, then requests a confirmation email; JSON and HTML registration responses expose only the Principal identifier and delivery outcome, never the raw challenge. The native target adapter builds the purpose-bound /confirm?token=... link, while integration fixtures use a recording adapter. GET confirmation invokes the existing governed principal.confirm path, preserving expiry, one-use, locking, activation and onboarding-grant semantics. The manual token textarea and POST token flow were removed from the target confirmation view.

PHP 8.3.33 syntax validation passed for the changed runtime and test files. The local-only refresh path was repaired to read staging with mariadb-dump, import the dump through client standard input, and avoid staging CREATE DATABASE/USE statements. Each refresh forcibly drops and recreates only the designated local PHPUnit database, making staging authoritative for local state. The PHPUnit bootstrap explicitly allows migration-ledger checksum mismatches for this snapshot path; strict checksum enforcement remains the default for other MigrationRunner callers. On 2026-09-22, ./bin/run-tests.ps1 tests\Integration\PrincipalAdmissionBusinessCreationTest.php tests\Integration\PrincipalAdmissionHardeningTest.php refreshed local IDY_TEST_IDY002 from staging idio2plat_staging at 78.129.220.19:3306, then passed 9 tests / 143 assertions, 0 failures, 0 errors. The refresh reads staging only; no state changes are sent to staging. No staging deployment was performed. Profile fields, profile image handling, persistent account control, logout redesign, Businesses navigation and Business creation UI remain NOT BUILT in this BUILD.

Required implementation sequence

1. Add the smallest schema/runtime support for profile revisions, approved profile Operations and protected Media/Asset metadata/reference, preserving the generic object/revision model and identity tables. 2. Add the admission communication adapter/template and email-link confirmation flow, with redacted outcomes, expiry/replay/rate-limit handling and no raw challenge in normal API/HTML responses. 3. Add authenticated profile projection and self-service display/profile-field mutations through OperationInvocationService/CommandHandler; add image upload, safe rendition, replacement and removal handling. 4. Extend the target shell with one responsive top-right Principal control and Businesses navigation, including no-Business state, server-resolved Business list and entitlement/grant-gated creation/onboarding. 5. Preserve the existing governed business.create handler and Business/Membership/Policy model; do not add an Account/Tenant owner or Genesis path. 6. Add focused unit/integration/HTTP/UI acceptance evidence, then update this status with exact code revisions, commands, environments, results and limitations before treating any part as VERIFIED.

Risks and genuine unresolved decisions

The current contracts do not yet select an email provider/transport, exact message template, email-change/re-verification Operation, password recovery contract, secondary-email cardinality, final Media/Asset physical store or final profile-field vocabulary. These are implementation/product decisions that must be explicitly approved within existing owners; they must not be inferred from the legacy profile. The core identity/profile boundary, confirmation semantics, Business authority model, shared mutation path and entitlement gate are settled.

Contract and test implications

The eventual evidence must cover registration state and duplicate handling; email delivery accepted/failed/unknown outcomes; expired, replayed, mismatched and concurrent confirmations; authentication denial before confirmation and session/logout behavior; profile read and authorized self-mutation with revisions/provenance; invalid and unauthorized image upload/read/replace/remove; persistent desktop/mobile shell behavior and keyboard access; authorized/no-Business/multi-Business navigation; Business association and server-owned creation; entitlement suspension; cross-Business isolation; Command idempotency/conflict; and non-disclosure of credentials, challenge material, storage paths and unauthorized objects. Browser checks must exercise the email-link path rather than a token-paste workaround.

Local PHPUnit Staging Snapshot Mechanism

Status: IMPLEMENTED / SAFETY-PATH VERIFIED; DATABASE REFRESH NOT EXECUTED

bin/refresh-test-database-from-staging.ps1 provides the one-way local snapshot operation. It reads missing staging connection values from the ignored local .env.local file without overriding existing process IDY_TARGET_DB_* values, verifies that the source is non-loopback and is not the fixed local test database, exports the source with the pinned MariaDB dump client, recreates only IDY_TEST_IDY002 using the existing local administrative configuration, and imports the dump with the local test user. Temporary dump and credential files are created outside the repository and removed on completion or failure. The script does not run migrations, Genesis, provisioning or fixtures and does not alter staging.

Every invocation of bin/run-tests.ps1 now refreshes IDY_TEST_IDY002 from staging before configuring and invoking PHPUnit; if refresh fails, PHPUnit is not run. PowerShell parsing, .env.local configuration validation and the missing-staging-input guard passed on 2026-09-22. A clean focused PHPUnit invocation reached the refresh command but returned a native MariaDB/PowerShell error before PHPUnit; no completed snapshot or test result was recorded.

Persisted Presentation Object Graph Migration BUILD

Evidence date: 2026-10-05 Scope: replacement of capability-specific presentation assembly with exact persisted Presentation Object graph references.

Capability presentation is now bound through persisted Presentation Object roots and recursively projected into RenderablePresentation.elements. The removed presentation_items configuration, capability card assembly, collection/item compatibility arrays and capability-specific summary projection are not production presentation authorities. Remaining verification is tracked by the focused renderer and integration checks below; the staging-backed test runner remains subject to the pre-existing relationship_index cleanup failure.

Surface UI Standard and Stylesheet Integrity BUILD

Evidence date: 2026-09-22 Scope: documentation authority and source-integrity cleanup only. No visual surface reconstruction, route, authentication, Business authority, object, Command/Operation, database or staging change was performed.

Stylesheet contamination

Read-only inspection found operational Build Mode prose prepended to the tracked target/style.css, followed by the legitimate target CSS. The target layout links /style.css, so this was a real target source inconsistency rather than merely a package note. Git inspection found target/style.css and release/target-release.json tracked. The former release-staging/, --help/ and var/ copies were generated or package artifacts and are not authoritative source; they have now been removed. No stylesheet generator or derived-file declaration was found, and the source file history contains no later stylesheet-specific correction.

The repair removed only the unrelated operational prefix from target/style.css and preserved the existing target CSS beginning at :root. The target layout's /style.css reference remains unchanged. Package copies were not regenerated or independently edited; they require regeneration through the normal release/package process before being treated as current artifacts. No staging or production deployment occurred.

Documentation authority established

docs/implementation/ui-system.md is now the authoritative current Surface UI Standard, version 0.1 dated 2026-09-22. It records evidence-backed brand values, unresolved design choices, semantic token roles, typography, shell, admission, components, responsive behavior, accessibility and a lightweight revision history. docs/reference/legacy-implementation.md now records the visual archaeology and Recover/Adapt/Reference only/Retire boundary as non-authoritative historical evidence. This status document remains the owner of implementation and verification evidence. No competing design-system document or architecture decision was created.

Validation and remaining limitations

Completed checks: read-only git status/tracking/history inspection; direct source inspection of the contaminated and package copies; confirmation that the target layout still links /style.css; confirmation that the tracked target stylesheet now starts at :root, contains no Build Mode or post-PDO text and has balanced braces; documentation authority and cross-reference review. The target CSS was not browser-rendered in this source-integrity change, and package copies were not regenerated. Existing application behavior tests were not rerun because this change did not alter runtime behavior; the existing 69/69 bounded IDY-010 HTTP evidence remains historical evidence from 2026-09-19, not new verification for this BUILD.

Next stage: continue the Surface UI reconstruction beyond the admission and shell slice, then regenerate and verify release/package artifacts from the tracked source. Browser, accessibility, live HTTP and package evidence remain separate gates; the first implemented slice is recorded below.

First Surface UI Reconstruction BUILD

Evidence date: 2026-09-22 Scope: first visual implementation on the current target surface. Existing routes, admission fields, session behavior, Business context resolution, object projections and Command/Operation boundaries were preserved.

Implemented in target/style.css: a coherent target token layer, dark/teal branded shell surfaces, light workspace and admission composition, typography hierarchy, panels, controls, buttons, links, status badges, notices, focus states, responsive table behavior and reduced-motion handling. Implemented in resources/views/target/layout.php, login.php, register.php and confirm.php: branded admission framing, current Business context, capability-driven navigation, active route treatment, semantic section headings and supplied light/dark horizontal wordmarks served from target/assets/idiosyncrasy/. The two SVG files are registered in release/target-release.json, so the target does not depend on sibling source assets at deployment time. No legacy marketing navigation or legacy authority behavior was restored.

Validation

Deferred

The final unified font choice, palette consolidation/contrast certification, exact breakpoint reconciliation, browser screenshots, assisted-technology verification, live target HTTP behavior and package regeneration remain unverified or deferred. This BUILD establishes the first implemented surface slice; it does not claim complete Surface UI reconstruction.

Target Release Foundation Evidence

Reviewed resolution correction

The previous reviewed target resolution was 166 files. The Capability Application handler, persisted projector, core-object Presentation provisioning and required Definition/Capability vocabulary add net files; the current exact public boundary is recorded by the release manifest, with exact-file-set and GitHub provenance validation. The corresponding internal provisioning package currently resolves to 200 files. Historical file-count observations remain historical and are not rewritten.

The reviewed target release definition is release/target-release.json. It is authoritative for the current target boundary; the resolved file list is derived from its approved patterns and explicit path snapshot. The current checked-in source resolves to the release manifest's verified file count. It includes the persisted Definition Explorer/publication path, Business-derived Capability Application handler, persisted-state capability projector, server-side Operation source resolver, exact Operation-identity authorization, no-network send_email simulation, core-object Presentation provisioning, existing bounded target UI, initialization classes and verified public assets. Provisioning-only Genesis, publisher installation and platform-opening materials remain outside the public target release. The test-only recording adapter is under tests/Support/ and is intentionally outside the target release. The internal StagingProvisioningPackage includes all runtime PHP and currently resolves to 202 files. The former release-staging/ audit was retired and is no longer used as current release evidence.

TargetReleaseDefinition rejects unsafe, duplicate or link-based paths and requires pattern expansion to equal the reviewed snapshot. TargetReleaseManifest requires GitHub authority, repository, full commit SHA and non-secret build identity; those fields participate in the canonical manifest digest and derived release ID. TargetReleasePackage creates only from an explicitly supplied source checkout and provenance file, and verifies an existing package without rebuilding it. Earlier focused package evidence used the 164-file public and 155-file internal sets (18 tests, 622 assertions; one test skipped). The prior public 166-file and internal 157-file package suites passed 18 tests / 630 assertions, one skipped; those counts predate this release-boundary change. The current read-only target resolution check passed at 228 public files and 202 internal files with PHP syntax checks. The public GitHub upload step preserves hidden files so the already-authoritative target/.htaccess survives artifact archival.

The historical staging comparison was retired with the snapshot; the current source boundary remains governed by the reviewed definition and exact-file-set checks.

bin/target-check.ps1 is a read-only local release-definition check. bin/target-local.ps1 is a guarded local launcher using the separate var/target-sessions-local path and loopback-only local database configuration. bin/target-release.ps1 consumes an already-created GitHub-bound package and verifies the 228-file manifest and exact provenance before its existing operator-visible phases. It does not package the arbitrary local working tree. Production activation and post-activation HTTP evidence remain unverified. Normal releases remain code/assets only and do not run migrations, provisioning, Genesis, platform opening, database mutation, staging or Plesk changes.

The ordinary release command is a code/asset operation only. It refuses migrations, provisioning, Genesis, platform opening, schema changes, data mutation, credential creation and Plesk configuration changes. It never includes or overwrites var/target-sessions.

The explicit bin/target-release.ps1 -UploadOnly operator mode performs the same local package checks, release-specific staging-directory preparation and recursive SCP transfer, then exits successfully without remote verification or activation. It does not change package contents or touch persistent sessions, database state, migrations, provisioning, Genesis, platform opening, Plesk or document-root configuration. A successful upload is staging evidence only, not remote integrity verification or activation evidence.

The explicit bin/target-activate.ps1 -ReleaseId <release-id> operator is implemented for an already-uploaded release. It validates the release-specific staging controls and structure, preserves the existing real target directory under a release-specific rollback location, switches target to the staged release's target pointer, and requires the activated identity plus HTTP /register check before success. Failure restores the previous target; the previous target is retained after success. Local PHP pointer resolution and PowerShell payload generation passed; a local POSIX shell execution and production activation remain unverified because no local WSL distribution is installed and production activation has not been run.

The former bin/target-upload-direct.ps1 file was obsolete historical material and has been removed. Only a GitHub-bound package consumed by target-release.ps1 is eligible for the reviewed staging path.

Stage 1 GitHub authority disposition

| Requirement | Status | Evidence or remaining gate | | --- | --- | --- | | GitHub repository and exact commit in release metadata | IMPLEMENTED / VERIFIED LOCALLY | TargetReleaseProvenance, canonical manifest, and package round trip; no credentials are stored. | | Reproducible package from exact checkout | IMPLEMENTED / VERIFIED LOCALLY | .github/workflows/build-target-release.yml checks out ${{ github.sha }}, validates, builds and uploads a verifiable artifact; the dependent staging job downloads that exact same-run artifact. | | Local operator cannot treat arbitrary working tree as release source | IMPLEMENTED / VERIFIED LOCALLY | target-release.ps1 requires an existing provenance-bearing package; target-package.php separates --create and --verify. | | Direct local-to-live upload | RETIRED | The obsolete direct-upload path was removed; only GitHub-bound packages are eligible for release handling. | | Remote provenance and package verification | REQUIRES REMOTE VERIFICATION | SSH capability is unresolved; no production command was run. | | Production deployment/activation | NOT YET IMPLEMENTED FOR THIS STAGE | No upload, activation, database mutation, migration, environment or Plesk change occurred. |

Staging deployment capability

The repository now has an explicit staging provisioning contract without changing the 133-file public runtime boundary. bin/provision-target.php --database=staging requires IDY_STAGING_DB_NAME, verifies that it matches IDY_TARGET_DB_NAME, rejects idio2plat and production-looking identities, and records migrations as IDY-STAGING. --database=target retains the exact idio2plat production safeguard and its existing release identity.

The automatic staging application deployment path is implemented in .github/workflows/build-target-release.yml: a successful push to main completes build-target-release, then the protected deploy-staging job downloads the exact same-run target release and calls bin/staging-deploy.sh. The helper validates the target artifact, establishes the existing password-authenticated SSH connection, uploads and installs the unchanged application package, and performs one GET request to STAGING_URL/health. GitHub receives no staging database credentials and performs no staging reset, migration, Genesis, platform opening or provisioning. Those operations are internal-script-only and must be explicitly authorized outside GitHub Actions. The workflow has no production reset or provisioning path.

The private staging provisioning package remains an internal operator artifact containing target runtime dependencies, the shared migration CLI, provisioning material, runtime migrations, the staging-only reset command and the required Genesis/platform-opening manifests. It contains no credentials and is never intended for the public document root or GitHub deployment. Staging migration and provisioning must be run by the internal scripts when explicitly authorized. Focused PHPUnit verification runs through the supported local wrapper; any remaining test deprecations are recorded in task evidence.

The selected-database preflight correction is IMPLEMENTED / VERIFIED LOCALLY: TargetProvisioningPreflight::assertEmptyDatabase() now binds its schema query to the validated TargetRuntimeConfig database identity. Production retains the exact idio2plat selector boundary; staging retains the explicit IDY_STAGING_DB_NAME equality and production-looking-name rejection. The focused TargetProvisioningPreflightTest, StagingDatabaseResetterTest and StagingProvisioningPackageTest run through the pinned local wrapper with 17 tests and 59 assertions passing; two PHPUnit deprecations remain.

The staging reset contract is IMPLEMENTED / INTERNAL-SCRIPT-ONLY / NOT EXECUTED: bin/reset-staging-database.php --database=staging requires explicit staging context and confirmation, matching target/designated staging identities, a non-production identity, and a same-server IDY_STAGING_RESET_DB_* administrative capability. Under the agreed single-user staging model, IDY_STAGING_RESET_DB_USER may equal IDY_TARGET_DB_USER; the dedicated reset capability settings and password remain explicit, and host/port must match the configured staging database server. Internal scripting must invoke reset before provision-target.php --database=staging; reset failure prevents provisioning. The disposable staging provisioning harness independently passed with 14 migrations, one Genesis run, one applied platform opening and zero credentials, using a generated local database which it cleaned up. The disposable reset end-to-end rehearsal remains UNVERIFIED because its prior permitted execution evidence was incomplete; no reset rehearsal or deployment was run for this integration task. Reset capability settings are not supplied through the GitHub deployment workflow. No staging reset or deployment is evidenced by this implementation.

Implemented / locally verified: staging identity validation, production identity rejection, 131-file public boundary preservation, internal staging bundle creation and provenance verification, the ledger-backed internal staging migration invocation, the application-only workflow/helper contract, the sshpass password-authentication contract, PHP lint, the focused 17-test/59-assertion suite, and the disposable staging provisioning rehearsal. The rehearsal completed with 14 migrations, one Genesis run, one applied platform opening, zero credentials, and successful disposable-database cleanup. Not verified: the disposable reset end-to-end phase sequence because its permitted execution evidence was truncated/incomplete; transfer to the real staging host, SSH authorization, staging filesystem permissions, DNS/TLS/PHP-FPM configuration, /health behavior on the host, or any real automatic staging deployment. The current workspace had no staging connection inputs or sshpass, and its cached package carried local zero-SHA provenance, so no live deployment was claimed or attempted. Shell syntax validation remains unavailable because this Windows environment has no installed WSL distribution.

Direct staging deployment status

The current Development Staging v1 mechanism is intentionally limited to exact artifact upload, package-tree installation under STAGING_REMOTE_ROOT, and one GET request to STAGING_URL/health. The deleted capability probe, activation lock, symlink switch, rollback choreography and remote manifest reconstruction are not part of this path. The 2026-09-21 live deployment request was blocked before remote execution because the workspace did not contain the staging GitHub Environment inputs, sshpass was unavailable, and the cached package was not bound to a real commit. Not verified: the disposable reset end-to-end phase sequence, a real automatic staging deployment, SSH authorization, remote filesystem permissions, DNS/TLS/PHP-FPM configuration, or the staging /health response.

Status Vocabulary

| Label | Meaning | | --- | --- | | SETTLED | Semantic contract approved in final D01-D10; not evidence of code | | SPECIFIED | A concrete implementation mechanism is chosen under that contract; not a new architecture decision or implemented feature | | NOT BUILT | No compliant implementation is evidenced in this inventory; existing unrelated functionality is not partial credit | | PARTIAL | A named part of the new contract has implementation evidence, with the uncovered parts stated | | VERIFIED | A specific requirement passed a recorded check against an identified revision/environment; not a blanket system claim | | OBSERVED | Source indicates behavior or an earlier snapshot describes it; not execution verification | | READY FOR CLOSURE | The audited implementation satisfies the frozen contract, with any remaining verification limitation recorded separately | | ENVIRONMENT BLOCKED | An executable verification could not run because of an environment prerequisite; this is not a test pass or implementation failure |

No row below is promoted to VERIFIED merely because this documentation was linted or linked successfully. Future evidence records must identify requirement, canonical owner, code/revision, check/fixture, date/environment, result and remaining limits.

IDY-001 Repository Isolation Evidence

Requirement: establish a distinct target runtime boundary without connecting it to the legacy application or database.

Implementation evidence:

Evidence recorded 2026-09-13: the pinned PHP smoke task reported PHP 8.3.33, and the focused IDY-001 checker completed all seven isolation, boundary and legacy-route checks. A live loopback HTTP verification then started the pinned PHP 8.3.33 built-in server with target as its document root and target/index.php as its router at http://127.0.0.1:8081, using only the existing isolated local database configuration mapped to IDY_TARGET_DB_*. GET /health returned HTTP 200 with {"runtime":"target","status":"boundary_ready","database_configured":true,"database_connected":true,"mutation_routes":[]}. GET / returned the same HTTP 200 target response. POST /campaigns returned HTTP 404 with {"runtime":"target","error":"route_not_found"}. The GET responses included Content-Type: application/json; charset=utf-8, Cache-Control: no-store and X-Content-Type-Options: nosniff. The server log showed normal request handling with no application error, and the temporary server was stopped with port 8081 released. Because the target composition root creates PDO before dispatch, database_connected:true is live evidence that the target database-backed path was exercised through HTTP; the configured database was the isolated idiosyncrasy_dev database. No setup script, migration, session or external service was accessed.

Status: VERIFIED for the IDY-001 target boundary under the stated local environment. This verifies the real target entry point, target-only configuration boundary, live PDO connection and rejection of the legacy mutation route through HTTP; it does not verify production Apache/PHP-FPM ingress, deployment configuration or broader application behavior.

Finding: the legacy smartftp.json deployment-credential file contains deployment credentials and is not part of the target runtime. It remains a legacy/deployment security risk requiring separate credential rotation and source-control handling; IDY-001 did not upload, reuse or expose it. The file is not present in the current tracked workspace, so this note is retained as historical security context rather than a live file link.

Local Development Environment Evidence

Requirement: prepare a reproducible local runtime/database combination compatible with the chosen first-milestone production baseline, without creating IDY-002 application behavior or running legacy setup.

Environment recorded 2026-09-13: Windows 10 Pro (64-bit, build 26200) with PowerShell 5.1. WSL 2.6.3 is installed, but no Linux distribution is present; the native user-local setup is therefore the smallest compatible mechanism. No pre-existing php, MariaDB, MySQL, database service, database listener or PHP 8.4 executable was found on PATH or in the inspected common installation locations. No global PATH, Windows service, Composer, framework, application code, database schema or legacy setup script was changed.

Provisioned runtime: PHP 8.3.33 NTS Visual C++ 2019 x64 and MariaDB 10.5.26 Windows x64 are installed below %LOCALAPPDATA%\Idiosyncrasy\dev-runtime, outside the repository. MariaDB's vendor-published SHA-256 for its ZIP was checked before extraction. The server is loopback-only at 127.0.0.1:3306, uses utf8mb4/utf8mb4_unicode_ci, defaults to InnoDB and has innodb_file_per_table=ON. An isolated empty idiosyncrasy_dev database and a database-scoped non-root user are configured with credentials stored only in the local ACL-restricted configuration directory.

Checks passed: the PHP CLI reports PHP 8.3.33; PDO, pdo_mysql, OpenSSL, cURL, DOM and Fileinfo are loaded. The database reports 10.5.26-MariaDB, mariadb.org binary distribution, default InnoDB, utf8mb4 and utf8mb4_unicode_ci. The non-root client created and dropped an InnoDB probe table, leaving zero tables. The pinned PHP executable connected to the isolated database using a mysql: PDO DSN and reported PDO_OK:10.5.26-MariaDB with the mysql PDO driver present. The generated MariaDB root client defaults file was restored in the local configuration directory after the database test reported it missing.

Operational interface: bin/php83.ps1 remains the pinned-PHP wrapper for direct use. The test and HTTP acceptance runners, and the PHP-specific VS Code tasks, invoke the same pinned executable directly because the machine's powershell.exe -File bin/php83.ps1 bridge is unreliable. bin/dev-db.ps1 supports Start, Stop, Status and Test; the latter verifies client and PHP PDO access without printing credentials. Static diagnostics passed for these helpers and tasks. This is a native Windows compatibility environment, not a substitute for later Linux/PHP-FPM or Plesk ingress verification.

Status: VERIFIED for the stated local PHP/MariaDB/PDO/InnoDB compatibility prerequisites. No IDY-002 or other new-platform application/runtime requirement is promoted by this environment evidence.

Production Target HTTP Boundary Evidence

Requirement: verify the deployed target HTTP boundary after the successful post-PDO startup trace, without provisioning, migration, Genesis, opening, database mutation or application changes.

Evidence recorded 2026-09-19: read-only GET requests were sent to https://platform.idiosyncrasy.co.uk through the live Plesk ingress. /health and / each returned HTTP 200 with runtime=target, status=boundary_ready, database_configured=true, database_connected=true and mutation_routes=[]. /login and /register each returned HTTP 200 with a JSON CSRF bootstrap response. An unknown route returned HTTP 404 with {"runtime":"target","error":"route_not_found"}. The responses identified PHP/8.3.33,PleskLin and included Content-Type: application/json; charset=utf-8, Cache-Control: no-store on the boundary responses and X-Content-Type-Options: nosniff.

This validation exercised the deployed target entrypoint and dispatch boundary only. It used no POST request, provisioning command, migration, Genesis, platform opening, database inspection or database mutation. The Plesk system logs remain inaccessible to the deployment account (Permission denied), so this evidence verifies current behavior but does not identify the historical target_configuration_unavailable exception. runtime_coordination remains neither observed nor established as that historical cause.

Status: VERIFIED for the current live target HTTP boundary under the stated production URL and date. This is limited to the observed GET boundary, startup/composition readiness and route response contract; it does not verify the complete first-milestone lifecycle, privileged PHP-FPM/Plesk log access, backups or production provisioning state.

Production HTTP/runtime release deployment

Evidence recorded 2026-09-19: the audited local release-staging/ release was transferred by non-destructive SCP into the existing application root /var/www/vhosts/idiosyncrasy.co.uk/platform.idiosyncrasy.co.uk/. The transfer contained exactly 128 files: 111 app/Runtime PHP files, 13 target templates, 3 target public files and 1 bootstrap file. No var/, database, CLI, test, documentation, configuration or deployment files were transferred, and the Plesk document root remained target/.

Read-only remote verification found all 128 expected files, all four critical paths, and var/target-sessions/ present. SHA-256 values for the transferred files matched the audited local release inventory. The session directory was outside the transfer scope and was not replaced or targeted. No provisioning, migration, Genesis, platform opening, database, environment, PHP or Plesk operation was performed.

The post-transfer HTTP smoke test used GET requests only. / returned HTTP 303 redirecting to /login; /login with Accept: text/html returned HTTP 200 HTML without target_configuration_unavailable; and /health returned HTTP 200 with boundary_ready. HTTP verification was observed at 13:27:39 GMT on 2026-09-19.

Status: VERIFIED for the audited HTTP/runtime file transfer, remote file checks and bounded GET smoke test. This does not certify the complete application lifecycle, backup/restore state or broader production security posture.

The earlier preflight evidence below records the state before this deployment and should not be read as a current claim that no production files were ever modified.

This provisioning-preflight investigation did not initiate a production database connection.

No provisioning command, migration, Genesis operation, platform-opening operation, or other production database mutation was executed.

provision-target.php = BLOCKED

Temporary staging registration diagnostic

Status: EXECUTED / ROOT CAUSE IDENTIFIED; CORRECTIVE DEPLOYMENT PENDING. The standalone staging registration diagnostic workflow uses the existing staging GitHub Environment, builds and verifies the selected exact-commit 159-file target release on the runner, and performs bounded read-only SSH, HTTP GET and database metadata inspection. Its remote helper is streamed over SSH stdin and does not create persistent staging files.

The diagnostic does not deploy, upload, install, migrate, provision, submit POST requests, mutate staging database rows or filesystem state, change Plesk/web-server configuration, or access production. Its bounded metadata inspection reports the POST-only schema tables and command_keys.business_id nullability, CREDENTIALS_COUNT, GENESIS_RUNS_COUNT, and, when present, each credential's principal_id, derived status, created_at, updated_at, password_changed_at, and disabled_at. It excludes password hashes, normalized login identifiers, challenge data, tokens, and all other credential material. The inspection also reports migration-ledger state, principal.register/principal.confirm Operation metadata, platform-opening records, current database privileges, and bounded error-log evidence. On the staging run for commit 0d8c9c2744eccea2bccb44d2d6074fb29cbc7e46, the deployed target identity and 131-file boundary matched the expected commit/package checks, /register GET returned 200 with target markers, all admission tables and required privileges were present, migration 0012/0013 were present, and the opening ledger reported one APPLIED record. Both canonical admission Operations were absent. This established opening/Operation drift as the registration failure; the registration handler and schema were not the defect.

The expected/deployed target release ID and digest difference is not causal evidence of source divergence: the target manifest identity includes the GitHub build provenance, including the per-run build identity, so separate workflow runs for the same commit can produce different content-derived release identities. The diagnostic distinguishes this artifact identity from the exact commit identity. The corrective code now reconciles approved opening effects whenever a matching APPLIED ledger row exists, and the normal staging migration step invokes that reconciliation before installing the public package. Staging deployment and the disposable end-to-end registration/confirmation/authentication/business.create validation remain PENDING until the corrected commit is pushed through the existing staging workflow; registration is not yet marked fixed.

The existing manual diagnostic now also streams a CLI-only bootstrap probe through its authorized SSH connection. The probe source is required in the checked-out workflow revision and is base64-streamed in the SSH command environment; the remote helper explicitly reports unavailable transport instead of silently omitting the probe. The probe runs against the already-installed staging root, requires no target-package upload and is not persisted on staging. It invokes the real TargetRuntimeCompositionRoot::fromEnvironment() path using the installed release's autoloader and process environment, then emits bounded exception evidence: class, sanitized message, code, application-relative file, line and at most 12 stack frames. Output is limited to structured fields; trace arguments and probe stderr are not emitted, and password, credential, token, cookie, session and DSN-like values are redacted or omitted. A thrown composition root returns a nonzero probe result while a completed composition root returns success. The probe does not change target HTTP behavior, add persistent logging, or add migrations/provisioning/database operations; it intentionally preserves any existing startup behavior performed by the real composition root. It is staging/operator-only and is invoked only when the staging registration diagnostic workflow is manually dispatched; this implementation has not itself been executed against staging.

New-Platform Verification

Definition-Driven Principal and Business Initialization Slice

Status: IMPLEMENTED / FOCUSED-VERIFIED, 2026-09-23. The target runtime now installs platform-owned, revisioned Principal and Business Definition objects and a generic constituent object Type through the existing universal object/revision model. It creates Business-scoped initialization Workflow Definition/Node and Operation objects on demand, binds a Workflow Execution to the existing subject and exact Definition/Workflow revisions, projects requirements generically through JSON/HTML target boundaries, and routes explicit input through OperationInvocationService and CommandHandler. Initialization uses deterministic constituent identities, recognizes compatible existing constituents, rejects ambiguous/incompatible constituents, and finalizes only when required Definition requirements are satisfied. Credentials, confirmation material and session data remain outside generic constituents.

Presentation-Driven Generic Object Explorer

Status: ARCHITECTURE REFACTORED, 2026-10-04. The /objects/{id} endpoint is now the canonical generic object exploration endpoint, with Business-scoped Presentation Definitions determining visibility and no automatic relationship discovery. A Presentation Instance is optional: it records a binding when explicit presentation-specific state or an independently addressable presentation binding is required; ordinary objects render directly from their Business Presentation Definition. Presentation Instances do not become copied sources of business data. The rendering flow follows: object resolution → optional Presentation Instance binding resolution → Business Presentation Definition resolution → presentation projection (using detail_fields) → generic presentation rendering → HTML. Object references render as links back to /objects/{id}, primitives as Name: value, and collections as linked object lists. The crucial separation is: data graph (all relationships as they exist) versus presentation (which relationships are explicitly exposed by the Presentation Definition). Future Standard Presentation Definitions and Business-derived definitions remain an architectural seam, not a current implementation claim.

Changes:

Architecture:

Implementation status:

Focused evidence: DefinitionDrivenInitializationTest passed 3 tests / 19 assertions. The existing PrincipalAdmissionBusinessCreationTest regression passed 7 tests / 135 assertions. ExistingSpearmintInitializationTest resolves the named Business by durable identity and never creates/deletes/replaces it, but its local-snapshot result is not promoted to VERIFIED: one refreshed snapshot explicitly lacked an eligible local Spearmint membership and another run was blocked by the pre-existing Genesis/ledger fixture error. No database migration or staging deployment was performed. The broader workflow/configuration command was not promoted to a pass because existing Idy007AVocabularyTest and related workflow suites fail during fixture cleanup with pre-existing foreign-key/Genesis-store errors before their relevant assertions.

This slice does not implement definition adoption or automatic migration, general recursive derived-state propagation, universal relationship recovery, general deletion lifecycle, unresolved-dependency resolution workflows, cycle pause/review, broad Policy composition or AI-assisted configuration. Workflow execution state is reused for initialization progress; initialized means only that this execution's declared requirements were satisfied.

Object Presentation Current Evidence

Status: DOCUMENTED ARCHITECTURE / AUDIT ONLY; NO CONSOLIDATION BUILD AUTHORIZED, 2026-10-05.

See the canonical Object Presentation contract and the View/UI implementation route. Current evidence is limited to the ordinary-object explorer path, capability projection paths and their existing renderer compositions. These paths remain separate implementations; their common model and duplication are not yet verified.

No templates, projectors, routing branches, database objects or presentation configuration were changed in this audit. Consolidation remains unauthorized until legitimate composition differences and accidental duplication are separately classified.

Core Object Model and Platform Authority Reconciliation

Status: DOCUMENTATION RECONCILIATION ONLY / NOT RUNTIME-VERIFIED, 2026-09-23. The cross-cutting core object model and authority document and its owner cross-references now record the following obligations. This alignment does not promote any item to VERIFIED, change release scope or claim a complete universal runtime.

The semantic contracts are settled, but specified does not mean implemented or proven. The following remain explicit deferred implementation capabilities: definition adoption and instance evolution; recursive derived-State calculation, invalidation/materialization and propagation; universal relationship endpoint-loss resolution and relationship lifecycle; general ordinary-removal, retirement and destruction behavior; runtime unresolved-dependency Events and resolution workflows; static/runtime cycle detection, pause and authorized review; broad Policy composition/conflict evaluation; provider-independent AI proposal validation and execution; and richer causal-history reconstruction beyond the bounded evidence slices named below.

| Obligation | Current evidence boundary | |---|---| | Empty and definition-less objects; arbitrary constituents; definitions as descriptive objects | Generic object/configuration slices exist, but complete arbitrary object and definition lifecycle coverage is not verified. | | Actual graph versus intended definition; explicit, revisioned definition adoption without automatic instance migration | IDY-008 installation is bounded configuration work; definition adoption and instance migration are not evidenced as a runtime capability. | | Derived State and recursive propagation through constituents and relationships | Addressable State definitions and bounded transition history are evidenced; general derived-state calculation, materialization and propagation are not verified. | | Multi-endpoint relationships and unresolved endpoint retention | Bounded relationship creation, integrity, cardinality and traversal are verified; universal endpoint-loss resolution and relationship retirement/deletion remain outside the verified slice. | | Ordinary data removal versus explicit retirement/destruction with retained history | The architecture specifies the distinction; the demonstrator's broader deletion, retirement and destruction behavior is not generally verified. | | Dependency classes, non-fabrication and unresolved-dependency events/resolution | Bounded workflow dependency references and execution controls exist; the full resolved/absent/unresolved/incompatible/failure behavior is not verified. | | Cycle detection, pause/escalation and finite workflow execution | The bounded interpreter limit is specified and partial workflow execution is evidenced; general causal cycle detection and human-resolution behavior are not verified. | | Author, relationship, ownership and AI output do not grant authority; human-only parity | Admission, Business isolation and selected AI-negative contracts are evidenced; broad authority coverage across all object/configuration categories remains incomplete. |

The implementation mechanism may materialize derived state, use relationship indexes, retain revisions or enforce a finite dispatcher bound, but those mechanisms remain subordinate to durable object state and the settled semantic contracts. See implementation architecture, development and the relevant architecture owners for chosen mechanisms and required checks.

Platform Governance Foundation

Status: PARTIAL / FOCUSED ADMISSION LIFECYCLE VERIFIED. Implemented evidence includes the explicit platform/business scope value object, direct-Principal platform AuthorityGrant lookup, exact platform Policy lookup with fail-closed conflict handling, scope-aware Command fingerprint inputs, the release-configured trusted business.create handler, composition-root registration and migration 0010_platform_governance_scope for nullable platform Command/Event Business scope.

The single CommandHandler admits and atomically commits the bounded platform bootstrap; the platform evidence descriptor revision permits nullable platform Command/Event Business scope without weakening the frozen IDY-005 artifact. The historical PHPUnit collection block caused by the unavailable mbstring extension has been cleared for the focused Foundation Genesis runner by loading the existing extension through the pinned PHP executable.

Principal Admission to Initial Business Evidence

Executable verification status: VERIFIED for the bounded admission lifecycle slice; broader security and deployment coverage remains incomplete. principal.register and principal.confirm are active revision 1 Operations with trusted handlers. PrincipalAdmissionService registers a pending Principal with normalized identity, Argon2id credentials and a hashed one-time confirmation challenge; confirmation activates the Principal and issues the platform onboarding grant. The target boundary routes registration, confirmation and platform commands through the existing governed Command path. CommandHandler::handleAdmission() resolves the exact Operation, validates the trusted handler, creates durable Command, Attempt, Outcome, Event and Provenance evidence, invokes the transaction-participating admission service, and owns the outer transaction. The focused integration test uses the actual TargetRuntimeCompositionRoot, Foundation-only Genesis, the platform governance/evidence vocabulary installers and isolated MariaDB state.

The canonical run on the pinned PHP 8.3.33 runtime with PHPUnit 11.5.56 was bin/run-tests.ps1 tests/Integration/PrincipalAdmissionBusinessCreationTest.php: 2 tests, 42 assertions, 0 failures, 0 errors, exit code 0. It verifies registration state and credential hashing, normalized login after confirmation, confirmation replay denial, invalid password denial, revocation of onboarding authority, server-owned initial Business/Membership/AuthorityGrant/Policy identities, settled Command/evidence linkage, command replay idempotency, payload conflict rejection and forged security-field rejection. PHP lint passed for the touched production and test files.

Genesis foundation and re-run validation remain credential-empty: a fresh Genesis run refuses a populated credential store, and an attempted Genesis re-run after admission remains rejected. Genesis revision 1 and its manifest value remain the immutable foundation anchor, while later retained revisions of the same addressable definition object are permitted during runtime evolution and reconstruction. Runtime GenesisRunner::assertCurrent() validates that anchor rather than requiring every current seed revision to remain version 1, and it tolerates legitimate post-Genesis admission credentials. Focused regression coverage verifies credential tolerance, governance descriptor evolution and Genesis-anchor protection.

Hardening evidence was recorded separately through bin/run-tests.ps1 tests/Integration/PrincipalAdmissionHardeningTest.php: 4 tests, 40 assertions, 0 failures, 0 errors, exit code 0. It verifies expired challenges remain pending and cannot issue onboarding authority, two concurrent confirmation processes produce exactly one successful consumer and one onboarding grant, registration/confirmation failure leaves no partial admission state, and a deliberately failed platform Business bootstrap rolls back the Command/evidence admission and all Business-scoped effects. The platform Command admission and Business effects now share one transaction; the existing Command mutation boundary is unchanged.

This evidence covers the JSON admission boundary and the normal governed business.create path. Target HTML registration and confirmation remain outside this slice; the bounded zero-Business onboarding view is covered below. No full-suite or production security certification is claimed.

Zero-Business HTML onboarding

Status: VERIFIED for the bounded zero-Business HTML onboarding slice. An authenticated Principal with no active Business membership now receives a first-use Create a Business form from /businesses. The form accepts only display_name and CSRF input. Its server-side HTML boundary generates the platform business.create Command envelope and invokes the existing CommandHandler with a null Business context, preserving active Operation, onboarding AuthorityGrant, platform Policy, trusted handler, idempotency, settlement, evidence and provenance checks. Browser input cannot supply Principal, Business, Membership, AuthorityGrant, Policy or Operation identity.

After settlement, the HTML boundary reads the resulting Business identity from durable settled Command evidence, validates the authenticated Principal's active Membership through BusinessContextResolver, and only then establishes the session Business context and redirects to /. Missing or non-settled evidence fails closed. Existing one-Business and multiple-Business selection remains on the /businesses and /business-context path.

Focused verification on the pinned PHP 8.3.33/PHPUnit 11.5.56 runner passed PrincipalAdmissionBusinessCreationTest.php with 5 tests, 75 assertions, 0 failures, 0 errors, 0 warnings and 0 skips. Coverage includes the zero-membership form, invalid input, CSRF rejection, forged security fields, successful server-resolved context handoff, revoked onboarding authority, and the existing governed replay/conflict and forged-Principal boundary. The existing Idy004AccessTest.php selection suite was retried twice but its fixture failed during CurrentLifecycleFixture registration before reaching selection assertions; it remains an unrelated pre-existing test-environment blocker and is not claimed as passed here.

The reported 41 editor problems on PrincipalAdmissionBusinessCreationTest.php are all dependency/editor diagnostics: one unresolved PHPUnit\Framework\TestCase type and 40 inherited PHPUnit assertion-method warnings. They are false positives from the editor not indexing the repository's PHPUnit PHAR/autoload surface; the pinned runner executes the test successfully. The workspace-wide diagnostic scan also reports unrelated PHPUnit warnings in other test files and is not evidence of admission defects. No diagnostics were suppressed.

The IDY-004 fixture now uses CurrentLifecycleFixture: after foundation-only IDY-003 Genesis and platform vocabulary installation, it admits Principals through registration, confirmation, login and governed business.create, resolving server-generated Business identity from persisted evidence. This is test infrastructure only; it does not add production provisioning, broaden business.create, restore historical Genesis state or create a generic test administrator.

The focused IDY-004 run on PHP 8.3.33/PHPUnit 11.5.56 reached 14 tests and 87 assertions, with 0 failures, 0 errors and 0 warnings, and 1 explicit skip for the deferred Policy activation/deactivation lifecycle. The supported inspection assertion now verifies the server-created Business through the existing governed /businesses identity projection, asserting its generated ID and display name; it does not treat an empty Business-Type /objects list as Business identity inspection. The history/revision and bounded object-listing fixtures now create target objects through authenticated Commands, using separate active Business-scoped mutation and inspection AuthorityGrants plus active allow Policies for the fixture Type. The Business root remains platform-scoped with business_id = null, while /objects remains limited to selected-Business-scoped objects. The malformed Principal rate-limit contract is resolved: after CSRF validation, malformed input receives source-address accounting without creating, accessing or mutating an identity bucket; canonical unknown UUIDs retain identity plus source accounting, and valid-but-unconfirmed noncanonical identities retain source-only accounting. No production authorization or mutation architecture changed.

The hardening suite does not claim broader authentication/security certification, production concurrency behavior beyond the two-process InnoDB fixture, or deployment-level rollback guarantees.

Rows below that are not covered by the bounded evidence record remain NOT BUILT in the sense defined above. Their semantic contracts are SETTLED and initial mechanisms are SPECIFIED in implementation architecture. No architecture decision is reopened by missing code or tests. The existing code is not evidence of a generic object runtime merely because it persists campaigns, JSON payloads or activity rows.

Runtime migration release correction

The canonical fresh-release migration set contains 15 unique IDs in lexical order: 0013_platform_opening.sql remains the canonical platform-opening migration, followed by 0014_retryable_confirmation_challenges.sql. The retryable migration SQL is unchanged; only its fresh-release identity changed. Existing databases may contain the historical 0013_retryable_confirmation_challenges ledger ID because that migration was previously applied under the colliding identity. MigrationRunner validates that legacy row against the unchanged retryable SQL checksum and treats it as satisfying canonical 0014 without executing the SQL again; it does not rewrite, delete or mutate the legacy ledger row. Invalid legacy checksums fail closed. Fresh databases execute and record canonical 0014 once, while platform-only databases execute it once and subsequent runs remain empty. 0013_platform_opening remains unchanged and canonical. No production database or Plesk configuration was modified.

Target provisioning and platform opening

The CLI-only target provisioning command has explicit --database=target and --database=staging selectors. Production target reads only IDY_TARGET_DB_*, requires the fixed target database identity idio2plat, and preserves the exact production safeguard. Staging additionally requires IDY_STAGING_DB_NAME to equal IDY_TARGET_DB_NAME and rejects production-looking identities. Both selectors verify the selected PDO database and refuse any existing table before mutation. They sequence reusable migrations, foundation-only Genesis and the approved Operation/Governance prerequisites without changing HTTP startup, normal Principal-bound authorization or human state. The release-bound platform opening applicator validates the release, derived Genesis digest and immutable effect mapping, applies the principal.register, principal.confirm and business.create Operations plus the platform Policy, and records identity, artifact, Genesis, mapping, effect and technical provenance evidence in the dedicated platform_opening_applications ledger. It uses no Principal, Business, Membership, credential, AuthorityGrant or persistent technical actor.

Approved opening contract

The opening release applies three Operations and one Policy. The persisted admission Operations are:

| Operation | ID | Revision | Scope | Handler | Status | | --- | --- | --- | --- | --- | --- | | principal.register | 9f4f6b8c-3d2e-4f10-8a11-223344556698 | 1 | platform | platform.principal-register | active | | principal.confirm | 9f4f6b8c-3d2e-4f10-8a11-223344556699 | 1 | platform | platform.principal-confirm | active |

The persisted business.create Operation is:

| Field | Approved value | | --- | --- | | ID | 9f4f6b8c-3d2e-4f10-8a11-223344556697 | | Name / revision | business.create / 1 | | Scope | platform | | Operation Type / revision | 9b4f6b8c-3d2e-4f10-8a11-223344556696 / 1 | | Handler | platform.business-create | | Inputs | display_name: string, required | | Targets | {} | | Context | principal_id: string, required | | Dependencies | [] | | Status | active |

The persisted platform Policy is:

| Field | Approved value | | --- | --- | | ID / name / revision | 7f3c2a91-6d84-4b27-9e53-c1a7f8402d6b / platform_business_create / 1 | | Policy Type / revision | bc1a466c-cc5f-4674-bd75-97281471a16b / 2 | | Scope / Business | platform / null | | Status / effect | active / allow | | Operations | business.create |

The immutable checked-in mapping is idy-platform-opening-effects.json: identity idy-platform-opening-effects, version 1, canonicalisation json-object-keys-recursive-v1, SHA-256 3f47a5e29e5704b9d85696ec31259d6b7e3e4a4706f9cc3cd6ea7eaed171ef43, release IDY-PLATFORM-OPENING. The digest is pinned to the canonical checked-in artifact and is not generated at provisioning time. Its effects are: verify opening artifact/digest; verify Genesis digest/run; verify Operation Type; verify Policy Type; assert all three trusted handlers/contracts; apply the principal.register, principal.confirm and business.create Operations; apply the platform Policy; and apply opening evidence. The Operation, Policy and evidence effects are durable; verification and assertion effects are non-durable gates.

The PlatformReleaseApplicationAuthority is temporary, release-bound, non-human and non-durable. It exists only in the controlled CLI provisioning context, is bound to the exact release/artifact/Genesis/mapping identity, is unavailable through HTTP, is not a Principal, credential or AuthorityGrant, cannot authorize normal runtime mutation or substitute for Principal authorization of business.create, and expires with the opening application.

Opening evidence is recorded only in platform_opening_applications, not in schema_migrations, genesis_runs, normal Command execution or IDY-008 workflow execution. The ledger binds application identity, release, artifact, Genesis, mapping, approved effect inventory, verification results, conflict/reconciliation information, technical provenance and timestamps, without a Principal dependency. APPLIED is the successful state; a repeat of the exact application durably transitions to ALREADY_CURRENT after reconciling every approved Operation/Policy effect; a safely established mismatch durably records CONFLICT; an incomplete or uncertain existing record durably transitions from the transient NEW marker to RECONCILIATION_REQUIRED. The applicator never creates NEW; it is reserved for an incomplete pre-application record and is not a separate durable opening phase. No conflict or reconciliation state is converted to APPLIED, and actual Operation/Policy effects remain atomic. This reconciliation rule closes the previously permitted drift in which an APPLIED ledger row could coexist with missing principal.register and principal.confirm Objects.

Focused opening evidence: PlatformOpeningApplicatorTest passed 7 tests / 20 assertions, including exact apply, idempotent re-application and recovery of missing approved effects under an existing APPLIED ledger row. The full disposable PHPUnit suite passed 353 tests / 1,332 assertions with 0 failures and 0 errors; it reported 5 existing warnings, 2 PHPUnit deprecations and 1 skipped test. The CLI selector gate passed for missing and non-target selectors; foundation and Genesis regressions remain covered by the full suite. These checks used only the disposable local IDY_TEST_* database where a database was required. No target provisioning command was run and no production database or deployment configuration was touched.

Fresh disposable provisioning validation

The test-only fresh disposable provisioning harness creates a unique IDY_TEST_E2E_<32 uppercase hex characters> database for each run using the protected local MariaDB operator configuration, grants only the configured test application user access, exports IDY_TEST_DB_*, and invokes disposable-provisioning-e2e.php. The PHP harness requires the exact generated identity, verifies SELECT DATABASE(), rejects the production identity and non-test names, refuses any pre-existing table, and uses no credentials in arguments or output. Cleanup drops only the exact generated identity after revalidation; -KeepDatabase is an explicit diagnostic retention option.

The validated command is:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File bin/run-disposable-provisioning-e2e.ps1

It exercises the same reusable components as the controlled target path in this order: EMPTY -> MIGRATED (all 15 checked-in migrations through 0014_retryable_confirmation_challenges, ledger and checksums) -> GENESIS_COMPLETE (IDY-003 foundation-only state and no human state) -> PLATFORM_OPENING_READY -> PLATFORM_OPENED APPLIED (approved artifact, mapping digest, three Operations, Policy, trusted handlers, and eleven-effect evidence) -> VOCABULARY_READY (Platform, Evidence and Governance descriptors required by the current target composition) -> RUNTIME_READY. Runtime composition is then checked through /health; it does not run migrations, Genesis or platform opening.

After provisioning, the harness uses the real TargetRuntimeCompositionRoot and boundary for Principal registration, confirmation, authentication and governed business.create. It verifies the three Operations and trusted handler paths before exercising the genuinely fresh registration lifecycle, then verifies Business/Membership/Business AuthorityGrant/Policy effects and Command/action/attempt/outcome/provenance/event evidence. It does not seed or create Principal, credential, Business, Membership, AuthorityGrant, Policy or continuing human authority during provisioning. The current disposable run reached the canonical 15-migration ledger and runtime provisioning checks, then stopped at the existing Principal confirmation or bounded onboarding authority failed assertion before IDY-008 and demonstrator initialization; the disposable database was cleaned. This is not initializer evidence and does not alter the separate production command bin/provision-target.php --database=target, its fixed idio2plat identity, or production environment/configuration.

Status: MIGRATION COMPATIBILITY VERIFIED LOCALLY; FULL DISPOSABLE PROVISIONING BLOCKED AFTER MIGRATION. The legacy 0013_retryable_confirmation_challenges compatibility path passed the focused database-backed test with 1 test and 6 assertions, covering unchanged legacy evidence, no re-execution and second-run emptiness. Invalid-checksum and both-ID compatibility cases require a separate isolated database fixture because MariaDB DDL in the runner commits the surrounding transaction; they are not claimed here. The later onboarding blocker prevents claiming platform-opening or initializer verification from the current disposable run. Production remains blocked pending separate target deployment, operator authorization, live backup/restore and hosting verification.

IDY-001 to IDY-009 Contract-Freeze Disposition

| Stage | Current disposition | Boundary | | --- | --- | --- | | IDY-001 | CLOSED / FROZEN | Repository isolation and target-boundary evidence remains valid. | | IDY-002 | DOCUMENTATION AMENDMENT | Foundation/runtime prerequisite wording is clarified; no application behavior is claimed. | | IDY-003 | FOUNDATION CONFORMANCE SLICE VERIFIED | Foundation-only Genesis artifact integrity, foundation-only seed checks, fresh-store refusal and existing idempotence/integrity evidence are implemented; the prior human-bootstrap path remains superseded. | | IDY-004 | CLOSED / CURRENT LIFECYCLE VERIFIED | The focused result is 14 tests / 87 assertions: 13 passed, 1 intentional skip and 0 failures. Current registration, confirmation, authentication, governed Business creation, Business inspection authorization, governed history/revision, bounded object listing, freshness invalidation and cross-Business context isolation are covered by the modernized focused fixture. The malformed-principal source-accounting contract is resolved and verified. The inactive Policy activation/deactivation lifecycle remains intentionally deferred. | | IDY-005 | CLOSED / FROZEN BOUNDARY | Governed mutation, Command, evidence and commit semantics remain the shared mutation boundary; admission operations do not weaken it. | | IDY-006 | CLOSED / FROZEN | The bounded Graph + generic UI contract is complete. 006A graph evidence passed 13 tests / 108 assertions; 006B presentation evidence passed 12 tests / 68 assertions; and the authenticated 006B HTTP acceptance passed 139/139 checks, with 0 failures, 0 skips, 0 runtime diagnostics and clean server shutdown. The human-without-SQL exit criterion is satisfied: the journey authenticates, selects Business context, inspects authorized objects and relationships, uses a declared transition form, submits a governed Command and inspects resulting Command/evidence output. Presentation tests confirm delegation through the existing CommandHandler; authorization, cross-Business isolation and denied-field non-disclosure remain enforced. | | IDY-006A | CLOSED / FROZEN | Relationship creation, indexing, integrity, cardinality and authorized traversal are implemented and verified. Focused graph evidence: 13 tests / 108 assertions, 0 failures, 0 errors, 0 risky and 0 skipped. Universal relationship retirement/end/update/supersession/deletion remains deferred and is not an IDY-006 closure requirement. | | IDY-006B | CLOSED / FROZEN | Generic View/Form definitions and server-rendered projection are implemented and verified. Focused presentation evidence: 12 tests / 68 assertions. The independent HTTP acceptance passed 139/139 checks, with 0 failures, 0 skips, 0 runtime diagnostics and clean server shutdown. The former 07c relationship-ID assertion was a test-contract mismatch: HTML exposes the authorized endpoint label, endpoint ID and direction, while the machine-readable projection retains the addressable relationship ID. Authorized relationship endpoint labels now link to the canonical /objects/{objectId} route; object identity remains objects.id, and resolution continues through the existing authorized object reader and Business context. | | IDY-007A | CLOSED / FROZEN | Workflow vocabulary and Node binding remain unchanged. | | IDY-007B | STATUS RECONCILIATION ONLY | Existing admission evidence remains Business/workflow-scoped; registration and confirmation are not workflow expansion. | | IDY-007C | PARTIAL / VERIFIED | The bounded governed dispatch lease and five-target finalization path is implemented through the Business-owned workflow_dispatch Operation, exact Operation resolution, OperationInvocationService, CommandHandler, Authority/Policy checks, expected-version and conditional resource-claim fencing, fixed dispatch participation and generic Command/Attempt/Outcome evidence. IDY-007 verification passed 58 tests / 231 assertions, including 19 finalization tests / 98 assertions; stale/expired/wrong-worker/wrong-token rejection, rollback, idempotency and one-winner concurrency are covered. A post-commit Event hook now invokes the bounded runner, which admits matching Workflows, claims leases, steps the interpreter and reloads persisted status. Waiting wake, expired-lease reclamation, richer reconciliation/recovery and database-backed end-to-end verification remain deferred/unverified. | | IDY-008 | PARTIAL / FOCUSED GENERIC INSTALLER VERIFIED | Reusable Business-scoped configuration requires an existing governed Business; it does not install platform opening, identity lifecycle, Business identity or authority prerequisites. Release identity/digest is Business-independent while runtime declarations, Commands and provenance bind to the authenticated Business. | | IDY-009 | COMPLETE / BOUNDED HTTP DEMONSTRATOR VERIFIED | The generic Business-scoped Enquiry -> Qualification -> Decision -> Project demonstrator passes the retained dedicated HTTP artifact at var/http-acceptance/idy009-result.json: 53 checks passed, 0 failed, with no runtime diagnostics and clean server shutdown. Focused installer, Enquiry, Qualification/Decision/Project integration and IDY-006B HTTP regression checks also pass. No Spearmint Business, Principal, Membership or Authority identity is created or seeded; the demonstrator artifact remains test-trusted only and no production trusted release exists. | | IDY-010 | CLOSED / BOUNDED SURFACE UI VERIFIED | IDY-010 implementation is closed at its bounded authoritative scope. The existing generic server-rendered Business surface provides a readable authenticated shell, server-resolved Business context, generic Enquiry and Qualification View Definitions, authorized object reads through AuthorizedObjectReader, and declared Operation forms. Enquiry list/detail and Qualification list use PresentationCatalog/PresentationProjector; Operations remain resolved through OperationInvocationService and mutations through CommandHandler, with AuthorityGrant/Policy checks, expected-version protection and governed Command/evidence preserved. The Enquiry -> Qualification read/result loop is implemented. The canonical idy010 HTTP acceptance artifact records 69/69 HTTP acceptance ÔÇö PASS, with zero failures, zero runtime diagnostics and clean shutdown. The earlier 51/51 result is historical/intermediate evidence. This verifies the bounded Surface UI increment only; the Surface is intentionally not a finished/full product UI, and broader capabilities remain future/refinement work rather than unresolved IDY-010 defects. |

IDY-001 -> IDY-009 remain frozen/current contractual territory. IDY-010 is established as the next major stage, but no UI functionality is claimed merely because underlying runtime or legacy UI capability exists. IDY-011+ are provisional future stages only; no future stage is implemented, verified or frozen here. The provisional Business Configuration Domains are open-ended capability areas, not mandatory independent modules or a fixed catalogue.

| Requirement and owner | Current evidence boundary | Required discriminating evidence | | --- | --- | --- | | Identity/Permission: identity and governance | Focused Principal admission, authentication, platform onboarding authority and initial Business governance are verified; broader permissions remain unverified | Cross-Business isolation, object/type/relationship permissions and governed action checks | | Object/Data: objects and types | Old domain persistence is not universal type/address implementation | Valid/invalid typed values across every persistent/addressable category, addressable type definitions and permitted nested scalars | | Relationship: business model | Foreign keys in old tables do not establish the shared relationship contract | Addressable relationships, endpoint integrity and cross-capability reuse | | Business DNA and semantics: business model, semantics | Brand fields and campaign settings are not a business-model runtime | Inspectable/configurable business representation in the same model, with approved rule/policy/constraint/goal/decision meanings | | Event: time and events | Old activity feed is not a general Event Engine | Recorded/effective-time and causal/provenance behavior; explain why an action occurred | | Workflow: workflows and automation | Saved editor actions and workflow badges are not executable workflow definitions | Deterministic definition/node execution, version binding, approval, transitions and outcomes | | Knowledge: knowledge | Visible textareas/files do not establish knowledge authority or retrieval | Knowledge outside ordinary properties, related objects, source/provenance and historically identifiable changes | | Retrieval: retrieval | Old scoped SQL queries are not the platform retrieval contract | Structural narrowing by type/relationships/state/time/permissions; optional constrained semantic retrieval | | Content: views and content | WordPress markup and logo uploads are limited adapter/UI assets | Shared content/media references, authorized edits and lifecycle/history behavior | | View/UI: views and content | Hard-coded templates, not model-generated applications | Editable view/form/navigation definitions rendered against the same authorized model | | Communication: communication and integrations | Activity previews do not establish messaging or notification delivery | Distinct messages/delivery state, authorization, failures and traceable outcomes | | Integration: communication and integrations | Concrete WordPress calls only, not a provider-neutral core contract | Per-connection supported operations, normalized tools, safe failures and secret boundaries | | Analytics: analytics and evolution | Analytics page is a placeholder | Reproducible historical measures, scoped retrieval and explained results | | Automation/Scheduling: workflows and automation | No general scheduler/worker; active flags do not execute work | Approved trigger/schedule/job distinction, retries, concurrency, cancellation, timezones and missed-run behavior | | AI/Intelligence: AI | Optional Groq generation is an adapter-specific example only | Controlled retrieval, validated proposals and authorized execution; core works with AI absent or unavailable | | Evolution/Optimisation: analytics and evolution | No observation-to-improvement loop evidenced | Observation, suggestion, review, approved change and measurement with provenance | | Cross-capability demonstrator: composition and extensibility | Disconnected old screens do not prove model reuse | A new useful capability assembled from shared types/relationships/workflows/views without bespoke foundations |

The fourteen engine responsibilities need not map to fourteen services; retrieval and shared-model acceptance cut across them. Required checks and no-AI/security negatives are detailed in development. The first demonstrator is the generic Business-scoped Enquiry -> Qualification -> Decision -> Project sequence. Historical Spearmint Design references are product provenance only and are not an IDY-009 platform, Business or runtime dependency. Broader product scenarios do not expand that milestone into a generic CRM.

First Milestone Evidence

| Area | Chosen mechanism | Current implementation status | |---|---|---| | Runtime/store | PHP 8.3.33 modular monolith; shared typed objects and retained revisions in MariaDB 10.5.26/InnoDB | Historical IDY-003 generic-store evidence is retained, but the human-bootstrap Genesis path is superseded; foundation-only Genesis and platform opening are NOT BUILT. IDY-005 governed mutation/history slice implemented and validated; IDY-006A/006B and IDY-007A/007B/007C bounded slices validated by the recorded canonical evidence | | Identity/Business/authority | Server sessions, explicit membership/grants and governed Policy evaluator | Bounded registration, confirmation, authentication, membership, Business context and business.create are implemented and focused-verified; broader policy/delegation/security coverage remains incomplete | | Commands and commit | Stable unique Command identity; explicit Action Execution/Attempts; expected-version writes; coherent state/history transaction | IDY-005 bounded mutation/history slice validated; generic participating transaction/evidence correction is verified separately below | | Recovery/distribution | Durable claims and execution state; reconciliation for unknown effects; shared process-independent mutation contract | SOURCE IMPLEMENTED; database-backed and authenticated-STAGING verification pending | | UI/login | Model-driven authorised object list/detail/forms and Command/result inspection | IDY-010 bounded foundation implemented and HTTP-verified; generic object list/detail provides readable declared fields, Type/state context and authorized relationship endpoint labels, and configured Operations provide declared-input and existing-target projections. Full Surface UI remains unbuilt | | Genesis | Foundation-only versioned CLI manifest with technical installation provenance; no human/customer runtime state | Foundation-only Genesis conformance hardening is implemented; the deterministic platform-opening release artifact is verified (2 focused tests / 4 assertions). Principal admission, authentication and ordinary business.create are implemented and verified only in the bounded lifecycle evidence above; broader runtime coverage remains open. Previous human Principal/credential/Idiosyncrasy Business Genesis evidence is superseded historical implementation evidence and is non-conforming to the frozen contract. | | Generic demonstrator process | Enquiry -> Qualification -> Project/Scoping first, preserving the full intended delivery lifecycle | Bounded Operation handlers, Business-scoped configuration fixture, governed effects and target affordances are implemented; the bounded four-stage HTTP acceptance is verified; production release artifact and deployment remain outstanding | | Runtime invariant suite | PHPUnit plus isolated InnoDB race/failure fixtures and fake external adapter | Canonical baseline: PHP 8.3.33, PHPUnit 11.5.56, 187 tests / 895 assertions, 0 failures, 0 errors, 0 risky, 0 skipped; broader workflow recovery remains NOT BUILT |

Bounded Implementation Closure Evidence

Evidence recorded 2026-09-16 against the canonical isolated runtime and .\bin\run-tests.ps1:

| Slice | Status and evidence | | --- | --- | | IDY-005 governed mutation/history | PARTIAL / VERIFIED for the implemented bounded mutation, authorization, expected-version, rollback, relationship-effect, Event/evidence settlement and reconciliation slice: 48 tests / 191 assertions PASS. This does not claim the wider platform mutation or first-milestone acceptance is complete. | | IDY-006A relationship graph | CLOSED / VERIFIED for the bounded Relationship Type, relationship object/index/slot, endpoint integrity, cardinality and authorized traversal slice: 13 tests / 108 assertions, 0 failures, 0 errors, 0 risky and 0 skipped. Universal relationship retirement/end/update/supersession/deletion remains deferred outside this frozen slice. | | IDY-006B generic presentation | CLOSED / VERIFIED for the bounded presentation vocabulary, authorized generic projection and governed human journey: 12 tests / 68 assertions, plus 139/139 HTTP acceptance checks, 0 failures, 0 skips, 0 runtime diagnostics and clean server shutdown. The IDY-010 presentation increments add readable declared values, object detail state context, authorized relationship endpoint labels and a generic Operation input descriptor; they remain separate from the IDY-006 contract and do not make the richer Surface UI part of IDY-006. | | IDY-006 combined Graph + generic UI | CLOSED / FROZEN | The authenticated HTTP journey demonstrates authentication, Business selection, authorized inspection, declared transition form, governed Command submission and resulting Command/evidence inspection without direct SQL. Presentation tests establish delegation through the existing CommandHandler; no production PHP change was required for closure. IDY-010 remains the later richer Surface UI/product-learning loop. | | IDY-007A workflow vocabulary | PARTIAL / VERIFIED for the implemented manifest-bound workflow vocabulary installation and validation slice through recorded focused evidence; the current full configured PHPUnit result remains UNKNOWN. | | IDY-007B workflow admission | PARTIAL / VERIFIED for the implemented workflow admission, execution identity, dispatch admission and authority-binding prerequisite slice through recorded focused evidence; the current full configured PHPUnit result remains UNKNOWN. | | IDY-007C bounded lease/finalization | PARTIAL / VERIFIED for the implemented governed dispatch lease, five-target finalization, fencing, authorization, current composition and generic evidence boundary: IDY-007 focused regression evidence passed with 58 tests / 231 assertions, including 19 finalization tests / 98 assertions. Claim, release, all five targets, stale/expired/wrong-worker/wrong-token rejection, rollback, idempotency and one-winner concurrency are covered. Waiting wake, expired-lease reclamation and richer reconciliation remain deferred. | | Generic conditional commit prerequisite | VERIFIED as a platform extension: an optional typed, allowlisted resource-claim predicate flows through Operation plans and Commands into the generic repository's atomic expected-version update condition; satisfied, stale, mismatched, expired and missing claims reject durably, while unguarded updates remain unchanged. Focused evidence: 48 tests / 191 assertions PASS in the IDY-005 mutation suite. IDY-007 dispatch now consumes this predicate through the governed Operation and CommandHandler path. | | Generic transaction/evidence participation | VERIFIED for the generic CommandHandler and SecurityAuditWriter contract: participating success, outer rollback/retry, authority and Policy rejection, conditional-claim rejection, unknown/reconciliation settlement and audit rollback preserve outer transaction ownership. Focused evidence: 9 tests / 43 assertions PASS; adjacent OperationInvocation/ConditionalCommit/Idy005 filter: 60 tests / 267 assertions PASS. | | IDY-007 Slice 1 sequential execution | PARTIAL / IMPLEMENTED, focused verification pending for the newly assembly-wired condition/end interpreter and exact Logic Definition reference path. The implementation supports the approved five finalization targets through Business-owned Operations installed by the configuration boundary. General workflow recovery, wake processing, retry/replay, scheduling and external-effect execution remain outside this slice. |

Historical full-suite evidence recorded before the current IDY-010 increment used PHP 8.3.33 and PHPUnit 11.5.56: 349 tests, 1,324 assertions, 0 failures, 0 errors, 5 warnings, 2 PHPUnit deprecations and 1 skipped test. It is not the current full-suite result. Focused evidence also passed for IDY-007 (58 tests / 231 assertions), IDY-005 (48 tests / 191 assertions), Operation invocation (12 tests / 76 assertions) and IDY-008 (25 tests / 121 assertions). The five-target finalization implementation uses the trusted workflow Operation composition, generic CommandHandler conditional commit and fixed dispatch participant; no direct semantic repository writer was added.

These results do not establish implementation of a general workflow interpreter, broader workflow recovery/retry/replay, scheduler or queue, external integrations, AI execution, public intake, workflow editor or completed UI. The IDY-007 Slice 1 interpreter intentionally executes only literal/equals condition nodes and end nodes through the existing governed lease/finalization boundaries. IDY-008 remains a focused implementation slice pending its approved release artifact and production trusted-release registration.

IDY-008 Task 3 Closure Evidence

Lifecycle and release boundary reconciliation

The authoritative lifecycle is:

Genesis -> platform opening -> Principal registration -> confirmation
-> authentication -> governed business.create -> existing Business
-> IDY-008 Business configuration -> normal governed operational activity

Genesis and platform opening create only generic platform foundations and capabilities. Principal admission is a runtime operation. business.create is a separate governed runtime operation that creates a Business and its initial governance. The demonstrator runs against an existing Business; no Spearmint Design Business exists and it is not a Genesis seed, platform-opening entity, IDY-008 bootstrap object or production special case.

IDY-008 is a governed installer for trusted, versioned, reusable Business-scoped configuration. It may create or update Business-owned Types, States, Transitions, Relationship Types, classifications, terminology, domain Policies, Workflow Definitions/Nodes, View/Form Definitions and approved configuration relationships through the existing Command boundary. It must not create a Principal, credential, confirmation/authentication state, Business, Membership, AuthorityGrant, platform authority or operational records such as People, Organisations, Enquiries, Qualifications or Projects. The separate generic Business initialization phase may subsequently create the approved initial operational objects through the installed governed Operations.

The database/configuration/idy-008/demonstrator.json file is the reusable demonstrator configuration release. Its canonical digest is registered by Idy008CliCompositionRoot for the normal authenticated CLI installer. It remains configuration-only: it does not contain operational Enquiry, Qualification, Decision or Project instances, and no operational data is created by configuration installation.

Deliberately unchanged release and deployment boundaries

The following boundaries remain explicit after the generic installer implementation:

These are later implementation and, where necessary, contract-enforcement tasks. They are not evidence that Spearmint has been provisioned and are not changed by this reconciliation.

Implementation status: IMPLEMENTED / CONFIGURATION INSTALLER ENABLED; OPERATIONAL PROVISIONING NOT CLAIMED

The generic IDY-008 path and focused governed installer are implemented, including the checked-in demonstrator release registration. The active contract keeps operational records outside the configuration manifest. The generic initializer supplies bounded runtime inputs and invokes the installed Operations; it does not introduce a manifest seed format or arbitrary production data artifact.

The following bounded requirements are implemented and focused-tested:

Focused evidence on 2026-09-18 used PHP 8.3.33, PHPUnit 11.5.56 and the isolated MariaDB test environment. Idy008InstallerTest.php passed 12 tests / 68 assertions. The adjacent ConfigurationReleaseVerifierTest.php and Idy008AAccessTest.php run passed 16 tests / 45 assertions. Combined focused evidence is 28 tests / 113 assertions, with zero failures and zero errors. It covers canonical digest verification, reusable release installation into two Businesses with the same digest and distinct Business-scoped runtime object/Command identities, same-release endpoint scoping, idempotency, drift/conflict, durable unknown/rejected evidence, pre-mutation rejection, forged target fields, identity/authority/operational declaration rejection, server-resolved authorization and cross-Business isolation. Production files reported no editor diagnostics. The production artifact and CLI smoke path remain unverified because the approved artifact and trusted registry entry do not exist.

The implementation introduced no installer-specific reconciliation engine, recovery/retry/replay engine, new mutation boundary, authorization architecture or installer persistence aggregate. Model C remains the governing reconciliation determination: existing durable evidence is inspected and classified, unsafe continuation is refused, and no new installer recovery engine is required.

IDY-009 Create Enquiry Boundary

Implementation status: COMPLETE / BOUNDED DEMONSTRATOR VERIFIED

The first IDY-009 slice adds the fixed create_enquiry handler and Enquiry Type descriptor vocabulary. It accepts source, summary, received time and an explicit unmatched: true input, then creates an Enquiry in received with contact_status: unmatched and server-owned created_by identity. The handler is registered through the existing trusted Operation registry.

The operation uses the Business-scoped OperationInvocationService: exact active Operation revision, declaration-driven input validation, server-resolved Business membership, Operation ownership, trusted-handler allowlisting and Operation-level AuthorityGrant/Policy checks remain in force. The service constructs the Command envelope and delegates the Enquiry effect to the existing CommandHandler, which remains responsible for mutation authority, idempotency, atomic mutation and durable evidence settlement.

Focused handler coverage was added for the unmatched plan and rejection of contact-bearing input. The canonical focused run on 2026-09-18 used PHP 8.3.33, PHPUnit 11.5.56 and bin/run-tests.ps1 tests/Unit/CreateEnquiryOperationHandlerTest.php: 2 tests, 8 assertions, 0 failures, 0 errors, no warnings/risky/skipped tests reported, exit code 0. The unit surface directly exercises the actual trusted CreateEnquiryOperationHandler and proves explicit unmatched: true, received state, unmatched contact status, Enquiry Type selection, server-provided created_by, and rejection of contact-bearing input.

This unit result is intentionally not broader evidence: it does not create a Business, resolve Membership, evaluate AuthorityGrant/Policy, invoke the trusted registry, persist a Command or Enquiry, or prove Command/evidence settlement. Those prerequisites belong to the surrounding Business-scoped OperationInvocationService and CommandHandler path. The unit passes context values directly because the handler contract receives server-resolved context; it does not bypass or replace the surrounding authorization boundary. The test has no database lookup, so it cannot accidentally match Genesis data. Contact-bearing input remains rejected by the handler itself; removing that guard would fail the second test.

Invocation-level integration evidence was then added with the legitimate Idy006BFixture Principal/Business/Membership path, an exact active Business-scoped Operation revision, the trusted handler registry, and explicit operation/mutation AuthorityGrant and Policy entries. The focused canonical run on 2026-09-18 used bin/run-tests.ps1 tests/Integration/CreateEnquiryOperationInvocationTest.php: 3 tests, 34 assertions, 0 failures, 0 errors, no warnings/risky/skipped tests reported, exit code 0. The successful invocation asserts settled Command and Outcome records, exact Command-effect-to-Enquiry identity linkage, Enquiry Type and revision, Business ownership, source/summary/received time, unmatched received state, and persisted Enquiry created_by equal to the server-resolved fixture Principal. The test also checks Command-linked Enquiry revision provenance, but does not independently assert the durable Provenance object's own principal_id or business_id. Guard sensitivity is covered by denial without Command creation when Operation authority is absent, and settled rejected Command evidence with no Enquiry when final mutation authority is absent. This proves the bounded explicit-unmatched invocation/persistence slice only; contact resolution, the remaining Spearmint operations and broader workflow behavior remain unverified.

The remaining three approved operations are now implemented through the same Business-scoped OperationInvocationService and trusted handler registry. The bounded integration fixture declares the Enquiry, Qualification, Decision and Project Types, required States, Transition Definitions, Relationships, active Operation Contracts and explicit AuthorityGrant/Policy objects through the existing generic object/configuration mechanisms; it is test configuration only and is not a production release artifact.

Focused IDY-009 evidence on 2026-09-18 used PHP 8.3.33, PHPUnit 11.5.56 and the isolated MariaDB test environment: DemonstratorQualificationOperationInvocationTest.php passed 9 tests / 42 assertions / 0 failures / 0 errors. It covers successful Qualification submission with create + relationship + transition effects, durable Command/Outcome/Provenance/Event evidence, invalid input and state, stale expected versions, reviewer/submitter separation, positive-decision Project gating, duplicate prevention, cross-Business denial, replay/conflict behavior, rollback and standalone transition declaration availability.

The target surface now exposes authenticated Business context, authorized object lists/details, history, relationships, graph and Command evidence, plus a generic Business Operation form and JSON/HTML invocation routes. Operation mutations pass through OperationInvocationService and then the governed Command/effect path; CSRF, membership, exact Operation revision, authorization and durable evidence remain server-owned. The dedicated IDY-009 HTTP acceptance proves the complete bounded Enquiry -> Qualification -> Decision -> Project sequence through that surface, including the distinct reviewer and final Project effects. The surface is intentionally bounded and does not provide public intake, AI execution or later lifecycle stages.

The established HTTP acceptance command bin/run-http-acceptance.ps1 -Suite idy006b was rerun on 2026-09-18 after correcting the stale 07c expectation. The suite passed 139/139 checks, with 0 failures, 0 skips, 0 runtime diagnostics, clean server shutdown and exit code 0. 07c now verifies the established authorized HTML projection by asserting the endpoint label; the adjacent checks retain endpoint identity, outgoing direction, cross-Business non-disclosure and secret-field exclusion. The relationship ID remains covered through the machine-readable relationship projection and focused graph evidence; no production relationship-ID rendering was introduced. Together with the focused 006A and 006B presentation results and the authenticated human-without-SQL journey, this is the final bounded IDY-006 acceptance evidence. The dedicated command bin/run-http-acceptance.ps1 -Suite idy009 produced the independently retained var/http-acceptance/idy009-result.json: 53 checks passed, 0 failed, 0 runtime diagnostics, clean server shutdown, exit code 0. It proves the complete bounded Enquiry -> Qualification -> Decision -> Project sequence through normal authenticated HTML operations, including distinct reviewer execution and settled Command evidence for each operation. The acceptance is limited to the disposable test-trusted demonstrator artifact; it does not establish a production trusted release or deployment.

IDY-008 Focused Verification Evidence

Executable verification status: VERIFIED for the focused repair; broader evidence remains limited

The focused PHPUnit command was executed with the pinned PHP 8.3.33 runtime and PHPUnit 11.5.56 through the direct invocation path. The Type-of-Type validator now uses descriptor validation, installer command/evidence classification accepts the canonical persisted JsonObject representation, and Presentation Type resolution normalizes nested stored objects without weakening fail-closed handling. Focused results on 2026-09-17 were: TypeDescriptorValidatorTest 15 tests/21 assertions, Idy008InstallerTest 9/36, Idy006BPresentationTest 10/65, GenericStoreAndGenesisTest 19/44, BusinessCreationOperationHandlerTest 2/13 and Idy008AAccessTest 11/40; all passed with zero failures and zero errors. The canonical PowerShell runner remains unavailable because its Start-Process argument list contains a null element:

This is not a test pass and is not described as a test failure. The full configured PHPUnit result is UNKNOWN ÔÇö the full configured PHPUnit run was previously stopped before producing a final summary. The mbstring limitation is an independent environment verification task and does not reopen IDY-008 implementation.

Approved production Spearmint manifest content, trusted production release ID/digest configuration, the production trust registry, the target Business, required Membership/AuthorityGrant/Policy and required platform prerequisites remain deployment/release prerequisites, not IDY-008 Task 3 implementation defects. No production release artifact is invented by this status entry.

IDY-003 evidence recorded 2026-09-13 (superseded): the frozen database/genesis/idy-003.json manifest was verified at 6217 canonical UTF-8 bytes with SHA-256 7edab9d7dad935ae9ea0ba81d78968ea6b6f75b5f87e99ea89f9f48e792c6908. Two historical evidence records report 26 tests/63 assertions and 30 tests/73 assertions; the later record includes Genesis Occurrence revision/timestamp integrity. Both describe the previous human-bootstrap implementation and therefore do not establish conformance to the now-frozen Foundation-only Genesis contract. The underlying generic-store and idempotency evidence remains historical. Its older conclusion that foundation-only Genesis, platform opening, registration, confirmation/onboarding and ordinary business.create remain NOT BUILT is superseded by the current evidence matrix above; foundation-only Genesis and platform-opening status remain separately bounded by their named evidence.

The milestone is authenticated entry into an authorised Business, addressable object inspection and a governed state change through Command -> Validation -> Authority/Policy -> Commit, with addressable state transition and provenance/history. Runtime conformance is not established until the specified tests pass.

Test Execution Infrastructure Evidence

Status: FOCUSED OPERATION INVOCATION VERIFIED; BROADER PLATFORM UNVERIFIED

Superseded historical analysis: The full-suite reset remediation on 2026-09-18 centralized WorkflowDefinitionValidatorTest, Idy004AccessTest, Idy007CFinalizationTest, principal-admission hardening setup and the HTTP FixtureInstaller on TestDatabaseContext::resetFoundation(). That helper deletes current FK children, including principal_confirmation_challenges before principal_identities and both before objects, while retaining FK enforcement. The embedded IDY-007C worker callers were also updated to pass the existing PDO to the current two-argument PrincipalRepository constructor; production composition roots were not changed. An earlier focused IDY-004 checkpoint reached six historical authentication/business-context fixture failures plus the separate malformed-input rate-limit contract boundary; its missing IDY-005 vocabulary prerequisite was corrected by installing the authoritative platform vocabulary. The complete PHPUnit suite was then recorded as non-green for those seven historical IDY-004 failures, with no FK-reset or stale-constructor errors returning. Subsequent work resolved the malformed-input boundary; the final IDY-004 evidence and current disposition are recorded above.

The pinned PHP 8.3.33 executable was confirmed to launch through the existing VS Code task. Captured probes showed that bin/run-tests.ps1 passed the space-containing PHPUnit PHAR path through Start-Process -ArgumentList, which split the path at F:\- and prevented PHPUnit from opening. The runner also passed a duplicate -dextension=mbstring; the pinned runtime already loads mbstring, and PowerShell treated the resulting native warning as a terminating error under its strict error policy.

The smallest infrastructure correction replaced that process launch with the PowerShell call operator while retaining separate temporary stdout/stderr capture and PHPUnit exit-code propagation, and removed the redundant extension flag. The disposable diagnostic wrapper and temporary tasks were removed after verification.

The first genuine focused result was 69 tests, 1 failure, 9 errors, exit code 1. Investigation confirmed the fixture gap and command-ID collision were test defects. Installing the established Idy006BFixture::installIdentity() Principal/Business/Membership fixture left operation-specific grants and policies explicit, and replacing the rejected-command ID with reserved UUID 75000000-0000-4000-8000-000000000016 preserved the ÔÇ£no Command was createdÔÇØ assertion without colliding with Genesis or other fixture addresses.

The corrected focused result, obtained through bin/run-tests.ps1 tests/Integration/OperationFoundationTest.php on 2026-09-18 with PHP 8.3.33, PHPUnit 11.5.56 and isolated MariaDB 10.5.26/InnoDB, is 69 tests, 126 assertions, 0 failures, 0 errors, with no warnings, risky tests or skipped tests reported, exit code 0. The run exposed and corrected two genuine production defects at the Operation Invocation boundary: nested persisted JsonObject operation declarations were not recursively normalized before typed validation, and Business-context/operation-authority denials were not mapped to the invocation contract's CommandException/command_denied result. No authorization rule was weakened and no alternate mutation path was introduced. A test-only visibility correction allowed the anonymous trusted-handler fixture to reference its declared type constant.

The repaired tests remain evidence-bearing rather than setup-only: active Business membership is required by the production resolver; operation-specific AuthorityGrant and Policy remain required by production authorization; the invalid typed-input case must fail before handler/Command creation; the unregistered-handler test exercises the allowlist; the isolation case uses a different Business context; and the successful invocation asserts settled Command state plus Outcome/evidence presence. Removing or bypassing those guards would make the corresponding assertions fail under the current fixture. This is focused evidence for the Business-scoped Operation Invocation Foundation and its Command/evidence delegation only, not broad platform verification. The dedicated Enquiry and downstream IDY-009 integration and HTTP acceptance evidence is recorded above. The current configured full PHPUnit run was stopped before PHPUnit produced a final summary; its result is UNKNOWN.

The test-only TestDatabaseContext now validates the bootstrapped MySQL PDO and IDY_TEST_ scope, and centralizes the repeated foundation reset list for adopted integration fixtures. This improves setup diagnostics and reduces reset-list drift without creating domain fixtures or weakening authorization tests.

Old Reuse Dispositions

These labels apply to candidate material, not completed code changes or certification.

| Disposition | Meaning | | --- | --- | | RETAIN | Preserve compatible knowledge or a visual/practice baseline, with explicit scope | | REFACTOR | Reuse may be worthwhile after boundary, security, integration or maintainability work | | REPLACE | New architecture requires a different implementation or binding | | REMOVE | Do not carry the obsolete behavior/assumption into the target; no deletion is performed by this document | | REFERENCE ONLY | Historical context or technical lesson, not a build contract |

Old Asset Inventory

The former marketing application, old controllers, views, services, repositories, assets, schema and setup utilities were retired from the workspace. Their design and implementation observations remain available in legacy implementation reference as historical, non-authoritative context only. No deleted legacy path is part of the target release or a current implementation contract.

Detailed old behavior/gaps live in legacy implementation reference; do not duplicate a full application inventory in each engine document. Reusable tokens/interactions live in UI system, mechanisms/configuration in security and operations, and backend specifics in WordPress.

Foundation View Removal and Initial Business Authority

Implementation status: PARTIAL / EVIDENCE LIMITED.

The runtime no longer uses the legacy FOUNDATION_VIEW identity or its allowed_type_ids/fields allowlist. AuthorizedObjectReader now enforces governed inspection, exact Business scope and the canonical machine projection id, type_id, type_revision, current_version, value. Relationship reading retains separate inspection and traversal authorization and relationship integrity checks. The obsolete FoundationInspection helper and hard-coded identity were retired. Genesis was not modified.

BusinessCreationOperationHandler now emits the Business, creator Membership, an allowing Business-scoped Business-Type inspection grant/policy and an allowing Business-scoped platform.install_configuration grant/policy targeting TYPE_OF_TYPE. View/Form Definitions remain presentation/configuration and are not authority sources.

TypeDescriptorValidator now recursively rejects the exact normalized credential-field names defined by the Objects and Types contract before GenericObjectRepository create/revise persistence. Ordinary substring fields remain valid. A read-only audit was attempted against the isolated object and revision stores before enabling the validator; the first audit completed without exposing values, but its detailed output exceeded the execution display limit, so complete row-level audit counts remain an evidence limitation. No remediation or data mutation was performed.

Focused PHPUnit verification uses the pinned PHP 8.3.33/PHPUnit 11.5.56 direct invocation because the canonical runner exits before PHPUnit when Start-Process receives a null argument-list element. Group-level results are the evidence boundary; no full-suite claim is made.

The focused repair evidence now includes: TypeDescriptorValidatorTest 15 tests / 21 assertions / 0 failures / 0 errors; GenericStoreAndGenesisTest 19 / 44 / 0 / 0; BusinessCreationOperationHandlerTest 2 / 13 / 0 / 0; Idy008AAccessTest 11 / 40 / 0 / 0; Idy008InstallerTest 9 / 36 / 0 / 0; and Idy006BPresentationTest 10 / 65 / 0 / 0. The remaining four IDY-006 Graph failures were caused by a fixture contradiction: the fixture described a relationship Type as hidden while granting both inspection and traversal for it. The fixture now authorizes only the visible relationship Type; production Graph code was not changed. Idy006GraphTest then passed with 13 tests / 108 assertions / 0 failures / 0 errors, including the four hidden-Type pagination, bounds, cursor, and filter cases. These are bounded direct-run results, not a full-suite verification claim.

Contract and Mechanism Dependencies

D01-D10 are settled. Canonical owners define semantics, implementation architecture chooses mechanisms, and this document records evidence. PHP/MariaDB is the chosen initial mechanism, not the logical definition of Idiosyncrasy or a migration obligation. Broader integrations, advanced scheduling, automated extraction, optional AI and the later Spearmint stages remain unbuilt; they do not block the bounded foundation or reopen architecture.

Evidence Update and Exit Gate

Promote a row to PARTIAL only when a named slice of the new canonical contract exists, not when an old analog is found. Promote a requirement to VERIFIED only with a reproducible check and its scope/limits; failed, unavailable and unrun checks remain visible. Use focused manual verification until a real suite exists, then record its actual command rather than an assumed runner. Recheck links and source coverage before old documentation removal; approval of this inventory does not authorize deletes or runtime changes. This documentation pass validates document structure and references only. It does not run setup, deploy, test live credentials or certify application behavior.

Presentation vocabulary provisioning correction — 2026-10-14

The deployed generic Business Presentation reconciler correctly reached the governed object.create Command, but STAGING settled that Command as unknown because the platform-owned Presentation Object Type was absent. The persisted Business, Dashboard, Overview and title state was unchanged. The missing Type is a target vocabulary provisioning gap, not a Business profile or authorization defect.

The correction adds PresentationVocabulary::install() to the established target provisioning runner and makes the idempotent runtime vocabulary installer available to the target release. The authenticated Business Presentation reconciliation boundary also ensures the same platform vocabulary is current before it submits tenant-scoped Object Commands. The existing staging database identity and one-Genesis preconditions remain enforced for the CLI path. This restores platform vocabulary without direct SQL or Business-data mutation. The generic Business reconciliation continues to create Dashboard and child Presentation Objects only through governed Commands.

This correction is implemented and locally package-verified at 214 release files. GitHub Actions run 38412907829 (workflow run 343) deployed commit e5778e23c019b44855afeb94eeba6c2109fb5049 successfully to STAGING as release IDY-TARGET-e825312cf382568dfe2a935b832fba2b5ec950204228ea66a8c60b5e5061f494. The staging health check returned a connected, boundary-ready target runtime.

The authenticated browser session retained the existing Principal and Business a20d5b62-078c-4ef4-b0ce-41027f9bc275 and observed / redirect to Dashboard 87c1954c-7810-445c-85dd-1bdc96a6f10f. The persisted navigation rendered Dashboard and Overview; the Overview Presentation Object 7302b84a-e3df-485c-8442-c8707334b08d resolved successfully. Before the correction, the same request returned HTTP 503 with no navigation; after the correction it rendered the Dashboard and Overview surface. The generic profile contains no demonstrator-only operational records. Direct post-repair row-level diagnostic output was not rerun after this browser verification, so the browser-visible projection is the evidence boundary for the final presentation state.

Functional Business surface increment — 2026-10-13

The next bounded increment is implemented locally but not yet deployed or authenticated-exercised on STAGING. It preserves the generic Presentation architecture and adds:

record operations explicit rather than presenting decorative controls.

The six catalogue entries without record operations remain presented but explicitly deferred; no demonstrator configuration or records are installed by the new generic profile. Local PHP runtime lint and target package verification pass with 223 files. PHPUnit dependencies and the approved database-backed test environment remain unavailable locally. STAGING deployment, capability configuration reconciliation, Business profile input, People/Projects create-edit journeys and post-reload verification remain pending the next release.

Functional Business surface STAGING verification — 2026-10-13

The capability implementation was deployed by GitHub Actions run 345 from commit f73650abec9a52b51438636b5fafedd768e09b25; the persisted record presentation-template correction was deployed by run 346 from commit 10621a42bf080fdbec39689cb03791826c550cf2, release IDY-TARGET-890a04b8332e79573505ee73284fb043b633215c95410e9d89a9dd84d46ca4ec. Both build/artifact verification and STAGING health checks succeeded.

Against the existing Business a20d5b62-078c-4ef4-b0ce-41027f9bc275, authenticated browser verification observed:

stuart@spearmintdesign.co.uk primary contact email was saved through the initialization workflow; the persisted initialization execution de65213f-c5d6-42e4-b56a-e4c8d91edbc4 is now initialized, while the optional address remains empty.

The first post-create Person redirect exposed a missing persisted record template and returned 404; no create was rolled back or duplicated. The record-template correction was then deployed and the same existing Person resolved and edited successfully. The current acceptance evidence is browser and deployed-runtime evidence; row-level post-verification diagnostics were not rerun.

The existing initialization workflow is the verified Logic/Workflow-adjacent business operation in this increment. Broader People/Projects workflow automation and Logic definitions remain deferred; the disabled top-level Workflow/Logic controls are not presented as operational proof.

Protected CLI environment loading correction — 2026-10-14

The protected bin/provision-target.php entrypoint previously called TargetRuntimeConfig::fromEnvironment() without loading the repository's existing local operator configuration. This caused a local PowerShell invocation to fail before database connection with Missing required runtime database setting: IDY_TARGET_DB_HOST, even though the operator configuration file exists.

The correction adds the allowlisted App\Runtime\Bootstrap\LocalRuntimeEnvironment loader. It loads only approved target database, staging identity, target runtime and Definition-publisher names from .env.local when those names are absent from the process environment. Explicit process variables remain authoritative. The web runtime does not load this file, no credentials are printed or persisted, and the existing staging database identity and publisher safeguards remain unchanged. The vocabulary CLI now uses the same helper.

Local validation confirmed PHP syntax, the allowlist/precedence behavior and the target package composition. The current local operator environment still fails the non-secret preflight because IDY_STAGING_DB_NAME and IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID are not present in the process configuration; protected provisioning was not executed. An approved operator must supply those existing STAGING configuration values securely before the command can proceed.

STAGING-only operational model — 2026-10-14

The current development phase now exposes the protected provisioning CLI only through --database=staging. The command uses the configured target database name as the STAGING identity when IDY_STAGING_DB_NAME is omitted, while retaining the non-production identity and selected-PDO checks. The internal generic target runtime and production identity preflight remain reusable abstractions for a future production requirement; no active production provisioning selector is exposed by the current operator command.

Routine GitHub release deployment remains application-only: it does not run provisioning, migrations, Genesis, platform opening or publisher authority installation. Publisher reconciliation remains a separate protected operation through the existing installer and browser/CLI boundaries.

Workflow and Logic surface increment — 2026-10-13

The authenticated Workflow and Logic status surfaces were added and deployed by GitHub Actions run 350 from commit 9d13c03b4dc87c91d70dcfc04d269b86134b5372, release IDY-TARGET-d683a6a2c4f521fde4fcf09cce7e4c9aad1bd98ffc69f9ff487acafc010bea29.

STAGING verification observed the existing Business initialization Workflow Definition (Business initialization, revision 1, active) and its persisted WorkflowExecution de65213f-c5d6-42e4-b56a-e4c8d91edbc4 with status succeeded and one completed step. Workflow Definition and Execution inspection is now authorized through the same governed Business authority reconciliation used by the capability surface.

The Logic surface correctly fails closed: the authenticated Principal does not have platform Definition inspection authority and no published supported Logic Definition is available in the current Business context. No Logic invocation control, fabricated result or stored-code execution is exposed. Creating and authorizing a platform Logic Definition remains the precise next dependency for a live Logic acceptance scenario. Notifications and Attentions remain disabled because their underlying contracts are not implemented.

Governed Logic publication attempt — 2026-10-13

The governed Logic publication surface is implemented and deployed. It loads the deterministic data-defined EQUAL Logic Definition fixture from minimal-project-status-logic.json, invokes the existing platform-scoped definition.publish Operation, and uses GenericLogicEvaluator for actual evaluation. It does not write Definitions directly and does not execute stored code.

The authenticated browser publication attempt returned command_denied. The existing narrow publisher-authority reconciliation route also failed closed because the current authenticated Principal is not the configured platform Definition publisher. No grant, Policy, Definition, revision or fake result was created. A platform operator must either authenticate as the configured publisher Principal or update the approved IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID configuration through the existing protected provisioning path before publication can succeed.

Consequently, live Logic evaluation and Workflow-to-Logic execution remain unverified and correctly unavailable. The precise blocker is platform publisher identity/authority configuration, not evaluator implementation.

Logic inspection authorization correction — 2026-10-14

The Logic inspection failure was caused by two inconsistent access decisions: TargetRuntimeConfig::canViewDefinitions() recognized the configured platform publisher, while TargetHtmlBoundary::canViewDefinitions() recognized only the separate inspection allowlist. The temporary same-request runtime evidence confirmed that the publisher setting was present through getenv() and matched the authenticated Principal; no hosting mismatch remained.

The correction centralizes the shared publisher-or-explicit-allowlist decision in DefinitionInspectionAccess and uses it from both runtime configuration and the HTML boundary. It does not grant access to unrelated Principals and does not imply publication or Logic execution authority. Focused three-case regression coverage was added for publisher, allowlisted and unrelated Principals.

Logic publication and evaluator verification — 2026-10-14

The deterministic Logic fixture was corrected to use the persisted Project Type as its typed subject, while retaining the canonical Definition identity c2000000-0000-4000-8000-000000000001, the Logic semantic role and the EQUAL(status, active) composition. GitHub Actions run 363, commit 632a7f64ce143e768126c22a69379dfa3cafa5c0, deployed the correction to STAGING.

The authenticated STAGING browser then published the Definition through the governed definition.publish Operation at revision 1. Evaluation through GenericLogicEvaluator returned true for the existing active Project 68ea1cdd-deaf-4859-8f4f-fa04b09f2a15 and false for the governed non-active acceptance Project 660c5111-0af2-4be5-bbbe-e03fc6678c64. These are observed runtime results, not fabricated execution records.

The Logic workspace initially had a presentation-only discovery mismatch: its published list recognized the historical definition_kind marker but not the canonical semantic_role: Logic marker. GitHub Actions run 364, commit 1dcf55b37b3433c272e1041de07f77d84018d8a7, deployed that correction. The authenticated browser now lists the published Logic Definition and continues to expose the governed evaluator. Workflow-to-Logic execution remains unverified because no Workflow Definition has yet been configured to reference this published Logic Definition.

Workflow-to-Logic integration verification — 2026-10-14

The existing Workflow contract supports a condition node whose expression is an exact logic_reference containing a Definition ID and positive revision. The bounded staging integration uses Workflow c3000000-0000-4000-8000-000000000001, revision 1, and references Logic Definition c2000000-0000-4000-8000-000000000001, revision 1. The Workflow is Business-scoped, triggered by the committed object.updated Event for the Project Type, and was persisted through the existing governed CREATE Operation path.

GitHub Actions run 384, commit 9b27a9f7acfa6fd8fad3f8ad334b5f771e5323b6, deployed the final execution-path and evidence corrections. Authenticated STAGING browser verification then observed:

WorkflowExecution 87657040-5b00-47d1-ace9-f2edbea9c0b5, status failed, one condition step, false branch, and persisted Logic evidence with the exact ID/revision.

The Project edits used the normal governed update form. The committed object.updated Event was admitted, leased, interpreted, re-evaluated by the trusted Workflow Operation boundary and finalized through the existing Workflow execution pipeline. The condition evidence records EQUAL, the subject Object ID, the boolean result and Logic Definition revision; no comparison was recomputed in the Workflow runtime.

The increment also corrected generic gaps discovered during verification: Workflow semantic validation now receives the object repository, trusted Workflow calls use Business runtime Operation identities, running-to-running steps validate the existing lease instead of attempting a new claim, and Workflow subject values are normalized to the evaluator's {id, revision, value} contract.

Earlier failed attempts remain retained as running executions because the broader recovery/reconciliation mechanism was not implemented at the time of this acceptance evidence. They were not rewritten or deleted; the two fresh executions above are the acceptance evidence. The authenticated Workflow workspace now exposes the persisted Definition and execution evidence, but it is a bounded staging configuration surface rather than a general Workflow authoring UI.

Workflow recovery and reconciliation implementation — 2026-10-14

The contract-defined bounded recovery slice is implemented in source:

target artifact.

Evidence actually obtained:

denial, conclusive safe resume and explicit linked local-Command reconciliation. These are automated local evidence, not live STAGING evidence.

The remaining live cases are unverified: same-Command browser replay, direct stale-worker/token submission, recovery denial through a second live Principal, live resume_safe, and live uncertain local-Command reconciliation. The available browser returned the Sign in surface after the latest deployment, and no second Principal or safe retained candidate was available. No direct database write, production deployment or duplicate Business/Principal/demo record was created.

The current implementation deliberately does not add a general dispatcher, wake loop, scheduled recovery worker or blind local-command replay. Those remain separate future scopes.

Core Object Presentation correction — 2026-10-14

Principal and Business persistence was already in the universal objects store; the implementation divergence was the presentation boundary. Business used a special detail page, Principal used /profile, and capability create routes rendered a separate record form.

The correction keeps one generic Object and Presentation model:

generic Command mutation boundary.

The focused generic-object and capability acceptance checks passed locally. The full PHPUnit result after this correction is recorded by the final build run; the pre-existing Presentation warning remains tracked separately.

Batch 6 — Full PHPUnit failure classification and reconciliation

Baseline evidence:

through bin/refresh-test-database-from-staging.ps1; STAGING was read-only and production was not contacted or mutated.

Failure classification and corrections:

| Failure group | Evidence and classification | Correction | | --- | --- | --- | | ExternalActionAuthorizationTest, SendEmailOperationInvocationTest, and Idy004AccessTest | Legacy fixtures supplied target_type_ids and stale Authority Grant revisions. Runtime correctly requires exact target_type_references and the current governance Type revision. Stale fixture contract. | Updated grants to governance revision 4 with exact Type references. | | Idy008AAccessTest | The fixture attempted to create current governance authority without installing the current persisted governance vocabulary. Fixture setup issue. | Installed PlatformGovernanceVocabulary before creating the grant. | | GenericStoreAndGenesisTest | Genesis/current governance installation now reaches revision 4; the assertion still expected revision 3. Stale expectation. | Updated the expected current revision to 4. | | PrincipalAdmissionHardeningTest | The expected 503 was initially 403 because the valid onboarding grant and platform policy led to a handler dependency failure: Initialization Type revisions were absent. Fail-closed runtime behavior was correct. | Installed InitializationVocabulary in the fixture; the rollback now reaches the injected event failure and returns 503. | | BusinessCreationOperationHandlerTest | Unit tests directly constructed a handler without its required repositories/resolver and asserted the retired target_type_ids/configuration-declaration contract. Stale test contract. | Added a governed disposable fixture with exact-reference dependencies and updated assertions to current exact Type references. | | Release and staging package tests | The source-defined resolver returned 228 target files and 202 staging files, while tests, workflows and current documentation still asserted 224/198. One manifest assertion also named the retired Capability projector. Release-contract drift. | Updated tests, workflow guards and current release documentation to 228/202 and the active persisted Presentation projector path. |

Targeted evidence after correction:

Presentation 37/276 with 1 warning; Dispatch Lease 10/49; Finalization 27/137; Operation Foundation 73/141; Mutation 48/191 with 1 PHPUnit deprecation; Exact Reference Resolver 14/48.

Final full-suite evidence:

fail-closed test evidence for unauthorized or unavailable governed state, not PHPUnit failures.

Verification:

occurred. The final worktree contains the preserved prior changes plus this batch's scoped fixture, release-contract and documentation updates.

Batch 7 — Test integrity and quality closure

Investigation established that the Batch 5 count of 534 and the Batch 6 count of 527 were not competing test-case/provider totals. The configured phpunit.xml suite included tests/Unit and tests/Integration but omitted tests/Runtime; explicit repository-path discovery included that directory. The seven missing methods were the three methods in DashboardPresentationTest and four methods in RenderablePresentationTest. The preserved Batch 5 output contains the Runtime grid failure, confirming that those tests were executed in the 534-test baseline. No tests were deleted, renamed or newly skipped.

The remaining notice inventory was reproduced with PHPUnit 11.5.56:

symlinks, the refreshed disposable snapshot does not contain Spearmint Design, and governed Policy activation/deactivation has not been assigned to an implemented stage.

Scoped corrections:

assert the documented size-50 class for a three-column effective span. Production rendering was not changed.

Validation was run sequentially against disposable local IDY_TEST_IDY002 with inherited IDY_TARGET_DB_* variables cleared:

| Scope | Result | | --- | --- | | Affected suites: GovernanceScope, Idy005 Mutation, Idy006B Presentation and Runtime Presentation | 98 tests, 517 assertions, 0 failures, 0 errors, 0 warnings, 0 PHPUnit deprecations | | Complete configured PHPUnit suite | 534 tests, 3,277 assertions, 0 failures, 0 errors, 0 warnings, 0 PHPUnit deprecations, 3 skipped |

The complete suite reported the same three explicit skip reasons listed above. Post-edit PHP syntax checks passed for all four changed PHP files, git diff --check passed, and the architectural compliance audit passed with zero findings across 178 scanned runtime files. A focused stale-contract search found no old DataProvider metadata, historical grid-style assertion or retired authority symbol in the changed Batch 7 files; the remaining target_type_ids occurrence is the existing generic relationship schema contract, not Authority Grant authorization. No commit, push, deployment, STAGING mutation or production mutation occurred.

Batch 9 — Release candidate evidence closure

The release scope was explicitly selected as the bounded Business-scoped Enquiry -> Qualification -> Project/Scoping demonstrator. The broader eight-capability platform, AI/provider integration, general scheduling, Stage 3D Type-revision work and production remain excluded. The live starting state was main at ac2c41d87fa4bfb21d56987da68dc2b9e8731770, with 104 worktree status entries (89 tracked modifications and 15 untracked files), no staged files, PHP 8.3.33, PHPUnit 11.5.56 and the disposable IDY_TEST_IDY002 procedure. Existing work was preserved; the three Products & Services/Stage 3D handoff documents remain outside the reviewed release source set.

The complete source reconciliation retained only changes required by the approved runtime, release, configuration, documentation and verification boundary. The reviewed staged set contains 100 paths (85 modified, 11 added, 3 deleted and 1 rename), including the eight new runtime classes required by the active app/Runtime/*/.php pattern and three exact-reference/composition regression tests. The active release/target-release.json resolved 228 public files. The separate operator-only StagingProvisioningPackage contract resolved 202 files; it was not conflated with the public package. The stale 171-file operational instructions were corrected to the verified 228-file public contract. bin/target-check.php reported a valid definition and 228 resolved files.

Sequential local evidence against disposable IDY_TEST_IDY002:

| Gate | Result | | --- | --- | | Release manifest/package/provisioning unit tests | 18 tests, 825 assertions, 0 failures, 0 errors, 1 valid skip | | Focused authorization, exact-reference, Presentation, mutation and workflow suites | 282 tests, 1,185 assertions, 0 failures, 0 errors, 1 valid skip | | Complete configured PHPUnit suite | 534 tests, 3,277 assertions, 0 failures, 0 errors, 3 valid skips | | PHP syntax checks | 84 changed/staged PHP files, 0 failures | | git diff --check | PASS | | Architectural compliance audit | 178 runtime files, 0 findings |

The three full-suite skips remain bounded and valid: Windows symlink capability, absent Spearmint Design in the disposable snapshot, and the unimplemented/unscheduled Policy activation lifecycle. Workflow exercises continued to emit the application-level fail-closed Inspection is not authorized diagnostics on STDERR; these are not PHPUnit warnings, failures or deprecations and were not suppressed. No PHPUnit warnings or deprecations were reported.

No authorized STAGING deployment or exact GitHub artifact provenance was available in this batch. Accordingly, this evidence supports a local candidate only, not a STAGING-accepted candidate or production release. STAGING acceptance, exact GitHub-bound package digest/provenance, browser acceptance, rollback evidence and production operations remain external blockers. The reviewed source is authorized for a local commit only; no push, deployment, STAGING mutation or production mutation is authorized or claimed.

Batch 10 — Push and GitHub provenance gate

The exact Batch 9 candidate was pushed only after explicit authorization. The local and remote main references now both resolve to 29fa8d83eed23bb596025c1ccd7066020b8437f7. The push was a normal non-force fast-forward from ac2c41d87fa4bfb21d56987da68dc2b9e8731770. The three excluded Products & Services/Stage 3D handoff documents remain untouched and untracked. No reset, clean, stash, amend or force-push was performed.

GitHub Actions run 39270017715 (run number 420) was created by the push. The build-target-release job completed successfully from the exact SHA; its checkout log records ref: 29fa8d83eed23bb596025c1ccd7066020b8437f7. The workflow wrote GitHub-bound provenance for repository StuMayne74/Idiosyncrasy, that commit SHA and build identity github-actions/Build target release artifact/39270017715. The build log reported the following verified public package evidence:

| Evidence | Result | | --- | --- | | Resolved public files | 228 | | Release digest | 8d934f39d10ffcf535d7863c36ebc5fb6b637bc559a87b645c03299c0ca6a285 | | Release identity | IDY-TARGET-8d934f39d10ffcf535d7863c36ebc5fb6b637bc559a87b645c03299c0ca6a285 | | GitHub artifact | idy-target-release-29fa8d83eed23bb596025c1ccd7066020b8437f7 | | Artifact ID | 12195740392 | | Uploaded ZIP SHA-256 | 4b706d84927c24d327812d547719be44639799f20348865bdad323ab47d75cde | | Artifact size | 424,742 bytes |

The build job's package verification and artifact upload therefore establish the exact GitHub artifact and its provenance. The same push workflow automatically started deploy-staging (job 118119666866) after the build; this was workflow-coupled behavior, not a separate manual deployment action. The job completed successfully and its log records the exact artifact download digest, exact repository/commit verification, STAGING_DEPLOYMENT=ACTIVATED, HTTP_VERIFICATION=PASSED path=/health, the release identity above and the same release digest. This establishes PASS for artifact deployment and the deployment helper's health check.

This is not full STAGING acceptance. No browser journey, authenticated Enquiry -> Qualification -> Project/Scoping acceptance, Business-isolation check, governed mutation/expected-version check, negative authorization or stale-reference check, workflow dispatch/finalization check, rollback exercise or post-deployment reconciliation was run in this batch. Those items remain NOT RUN or UNVERIFIED. The deployment was an automatic consequence of the authorized push, not a separately approved STAGING deployment decision; the workflow's automatic STAGING coupling is a release-control risk requiring owner review before a future push. No production deployment or production mutation was performed or authorized.

Batch 11 — STAGING acceptance preflight

The read-only preflight reconfirmed local HEAD and origin/main at 29fa8d83eed23bb596025c1ccd7066020b8437f7. The only worktree changes are the existing uncommitted Batch 10 update to this file and the three preserved, untracked Products & Services/Stage 3D handoff documents. No source, workflow or excluded document was changed in this batch.

The GitHub Actions run 39270017715 remains completed successfully for the exact deployed SHA. Its published artifact remains idy-target-release-29fa8d83eed23bb596025c1ccd7066020b8437f7, with ZIP digest 4b706d84927c24d327812d547719be44639799f20348865bdad323ab47d75cde. The deployment log records the deployed release identity IDY-TARGET-8d934f39d10ffcf535d7863c36ebc5fb6b637bc559a87b645c03299c0ca6a285, the matching release digest, and a successful target-runtime /health verification. A fresh direct workstation GET was not completed because Windows Schannel returned CRYPT_E_REVOCATION_OFFLINE; the CI deployment evidence is therefore the current verified health evidence, not a new interactive browser observation.

The existing HTTP acceptance README and runner are local-only. The PowerShell launcher requires loopback idiosyncrasy_dev configuration, provisions only disposable IDY_TEST_IDY002, sets target variables to that disposable database, and starts a local PHP server at 127.0.0.1:8081. FixtureInstaller runs migrations, resets foundation state, installs Genesis, vocabulary, demonstrator configuration and fixture identities. It is not safe to aim at STAGING and must not be reused against the deployed database.

The existing idy010 suite is the closest bounded Business-scoped browser journey. It covers authenticated Business selection, generic Presentation resolution, Enquiry creation, Qualification submission, exact revision and target rejection, cross-Business non-disclosure, CSRF, stale expected-version rejection, command evidence and no-GET-mutation. idy009 covers the complete Enquiry -> Qualification -> reviewer Decision -> Project path, but it creates persistent records. Neither suite is a STAGING-safe read-only probe, and neither provides a separate STAGING authentication/configuration boundary. The local capabilities suite is read-only after its fixture reset but is also local-only. Workflow dispatch/finalization coverage exists in Idy007CDispatchLeaseTest and Idy007CFinalizationTest as disposable database integration tests; no remote STAGING workflow endpoint is exposed by the current acceptance runner.

The deployment-control review found that .github/workflows/build-target-release.yml triggers on pushes to main; deploy-staging is conditioned directly on that push, depends on the build job, uses the staging environment and has contents: read plus actions: read. The environment declaration exists, but repository evidence does not establish that required reviewers or a deployment-branch restriction are configured; the observed Batch 10 job ran without an approval pause. The smallest proposed correction is to remove the push condition from deploy-staging and permit it only on an explicitly invoked, protected deployment workflow/job after artifact provenance is available. The staging environment must require an authorized reviewer; a later design may add an exact-SHA/artifact input if deployment of a previously built artifact rather than a same-run rebuild is required. No workflow change was made in Batch 11.

STAGING product acceptance is NOT RUN. Authenticated STAGING credentials, the approved test Business/Principal pair, a record-isolation and cleanup plan, and an owner-authorized mutation window are prerequisites. No browser journey, persistent STAGING mutation, reconciliation, cleanup or production operation was performed.

Batch 12 — Secure STAGING access readiness

The repository-only readiness review found no confirmed secure operator mechanism for browser-level STAGING acceptance. The existing protected staging GitHub Actions environment supplies deployment and infrastructure diagnostic transport through environment variables and secrets such as the STAGING SSH values and target database values. The staging-registration-diagnostic.yml workflow is explicitly read-only for remote filesystem/database metadata and performs a GET-only /register diagnostic; it does not provide a Principal login credential, approved test Business identity, browser session or product acceptance client.

The checked-in staging deployment metadata contains non-secret SSH host/user/root and an external identity-file path. It is deployment metadata, not a browser-acceptance credential store. The documented external secrets/environment mechanisms likewise do not establish that an approved STAGING Principal credential or test identity exists. IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID is a non-secret configuration binding for an existing publisher and is not acceptance authorization.

The existing HTTP acceptance runner remains intentionally local-only: its launcher requires loopback idiosyncrasy_dev, provisions/resets disposable IDY_TEST_IDY002, installs fixtures and starts 127.0.0.1:8081. Its fixture password and identifiers are test data and must not be treated as current STAGING identities. The generic HTTP client supports a supplied base URL but no approved remote configuration boundary; adding one without an owner-approved credential and identity contract would create speculative remote execution infrastructure.

Therefore the outcome is BLOCKED — OPERATOR CONFIGURATION REQUIRED. Missing or unverified prerequisites are: an authorized remote-capable client path, approved STAGING Principal credentials, the approved test Business and any reviewer identity required by the bounded journey, and operator confirmation that those values are available through a secure mechanism without entering chat or source control. No STAGING HTTP request, login, environment mutation, database operation, code change, commit or push was performed in Batch 12.

Batch 13 — Secure operator handoff and readiness verification

The authorized operator was asked to confirm readiness through the existing secure process without disclosing credentials, tokens, private keys, session cookies or secret configuration values. The operator confirmed only that the current authorization remains limited to read-only STAGING probes; it does not authorize login attempts, POST requests, mutations, cleanup, deployment or database operations.

The following prerequisites remain UNVERIFIED/BLOCKED:

The operator did not confirm those prerequisites as available. No browser session, credential test, STAGING HTTP request, database access, environment mutation, workflow change, commit or push was performed. Historical CI deployment and /health evidence remains historical deployment evidence and does not establish current operator access or product acceptance.

Batch 14 — STAGING deployment control remediation

The repository-only review reconfirmed main and origin/main at 29fa8d83eed23bb596025c1ccd7066020b8437f7, with the existing uncommitted status evidence and three excluded untracked documents preserved. Before this change, build-target-release.yml ran the build/provenance/artifact job on both push to main and workflow_dispatch, but its deploy-staging job was conditioned on every push to main. That made an ordinary push eligible for STAGING deployment.

The workflow now retains build, package, provenance and artifact publication for pushes and manual dispatches, and adds a required deploy_staging boolean input defaulting to false. deploy-staging runs only when the workflow is explicitly dispatched with that input set to true. The manual run builds and publishes the artifact for its selected exact github.sha; the deployment job downloads that same-run SHA-named artifact and retains the existing manifest, release identity, 228-file count, GitHub provenance, repository/commit and package verification before invoking the deployment helper. No arbitrary latest-artifact or cross-run selection was introduced.

The protected staging environment, existing non-overlapping concurrency group, contents: read/actions: read deployment permissions and deployment helper health verification remain in place. The build job has no secrets.* reference and no STAGING deployment secret. The existing read-only diagnostic workflow and production paths were not changed.

Verification performed without STAGING or production access:

| Check | Result | | --- | --- | | PHP syntax for changed TargetReleasePackageTest.php | PASS | | Repository-only workflow trigger/secret/provenance static validation | PASS | | git diff --check | PASS | | PHPUnit | NOT RUN — the repository bootstrap connects to and migrates the disposable test database, prohibited by this batch's no-database-operation boundary | | bash -n bin/staging-deploy.sh | NOT RUN — WSL has no installed distribution; the unchanged helper was statically checked for its required verification/health markers | | STAGING/production requests or operations | NOT RUN |

This change cannot establish GitHub Environment enforcement from repository evidence. An authorized GitHub administrator must independently configure and verify required reviewers and deployment-branch restrictions for the staging environment, and must control who can dispatch with deploy_staging=true. No commit, push, deployment or environment mutation was performed.

Batch 15 — Deployment protection verification and release gate

The local Batch 14 workflow and regression-test implementation were rechecked without network access to STAGING or production. The workflow still proves the following locally:

The focused local workflow validator passed. PHP syntax for TargetReleasePackageTest.php, editor diagnostics for the changed files and git diff --check also passed. PHPUnit was not run because its bootstrap connects to and migrates the disposable test database, which is prohibited by this batch's no-database-operation boundary. No STAGING or production request, workflow dispatch, deployment, activation or persistent mutation was performed.

Read-only GitHub Actions metadata confirmed the active workflow and the historical successful push run 39270017715 at 29fa8d83eed23bb596025c1ccd7066020b8437f7. The available Actions interface does not expose environment reviewer, deployment-branch or bypass settings. An unauthenticated read-only request to the GitHub environment endpoint returned 404 Not Found; this may represent absent access or a hidden administrative resource and does not establish that the staging environment is absent or unprotected.

The release gate is therefore BLOCKED pending authorized GitHub administrator verification. The administrator must confirm, without changing the application workflow in this batch:

1. staging has at least one required reviewer or approved equivalent. 2. Deployment branches/tags are restricted to the intended release path. 3. The users/teams allowed to dispatch the workflow are appropriate. 4. No environment bypass setting or administrator path defeats the required approval for this deployment.

The worktree remains at local and remote SHA 29fa8d83eed23bb596025c1ccd7066020b8437f7, with the existing uncommitted Batch 10–14 evidence and three excluded untracked documents preserved. No commit, push, reset, clean or stash was performed.

Batch 16 — GitHub Environment protection confirmation

The available browser session could not open the repository's GitHub Environment settings page; GitHub returned its generic Page not found response. The unauthenticated GitHub Environment API request also returned 404 Not Found. Neither response establishes that the Environment is absent or unprotected.

An authorized-administrator attestation confirmed that the GitHub staging Environment exists. The same attestation did not confirm the remaining server-side controls:

| Protection check | Result | Evidence | | --- | --- | --- | | staging Environment exists | CONFIRMED | Non-secret authorized-administrator attestation | | Required reviewers | UNVERIFIED | No administrative setting evidence supplied | | Deployment branch/tag restrictions | UNVERIFIED | No administrative setting evidence supplied | | Deployment initiation permissions | UNVERIFIED | No administrative setting evidence supplied | | Administrator/environment bypass control | UNVERIFIED | No administrative setting evidence supplied | | deploy_staging defaults false and requires explicit manual true | CONFIRMED locally | Workflow inspection and Batch 15 static validation; not server-side execution |

No reviewer identities, screenshots, credentials, tokens or configuration values were collected or recorded. No workflow dispatch, STAGING or production request, deployment, setting change, commit, push, reset, clean or stash was performed.

The release gate remains BLOCKED. An authorized GitHub administrator must inspect repository Settings -> Environments -> staging and attest that required reviewers, intended deployment branch/tag restrictions, deployment initiation permissions and bypass controls are all configured as required.

Batch 17 — Final GitHub STAGING protection attestation

The authorized-administrator attestation for the four outstanding controls was explicitly negative or inadequate:

| Protection check | Result | Attestation | | --- | --- | --- | | Required reviewers | NOT CONFIGURED | NO | | Deployment branch/tag restrictions | NOT CONFIGURED | NO | | Deployment initiation restrictions | NOT CONFIGURED | NO | | Approval bypass control | NOT CONFIGURED | No native required-approval rule exists under the current configuration |

The local workflow's explicit workflow_dispatch and deploy_staging=true condition remains confirmed, but that local condition does not provide server-side Environment approval. The release gate remains BLOCKED and the deployment-control remediation is not ready to commit or push.

Before a separate commit/push decision, an authorized GitHub administrator must configure and verify:

1. At least one authorized required reviewer for the staging Environment. 2. Deployment branch/tag restrictions limited to the intended release path. 3. Appropriate repository Actions/workflow-dispatch permissions for deployment initiation. 4. The available control that prevents administrators from bypassing required Environment protection, followed by an independent verification that the approval gate is effective.

No settings, code, workflow or repository state were changed in this batch. No workflow dispatch, deployment, STAGING/production request, commit, push, reset, clean or stash was performed.

Batch 18 — Automatic deployment restoration assessment

The owner-approved testing model was re-audited before implementation. The existing bin/run-tests.ps1 runner:

1. invokes bin/refresh-test-database-from-staging.ps1; 2. reads the approved STAGING snapshot and recreates the local IDY_TEST_IDY002 database; 3. configures the local IDY_TEST_DB_* process variables; 4. invokes the pinned PHP 8.3.33 runtime and PHPUnit 11.5.56.

tests/bootstrap.php independently requires a MySQL-compatible IDY_TEST_* database and applies the runtime migrations before the configured PHPUnit suites run. This is the established local disposable-copy process; it was not replaced, duplicated or invoked in this batch.

The current local workflow still has the Batch 14 manual-only condition: deploy-staging requires workflow_dispatch with deploy_staging=true. The current origin/main/GitHub workflow is different: its workflow file has no dispatch input and deploys on a push to main, but it also has no PHPUnit job. The remote workflow file was independently fetched from GitHub at SHA bd25a9f7b7e51e1930d200b6f8e1e771037617ea.

No supported mechanism exists in the repository to make GitHub Actions either:

The workflow has no approved self-hosted runner, snapshot artifact handoff, attestation contract or external check-consumption mechanism. Adding an independent GitHub Actions MariaDB service would violate the established database authority and owner-approved testing model. Treating a local result or committed evidence file as a GitHub test pass would not be trustworthy.

Accordingly, no workflow change was authorized or made. Automatic push-to-main deployment cannot honestly be restored as a full test-gated deployment within this batch's constraints. Restoring only the push condition while omitting the required PHPUnit gate would violate the deployment policy. A future implementation requires the smallest additional owner-approved mechanism that preserves the local runner while providing a trustworthy GitHub deployment prerequisite; no such mechanism is currently documented or present.

No PHPUnit run, STAGING snapshot refresh, STAGING/production database access, workflow dispatch, deployment, commit or push occurred in this batch.

Batch 19 — Established automatic STAGING deployment restored

The actual worktree was rechecked at local and remote SHA 29fa8d83eed23bb596025c1ccd7066020b8437f7. The local workflow differed from origin/main only in the Batch 14 deploy_staging dispatch input and the manual-only deploy-staging condition. The remote workflow and historical GitHub Actions run 39270017715 confirm the previously working policy: pushes to main build and verify the exact release, then automatically run the protected STAGING deployment job. That run successfully deployed the exact SHA and passed the deployment helper's /health check.

The local deviation was restored without introducing a new pipeline:

The focused workflow regression assertion now verifies automatic push deployment and that manual dispatch cannot enter deploy-staging. The established local testing model remains unchanged: the approved bin/run-tests.ps1 process refreshes the disposable local database from the approved STAGING snapshot and runs the pinned PHPUnit suite locally. The GitHub workflow's actual checks remain its existing PHP validation, target-check, GitHub provenance generation, package creation/verification and exact artifact publication; the local PHPUnit result is not represented as a GitHub-executed test or fabricated attestation.

The native GitHub Environment approval controls remain a separate documented security limitation and were not changed. They do not alter restoration of the established automatic deployment policy, but repository administrators could still change workflow or repository behavior.

No STAGING/production database access, workflow dispatch, deployment, activation, commit or push occurred. The three excluded proposal/Stage 3D documents and all unrelated worktree changes remain preserved.

Batch 20 — Bounded legacy AuthorityGrant contract migration — 2026-10-18

The STAGING inspection failure was established as persisted contract drift, not an authorization-reader defect. The affected legacy AuthorityGrant Objects are bound to AuthorityGrant Type revision 1 and carry target_type_ids; the current AuthorityGrant Type revision 4 and runtime require exact target_type_references containing persisted Type Object identity and revision. The existing authorized reader therefore fails closed when it cannot resolve an accepted exact Type reference.

The implementation adds a bounded, staging-guarded operator path through the existing generic Command, Object revision, provenance and event mechanisms. object.rebind_type is not a normal grant-management API: it is accepted only for this migration authorization operation, only for an AuthorityGrant Type, only when an active Business Administrator grant with object.update and an allowing Policy authorizes the target, and only with an explicit expected Object revision. The migration:

1. requires the exact legacy grant identity, Business and current Object revision; 2. reads each persisted legacy Type identity and all valid Type Object history revisions; 3. fails closed for malformed, duplicate, missing or invalid Type identities; 4. removes target_type_ids, writes exact Type references and rebinds the same grant identity to the current AuthorityGrant Type revision; and 5. appends one governed Object revision plus the normal Command, Event and Provenance evidence.

Local evidence against disposable IDY_TEST_IDY002 with PHP 8.3.33 and PHPUnit 11.5.56:

| Suite | Result | |---|---| | AuthorityGrantContractMigrationTest | 4 tests, 33 assertions, 0 failures, 0 errors | | AuthorityGrantContractMigrationTest, ExactObjectReferenceResolverTest, Idy006BPresentationTest, DashboardPresentationIntegrationTest | 55 tests, 357 assertions, 0 failures, 0 errors |

PHP syntax checks and git diff --check passed. No STAGING or production database mutation was executed. The new CLI does not run during deployment; after the code is released, an authorized operator must invoke it separately for each confirmed legacy grant with the exact Business, grant identity and expected current revision. Read-only inspection must then verify authorized Business/Dashboard reads and preserved unauthorized and cross-Business denials before Presentation graph repair begins.

Batch 21 — Obsolete release count gate removed — 2026-10-20

Push afc83ad passed the target-release build and package publication job, but the automatic STAGING deployment job stopped during downloaded-artifact verification because the package had changed from the historical reviewed total of 228 files. The package remained valid: canonical manifest identity, per-file byte and SHA-256 checks, GitHub provenance and required target paths all verified locally, and no STAGING mutation occurred.

The obsolete fixed total-file-count assertions were removed from the build and read-only diagnostic workflows and their deployment tests. Manifest metadata remains informational, while manifest-declared paths, per-file integrity, provenance, release identity, required files and target health remain enforced. The package was reproduced locally with the pinned PHP runtime and verified through the unchanged canonical package verifier.

Batch 22 — Capability Definition Type revision-4 review — 2026-10-20

The Capability Definition Type retains its historical revision-3 descriptor without navigation_order and appends the current navigation_order contract as revision 4. The canonical descriptor digests are:

7ede8432e75229b5d7fddeb1068fb3bd14f8519b943a2753182c6a2930d43726.

The local migration uses the existing Type Object revision mechanism, coordination lock, expected-version enforcement, validation, revision history and provenance. It accepts only the exact revision-3 predecessor, is idempotent when revision 4 is already current, preserves revision-3 Definition references, and does not rebind existing Definitions or alter platform.type_revision. The protected vocabulary reconciliation accepts the exact historical predecessor before the append.

Local evidence against disposable IDY_TEST_IDY002 with PHP 8.3.33 and PHPUnit 11.5.56:

| Suite | Result | |---|---| | Capability revision, vocabulary and Person/Organisation regressions | 38 tests, 481 assertions, 0 failures, 0 errors, 0 warnings | | Legacy Dashboard presentation integration | 3 failures in the unchanged fixture path; standard application provisioning is defined but not invoked by FixtureInstaller |

PHP syntax checks, canonical hash assertions and git diff --check passed. The revision-4 change remains local review evidence only: it has not been committed, deployed, reconciled or executed against STAGING or production. An authorized rollout must first verify the exact persisted revision-3 predecessor and dependent Definition inventory, then deploy through the protected workflow and run the approved vocabulary reconciliation.

Batch 23 — Stage 3D partial owner decision record — 2026-10-21

The project owner supplied a partial Stage 3D decision record. The approved-in-principle direction preserves Presentation/View Definition Type revision 1 and appends revision 2 with optional target_type_revision, preserves Capability Definition Type revision 3 and appends revision 4, excludes the separate Presentation Object Type, and prohibits historical descriptor rewrites or automatic Definition/View rebinding.

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

The direction requires a separate grant and Policy, the existing governed Operation/Command/evidence pipeline, commit-time authorization and expected-version/hash revalidation, coordination and target locking, and two independently atomic idempotent Commands. The intended existing-target invocation is a separate bounded authenticated CLI based on the existing reconcile-foundation.php safeguards. No Operation, grant, Policy or Principal has been installed or authorized by this record.

The following remain unresolved: decision owner/delegated authority and governance reference; trusted handler/release owner; collision-checked final identifiers; designated Type-revision Principal and any Definition Publisher Principal reuse; final CLI and credential contract; event/reason-code names; diagnostic detail and protected workflow; and any additional conditions.

This is documentation evidence only. No tests, diagnostic, authentication, deployment, STAGING/production mutation or Type-revision execution occurred. Source-controlled hashes and candidate identifiers remain unverified against persisted STAGING state.

Stage 3D remains PLAN ONLY / NO-GO FOR BUILD.

Project transition browser verification

The declared from_state_id submission correction was deployed in protected release run 39921964569 (run 511), commit 609e16cd280ca171ac29c6bfdd4bed84cfecf802. The deployment package and deploy-staging job both completed successfully.

Authenticated browser verification was performed on https://platform-staging.idiosyncrasy.co.uk/ using the existing Spearmint Design business and Project 660c5111-0af2-4be5-bbbe-e03fc6678c64. Submitting the persisted planned -> active action succeeded and opened Command evidence:

c92ebd13-d57e-48c8-b4df-f5171598e91a, Business a20d5b62-078c-4ef4-b0ce-41027f9bc275, source target_html.

Reloading the exact Project detail URL preserved status Active, version 3, the persisted Change project status action, and the configured Milestone and People relationship actions. This completes the browser verification of the corrected Project lifecycle submission path.

Batch 25 — Shared body grid and direct Presentation manipulation — 2026-10-22

The fixed Presentation layout mechanism is now recorded across the UI implementation references. Every authenticated main-body Presentation surface, including Dashboard, capability and ordinary Object views, uses the shared six-column grid at wider viewports and collapses to one column responsively. The persisted minimum/default Presentation Object span remains two columns.

Layout editing has one mechanism only: the shared Edit layout / Save layout interaction, a top-right drag handle for repositioning and a bottom-right resize handle for changing width and height. Per-Presentation-Object action buttons are not part of the contract. Position and size continue to persist through the governed user-preference Object route with exact references and optimistic version checks.

Changed implementation surfaces:

Focused evidence:

| Check | Result | |---|---| | DashboardPresentationTest | 6 tests, 34 assertions, 0 failures, 0 errors | | Idy006BPresentationTest | 37 tests, 282 assertions, 0 failures, 0 errors | | PHP lint, Node syntax checks and git diff --check | Passed |

The integration test emitted the existing non-fatal denied inspection diagnostic to STDERR after PHPUnit reported success; the PHPUnit result itself was 37/37 passing. STAGING deployment and authenticated browser verification remain the final release checks for this batch.

Batch 25 — Revision-1 Presentation blocker and honest empty state — 2026-10-21

The existing Presentation runtime can render a useful initial Presentation without appending Presentation/View Definition Type revision 2. Focused local evidence against the already-provisioned test database passed:

| Suite | Result | |---|---| | Idy006BPresentationTest | 37 tests, 276 assertions, 0 failures, 0 errors, 1 warning | | DashboardPresentationTest | 4 tests, 29 assertions, 0 failures, 0 errors | | DashboardPresentationIntegrationTest::testDashboardUsesPersistedCompositionAndCommonRenderablePresentation | 1 test, 10 assertions, 0 failures, 0 errors |

The current protected STAGING diagnostic run 39615620287 established that the Presentation Object Type exists at revision 1, the Business has the exact Dashboard reference 87c1954c-7810-445c-85dd-1bdc96a6f10f at revision 2, the Dashboard, Overview and Overview title Presentation Objects exist, and the active inspection grant includes the Presentation Object Type. The authenticated browser nevertheless rendered the Dashboard title with an empty persisted element tree and only the Dashboard navigation entry.

The actual blocker is therefore not Presentation Type revision 2. The current runtime's exact governed Presentation Object traversal is suppressing the STAGING child branches because their persisted reference/value/authorization compatibility has not been proven. The existing projector must not be weakened with a permissive fallback or synthetic Business data. The new Presentation template now renders a truthful, accessible empty state instead of a blank surface when no authorized persisted elements survive projection.

The protected Stage 3D Type diagnostic implementation remains the bounded next evidence route. Its sources are still uncommitted and have not been executed against STAGING. No Type revision, grant, Policy, Principal, Presentation Object, Business binding or consumer was mutated.

Stage 3D remains PLAN ONLY / NO-GO FOR BUILD.

Batch 24 — Stage 3D read-only diagnostic implementation — 2026-10-21

The protected STAGING registration diagnostic now has a bounded Type-revision inspection slice. The new diagnostic receives the exact checked-out source through the protected workflow's existing SSH helper, opens the verified STAGING database in a read-only transaction and performs only prepared SELECT queries. It does not use the empty-target provisioning route, runtime migration, reconciliation, repository mutation or Type-revision authority.

For the two approved target Type Object IDs only, the diagnostic reports existence, current Object version, Type-of-Type identity, scope, the persisted current descriptor and canonical hash when safely available, retained history versions and hashes, revision-level command_id/provenance_ref state, bounded related evidence references, bounded dependency identifiers/counts and comparison against the proposed historical and target hashes.

Comparison is fail-closed:

truncated history, unavailable required schema/evidence or other inability to prove the comparison.

History, dependencies, evidence references and descriptor output are bounded. Sensitive-looking descriptor fields are redacted in output while canonical hashes are calculated from the unredacted persisted descriptor. Missing history or evidence is never inferred from source-controlled fixtures.

Focused local evidence:

| Check | Result | |---|---| | StagingTypeRevisionDiagnosticTest against already-provisioned local test database | 9 tests, 23 assertions, 0 failures, 0 errors | | PHP syntax checks for diagnostic class, probe and test | Passed | | Protected shell syntax check | Passed with Git Bash | | Read-only source-token safety check | Passed | | git diff --check | Passed |

The protected workflow has not been run for this change. No automated test connected to STAGING, no diagnostic was executed against STAGING, and no persisted Type revision, grant, Policy, Principal, Definition binding or consumer was changed. Actual STAGING Type state therefore remains UNVERIFIABLE pending separately authorized protected workflow execution.

Stage 3D remains PLAN ONLY / NO-GO FOR BUILD.

Principal / Business model clarification — 2026-10-28

Status: DOCUMENTATION ONLY; PROPOSED CLARIFICATION PENDING PROJECT-OWNER APPROVAL. Stu directed that no additional Principal, Membership or AuthorityGrant records be created, and that the Person/Principal/Business/Relationship/Membership/Authority/Account model be reconciled with existing decisions first. The reconciliation is recorded in identity and governance. It maps each concept to existing mechanisms, lists what is already settled, and records five unresolved owner questions, the governed presentation route, and the temporary restrictions with revisit conditions.

Evidence and limits:

Smallest safe next step, for approval: approve (or amend) the concept map and rule on unresolved questions 1-2 (Person-Principal association; Person-Business relationship Types). Until then no identity or authority data changes and the Principal/Business presentation stays minimal.