Docs/Policies & workflows

Policy center and inheritance

Screens 3.1 and 3.2 — review effective policy with its sources and simulate how department, agency and office scopes inherit.

PEEK Platform Administrator · PEEK Technical Reviewer

/peek/customers/tenant-a/3-1

Live walkthrough · Policy center and inheritance

Policy center and inheritance — /peek/customers/tenant-a/3-2 — /peek/customers/tenant-a/3-2

The Customer Policy Center shows the effective governance configuration for a tenant. Three kinds of value are always displayed distinctly: platform restrictions, agency decisions and recommendations. Every effective value identifies its scope, type, source version and decision authority.

How inheritance works

Policy flows department → agency → office.
A child scope may always tighten a parent ceiling.
Relaxing requires the control to be explicitly delegable and valid authority; a nondelegable parent restriction can never be relaxed by a child.
Simulation on 3.2 reports effective values and safe reasons without changing live policy.

3.1 · Customer Policy Center

Review the effective governance configuration. Open it at /peek/customers/tenant-a/3-1 (any tenant ID you can access works in place of tenant-a). The primary action is Open or draft policy configuration, which requires policy.read or policy.draft.

How 3.1 works

1. Display effective rules, inherited restrictions, recommendations and pending changes
2. Open a versioned draft

Screen 3.1 contract

Fields shown: Policy versions, sources, agency decisions, release status
Primary action: Open or draft policy configuration
Required capability: policy.read or policy.draft
Validation: Every effective value identifies scope, type, source version and decision authority.
Successful outcome: Draft and current policy are visibly separate, with a traceable diff.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.3.1.action (acceptance test AT-UI-3.1)
Requirements: R02, R06, R07, R28, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-3.1

Boundary — Show platform restrictions, agency decisions and recommendations distinctly.

Rejected even if the browser allows it — Present an unadopted recommendation as effective agency policy; acceptance must fail.

3.2 · Policy Scope & Inheritance

Explain which policy applies to a department, agency or office. Open it at /peek/customers/tenant-a/3-2 (any tenant ID you can access works in place of tenant-a). The primary action is Simulate scope change, which requires policy.simulate.

How 3.2 works

1. Choose department, agency or office scope
2. Compare inherited values with a proposed child configuration

Screen 3.2 contract

Fields shown: Scope tree, parent restriction, override, effective result
Primary action: Simulate scope change
Required capability: policy.simulate
Validation: Child scope may tighten a ceiling; relaxation requires an explicitly delegable control and valid authority.
Successful outcome: Simulation reports effective values and safe reasons without changing live policy.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.3.2.action (acceptance test AT-UI-3.2)
Requirements: R02, R06, R07, R28, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-3.2

Boundary — A child cannot relax a nondelegable parent restriction.

Rejected even if the browser allows it — Override a nondelegable restriction through a child-office setting; deny publication.

Related guides

Recommended policy settings

Screen 3.3 — publish persona-based recommended settings with rationale for agency review.

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.

Policy exceptions and expiration

Screen 3.7 — review bounded exceptions with explicit scope, authority and end date.