Kernel R1 — UAT Handover

1. Handover purpose and current decision

This package hands the implemented Kernel scope to the UAT team for structured execution. It combines module walkthroughs, end-user procedures, source-backed implementation scope, cross-module ownership, editable test records and existing engineering evidence.

“R1” is the logical handover baseline requested for this package. The application was delivered through multiple recorded component releases. This document does not invent a single new application build or deployment tagged R1. The release owner must confirm the active UI, APIs, workers, database migrations and published configuration as one frozen UAT baseline.

The scope is Kernel only, including MEDES. The reader scope contains only Kernel module procedures. Integrum, full Nexus and PGATE remain labelled architecture references; only the implemented bounded Nexus connection/source-refresh capability is included in the Studio/Scheduler paths.

2. Package map and how to use it

1. Read the scope and gaps; agree which capabilities are in this UAT cycle.
2. Complete Environment, Access, Test Data and Entry Gates in the workbook.
3. Follow the relevant walkthrough, then use the end-user guide for field, lifecycle and recovery details.
4. Execute the linked cases and per-screen checks. Record actual results and evidence; raise defects immediately.
5. Complete cross-module and negative tests, regression, cleanup and exit gates.
6. Sign the module and overall decision against the frozen installation.

Extract the ZIP before opening files. The documentation library works offline and retains its screenshots and fonts; application links still require authorized login and network connectivity. CSVs are portable mirrors of the initial workbook. Choose one execution register as the source of truth; they do not synchronize automatically.

3. Module-by-module implementation baseline

4. Platform boundaries and cross-module flow

The application owner retains business data and business decisions. IAM owns identity, selected context, authorization and cross-boundary security bridges. Axis owns presentation metadata and rendering. Tenant Engine/TCP own tenancy and readiness; Regulix owns governed orchestration; TimeVault governs configured temporal records; Custodia owns evidence custody; Vista/Pulse own content/output; Scheduler dispatches registered owner operations.

Execute in dependency order: Core references → tenant/subscription/configuration → environment and entitlements → IAM context → Axis rendering → owner definitions and datasets → business authoring → independent decisions → publication → execution/delivery → audit and recovery. Read-only browsing can proceed in parallel where prerequisites already exist; blocked mutations must retain their dependency reason.

1. Organization to access: Core organization → Tenant evidence/subscription → TCP environment/grants → IAM account/profile/roles → Axis screen/control rendering.
2. Data to content: define/pick source → build/pick related datasets → independently review/publish dataset → name/basic details → report/template/dashboard Studio → saved current-data preview → independent review → publication.
3. Content to automation: published artifact/version → registered Scheduler job/Run as/binding → preview → independent review → publish → schedule/calendar/queue → owner output → attempts/audit.
4. MEDES: member/case → Custodia evidence/admission → Regulix work/review → Pulse correspondence → provider-specific delivery → response → Vista reporting and audit.

Open cross-module walkthroughs · see the corresponding separate package · Open ownership and integration handbook · see the corresponding separate package

5. Existing evidence and what it establishes

The latest retained production screen report is dated 2026-10-19T22:58:35.010392+00:00. It records 306 unique actual-user screens passing within a rendered-menu union of 307, and 394 passing profile/screen checks with 1 failed check. These are different denominators. They are not percentages of completed business UAT.

The remaining failed screen is Security Dashboard: the recorded configuration guard required publication of a reviewed security page. MEDES access inspection separately found no relevant grants in the inspected profiles. Later configuration changes have not been re-queried during packaging.

Earlier native and fixture tests cover presentation, authorization boundaries, migrations, worker behavior and selected business paths. Their scope is retained in the evidence register. Documentation verification covers file rendering, links and downloads only. New UAT cases remain unexecuted.

6. Environment, identities, fixtures and entry gates

Use the known MediFlex deployment URL only after the environment owner confirms the intended UAT target. Do not assume the public production portal is a disposable test environment. Record the actual release and context in the workbook; do not put passwords, session cookies, tokens or provider secrets in test evidence.

Functional actors

Data preparation

7. UAT execution plan and evidence rules

The execution register contains 280 cases: 245 retained module procedures and exceptions plus 35 dedicated cross-module, security, lifecycle, output and operational cases. The screen register contains 554 entries: 484 application source routes, 32 native IAM screens, 37 separate Regulix entries and one explicitly unverified Atlas portal entry. A route is not proof of a deployed usable feature; use the scope and gate columns.

How to record a result

1. Assign tester and selected profile, tenant/domain, environment and build before acting.
2. Read preconditions, exact screen and expected result. Use the walkthrough’s numbered steps and screenshots; capture current evidence for UAT.
3. Execute once. Record created record IDs, versions, output references and request correlation where relevant.
4. Compare actual behavior to expected behavior. Choose Pass, Fail, Blocked or Not applicable. A planned case stays Not run.
5. Attach evidence and defect/dependency ID. Blocked is not Pass. Not applicable needs a release-owner scope decision.
6. For a fix, preserve the original failure, record fix baseline and a separate retest result.

Evidence naming: R1_<case-id>_<profile>_<step>_<UTC-date-time>. Retain screen/record state before and after, exact decision/output reference, selected context and the relevant response/correlation ID. Mask personal data and secret values. A screenshot of an empty grid is evidence of that read state, not proof of create/approve success.

For screen checks, inspect standard header and Back placement, actual font/icon/theme, dynamic menus, control/data authorization, originating-row review, create/edit/concurrency, explicit active/inactive behavior and responsive/SPA navigation. Mark review or lifecycle checks N/A only when the screen has no such operation and document why.

8. Known gaps, parked work and exclusions

The following are carried forward from dated source records and the established scope. They are not all software defects: some are owner approvals, data/provider setup, roadmap scope or unexecuted acceptance. Assign named owners and dispositions before UAT begins.

9. Defect management and regression

Use New → Triaged → In progress → Ready for retest → Closed, or Reopened / Deferred with accepted-risk reference. Priority P0/P1/P2 indicates execution or fix urgency; it is not severity. Capture reproducible steps, expected and actual outcomes, exact baseline, profile/context and evidence. Never “fix” a failed authorization test by granting an unrelated broad administrator role.

After correction, rerun the failing case, a neighboring positive case, its permission-denied counterpart and affected downstream handoff. For data or publication fixes, verify old immutable history and current version binding. For retry fixes, verify no duplicate owner side effect. Keep original and retest records.

10. Operations, support and safe recovery

Release and rollback boundary

Before UAT freeze, the release owner reconciles the historical receipts with the active installation and signs the environment record. If a correction is needed, build a bounded candidate, rehearse exact migrations/configuration and rollback in isolation, obtain required release authorization, deploy the reviewed artifact, verify health plus affected authenticated journeys and issue a new UAT baseline. This package itself deploys nothing.

Rollback must use the matching component receipt, verified backup and change-specific procedure. A UI rollback does not roll back database/configuration changes. A database restore or job cancellation does not undo a provider’s accepted delivery. Stop new dispatch as authorized, record in-flight work, reconcile owner outcomes and then follow the approved recovery sequence. Keep immutable attempts and audit history.

Complete the support roster in Environment. Route identity/access failures to IAM, presentation metadata to Axis, tenant facts to Tenant/TCP, data connections to the data/integration owner, content/output to Vista/Pulse, execution to Scheduler, and business case decisions to MEDES/Regulix. Escalation contacts and service targets must be assigned; no names or SLAs are invented here.

11. Exit criteria and formal acceptance

Allowed decisions are Accept, Accept with conditions, or Reject. Conditional acceptance must list exact modules/capabilities excluded, defect/gap IDs, workaround, responsible owner and target decision/date. The presence of manuals or historical engineering passes does not satisfy an exit gate.

Use the workbook Sign Off tab for each module and the overall decision. The printed form is a signature aid; store its approved copy and reference it in the same controlled register.

12. Traceability, package integrity and document control

There are 90 requirement/journey entries mapped to 280 cases. Each retained module case links to its precise walkthrough/manual chapter; the workbook includes the procedure text and expected result. The screen catalog and 34 originating-record review commands complement journey coverage. These inventories provide a test allocation baseline, not a claim that every path or policy permutation has passed.

Evidence snapshots retain source SHA-256. Selected large records are reduced to their relevant summary fields; originals remain identified by their source hash. Historical production reads are provided in a separate CSV, not merged into R1 execution results. The Kernel reader revision retains earlier procedures in HTML. Infrastructure references outside the reader scope use operator reference IDs; resolve those IDs against the controlled source baseline before executing a command.

The final ZIP has an integrity receipt and file SHA-256 manifest. Keep the issued ZIP unchanged. Make a dated working copy of the workbook/registers for execution; its changed hashes are expected. Archive the completed workbook, evidence and signed decision as a new UAT outcome edition.

Prepared by: Kernel engineering documentation handover. Document date: . Business signatories: pending. Application build: confirm in Environment and Release Baseline. New deployment during packaging: none. New business acceptance during packaging: none.

Current release additions and acceptance

The following changes update the earlier handover baseline. Earlier results retain their original scope. The additional business UAT cases start Not run and require actual tester evidence.

Feature register · Additional UAT cases · New evidence index

MEDES entry gate: technical installation is complete; target activation is incomplete. Role grants, enabled APIs and document-review route must be verified before a live business demo. Provider-based delivery additionally requires approved provider setup and authorized destinations.

Verification boundary: the Axis screen-context release records 35 rollback-only database checks, 12 UI tests and 15 fixture-browser checks. The notification contract correction records 11 schema checks and 17 rollback-only database checks. These are not a complete authenticated production journey or a new client UAT sign-off.