Docs/SI services & Sigma

Permitted uses, persona access and evidence

Screens 4.3, 4.4 and 4.9 — recommend SI by persona, constrain processing by data class and purpose, and trace use cases to agency approval evidence.

PEEK Platform Administrator · PEEK Technical Reviewer

/peek/customers/tenant-a/4-4

Live walkthrough · Permitted uses, persona access and evidence

Permitted uses, persona access and evidence — /peek/customers/tenant-a/4-3 — /peek/customers/tenant-a/4-3

Permitted uses, persona access and evidence — /peek/customers/tenant-a/4-9 — /peek/customers/tenant-a/4-9

Processing boundaries are the intersection of use case × data class × provider route × operation. The published boundary is applied before retrieval context is built and before anything is sent to a provider.

Readable is not processable — Data a user can read is not automatically approved for provider processing. Unknown data classes or unsupported purposes deny processing. Readable-but-prohibited evidence is blocked before transmission.

4.3 Persona access recommendations — suggested SI tasks per persona with synthetic preview; publishing never adopts them for a real user or opens restricted records.
4.4 Permitted uses & data boundaries — the enforceable processing boundary.
4.9 Use cases & approval evidence — owner, agency decision, official references and review dates. Expired or missing authority blocks new affected processing; official policy titles keep their actual wording.

4.4 · Permitted Uses & Data Boundaries

Constrain SI processing to approved data and purposes. Open it at /peek/customers/tenant-a/4-4 (any tenant ID you can access works in place of tenant-a). The primary action is Publish processing boundary, which requires si_boundary.publish.

How 4.4 works

1. Set permitted processing intersections by use case, data category, provider route and operation

Screen 4.4 contract

Fields shown: Use case, data class, provider, transformation, allowed destination
Primary action: Publish processing boundary
Required capability: si_boundary.publish
Validation: Readable data is not automatically approved for processing. Unknown data class or unsupported purpose denies processing.
Successful outcome: Published boundary is applied before retrieval context construction and provider dispatch.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.4.4.action (acceptance test AT-UI-4.4)
Requirements: R02, R06, R09, R28, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-4.4

Boundary — Data-readable does not mean authorized for provider processing.

Rejected even if the browser allows it — Send readable but provider-prohibited evidence to an allowed model; block before transmission.

4.3 · Persona Access Recommendations

Recommend SI capabilities by business persona. Open it at /peek/customers/tenant-a/4-3 (any tenant ID you can access works in place of tenant-a). The primary action is Release recommendation, which requires si_recommendation.publish.

How 4.3 works

1. Recommend persona SI tasks and permitted data uses with a synthetic preview and rationale

Screen 4.3 contract

Fields shown: Persona, permitted uses, data limits, applicable template
Primary action: Release recommendation
Required capability: si_recommendation.publish
Validation: Every suggested use is bounded by provider, purpose, current record rights and purchased capability.
Successful outcome: Publish a recommendation without adopting it for any actual agency user.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.4.3.action (acceptance test AT-UI-4.3)
Requirements: R02, R06, R28, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-4.3

Boundary — Any agency adoption shown in a preview is read-only in the PEEK center.

Rejected even if the browser allows it — A recommendation change must not grant a persona access to previously restricted records.

4.9 · SI Use Cases & Approval Evidence

Trace use-case authorization to agency evidence. Open it at /peek/customers/tenant-a/4-9 (any tenant ID you can access works in place of tenant-a). The primary action is Review evidence, which requires si_evidence.review.

How 4.9 works

1. Associate a use case with owner, agency decision, official references where applicable and review dates

Screen 4.9 contract

Fields shown: Use case, owner, decision, source references, review date
Primary action: Review evidence
Required capability: si_evidence.review
Validation: Decision scope must cover data, purpose and environment. Official titles retain their actual wording.
Successful outcome: Use-case readiness reflects evidence status; expired or missing authority blocks new affected processing.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.4.9.action (acceptance test AT-UI-4.9)
Requirements: R02, R06, R08, R28, R41, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-4.9

Boundary — Product terminology SI does not rename official policy titles.

Rejected even if the browser allows it — Treat a policy badge in a mock image as verified approval; readiness must fail.

Related guides

Sigma Companion and service routing

Screen 4.5 — declare Sigma’s permitted tasks, provider route, fallback candidates and manual path.

Policy sources and applicability

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

Data access and permitted use

Screen 6.4 — separate source access from secondary uses: export, SI processing, actions and onward handoff.