user-engine/docs/platform-admin-acceptance.md

Platform administrator acceptance

Priority workplan: USER-WP-0030. Platform administration requires the platform operator role and MFA; policy changes and factor recovery require recent MFA. Membership in every tenant is not required. Ordinary tenant administrators cannot read cross-tenant platform support records.

Journey	Implemented acceptance	Remaining integrated evidence
P01 Platform entry	Role-aware navigation and tenant-independent console; member denial	Existing provider sign-in acceptance still applies
P02 Tenant and first admin	Authority readback, local bootstrap rollback and retry without duplicate admin	Real first-admin sign-in depends on provider
P03 Tenant inspection	Exact identifier, ambiguous-name handling and selected scope	No new implementation gap
P04 Administrator recovery	Tenant restoration and recent-MFA lost-factor preview, proof attestation, signed scope confirmation, audited disable/readback/retry and replacement enrollment	Implemented and deployed; evidence: evidence/2026-09-13-p04-recovery.md
P05 Service operations	Checked provider/credential/mail status, controlled selected delivery and uncertain-outcome recovery	Deployed; see evidence/2026-09-13-p05-service-operations.md. Actual customer inbox receipt remains a user journey.
P06 Authentication policy	Recent-MFA scoped policy preview/apply/audit/rollback; mandatory and optional-after-enrollment; application MFA wins	Deployed and persisted; see evidence/2026-09-13-p06-authentication-policy.md.
P07 Tenant lifecycle	Authority version/confirmation, stale-state rejection and recovery	Application propagation must be verified at the application
P08 Support investigation	Exact reference across audit/delivery records, tenant filter, safe metadata, unknown-evidence state and delivery drill-down	Provider actions require provider evidence; portal records alone cannot prove rollback

Investigate a support reference

Open Platform activity from the platform navigation. Paste the exact support reference and optionally the full tenant identifier. The view matches before limiting display to the newest 100 records. It shows recorded actor/action and current delivery state without raw payloads, free-text audit summaries, or provider errors. Follow Inspect delivery to its retry/readback page. No matching records means evidence is missing; it does not prove no action happened.

Restore tenant access

Open the tenant's users page and choose Restore tenant account. Check the named person and tenant in the confirmation. Verify the request through the established support process. The operation restores that tenant account and prepares a missing directory login. It does not reset a password, remove an authenticator, clear a global suspension or prove account ownership. Use provider recovery for those cases. Cancel makes no change; failed provider readback must not become local success. Keep the support reference when escalating.

Run acceptance

make test
make test-journeys JOURNEY_ARGS="--role platform_admin --report /tmp/platform-admin-report.json"
make test-browser-journeys
make test-journeys JOURNEY_ARGS="--role platform_admin --require-complete"

The platform completeness selection now includes P04–P06 and must pass with --require-complete. The portal regression suite has 232 tests with disposable PostgreSQL enabled; 30 isolated Chromium checks pass. Installed-provider native and browser acceptance is recorded separately in P06 evidence. Customer sign-in and application access remain USER-WP-0028 / KEY-WP-0034 / VERGABE-WP-0019.

Historical provider handoff (superseded for P04–P06)

KEY-WP-0035/NK-WP-0033 and USER-WP-0030-T03 retain the provider gap. The registered net-kingdom-privacyidea-admin-token route was rechecked and remains non-resolvable: concrete custody path/fields, expiry/revocation and approved attended action are unpublished. A provider credential for attended resolver repair must not be assumed to be the correct ongoing realm-scoped factor-read credential. The owner must establish the consumer contract and verify its exact permissions and renewal before policy or recovery rollout. No secrets belong in this document, support references, chat or activity records.

P04 recovery now uses the signed platform session and private provider service. Use Authenticator recovery for exact-login preview and support-reference readback. No provider credential or OpenBao login is requested from the operator. See evidence/2026-09-13-p04-recovery.md for the implemented boundary and acceptance.

RPF-WP-0040 supplies the dedicated factor-read credential and renewal contract. P05 verified its operating recovery; P06 deployed scoped policy and guarded onboarding. The historical resolver-credential incident remains NK-WP-0033, not a gate on the completed platform journeys.