# Readiness Register Status: authoritative register of temporary decisions, deferred capabilities, known defects, architectural gaps, operational dependencies and production-readiness risks. Baseline audit 2026-10-28 at commit `d2c0f09` on `main`. This register does not claim, and must not be read as claiming, that the platform is production ready. ## Purpose, Authority and Rules This is the single place where an item that is temporary, deferred, provisional, blocked or unverified is recorded together with its revisit trigger. It records; it does not decide architecture. D01-D10 are settled and are not reopened here. Semantic contracts remain with their canonical owners (see the [authority map](../README.md#authority-map)); chronological build evidence remains in [implementation status](status.md). Where this register and a historical status section disagree on whether something is open, this register is the current record and the discrepancy is itself recorded (PRR-005, PRR-049). **Standing rule (mandatory).** 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. Maintenance rules: - A new temporary decision, deferral, workaround or unverified assumption is added here in the same change that introduces it. Do not delete an item; change its status and append the closing evidence. - `verified resolved` requires the evidence named in the item's *Closing evidence* field, cited by commit, workflow run or recorded STAGING check. A statement in a status section is not closing evidence. - `accepted` is not a status. A formally authorised acceptance decision is recorded in the item with the decision reference and approver; none exists today. - Owners, deadlines and approvals are never inferred. They are recorded as `unknown` until a human supplies them. - Statuses: `open`, `blocked`, `deferred`, `in progress`, `resolved pending verification`, `verified resolved`. Classifications: Temporary decision, Deferred capability, Known defect, Architectural gap, Operational dependency, Production-readiness risk, Resolved-but-requires-verification. - Severity is the impact on a production-readiness decision, not on the staging demonstrator: Critical blocks any such decision; High must be resolved or formally accepted before it; Medium and Low must be recorded and scheduled. Evidence method and limits are in [Part C](#part-c-evidence-and-audit-limits). Every item is based on repository evidence, git history, GitHub Actions run metadata and one read-only STAGING browser navigation. No test, build, deployment, migration or database command was run in this audit. ## Summary Counts 67 items (PRR-001 to PRR-067). No item is `verified resolved`. | Classification | Count | | Severity | Count | | Status | Count | |---|---|---|---|---|---|---|---| | Known defect | 11 | | Critical | 3 | | open | 42 | | Deferred capability | 14 | | High | 21 | | deferred | 13 | | Temporary decision | 11 | | Medium | 31 | | blocked | 5 | | Production-readiness risk | 9 | | Low | 12 | | in progress | 5 | | Architectural gap | 14 | | | | | resolved pending verification | 2 | | Operational dependency | 6 | | | | | verified resolved | 0 | | Resolved-but-requires-verification | 2 | | | | | | | ## Part A: Register **Terminology note, 2026-11-02.** Items dated before this note use "Principal" as legacy wording for User; the existing persisted Type is named Principal, but its records represent User accounts, and Principal is a legacy implementation identifier, not a current architectural concept or a separate identity Type (PRR-061). Descriptive identity prose in PRR-002 and PRR-052 to PRR-060 was aligned to User on 2026-11-02; literal identifiers and dated quoted names are unchanged. Those items are otherwise unchanged and are not rewritten. Field key: **Cur/Int** current versus intended behaviour; **Evidence**; **Why/Impact** reason, affected areas and consequences; **Deps** dependencies and approvals; **Fix** proposed resolution; **Trigger** exact revisit trigger; **Close** required verification evidence; **Prod** production impact and related decisions. ### Production gates and governance #### PRR-001 No production deployment, activation or rollback path **Classification:** Production-readiness risk · **Severity:** Critical · **Status:** blocked - **Cur/Int:** Only STAGING workflows exist. Intended: a documented, authorised, reversible production release path. - **Evidence:** `.github/workflows/` (build-target-release, staging-*); the profile-migration workflow refuses a production-named target database; [security and operations](security-and-operations.md); production provisioning is CLI-only with `--database=staging` (PRR-040). - **Why/Impact:** Production work is not authorised; every production concern is therefore unverified. - **Deps:** Human authorisation and approver: unknown. Depends on PRR-002, PRR-003, PRR-036, PRR-038. - **Fix:** Define production activation, rollback and approval in [security and operations](security-and-operations.md) after the gating items close. - **Trigger:** A human authorises production planning, or any item above moves to `verified resolved`. - **Close:** Authorised production runbook, a rehearsal on disposable infrastructure and recorded rollback evidence. - **Prod:** Blocks production. Related: none recorded. #### PRR-002 Stage 3D is PLAN ONLY / NO-GO FOR BUILD **Classification:** Architectural gap · **Severity:** Critical · **Status:** blocked - **Cur/Int:** Platform Type-revision authority is only partially decided; the production evidence package (21 platform Types) is not supplied. Intended: an approved owner decision and an authorised read-only production Type/dependency inventory. - **Evidence:** [owner decision request](stage-3d-owner-decision-request.md) (status "PARTIALLY DECIDED — PLAN ONLY / NO-GO FOR BUILD"); [production evidence request](stage-3d-production-evidence-request.md); status headings "Stage 3D gate resolution". - **Why/Impact:** Unresolved: decision owner/reference, handler owner, candidate ID collision, Type-revision User, CLI/credential contract, event names. Governed Type revision cannot be built. - **Deps:** Human owner decision and read-only production access authorisation: both unknown/unsupplied. - **Fix:** Close the listed unresolved items in the decision request, then supply the evidence package. - **Trigger:** The owner decision request is completed or the evidence package is delivered. - **Close:** Recorded decision reference, evidence package, then a re-plan from the canonical owners. - **Prod:** Blocks governed Type changes (PRR-009, PRR-008). Related: Stage 3A-3D sections of status. #### PRR-003 No complete Capability Definition is documented, implemented or published **Classification:** Architectural gap · **Severity:** Critical · **Status:** blocked - **Cur/Int:** Status records "DOCUMENTATION GAP — NO CAPABILITY IMPLEMENTATION BUILD AUTHORIZED". The earlier "all capabilities published" slice is recorded "NON-CONFORMING PRIOR SLICE" (shallow constituent list). Intended: a platform-owned revisioned Definition whose composed graph is complete, with exact constituent bindings and a defined Business instantiation contract. - **Evidence:** status.md (non-conforming prior slice sections); [AGENTS.md](../../AGENTS.md) Capability Definition rule; [data-defined semantics audit](data-defined-semantics-audit.md). Whether non-conforming publisher code was removed is not verified here. - **Why/Impact:** The product's central claim (capabilities as Definitions) lacks its authority record. - **Deps:** Documentation completion by Stu/owners; approver unknown. - **Fix:** Complete the documentation contract; then re-audit code against it; do not repair by promoting manifests or fixtures. - **Trigger:** The complete recursive composition, publication owner/boundary, provenance and instantiation contracts are documented. - **Close:** Documented contract, code audit, conformance tests against exact revisions. - **Prod:** Blocks a defensible production claim. Related: IDY-008 contract, D01-D10 unchanged. #### PRR-004 Eight capability workspaces are Presentation-Object compositions, not Definition authority **Classification:** Temporary decision · **Severity:** High · **Status:** open - **Cur/Int:** The eight workspaces on STAGING are produced from Presentation profile revision 11 (209 nodes) and demo data. Intended: Presentation derived from Capability Definitions and Business bindings. The relationship is not recorded in a canonical owner. - **Evidence:** status.md "Eight-capability demo business and presentation restoration"; `CoreObjectPresentationProfile.php`; profile migration workflow. - **Why/Impact:** The demonstrator can be mistaken for the product's authority model (PRR-003, PRR-012). - **Deps:** PRR-003. - **Fix:** Record the interim authority relationship in [implementation architecture](architecture.md); replace when Capability Definitions exist. - **Trigger:** PRR-003 closes, or any new workspace is added. - **Close:** Workspaces regenerated from Definitions with no JSON-profile bootstrap, verified on STAGING. - **Prod:** Medium-term rework. Related: none. #### PRR-005 Semantic-retirement compliance status is contradictory **Classification:** Resolved-but-requires-verification · **Severity:** High · **Status:** resolved pending verification - **Cur/Int:** The static semantic-retirement gate was recorded FAIL (12 violations in 180 files, B0-B3 families). Later sections record PASS / 0 findings while others say migration is incomplete. - **Evidence:** status.md "Data-defined semantic authority contract — PLAN ONLY" and later batch sections; [data-defined semantics audit](data-defined-semantics-audit.md). The gate was not re-run in this audit. - **Why/Impact:** The current compliance state is unknown from the documents alone. - **Deps:** None. - **Fix:** Re-run the gate on the audit commit and record the result. - **Trigger:** Any change under `app/Runtime` or the next Definition/Application change. - **Close:** Recorded gate output for a named commit, with the status contradiction reconciled. - **Prod:** Unknown compliance. Related: PRR-006, PRR-007. #### PRR-006 Revision defaults silently to 1 **Classification:** Known defect · **Severity:** High · **Status:** open - **Cur/Int:** Code defaults missing revisions to 1 (e.g. `TargetHtmlBoundary.php` lines 1345-1348, 1397-1413, 1693, 1819; `CoreObjectPresentationProfile.php` line 108; `CommandHandler.php` lines 1642, 1760, 1964, 2004; `DefinitionApplicationOperationHandler.php` line 715; `PresentationCatalog.php` line 227). Hardcoded revision-1 acceptance reported in `WorkflowVocabulary.php` and `PlatformVocabulary.php` (not re-verified). Intended: omitted revisions never silently default ([AGENTS.md](../../AGENTS.md)). - **Evidence:** grep of `app/Runtime` on 2026-10-28. Some sites (display-only `version`) may be benign; each has not been classified. - **Why/Impact:** A missing revision can bind the wrong Type revision after a revision-2 rollout. - **Deps:** PRR-002 for Type-revision rules. - **Fix:** Classify each site; reject or surface a missing revision where it is authority. - **Trigger:** Before any Type or View revision 2 is published to STAGING. - **Close:** Per-site disposition list plus tests that a missing revision is rejected. - **Prod:** Data-integrity risk. Related: invariant tests in [development](development.md). #### PRR-007 Business-specific literals in generic runtime code **Classification:** Architectural gap · **Severity:** Medium · **Status:** open - **Cur/Int:** Sales/Projects constants in `StandardCapabilityDefinitionCatalog.php`; marketing constants in `CapabilityCompositionVocabulary.php`; Enquiry/Qualification/Project handlers under `app/Runtime/Demonstrator`; demo population in `SpearmintDemoPopulationService.php`. Intended: Business semantics are data. - **Evidence:** code scan (agent report, not re-verified line by line). - **Why/Impact:** Violates the business-adaptive product definition if reachable in production. - **Deps:** PRR-003, PRR-005. - **Fix:** Confirm reachability; move to data or isolate as demonstrator-only. - **Trigger:** PRR-005 gate re-run or PRR-003 closure. - **Close:** Gate PASS with these files either removed or documented as non-production. - **Prod:** Medium. #### PRR-008 Capability View `target_type_revision` pin reverted; New/Add hidden **Classification:** Temporary decision · **Severity:** High · **Status:** in progress - **Cur/Int:** Commit `2892813` pinned `target_type_revision` on capability Views; STAGING View Type revision 1 rejected it (`unknown_value_property@value.target_type_revision`) and three reconciliation runs failed on 2026-10-28. Commit `d2c0f09` reverted the pin. `TargetHtmlBoundary` now Edits using the record's persisted `type_revision` and returns 409 where a View binding differs or the revision is missing; New returns 409 when the View binds no exact Type revision and `mutationAvailable()` hides the action. Intended: Views bind an exact Type revision (View revision 2, PRR-009). - **Evidence:** commits `2892813`, `d2c0f09`; `TargetHtmlBoundary.php` lines 652-705 and 1083-1108; read-only STAGING navigation of the Projects workspace showed no Add/New link. `objectListActions` (line 1111) still builds an Add href; its use for revision-1 Views is not verified. This decision was not recorded in any document before this register. - **Why/Impact:** Creating records from capability workspaces is intentionally unavailable. Edit authority is the record's own revision. - **Deps:** PRR-002, PRR-009. - **Fix:** Publish View revision 2 with an optional/accepted binding property via the governed path, then restore New. - **Trigger:** View Type revision 2 is available on STAGING or Stage 3D is decided. - **Close:** STAGING check that New is offered and binds an exact revision; test for the 409 paths. - **Prod:** Feature restriction; no data loss expected. Related: status/commit record. #### PRR-009 View revision 2 and Capability Definition revision 4 rollout pending **Classification:** Deferred capability · **Severity:** Medium · **Status:** blocked - **Cur/Int:** Proposed only: preserve View revision 1, append revision 2 with optional `target_type_revision`, and Capability Definition revision 4 (`navigation_order`). Rollout recorded as pending (Batch 22). - **Evidence:** [owner decision request](stage-3d-owner-decision-request.md); status Batch 22. - **Why/Impact:** Navigation ordering and exact-revision binding remain unavailable. Also, the New/Add action is hidden for every manifest View (including the Person Contact Profile and Business Details Views of manifest v6) because creation needs a View revision pin that View Type revision 1 rejects; those records can be created only by governed population or configuration, not by a UI user, until this closes. - **Deps:** PRR-002. - **Fix:** Implement after Stage 3D GO. - **Trigger:** Stage 3D BUILD authorised. - **Close:** STAGING verification of revisions and navigation order. - **Prod:** Medium. #### PRR-010 IDY-008 declaration reconciliation Operation and CLI authentication adapter undefined; reconcile workflow manual-only **Classification:** Deferred capability · **Severity:** High · **Status:** open - **Cur/Int:** `platform.reconcile_configuration_declaration` is unallocated/unimplemented; the CLI authentication adapter contract is undefined. The reconciliation workflow was changed in `d2c0f09` to `workflow_dispatch` only after three failed push runs (≈09:08, 09:12, 09:15 on 2026-10-28). Stale CLI guards have failed earlier runs. Intended: governed Operation-based reconciliation with an approved credential path. - **Evidence:** [IDY-008 contract](idy-008-contract.md); status IDY-008 sections; `staging-idy008-reconciliation.yml`; GitHub Actions run list. - **Why/Impact:** Business configuration cannot be reconciled reproducibly. - **Deps:** Operation allocation, credential contract: owner unknown. - **Fix:** Allocate the Operation and define the adapter in the IDY-008 contract. - **Trigger:** Next change to reconciliation or the first reconciliation of a non-demo Business. - **Close:** Successful workflow run on a named commit plus idempotent re-run evidence. - **Prod:** High. Related: IDY-008. #### PRR-011 Platform Form publication subsystem does not exist **Classification:** Deferred capability · **Severity:** Medium · **Status:** deferred - **Cur/Int:** Not built. Intended per contract: governed publication path. - **Evidence:** status IDY-008 sections. - **Why/Impact:** Forms rely on fallbacks (PRR-024). - **Deps:** Owner decision: unknown. - **Fix:** Plan from canonical owners. - **Trigger:** First requirement for a platform-owned Form. - **Close:** Contract, implementation and STAGING verification. - **Prod:** Medium. #### PRR-012 Core presentation reconciliation is containment, not migration **Classification:** Temporary decision · **Severity:** Medium · **Status:** open - **Cur/Int:** The JSON profile still supplies bootstrap/comparison input to the runtime. Intended: Presentation Objects as sole authority. - **Evidence:** status "containment, not migration"; `config/` profile and profile-migration workflow. - **Deps:** PRR-003, PRR-004. - **Fix/Trigger/Close:** Remove the profile as input when Definitions exist; verify by a STAGING reconciliation with the profile absent. - **Why/Impact:** Drift risk between source and persisted state (none found at last audit, status 2026-10-27). - **Prod:** Medium. #### PRR-013 Product-level Policy lifecycle unimplemented **Classification:** Deferred capability · **Severity:** Medium · **Status:** deferred - **Cur/Int:** Activation/deactivation not implemented or scheduled; an explicit test is skipped. - **Evidence:** PHPUnit skip; status. - **Deps:** Owner scheduling: unknown. - **Fix/Trigger:** Plan on request; trigger is any need to change Policy state at runtime. - **Close:** Implementation and the skipped test executing and passing. - **Why/Impact:** Policies cannot be managed in production. **Prod:** Medium. #### PRR-014 Products & Services semantic proposal unapproved **Classification:** Architectural gap · **Severity:** Medium · **Status:** open - **Cur/Int:** Offering vocabulary/lifecycle is a proposal; STAGING demo data holds 13 offerings regardless. - **Evidence:** [products-services-semantic-proposal.md](products-services-semantic-proposal.md); demo population service. - **Deps:** Owner approval: unknown. - **Fix/Trigger:** Approve or reject; trigger is any Products & Services change. - **Close:** Approved contract and reconciled demo data. - **Why/Impact:** Demo data may presume unapproved semantics. **Prod:** Medium. #### PRR-015 Missing Types and Views **Classification:** Deferred capability · **Severity:** Medium · **Status:** deferred - **Cur/Int:** No Tasks/Deliverables Types. Ten Types lack View Definitions (Opportunity, Goal, Audience, Content, Response, Execution, Exception, Handover, Resource, Assertion). Person and Organisation Types carry only `display_name`. - **Evidence:** status Type/View audits; capability catalogue. - **Deps:** PRR-002 for governed Type changes. - **Fix/Trigger:** Add via governed path when a capability needs them. - **Close:** Types/Views published and verified on STAGING. - **Why/Impact:** Capabilities cannot show or create these records. **Prod:** Medium. ### Workflow, Actions and automation #### PRR-016 Workflow runtime limited to bounded sequential execution **Classification:** Deferred capability · **Severity:** High · **Status:** deferred - **Cur/Int:** IDY-007C Slice 1 (leases, finalisation) is implemented. Not built: wake/resume, parallel, scheduler, queue, worker, retry/replay, compensation; no general worker runtime. - **Evidence:** [IDY-007C contract](idy-007c-contract.md); status. - **Deps:** Owner scheduling: unknown. - **Fix/Trigger:** Plan each from the contract; trigger is first requirement for long-running or scheduled automation. - **Close:** Per-capability implementation plus recovery evidence (PRR-018). - **Why/Impact:** Automation is not production grade. **Prod:** High. #### PRR-017 Action execution is simulation-only **Classification:** Deferred capability · **Severity:** High · **Status:** deferred - **Cur/Int:** Actions (e.g. `send_email`) do not perform network effects. Intended: governed real effects. - **Evidence:** [implementation architecture](architecture.md); status Action foundation. - **Deps:** Integration decisions: unknown. - **Fix/Trigger:** Plan from [communication and integrations](../architecture/communication-and-integrations.md) on first real-effect requirement. - **Close:** Verified governed effect with provenance on STAGING. - **Why/Impact:** No external communication. **Prod:** High. Related: PRR-041 (mail). #### PRR-018 Live recovery cases unverified; stale `running` executions on STAGING **Classification:** Known defect · **Severity:** Medium · **Status:** open - **Cur/Int:** Recovery paths are covered by tests but not live cases; stale `running` executions remain from earlier runs. - **Evidence:** status IDY-007 sections. Current STAGING data not inspected (PRR-C1). - **Deps:** STAGING read access. - **Fix/Trigger:** Inspect and resolve before the next workflow acceptance. - **Close:** Recorded STAGING query and a live recovery run. - **Why/Impact:** Misleading execution state. **Prod:** Medium. #### PRR-019 Workflow event-dispatch authorisation diagnostic unresolved **Classification:** Known defect · **Severity:** Medium · **Status:** open - **Cur/Int:** A non-fatal authorisation diagnostic during event dispatch is recorded unresolved. - **Evidence:** status IDY-007 sections; not re-verified. - **Deps:** None. - **Fix/Trigger:** Diagnose on next dispatch change. - **Close:** Diagnostic cleared with a test. - **Why/Impact:** May hide an authorisation fault. **Prod:** Medium. ### Runtime behaviour and security-relevant code #### PRR-020 Authorisation failures are swallowed to empty/false without observability **Classification:** Production-readiness risk · **Severity:** Medium · **Status:** open - **Cur/Int:** `AuthorizedObjectReader.php` (lines 35-70), `TargetHtmlBoundary.php` (≈630-645) and `AuthenticationService.php` convert exceptions to `[]`/false. This fails closed, but faults are invisible. Intended: fail closed and observable. - **Evidence:** code scan; not re-verified line by line. - **Deps:** Logging design: none exists (PRR-C2). - **Fix/Trigger:** Add structured logging when an observability approach is chosen. - **Close:** Tests proving denied and faulted paths are distinguishable. - **Why/Impact:** Hard to diagnose outages. **Prod:** Medium. #### PRR-021 Definition Edit uses the Presentation revision as authority **Classification:** Architectural gap · **Severity:** Medium · **Status:** open - **Cur/Int:** `TargetHtmlBoundary.php` lines 749-806. Intended: revision authority per the canonical Definition contract. - **Evidence:** code; relation to PRR-003. - **Deps:** PRR-003. - **Fix/Trigger:** Review when PRR-003 closes. - **Close:** Conformance test against the Definition contract. - **Why/Impact:** Edits may bind the wrong revision. **Prod:** Medium. #### PRR-022 Cross-phase provisioning is non-atomic (`reconciliation_required`) **Classification:** Known defect · **Severity:** Medium · **Status:** open - **Cur/Int:** A partially completed provisioning can persist in `reconciliation_required`. Intended: atomic or explicitly recoverable. - **Evidence:** status IDY-008 sections. - **Deps:** PRR-010. - **Fix/Trigger:** First provisioning of a non-demo Business. - **Close:** Failure-injection test plus a documented recovery procedure. - **Why/Impact:** Business setup can stall. **Prod:** Medium. #### PRR-023 No delete operation; superseded Presentation Objects remain **Classification:** Deferred capability · **Severity:** Low · **Status:** deferred - **Cur/Int:** Orphans accumulate. **Evidence:** status. **Deps:** owner decision on retention: unknown. - **Fix/Trigger:** Retention/removal design. **Close:** Documented retention rule. - **Why/Impact:** Clutter only. **Prod:** Low. ### User interface #### PRR-024 UI placeholders and fallbacks **Classification:** Known defect · **Severity:** Low · **Status:** open - **Cur/Int:** Disabled callout button (`presentation.php` ≈601-602); calendar/date-range button without action (≈270-273); fallback fields (≈828-829); text control fallback for unsupported field types (`operation_form.php` ≈21). - **Evidence:** code scan. - **Deps:** PRR-011. - **Fix/Trigger:** Remove or implement at the next renderer change. - **Close:** Browser verification on STAGING. - **Why/Impact:** Dead controls. **Prod:** Low. #### PRR-025 Declared UI capabilities not built **Classification:** Deferred capability · **Severity:** Medium · **Status:** deferred - **Cur/Int:** Client-side only filtering/search; no chart label thinning, agenda mode, `date_span` progress, per-record relationship counts, internal content-column preference; internal layout contract mismatch (nested-layout test: resolved pending verification, see PRR-029); no Notifications/Attentions surfaces. - **Evidence:** [UI system](ui-system.md); status. - **Deps:** Owner scheduling: unknown. - **Fix/Trigger:** Plan per item at the next UI milestone. - **Close:** Browser-verified on STAGING. - **Why/Impact:** Large data sets will not scale (client-side filtering). **Prod:** Medium. #### PRR-026 Workflow/Logic UI is configuration-only; profile/account features and temporary admin workspace **Classification:** Temporary decision · **Severity:** Medium · **Status:** open - **Cur/Int:** Workflow/Logic UI is a bounded configuration surface, not authoring; profile/account features are not built; the admin workspace is explicitly temporary. - **Evidence:** status; [UI system](ui-system.md). - **Deps:** Product decision: unknown. - **Fix/Trigger:** Replace when authoring or account management is planned. - **Close:** Removal/replacement verified. - **Why/Impact:** Operators rely on a temporary surface. **Prod:** Medium. #### PRR-027 Accessibility, keyboard, touch, cross-browser and pixel verification not performed **Classification:** Deferred capability · **Severity:** High · **Status:** deferred - **Cur/Int:** Deferred in [UI system](ui-system.md); display-scope states (standalone_only, standalone_and_embeddable, embeddable_only) not browser-verified; empty states untested; earlier second-hand baselines could not be reproduced. - **Evidence:** UI system; status acceptance notes. - **Deps:** None. - **Fix/Trigger:** Before any external user access. - **Close:** Recorded assessment against a named standard on named browsers. - **Why/Impact:** Accessibility obligations unmet. **Prod:** High. #### PRR-028 STAGING data and inference choices are provisional **Classification:** Temporary decision · **Severity:** Low · **Status:** open - **Cur/Int:** Demo data (212 records, 83 relationships, reference date 2026-10-27) is fixed to a date; pre-existing acceptance records inflate KPIs (Projects 10 vs 8 demo; People 13 includes an acceptance person); filter vocabularies are inferred; the default status tone palette lives in the renderer. - **Evidence:** status 2026-10-27 section. - **Deps:** None. - **Fix/Trigger:** Cleanup or data-defined palette at next data reset. - **Close:** STAGING counts match the demo definition. - **Why/Impact:** Demo KPIs not reliable. **Prod:** none for production data. #### PRR-051 KPI history is limited to data that carries genuine dates **Classification:** Deferred capability · **Severity:** Medium · **Status:** deferred - **Cur/Int:** Finance revenue, expenses and forecast KPI cards and the Marketing Responses KPI card (`received_at`) show a time-series line of the same filtered records as the KPI value, with a granularity control limited to grains that yield at least two periods and a trend over complete adjacent periods (semantics: PRR-054). The Forecast card has no trend claim because its records are forward-dated. The Dashboard People, Projects and Pipeline KPIs and the Marketing Active campaigns and Published content KPIs have no history. Sales Revenue won, Open pipeline and Operations Executions running have no suitable dated source (forecast value, or a status filter that history by `started_at` would misstate). Intended: every KPI that measures dated records offers a history and comparison. Update 2026-10-29 (full KPI inventory, see [status](status.md) and PRR-055): all 18 other capability-page KPIs were audited and none qualifies for a chart today. A history series must count events by a declared date and describe the same records as the headline value. Opportunity has only the forward-looking `target_close_date` (a schedule); Execution `started_at` and Exception `raised_at` date events, but the headlines are the current status filters "running" and "open or escalated", so a per-period event chart would not describe the headline; Project `start_date` dates starts while the headline counts all or active projects; Offering, Person, Organisation, Knowledge Item and Assertion declare no date property. They stay compact metric-only. Campaign, Content and Operational Work also declare no date (Stage 3D, PRR-002). - **Evidence:** profile revision 17 nodes `finance-accounts-kpi-*` and `marketing-page-kpi-responses*`; `PersistedPresentationObjectProjector::groupedPoints`; `tests/Unit/PresentationTimeBucketTest.php`; status 2026-10-28 (KPI cards) section; source scan of declared Type properties (Project has `start_date` and `due_date`; Milestone has `due_date` only; Campaign declares no date property). - **Why/Impact:** Demo records were all created on one day, so a `created_at` history would present seeding time as business history; Sales `target_close_date` is a forecast; Date properties for Campaign and Milestone need Type revisions (PRR-002). The synthetic revenue and expense dates are demonstration data (PRR-028), not business history. - **Deps:** Stage 3D (Date properties); an owner decision on whether governed, clearly labelled synthetic history may be added through `SpearmintDemoPopulationService` (`created_at` is system-assigned and the population route has not been shown to support back-dating, so any such history must use declared date fields). Approver: Stu. - **Fix:** Use a declared date field for each KPI source (or add one by Type revision), add governed synthetic demo records if approved, then replace the literal text with the generic chart and its computed empty state. Cumulative ("total over time") measurements would need an aggregation extension not built. - **Trigger:** Stage 3D authorised, or the demo data gains declared dated fields, or the owner approves synthetic history. - **Close:** STAGING shows trend and comparison for each dated KPI with values reconciled to the records; no literal trend text remains. - **Prod:** Medium; the demonstrator must not be read as showing real trends. #### PRR-052 Person, User and Business detail attributes are blocked by the identity model and Stage 3D **Classification:** Architectural gap · **Severity:** High · **Status:** in progress - **Decision 2026-10-29 (Stu):** The route is not Stage 3D platform Type revision. Business-scoped data Types are installed through the governed configuration installer (manifest v6, release `generic-business-capability-configuration-v6`): Person Contact Profile (`a1000000-…-000000000201`: `display_name`, `email`, `telephone`, `biography`) and Business Details (`a1000000-…-000000000202`: `display_name`, `website`, `telephone`, `trading_address`, `registered_address`, `registration_number`), with Relationship Types Person to Contact Profile (`c2000000-…-0105`) and Person to Principal (`…-0106`, legacy name; a potential User-to-Person link; uninstantiated, PRR-059) and Views `a2000000-…-000000000011` and `…0012`. The platform Person, User and Business Types (the User Type is persisted under the legacy name Principal) and their identifiers are untouched. Person, User, Business, Membership and AuthorityGrant stay distinct; no relationship confers authority. Date of birth and sex are excluded (PRR-057). The Business Details values for Spearmint Design are not seeded: real values need the owner, and creating a Business Details record from the UI is blocked by the View revision pin (PRR-008 and PRR-009: the New action stays hidden for manifest Views, while Edit of an existing record works). Status: manifest, authority extension, demo contact profiles for three fictional Persons and tests built; not yet deployed or verified on STAGING. - **Cur/Int:** Person and Organisation hold only `display_name`; User and Business detail show `display_name` and `status`. Intended: authority-controlled presentation and editing of personal and business attributes, with Person, User, Business relationship and Membership kept distinct. - **Evidence:** [identity and governance](../architecture/identity-and-governance.md) (concept map, five open questions, and the 2026-10-28 route subsection, which is the authoritative plan); `InitializationVocabulary`. - **Why/Impact:** Missing fields need governed Type revisions (PRR-002) and owner answers to the five questions; date of birth and sex also need privacy, purpose and access decisions. No User, Membership or AuthorityGrant was created and none may be created to populate demonstration pages. Constituent Objects (Business `contact_email`/`address`, User `profile_note`) are an existing storage route that is not presented. STAGING read 2026-10-28 (authenticated, read-only): the User (persisted under the legacy name Principal), Business, Person and Organisation Definitions exist (Explorer, `/objects?type_id=a1000000-...-0001`), and their detail Views show only the name and Type reference; `/objects?type_id=a1000000-...-0002` (constituents) returns 404 "Presentation Definition is unavailable", and `/relationships` and `/graph` for Business, User and a Person return 404 because their Views declare no relationship section. Whether the constituent Objects exist was not observable through any listing route. A direct read by deterministic id (`InitializationVocabulary::constituentId`, STAGING 2026-10-29) now shows: the Business `contact_email` constituent exists (the unscoped lookup finds it) but the authorised reader refuses it, while the Business `address` and User `profile_note` constituents do not exist (no object has those ids). The read is refused because the Business administrator's inspection grant names no Constituent Type target; see PRR-056 for the exact blocker. Business and User detail Views now present every existing Type property (name, status, kind, created, updated) through data-defined record templates (profile revision 19); they do not and cannot show the constituents. - **Deps:** Stu: answers to questions 1-5, attribute and privacy approval, Stage 3D authorisation. - **Fix:** The sequence in the identity document (decisions, Stage 3D, Type and Definition revisions, View revision 2, core-profile revision 2, synthetic demo data, STAGING verification). - **Trigger:** Any owner answer to questions 1-3, or Stage 3D authorised for build. - **Close:** Recorded owner decisions, governed revisions published, STAGING create/edit/conflict/isolation checks. - **Prod:** High; blocks any user-facing identity or business profile. #### PRR-056 Constituent Objects are not readable under the Business administrator's authority **Classification:** Architectural gap · **Severity:** Medium · **Status:** in progress - **Decision 2026-10-29 (Stu):** Grant Stuart Mayne's `business_administrator` Membership inspection of the Constituent Type (inspect only) through a governed, audited operation, not Stage 3D and not the direct-SQL script. The operation is `BusinessTypeAuthorityExtensionService` (`bin/extend-business-type-authority.php`, protected workflow `staging-business-type-authority-extension.yml`). **Superseded in mechanism 2026-10-29 by PRR-060:** the first additive extension (commit `17ca686`) gave the shared grants excess effective operations on the identity targets (STAGING diagnostic, build `d5c145d`: `nothing_beyond_approved_scope` false), so it was not applied. The service now reconciles to an exact target-specific scope: Constituent Type inspect only through the dedicated `business_identity_inspection` grant, with the identity references removed from the shared grants under a verified baseline. Still limited to the Spearmint Design Business on STAGING, bound to the administrator Membership, creating no User, Membership or blanket grant and writing through one atomic `CommandHandler` command under the acting User's own authority. Implemented and tested; **not yet run on STAGING**. Part (b) below, the record-bound source filter, is unchanged and still open, so Constituent fields are still not presented. - **Cur/Int:** Business `contact_email` and `address` and User `profile_note` are stored as Constituent Objects (Type `a1000000-0000-4000-8000-000000000002`, deterministic ids), written by the initialization workflows. Authorised inspection (`AuthorizationService::authorizeInspection`) is per target Type, and the administrator's inspection grants name no Constituent Type target. STAGING 2026-10-29: `contact_email` exists but `GET /objects/{id}` returns 404 "Object not found" (reader refusal); the other two ids do not exist. Intended: a bounded, authorised, generic read of a subject's constituents (subject-id match, no cross-Business reach) presented in the Business and User detail templates, with "not set" distinguished from "not readable". - **Evidence:** `AuthorizedObjectReader::get`, `AuthorizationService::authorizedInspectionTypeIds`, `InitializationOperationHandler` (apply constituent), the 2026-10-29 id probe in PRR-052. `bin/create-constituent-authorization-grants.php` inserts grants by direct SQL with a hardcoded Business and Membership; it is not an approved route and must not be run. - **Why/Impact:** Granting inspection is an authority change. The governed route must be an authorised Operation that creates an inspection AuthorityGrant for the Constituent Type, and the projector also needs a record-bound source filter (current filters accept only literal `in` values and `projectDisplay` has no parent-record context). Neither exists, and a grant must not be created through demo seeding. - **Deps:** Stu: approval to grant inspection of the Constituent Type to Business administrators and the approved grant route; then a small generic projector extension. - **Fix:** (1) Approve and execute the governed inspection grant; (2) add a record-bound filter and parent-record context to `projectDisplay`; (3) extend the Business and User record templates (the User Type is persisted under the legacy name Principal) with constituent fields; (4) STAGING verification. - **Trigger:** Stu approves the grant, or an approved grant route is built. - **Close:** STAGING detail shows `contact_email` (and `address`, `profile_note` once set) read through the authorised reader, with an explicit not-set state, and a non-member cannot read them. - **Prod:** Medium; the Business contact email cannot be shown or edited from the UI until closed. #### PRR-053 Saved layout preferences override authored sizing **Classification:** Temporary decision · **Severity:** Low · **Status:** open - **Cur/Int:** Layout saves persist span, order and height for every card, and a saved preference overrides the authored profile value, so later authored height or span changes do not reach a user who has saved a layout until they reset it. Height has no enforced minimum beyond 1rem and content always overrides it; width is limited to the 2/3/4/6-of-6 spans. Intended: preferences override only the properties a user actually changed, with an explicit reset. - **Evidence:** `PresentationPreferenceService`, `dashboard-drag-drop.js`; status 2026-10-28 section. - **Why/Impact:** Authored layout corrections can appear not to deploy for users with saved layouts; the Dashboard was verified equal to the authored geometry on 2026-10-28. - **Deps:** None (design choice by Stu). - **Fix/Trigger:** Persist only changed properties and add a reset-to-default control when preferences are next revised. - **Close:** A saved single-card change leaves other cards following the authored profile after a profile revision. - **Prod:** Low. #### PRR-054 Time-axis zero-fill and period-completeness semantics are provisional **Classification:** Temporary decision · **Severity:** Low · **Status:** open - **Cur/Int:** Line charts over a time bucket show a contiguous axis in which a period with no records is `0`, and a period is "complete" when its end date is before the server's current date; trend text compares only complete adjacent periods and names the incomplete ones it excluded. Intended: the same rules, but with a business-timezone "today" and a declared distinction between "no activity" and "no data" for sources that are only partially loaded. - **Evidence:** `PersistedPresentationObjectProjector::groupedPoints` and `timeBucket`; trend block in `resources/views/target/presentation.php`; `PresentationTimeBucketTest`, `DashboardPresentationTest`; [UI system](ui-system.md) (KPI card, time axis and trend semantics). - **Why/Impact:** Zero-fill was necessary because comparing only the periods that happen to contain records compared non-adjacent months (Expenses "-36% vs previous month" actually compared October with August). Risks: a source that is simply not loaded for a month reads as zero activity (Finance Expenses shows September as 0 and a "-100%" change); the server date, not the Business timezone, decides completeness; no like-for-like or seasonal adjustment. - **Deps:** None for the current behaviour. A business-timezone clock and a "no data" distinction need an owner decision (Stu) and a documented source property. - **Fix/Trigger:** Review when a Business timezone is modelled, when a real (non-demo) dated source is first charted, or when a "no data" marker is specified. - **Close:** Completeness uses the Business date; sources declare whether absent periods mean zero; STAGING trends reconcile to the records. - **Prod:** Low for the demonstrator; Medium if shown with real data. #### PRR-055 Metric-only KPI cards use a compact authored height; Campaign and Milestone dates await Stage 3D **Classification:** Temporary decision · **Severity:** Low · **Status:** open - **Cur/Int:** The 18 metric-only capability KPI surfaces (Products & Services, Projects including Milestone progress, People, Sales, Operations, Knowledgebase) declare `preferred_height` 6 (96px minimum), the Marketing precedent, instead of 12; content height still wins and the layout editor, saved preferences and the "Height min is 1rem" rule are unchanged. Chart-enabled `kpi_card`s (Finance, Marketing Responses, Dashboard) keep their larger heights. Intended: the same outcome from a content-aware rule that derives a card's height from its content, so authored heights are not needed for it. - **Evidence:** profile revision 18 (`*-kpi-*` and `projects-page-progress` nodes); `BusinessPresentationProfileTest::testMetricOnlyKpiSurfacesUseTheCompactPreferredHeight`; before the change STAGING rendered these cards at 192px with the content centred in empty space. - **Why/Impact:** A governed profile revision was the smallest change that preserved the layout editor. Risks: the height is an authored number, not derived; users with saved preferences for a card keep their saved geometry (PRR-053). - **Deps:** None for the present behaviour. KPI history for Campaigns, Milestones, Content, Operational Work, Offerings and Knowledge Items needs date properties that no Type declares: adding them is a Type revision, blocked by Stage 3D (`platform.type_revision`, NO-GO, PRR-002). Until then those KPIs stay metric-only and no history is inferred from current lifecycle values. - **Fix/Trigger:** Review when Stage 3D permits Type revisions (add the date properties, then a history series per PRR-051 acceptance criteria) or when a generic content-aware card height is specified. - **Close:** Each KPI with a declared date source charts the same records as its headline; metric-only cards derive their height from content; STAGING rendered pages show no excess space. - **Prod:** Low. #### PRR-057 Date of birth and sex are excluded from the Person model **Classification:** Temporary decision · **Severity:** Medium · **Status:** deferred - **Cur/Int:** The Person Contact Profile Type (`a1000000-…-000000000201`) declares `display_name`, `email`, `telephone` and `biography`. Date of birth and sex are not declared and no UI field exists for them. Intended: either model them under an owner-approved privacy basis or confirm they stay out of the platform. - **Evidence:** Owner decision 2026-10-29 (Stu, recorded here); Stage 3D documents require a stated purpose, access rule and minimisation decision for personal attributes; manifest v6 Person Contact Profile declaration. - **Why/Impact:** Both are special-category-adjacent personal attributes. No purpose, access rule, retention rule or minimisation decision exists, and nothing in the demonstrator needs them. The sex representation is also undecided (open vocabulary, controlled list or gender-identity model). - **Deps:** Stu: purpose, lawful basis, field-level access rule (who may read and edit), retention and a representation decision. A manifest revision that adds optional properties; no Stage 3D dependency, because the route is a Business-scoped Type installed through the governed configuration installer. - **Fix:** Reconsider only when a documented product need and the privacy decisions above exist; add the properties to a new manifest version with field-level authorisation, never as a default-visible field. - **Trigger:** A concrete use case (for example payroll, safeguarding or an age-gated service) or the owner asking for the fields. - **Close:** Recorded decision with purpose and access rule; Type declares the properties; STAGING shows them only to authorised readers. - **Prod:** Medium; excluded by design until decided. #### PRR-058 One-to-one relationship cardinality is not supported by the relationship slot store **Classification:** Known defect · **Severity:** Medium · **Status:** open - **Cur/Int:** A Relationship Type with `source_cardinality` and `target_cardinality` both `one` cannot be instantiated: `CommandHandler` inserts one `relationship_slots` row per `one` end with the same `relationship_id`, and `uq_relationship_slot_relationship` (migration 0005) allows one row per relationship, so the command ends `reconciliation_required` (PDO duplicate key). Intended: a one-to-one Relationship Type is instantiable and enforces both ends. - **Evidence:** `CommandHandler::commitRelationshipEffect`; `database/runtime-migrations/0005_idy006_relationships.sql`; observed while building the Person Contact Profile demo data (test `SpearmintDemoPopulationTest`). - **Why/Impact:** Person to Contact Profile (`c2000000-…-0105`) and Person to Principal (`…-0106`, legacy name; a potential User-to-Person link) are declared `source_cardinality: one`, `target_cardinality: many`. A Person has at most one profile and at most one User link, but nothing prevents two Persons sharing one profile or one User representing two Persons. The uniqueness of the target end is therefore not enforced by the runtime. - **Deps:** A runtime migration (change the slot uniqueness to include the endpoint role) and a generic CommandHandler review; not part of this change. - **Fix:** Make the slot uniqueness `(relationship_id, endpoint_role)`, then tighten both Relationship Types to one-to-one through a new manifest version. - **Trigger:** The owner decides to enforce target uniqueness, or a Relationship Type needs one-to-one. - **Close:** Test that a second source or second target for a one-to-one type is refused; both types tightened. - **Prod:** Medium. #### PRR-059 Business-to-Person association and the User-to-Person link are not instantiable **Classification:** Architectural gap · **Severity:** Medium · **Status:** open - **Cur/Int:** (1) Relationship Type `c2000000-…-0106` (Person to Principal, legacy name; a potential User-to-Person link) is declared so the model is explicit, but no grant covers `object.relate` on it and no User link was created: this is deliberate, because linking a User to a Person is an identity decision. (2) A Business-to-Person relationship cannot be created: the Business Object has a null `business_id` and a relationship's source must belong to the command Business, so the Business cannot be an endpoint. Membership relates only a User to a Business. Intended: Person to Business association (employment, ownership, contact) modelled and distinct from Membership and authority. - **Evidence:** `CommandHandler::commitRelationshipEffect`; `BusinessCreationOperationHandler` (Membership value: `principal_id` (legacy identifier for the User), `business_id`, `membership_kind`, `status`); [identity and governance](../architecture/identity-and-governance.md). - **Why/Impact:** Business Details are shown on the Business page through an object collection of the Business Details Type, not through a relationship. A Person's association with the Business, and an identity link, remain unmodelled. Membership is not and must not become that association, and no relationship grants authority. - **Deps:** Stu: whether a Person is linked to a User (the Relationship Type is named Person to Principal in its legacy declaration) by this Relationship Type, who may create the link and through which admission workflow; whether a Business-scoped surrogate or a Business endpoint extension models Person to Business association. - **Fix:** Owner decision, then either a RELATE grant through the governed extension service for the identity link, and a documented endpoint rule for Business-side associations. - **Trigger:** The owner decides the Person-User link policy or asks for Person to Business association. - **Close:** Documented decision; governed creation path; STAGING shows the association with Membership and authority unchanged. - **Prod:** Medium. #### PRR-060 Authority grants and Policies cannot scope operations per target; identity authority uses dedicated grants **Classification:** Architectural gap · **Severity:** Medium · **Status:** resolved pending verification - **Run 2026-10-31:** reconciliation executed on STAGING (baseline v10; four grants created; shared grants narrowed to v12; `exact_scope_match` true; rerun `already_reconciled`; unchanged after demo population). Remaining verification: a live unauthorised-edit rejection with a second User, and no re-widening after the next demo population by a different operator. one operation list with one `target_type_references` list, and a Policy applies to an operation across the whole Business (`BoundedPolicyEvaluator::matchingPolicies` has no target input), so one grant cannot give different operations on different Types. STAGING diagnostic (build `d5c145d`, 2026-10-29) proved the shared `business_administrator_inspection` and `business_administrator_demonstrator` grants (both version 11) exposed `object.relate`, `object.transition` and `platform.traverse_relationships` on the identity targets beyond the approved scope (`nothing_beyond_approved_scope` false). Intended (decided by Stu, 2026-10-29): approved scope per target is exact: Person Contact Profile and Business Details Types: inspect, create, update; Person to Contact Profile relationship: inspect, relate, update, traverse; Person to Principal relationship (legacy name; a potential User-to-Person link) and Constituent Type: inspect only; `object.transition` and `object.rebind_type` on none. - **Decision 2026-10-29 (Stu):** (1) Relationship creation is `object.relate` on the relationship Type; `object.create` is never granted on a relationship Type. (2) `platform.traverse_relationships` is granted on the Person to Contact Profile relationship only, because the Person detail's Contact Profile section reads it through a `relationship_reference` source and the authorised relationship reader requires traverse plus inspect on the relationship Type; traversal is only ever consulted for relationship Types. (3) Four deterministic, idempotent, Business-scoped grants bound to Stuart's active `business_administrator` Membership for Spearmint Design: `business_identity_inspection` (inspect; all five targets), `business_identity_editor` (create, update; the two data Types), `business_identity_profile_relationship` (relate, update; the profile relationship) and `business_identity_profile_traversal` (traverse; the profile relationship). The identity Type references introduced by this work are removed from the two shared grants in the same atomic command; every other reference and every operation is preserved. Policies, the AuthorityGrant Type, Users and Memberships are unchanged. - **Implemented, not yet deployed or run:** `BusinessTypeAuthorityExtensionService::reconcile` establishes a baseline from each shared grant's recorded revision history (contiguous versions, latest equals current, latest revision with no identity reference, binding unchanged) and **stops before any mutation** if it cannot; it then issues one `CommandHandler` command with four create effects and up to two update effects, so it is atomic and authorised before commit. A rerun writes nothing. `SpearmintDemoPopulationService::reconcileTypeAuthority` no longer merges the Contact Profile Type or the profile relationship into the shared grants, so demo population cannot re-widen them. The read-only diagnostic reports per target the expected set, the effective set (real grant lookup plus Policy evaluation), `exact`, per shared grant the baseline, the dedicated-grant inventory, and `exact_scope_match`, `nothing_beyond_approved_scope` and `unrelated_targets_unchanged` verdicts. `BusinessTypeAuthorityExtensionTest` (13) and `SpearmintDemoPopulationTest` pass, including positive, negative, atomicity (forced failure), idempotency, drift convergence, baseline-failure and unrelated-Type regression cases. - **Trade-off:** The shared grants are narrowed only in the identity references; because grants are Type x operation-set, any future target that needs a different operation set from the shared grants needs its own grant too. Traversal on relationship 105 is inseparable from the Person page's Contact Profile section as designed; removing it would remove that section's data. - **Evidence:** `AuthorityGrantRepository::findFor`, `BoundedPolicyEvaluator`, `AuthorizedRelationshipReader`, `CommandHandler::effectTypeId` (RELATE uses the relationship type id), STAGING diagnostic output for build `d5c145d`. - **Deps:** Stu: dispatch of the mutating workflow after reviewing the pre-run diagnostic baseline. - **Fix/Trigger:** Push; dispatch the workflow with `diagnose_only=true`; on approval dispatch the mutating run, then a read-only run. - **Close:** Post-run diagnostic shows `exact_scope_match`, `nothing_beyond_approved_scope` and `unrelated_targets_unchanged` all true on STAGING, and the identity pages work through the dedicated grants. - **Prod:** Medium; the Person Contact Profile section and Business Details collection need this authority. #### PRR-061 Legacy Principal identifiers remain until a governed User reconciliation **Classification:** Architectural gap · **Severity:** High · **Status:** blocked - **Cur/Int:** The owner correction of 2026-11-02 settled that there is no separate Principal concept: the platform identity and authority subject is the User, and existing Principal objects are Users. The implementation still carries the legacy name: the persisted Type is named Principal (with `principal_kind`), Membership and AuthorityGrant values use `principal_id` under `additionalProperties: false`, the tables `principal_identities` and `principal_confirmation_challenges` exist, the Operations are `principal.register` and `principal.confirm`, and retained evidence and configuration use `principal_id`-style fields. Intended: the same records described and eventually named as User accounts, through a separately authorised migration. No new User object and no second identity model. - **Evidence:** [legacy Principal identifiers](architecture.md#legacy-principal-identifiers); [owner-correction note](../governance/decisions.md#unnumbered-cross-cutting-correction---user-replaces-principal); `database/genesis/idy-003.json`; migration `0012_principal_admission.sql`; `database/genesis/idy-platform-opening-effects.json`; `database/configuration/idy-008/demonstrator.json` (`submitter_principal_id`, `reviewer_principal_id`, `responsible_principal_id`); a 2026-11-02 count of about 1,400 `app/` and 690 `tests/` references. Counts are indicative, not an audit. - **Why/Impact:** Renaming Types, Operations or Genesis definitions needs governed Type revisions (blocked by Stage 3D, PRR-002), changes manifest digests and cannot rewrite retained evidence. The legacy name must not be read as a continuing Principal concept. Frozen contracts carry a dated supersession note instead of a rewrite. - **Deps:** PRR-002; a separately authorised migration design; Stu approval. Whether `principal_kind` is redundant when every User is an account, and the aliasing of retained evidence, are unresolved. - **Fix:** Design and authorise a reconciliation (Type revisions, Operation renames, column and code renames, vocabulary and manifest regeneration, evidence aliasing). Not authorised and not designed. - **Trigger:** Stage 3D authorised for build, or any authorised change to the Principal Type, Operations, tables or Genesis definitions. - **Close:** Recorded migration decision; governed revisions published; STAGING verification that identity, Membership and authority are unchanged and retained evidence is intact. - **Prod:** High; a production identity model should not ship with a superseded name unless that is formally accepted. #### PRR-062 Non-human actors and delegated-authority succession are unresolved **Classification:** Architectural gap · **Severity:** Medium · **Status:** open - **Cur/Int:** Intended direction (owner, 2026-11-02): there is no independent non-human identity or authority subject; automation, workflows and integrations act under authority delegated by a User, and the technical executor is recorded as execution provenance. Proposed, not settled: when delegated authority is removed with a replacement the execution continues under the replacement; when removed without one, or lost by other means (account disabled, User leaves, authority revoked), the affected execution pauses, relevant staff are notified and a replacement is required to resume. Current implementation: worker and execution provenance exist; the delegated-authority and pause behaviour is not built. - **Evidence:** [delegated authority for automation](../architecture/identity-and-governance.md#delegated-authority-for-automation); [workflows and automation](../architecture/workflows-and-automation.md). - **Why/Impact:** Unresolved, and not to be answered by inference: what is an appropriate replacement; whether the replacement must accept responsibility; who is notified; whether workflow and automation types need different authority models; whether queued or in-progress operations are suspended, cancelled or allowed to complete; the detailed execution model, revocation, User departure and disablement, and inbound callback authorisation. - **Deps:** Stu decisions on the questions above. - **Fix:** Decide in the identity owner, then specify the mechanism in the workflow owner. - **Trigger:** Workflow runtime beyond the bounded slice (PRR-016), real Action effects (PRR-017), or any inbound integration work. - **Close:** Documented decisions and conformance evidence for pause, replacement and notification behaviour. - **Prod:** Medium; blocks unattended automation that must outlive a User's authority. #### PRR-063 Entitlement gate, Licensed and Guest classification and activation are not built **Classification:** Deferred capability · **Severity:** High · **Status:** deferred - **Cur/Int:** Intended future architecture: Business subscription, derived commercial conditions (subscribed, unsubscribed, never activated, lapsed), Licensed and Guest User classification and the entitlement gate on Business-scoped operational execution. `business.create` and User registration are free and never gated. **Current: all Businesses are treated as active; no subscription, entitlement, billing, activation or Guest enforcement exists.** - **Evidence:** [subscriptions and entitlements](../architecture/subscriptions-and-entitlements.md); [Licensed and Guest Users](../architecture/identity-and-governance.md#licensed-and-guest-users); a read of the implementation found no enforcement. - **Why/Impact:** The derivation of Licensed and Guest status and its edge cases are open. Licensed status never grants authority; Membership, AuthorityGrant and Policy remain the only authority. A Guest cannot execute Business operations. - **Deps:** Stu design decisions; PRR-064, PRR-065, PRR-067. - **Fix:** Specify derivation and edge cases in the owner documents, then build behind an explicit authorisation. No restriction may be added to the current build or the Spearmint Design milestone. - **Trigger:** Owner authorises commercial-model design or build. - **Close:** Documented derivation; conformance and STAGING evidence of the gate, with authority unchanged. - **Prod:** High; a commercial launch cannot proceed without it. No effect on the current demonstrator. #### PRR-064 Guest authority scoping cannot express per-instance visibility **Classification:** Architectural gap · **Severity:** Medium · **Status:** open - **Cur/Int:** Intended: a Guest (for example an invited external party) sees and does only what authority allows, and cannot execute Business operations. Current: grants and Policies cannot scope visibility to individual instances, and Policy applies per operation across the Business (PRR-060). How Guest visibility is expressed is undecided. - **Evidence:** PRR-060; [identity and governance](../architecture/identity-and-governance.md#licensed-and-guest-users). - **Why/Impact:** Do not invent a mechanism, a visibility store or a new Type. - **Deps:** Stu; PRR-060 and PRR-063. - **Fix:** Owner decision within the universal authority mechanics. - **Trigger:** Guest access is designed or built. - **Close:** Documented scoping mechanism and an isolation check. - **Prod:** Medium. #### PRR-065 Mechanism for synthetic promotional preview content is unresolved **Classification:** Architectural gap · **Severity:** Medium · **Status:** open - **Cur/Int:** Requirement (owner): synthetic promotional content shown to an unsubscribed Business must never become genuine Business data in the authoritative Business Graph. Mechanism: unresolved; no storage mechanism or second data model is introduced. Current: no preview is implemented. - **Evidence:** [unsubscribed Business and promotional preview](../architecture/subscriptions-and-entitlements.md#unsubscribed-business-and-promotional-preview); [views and content](../architecture/views-and-content.md). - **Why/Impact:** The existing demo population is explicit demonstrator data, not preview content, and must not be read as the mechanism. - **Deps:** Stu; PRR-063. - **Fix:** Owner decision that satisfies the requirement within the universal Object model. - **Trigger:** Preview presentation is designed or built. - **Close:** Documented mechanism and evidence that preview content cannot appear in the authoritative Business Graph. - **Prod:** Medium. #### PRR-066 User account to Person profile privacy and transfer mechanisms are unresolved **Classification:** Architectural gap · **Severity:** High · **Status:** open - **Cur/Int:** Intended conceptual model (owner, 2026-11-02): the User account is the source of truth for personal information; a Person profile is Business-scoped; the User-to-Person relationship is always Business-scoped; personal information is never visible to a Business merely because a Person is associated with the User; transferred information becomes subject to Business-scoped access and privacy rules; a Business cannot access another Business's Person profile. Current: the Person Contact Profile Type holds `display_name`, `email`, `telephone` and `biography`; the Relationship Type `...0106` is declared and inert (PRR-059). - **Evidence:** [User account and Person profile](../architecture/identity-and-governance.md#user-account-and-person-profile); PRR-052, PRR-057, PRR-058, PRR-059. - **Why/Impact:** Unresolved: which User attributes may be copied; copy or move; whether changes propagate; whether the User must authorise each disclosure; the effect of deletion, retention and privacy requests on copied data. No one-to-one relationship or synchronisation is assumed. - **Deps:** Stu; privacy and lawful-basis review; PRR-057, PRR-058, PRR-059. - **Fix:** Owner decisions, then governed Type and relationship design. - **Trigger:** Any User-to-Person link, personal-attribute storage, or profile transfer is planned. - **Close:** Documented decisions, privacy approval and cross-Business isolation evidence. - **Prod:** High; personal data handling is a production gate. #### PRR-067 Billing and pricing-transition rules are unresolved **Classification:** Deferred capability · **Severity:** Medium · **Status:** deferred - **Cur/Int:** The bands are the current working commercial proposal (1-30 Licensed Users £199 a month; 31-100 £499; 101-500 £1,499; 501 and over from £2,499, individually negotiated). Pricing-transition rules, point-in-time counting, billing periods, the commercial payer or manager and lapse timing are unresolved. Current: no billing is implemented. - **Evidence:** [subscriptions and entitlements](../architecture/subscriptions-and-entitlements.md#commercial-model-current-working-proposal). - **Why/Impact:** Commercial terms, not feature tiers; no code or configuration may embed them as authority. - **Deps:** Stu; PRR-063. - **Fix:** Owner decisions recorded in the commercial owner. - **Trigger:** Billing design or build is authorised. - **Close:** Documented rules and billing evidence. - **Prod:** Medium. ### Tests and verification evidence #### PRR-029 Full PHPUnit suite is not recorded green **Classification:** Known defect · **Severity:** High · **Status:** open - **Cur/Int:** The latest recorded full run (605 tests) failed `testNestedPresentationObjectsUseIndependentContentLayout` and five `Idy006GraphTest` cases (recorded as pre-existing). Earlier sections record other failures (legacy Dashboard fixtures, `Idy006BPresentationTest`, `Idy004AccessTest`/`GenericStoreAndGenesisTest`). Conditional skips: Policy lifecycle, Windows symlink, Spearmint absent from snapshot. Update 2026-10-28 (targeted runs on the current checkout, not a full run): the nested-layout failure was bisected to `1b1422f` (its assertions encoded a wrapper/`presentation-mode-expanded` contract that the renderer no longer emits and that no CSS or JS reads) and the test was corrected to the current contract; `tests\Runtime\Presentation` is OK (37). The five `Idy006GraphTest` failures were re-run and reproduce identically at `c9492a8`, so they predate this phase (one-hop graph requests return 503 in the test harness; cause not investigated). `tests\Unit` OK (172, 1 skipped), `Idy006BPresentationTest` OK (50), `TargetReleaseManifestTest` OK. The full suite was still not run. Update 2026-10-29: the full suite was run on the working tree (644 tests, 5,091 assertions): the only failures are the five `Idy006GraphTest` cases already recorded as pre-existing (4 failures returning 503 and 1 TypeError), with 3 conditional skips; no regression was introduced by the authority reconciliation work. It is still not recorded on a clean checkout in CI. - **Evidence:** status.md; `phpunit.xml`. - **Deps:** Disposable test DB (PRR-032). - **Fix/Trigger:** Fix or formally retire each failure; trigger is the next full run. - **Close:** Full-suite run output for a named commit with zero unexplained failures. - **Why/Impact:** Regression confidence unknown. **Prod:** High. #### PRR-030 No automated test job in CI **Classification:** Production-readiness risk · **Severity:** High · **Status:** open - **Cur/Int:** The build workflow builds and deploys to STAGING; it runs no PHPUnit job. Intended: tests gate deployment. - **Evidence:** `.github/workflows/build-target-release.yml`. - **Deps:** CI needs a test database; the policy is a staging-cloned disposable database (PRR-032): a design decision is unknown. - **Fix/Trigger:** Decide CI test mechanism; trigger is the next workflow change. - **Close:** A required passing test run on a pull request or push. - **Why/Impact:** Any push to `main` deploys untested code to STAGING. **Prod:** High. #### PRR-031 Weak assertions in tests **Classification:** Known defect · **Severity:** Low · **Status:** open - **Cur/Int:** `assertTrue(true)` patterns in WorkflowDefinitionValidatorTest, TypeDescriptorValidatorTest, ConfigurationReleaseVerifierTest, TargetProvisioningPreflightTest and OperationFoundationTest (agent report, not re-verified). - **Evidence:** test scan. - **Deps:** None. **Fix/Trigger:** Strengthen at next edit of each file. - **Close:** Assertions that fail on regression. - **Why/Impact:** False confidence. **Prod:** Low. #### PRR-032 Test infrastructure dependencies **Classification:** Operational dependency · **Severity:** Medium · **Status:** open - **Cur/Int:** Tests need a disposable database refreshed from staging by `bin/refresh-test-database-from-staging.ps1` and `IDY_TEST_*` settings. `vendor/` is absent in this checkout, so `vendor\bin\phpunit` is unavailable; `bin\run-tests.ps1` treats stderr noise as fatal. - **Evidence:** repository check 2026-10-28; [development](development.md). - **Deps:** Staging read access; approver unknown. - **Fix/Trigger:** Document setup steps; trigger is the next test run. - **Close:** A documented clean-checkout test run. - **Why/Impact:** Hard to reproduce results. **Prod:** Medium. #### PRR-033 HTTP acceptance suite is excluded and local-only **Classification:** Operational dependency · **Severity:** Medium · **Status:** open - **Cur/Int:** `tests/HttpAcceptance` is outside PHPUnit and must not run against STAGING. Remote acceptance evidence is mostly manual STAGING browser checks in status.md. - **Evidence:** `phpunit.xml`; status. - **Deps:** None. - **Fix/Trigger:** Decide a repeatable acceptance path. - **Close:** A recorded repeatable acceptance run. - **Why/Impact:** Acceptance not reproducible. **Prod:** Medium. #### PRR-034 Destructive staging purge code has no tests **Classification:** Production-readiness risk · **Severity:** High · **Status:** open - **Cur/Int:** `app/Staging/BusinessPurgeRepository.php` and `bin/purge-non-spearmint-businesses.php` (referenced only by each other) delete Business data, guarded by environment variables and database-name checks. No tests reference it. `app/Release` holds a staging reset path. - **Evidence:** grep of `tests`, `app` and `bin` on 2026-10-28. - **Deps:** None. - **Fix/Trigger:** Add guard tests or remove from the release package; trigger is before any non-STAGING environment exists. - **Close:** Tests proving refusal on a non-staging database name. - **Why/Impact:** Data-loss risk if misdirected. **Prod:** High. ### Operations and deployment #### PRR-035 Staging deployment uses password SSH with host-key checking disabled **Classification:** Production-readiness risk · **Severity:** High · **Status:** open - **Cur/Int:** `bin/staging-deploy.sh` uses `sshpass`, password authentication, `StrictHostKeyChecking=no` and `UserKnownHostsFile=/dev/null`. Intended for production: key-based authentication and a pinned host key. - **Evidence:** `bin/staging-deploy.sh` lines 25, 82-83. - **Deps:** Hosting capability: unknown. - **Fix/Trigger:** Before any production deployment reuse of this script. - **Close:** Authentication and pinned-host-key change verified on a deploy run. - **Why/Impact:** Man-in-the-middle exposure of the deployment credential. **Prod:** High. #### PRR-036 GitHub Environment protections recorded NOT CONFIGURED **Classification:** Production-readiness risk · **Severity:** High · **Status:** open - **Cur/Int:** status.md (≈4948-4951) records required reviewers, branch/tag restrictions, initiation restrictions and bypass control as NOT CONFIGURED. Settings are not in the repository and were not re-inspected. Batches 14-19 contradict each other on manual versus automatic deployment. - **Evidence:** status.md; workflows use `environment: staging`. - **Deps:** Repository admin: Stu (assumed; not recorded). - **Fix/Trigger:** Inspect the live settings and record them. - **Close:** A dated settings export or screenshot reference. - **Why/Impact:** Deployment approval is not enforced. **Prod:** High. #### PRR-037 Automatic deployment and chained migration on every push to `main` **Classification:** Temporary decision · **Severity:** Medium · **Status:** open - **Cur/Int:** `build-target-release.yml` deploys to STAGING on push to `main`; the profile-migration workflow follows on `workflow_run` success. The runs for `d2c0f09` were observed: profile migration succeeded. Intended for production: gated release. The previous push trigger on reconciliation was removed in `d2c0f09`. - **Evidence:** workflow files; GitHub run list. - **Deps:** PRR-036. - **Fix/Trigger:** Review when PRR-036 is settled. - **Close:** Documented, enforced promotion rule. - **Why/Impact:** Merge equals deploy on STAGING. **Prod:** High if reused. #### PRR-038 Push-triggered utility workflows **Classification:** Production-readiness risk · **Severity:** Low · **Status:** open - **Cur/Int:** The demo population workflow runs on push when the commit message contains `[populate-staging]`; the registration diagnostic workflow has a push trigger (scope not examined). - **Evidence:** `staging-spearmint-demo-population.yml` line 28; `staging-registration-diagnostic.yml` lines 4-5. - **Deps:** None. - **Fix/Trigger:** Make dispatch-only before wider contributor access. - **Close:** Workflow files changed and a run history showing none triggered by push. - **Why/Impact:** Accidental data changes on STAGING. **Prod:** Low. #### PRR-039 Hosting prerequisites not scripted **Classification:** Operational dependency · **Severity:** High · **Status:** open - **Cur/Int:** PHP `mail()` targets localhost:25 so registration returned 503 without an MTA; proxy-header HTTPS trust, `APP_ENCRYPTION_KEY` and cron are host configuration outside the repository. Intended: documented and checked prerequisites. - **Evidence:** status; [security and operations](security-and-operations.md) (new-runtime configuration requirements not yet implemented or checked). - **Deps:** Hosting provider access: unknown. - **Fix/Trigger:** Add a prerequisites checklist and preflight check. - **Close:** Preflight output on a named environment. - **Why/Impact:** Registration, secure cookies and encryption can fail in a new environment. **Prod:** High. #### PRR-040 Provisioning is manual and STAGING-only **Classification:** Operational dependency · **Severity:** High · **Status:** open - **Cur/Int:** Migrations, Genesis, vocabulary, platform opening and publisher install are operator CLI steps that require `IDY_STAGING_DB_NAME` and `IDY_TARGET_DEFINITION_PUBLISHER_PRINCIPAL_ID`. There is no environment selector beyond `--database=staging`. - **Evidence:** status provisioning sections; `bin/`. - **Deps:** PRR-001. - **Fix/Trigger:** Define the production provisioning contract when PRR-001 is authorised. - **Close:** Rehearsed provisioning on disposable infrastructure. - **Why/Impact:** Not reproducible. **Prod:** High. #### PRR-041 Required variables and secrets are not reproducibly provisioned **Classification:** Operational dependency · **Severity:** Medium · **Status:** open - **Cur/Int:** SSH host/port/user/password, `STAGING_REMOTE_ROOT`, `IDY_TARGET_DB_*`, `IDY_OPERATOR_PASSWORD` and related values exist only in GitHub/hosting settings. No inventory records them (names only; never values). - **Evidence:** workflows; deploy script. - **Deps:** Admin access. - **Fix/Trigger:** Record names and owners (no values). - **Close:** Inventory document reviewed against workflow references. - **Why/Impact:** Loss of settings blocks recovery. **Prod:** Medium. #### PRR-042 AuthorityGrant legacy contract migration is manual and not live-verified **Classification:** Resolved-but-requires-verification · **Severity:** Medium · **Status:** resolved pending verification - **Cur/Int:** Migration is a manual STAGING workflow. Live transition evidence for the `from_state_id` hardening is one Project planned→active transition (run 511). - **Evidence:** `staging-authority-grant-migration.yml`; status. - **Deps:** None. - **Fix/Trigger:** Further live transition tests at next State change. - **Close:** Recorded live transitions for each State machine in use. - **Why/Impact:** Security-relevant hardening has narrow evidence. **Prod:** Medium. #### PRR-043 Profile payload size workaround **Classification:** Temporary decision · **Severity:** Low · **Status:** open - **Cur/Int:** The profile exceeded the 128 KiB environment-variable limit and is passed gzip+base64; a manual dispatch fallback remains for exceptional runs. - **Evidence:** profile-migration workflow; status. - **Deps:** None. **Fix/Trigger:** Revisit when the profile grows or PRR-012 closes. - **Close:** Payload delivered without size workaround. - **Why/Impact:** Fragile deployment step. **Prod:** Low. #### PRR-044 No security certification or penetration test; security configuration unchecked **Classification:** Production-readiness risk · **Severity:** High · **Status:** open - **Cur/Int:** [Security and operations](security-and-operations.md) states there is no certification or pentest, and new-runtime configuration requirements are not implemented or checked. - **Evidence:** that document. Backup/restore, monitoring, alerting and data-retention evidence was not located; see Part C. - **Deps:** Budget/approver: unknown. - **Fix/Trigger:** Before any production user access. - **Close:** Independent test report and remediation evidence. - **Why/Impact:** Unknown exposure. **Prod:** High. #### PRR-045 Workstation HTTPS verification fails (`CRYPT_E_REVOCATION_OFFLINE`) **Classification:** Operational dependency · **Severity:** Low · **Status:** open - **Cur/Int:** Direct HTTPS checks from the audit workstation failed earlier; verification relied on workflow runs and the browser tool. - **Evidence:** audit session. **Deps:** workstation configuration. - **Fix/Trigger:** Fix revocation checking or document the alternative. - **Close:** Successful direct request. - **Why/Impact:** Weakens independent verification. **Prod:** Low. #### PRR-046 WordPress adapter unbuilt and unverified **Classification:** Deferred capability · **Severity:** Low · **Status:** deferred - **Cur/Int:** [WordPress](wordpress.md) documents discovery only. Backend-specific; not a platform dependency. - **Evidence:** that document. **Deps:** Product decision: unknown. - **Fix/Trigger:** First WordPress delivery requirement. - **Close:** Verified draft delivery. - **Why/Impact:** None unless used. **Prod:** Low. ### Documentation hygiene #### PRR-047 Tracked root-level completion reports claim production readiness **Classification:** Production-readiness risk · **Severity:** High · **Status:** open - **Cur/Int:** About 50 tracked root files (e.g. `PRODUCTION-DEPLOYMENT-READY.md`, `DEPLOYMENT-READINESS-FINAL.md`, `BUILD-COMPLETE-SUMMARY.txt`, `PROJECT-COMPLETION-*.md`, `WORK-COMPLETED.md`, `IMPLEMENTATION-STATUS.txt`) state "production ready" or "complete", some for the legacy marketing application. They are outside the authority map and contradict this register. - **Evidence:** repository root listing (agent report); not individually reviewed. - **Deps:** Archive/removal authorisation: Stu. - **Fix:** Mark non-authoritative or move to `docs/archive/`; do not delete without authorisation. - **Trigger:** Next documentation housekeeping or any external review of the repository. - **Close:** Files archived or marked, with the authority map referencing the disposition. - **Why/Impact:** A reviewer may take them as readiness evidence. **Prod:** High (misleading evidence). #### PRR-048 Stale competing documents under `docs/` **Classification:** Known defect · **Severity:** Medium · **Status:** open - **Cur/Int:** `docs/implementation/PHASE-7-COMPLETION.md` ("production ready"), `Phase-8-Implementation-Status.md`, `UI-CAPABILITY-PROJECTION-FIX.md`, `PRESENTATION-*.md`, `docs/Phase-8-*.md` sit outside the 35-active-document structure and outside the authority map (see the active-document inventory in [documentation governance](../governance/documentation.md#granularity-and-archive-policy)). - **Evidence:** glob of `docs/`. - **Deps:** Archive authorisation: Stu. - **Fix/Trigger/Close:** As PRR-047. - **Why/Impact:** Competing sources. **Prod:** Medium. #### PRR-049 status.md is unordered, contains mojibake and contradictions **Classification:** Known defect · **Severity:** Medium · **Status:** in progress - **Cur/Int:** 5,346 lines (466 KB), not chronological; headings contain mojibake; sections contradict each other (PRR-005, PRR-036). This audit adds a top summary and this register but does not rewrite history. - **Evidence:** status.md. **Deps:** Stu's approval to restructure. - **Fix/Trigger:** Archive superseded sections when approved. - **Close:** status.md reduced to current evidence with history archived. - **Why/Impact:** Hard to find the current state. **Prod:** Medium. #### PRR-050 Legacy marketing artefacts remain in the repository **Classification:** Known defect · **Severity:** Low · **Status:** open - **Cur/Int:** `database/migrations/20260902_campaign_automation_controls.sql` creates legacy campaign tables; the release manifest packages only `database/runtime-migrations/*.sql`, so it is not deployed. Old `build-*.txt` logs and root logs (e.g. `full-suite.log`, 2026-09-16) are old local artefacts and are not current evidence. - **Evidence:** `release/target-release.json`; file inspection. - **Deps:** Removal authorisation: Stu. - **Fix/Trigger:** Archive at housekeeping. - **Close:** Files archived or documented as legacy. - **Why/Impact:** Confusing artefacts. **Prod:** Low. ## Part B: Production-Readiness Gap Assessment (2026-10-28) The platform is **not** declared production ready. Nothing in this audit authorises production work. 1. **Executive summary.** The STAGING demonstrator works for the eight workspaces and bounded sequential workflows. Production readiness is blocked by missing governance decisions (PRR-002, PRR-003), the absence of any production path (PRR-001), unreproducible and unverified operations (PRR-035 to PRR-041), a non-green and ungated test position (PRR-029, PRR-030) and unbuilt or unverified runtime capabilities (PRR-016, PRR-017). 2. **Production blockers.** PRR-001, PRR-002, PRR-003 (Critical); High items that must be resolved or formally accepted first: PRR-004, PRR-005, PRR-006, PRR-008, PRR-010, PRR-016, PRR-017, PRR-027, PRR-029, PRR-030, PRR-034, PRR-035, PRR-036, PRR-039, PRR-040, PRR-044, PRR-047. Acceptance decisions: none exist. 3. **Necessary temporary restrictions.** PRR-008 (New hidden on revision-1 Views), PRR-012 (profile containment), PRR-004 and PRR-026 (Presentation compositions and temporary admin surface), PRR-037 (auto-deploy to STAGING only), PRR-043 (payload workaround). These are acceptable only on STAGING. 4. **Deferred stages.** Stage 3D (PRR-002, PRR-009); Capability Definition build (PRR-003); IDY-008 Operation and adapter (PRR-010); workflow runtime beyond Slice 1 (PRR-016); real Action effects (PRR-017); Policy lifecycle (PRR-013); Forms (PRR-011). None may start without the stated authorisation. 5. **Unverified or defective behaviour.** PRR-005, PRR-006, PRR-018, PRR-019, PRR-022, PRR-029, PRR-042, plus STAGING facts not inspected (Part C). 6. **Source-only features.** Features present in code or documentation without live verification: display-scope states and empty states (PRR-027), live recovery (PRR-018), WordPress (PRR-046), Policy lifecycle code paths (PRR-013) and the non-conforming Definition publisher (PRR-003). 7. **Operational prerequisites.** PRR-036, PRR-039, PRR-040, PRR-041, PRR-032, PRR-045; plus backup, monitoring and retention (Part C). 8. **Prioritised resolution sequence.** (a) Close governance: PRR-002, PRR-003, then PRR-004/PRR-012. (b) Restore verification: PRR-005, PRR-029, PRR-032, PRR-030. (c) Correct authority defects: PRR-006, PRR-008/PRR-009, PRR-021. (d) Make operations reproducible: PRR-036, PRR-035, PRR-041, PRR-039, PRR-040, PRR-010, PRR-022. (e) Runtime capability: PRR-016, PRR-017, PRR-018. (f) Quality gates: PRR-027, PRR-044, PRR-034. (g) Housekeeping: PRR-047, PRR-048, PRR-049, PRR-050. Order within a step follows dependencies named in each item; this is an engineering ordering, not a schedule or owner assignment. 9. **Evidence required to close.** Each item's *Close* field. Common forms: a recorded full-suite run for a named commit; a successful GitHub Actions run for a named commit; a dated STAGING browser or query check; a recorded human decision reference. 10. **Evidence gaps.** See Part C. ## Part C: Evidence and Audit Limits Inspected: governing documents, [status](status.md) (read in slices by read-only agents; coverage of that 466 KB file is not guaranteed complete), implementation and architecture documents, application source (targeted scans), `tests/`, `phpunit.xml`, workflows, `bin/` scripts, release manifest, git history to `d2c0f09`, GitHub Actions run metadata (728 runs, 0 open issues) and one read-only STAGING browser session. Not inspected or not determinable: - C1: Live STAGING database and server state (executions, record counts, persisted View/Type revisions). The persisted state after the rejected pin is presumed unchanged because reconciliation failed; unverified. - C2: Backup/restore, monitoring, alerting, log retention and data-retention arrangements; no evidence was located. - C3: GitHub Environment, secret and branch-protection settings (not in the repository). - C4: Hosting configuration (MTA, proxy, cron, key storage). - C5: Production systems of any kind: not accessed and not authorised. - C6: Test results: no test or build was run; recorded results in status.md are second-hand. - C7: Line-level confirmation of several code findings reported by read-only agents (marked "not re-verified"). - C8: Content of the ~50 root completion reports (identified by name and heading only). - C9: Dependency licences and vulnerability scanning; no evidence located. - C10: The build workflow run for `d2c0f09` was not individually confirmed; the dependent profile-migration run (created 2026-10-28 09:40:57Z) succeeded. - C11: A concurrent session committed `d2c0f09` during the audit; findings reflect that commit. ## History - 2026-10-28: Created from a full documentation, code, test, workflow and git audit. Supersedes no earlier register; none existed. No item was found `verified resolved`. - 2026-10-28 (UI phase): added PRR-051 (KPI history), PRR-052 (identity detail attributes) and PRR-053 (saved layout preferences); updated PRR-025 and PRR-029 with the nested-layout test diagnosis and the re-verified pre-existing `Idy006GraphTest` failures. Items 051-053 sit beside PRR-028 in the User interface group, not at the end of the list. - 2026-10-28 (KPI cards): added PRR-054 (time-axis zero-fill and completeness semantics, beside PRR-053); updated PRR-051 (Marketing Responses history, per-source dating audit) and PRR-052 (read-only STAGING inspection of identity Definitions and constituents). - 2026-10-29 (KPI inventory): added PRR-055 (compact metric-only KPI height; Campaign and Milestone date properties as a Stage 3D dependency); updated PRR-051 with the full 18-KPI history assessment. - 2026-10-29 (identity detail): added PRR-056 (Constituent Objects unreadable under the administrator's inspection grants; STAGING id probe); updated PRR-052 with the probe result and the Business and Principal record templates (profile revision 19). Counts: 56 items, blocked 6, Medium 23, Architectural gap 7. - 2026-10-29 (authority reconciliation): added PRR-060 (grants and Policies cannot scope operations per target; four dedicated identity grants, relate-as-create, traversal on the profile relationship only); updated PRR-056 (mechanism superseded) and PRR-029 (full suite run). Counts: 60 items, in progress 5, Medium 27, Architectural gap 9. - 2026-11-02 (User and commercial model reconciliation; documentation only): added PRR-061 (legacy Principal identifiers), PRR-062 (non-human actors and delegated succession), PRR-063 (entitlement, Licensed/Guest and activation unbuilt), PRR-064 (Guest authority scoping), PRR-065 (preview-content mechanism), PRR-066 (User account to Person profile privacy) and PRR-067 (billing and pricing transitions); added a Part A terminology note covering PRR-052, PRR-056, PRR-057, PRR-058, PRR-059 and PRR-060, whose "Principal" wording is legacy for User and is otherwise unchanged. Counts: 67 items, open 42, deferred 13, blocked 5, High 21, Medium 31, Deferred capability 14, Architectural gap 14. No implementation, database or STAGING change; all Businesses remain treated as active.