Docs/Policies & workflows

Authorization, testing and publishing

Screens 3.5 and 3.8 — route agency authorization and PEEK technical review, run validation scenarios and publish an approved configuration.

PEEK Platform Administrator · PEEK Technical Reviewer

/peek/customers/tenant-a/3-8

Live walkthrough · Authorization, testing and publishing

Authorization, testing and publishing — /peek/customers/tenant-a/3-5 — /peek/customers/tenant-a/3-5

Releasing a configuration needs two independent kinds of authority: the agency’s policy decision and PEEK technical review. PEEK technical approval can never substitute for agency policy authority (3.5). Test & Publish (3.8) brings both together with the diff, validation scenarios and affected tenants.

Release path

1. Draft
Open a versioned draft from the policy center.
2. Route authorization (3.5)
Attach agency decision evidence and request independent PEEK technical review, according to change type.
3. Test (3.8)
Compare the diff and run required validation scenarios; blocking failures stop release.
4. Publish (3.8)
Configuration and audit commit atomically; one release event and adoption notices are emitted.

Approvals bind to the exact diff — Review binds to the exact diff and versions. Changing a field invalidates any approval covering it, and a dependency that changes between review and publish returns a conflict that requires reevaluation.

3.5 · Policy Authorization & Release Routing

Separate agency authorization from platform release. Open it at /peek/customers/tenant-a/3-5 (any tenant ID you can access works in place of tenant-a). The primary action is Route authorized configuration for release, which requires policy.release.

How 3.5 works

1. Route agency authorization evidence and independent PEEK technical review according to change type

Screen 3.5 contract

Fields shown: Agency decision evidence, PEEK technical reviewer, version, effective date
Primary action: Route authorized configuration for release
Required capability: policy.release
Validation: Review binds to exact diff and versions. Changed fields invalidate approvals covering those fields.
Successful outcome: A reviewed draft becomes scheduled or active with separate authority references.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.3.5.action (acceptance test AT-UI-3.5)
Requirements: R02, R06, R07, R28, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-3.5

Boundary — PEEK technical approval cannot substitute for agency policy authority.

Rejected even if the browser allows it — Use only PEEK technical approval for a change requiring agency authorization; block release.

3.8 · Test & Publish Configuration

Compare the proposed effective configuration before release. Open it at /peek/customers/tenant-a/3-8 (any tenant ID you can access works in place of tenant-a). The primary action is Publish approved version, which requires configuration.publish.

How 3.8 works

1. Compare diff, run required validation scenarios, obtain required decisions and publish a selected version

Screen 3.8 contract

Fields shown: Diff, test cases, blockers, approval evidence, affected tenants
Primary action: Publish approved version
Required capability: configuration.publish
Validation: Current versions, no blocking validation failures, independent review and required agency evidence must pass at commit.
Successful outcome: Commit configuration and audit atomically; emit one release event and adoption notices.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.3.8.action (acceptance test AT-UI-3.8)
Requirements: R02, R06, R07, R24, R28, R30, R38, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-3.8

Boundary — Validate independent module configurations, handoff permissions and change effects before release. Technical publication does not constitute agency adoption.

Rejected even if the browser allows it — Change a dependency after review but before publish; return conflict and require reevaluation.

Related guides

History and controlled rollback

Screen 3.9 — restore a previous configuration as a new release, checked against current entitlements and rights.

Catalog lifecycle: draft, review, publish

How every “Publish …” screen works: draft, validation, independent technical review bound to the diff hash, then publish.

Policy sources and applicability

Screen 3.10 — maintain traceable references to official sources and review why they apply to a tenant.