PKPEEK Docs
Docs/Policies & workflows

Handoff and synchronization governance

Screen 3.11 — publish package submission, human acceptance, immutable accepted versions and changed-input review rules.

PEEK Platform Administrator

/peek/customers/tenant-a/3-11
Live walkthrough · Handoff and synchronization governance
/peek/customers/tenant-a/3-11

Handoffs move a package (for example a market research package) from one module to another. The governance profile defines package types, who may submit and who may accept or return, separation rules and how changed inputs are reviewed. Core and the agency app enforce the published rules identically.

Handoff lifecycle

  1. 1. Submit

    A user with handoff.submit submits a package version.

  2. 2. Accept or return

    A different user with handoff.decide accepts or returns it. Accepted versions are immutable.

  3. 3. Source changes

    A newer source version (v4 after accepted v3) never replaces v3; it creates review-required lineage.

  4. 4. Changed-input review

    A user with handoff.review_change decides whether to adopt the change.

Note — Absent or intentionally disabled peer modules are never synchronization targets — no phantom “pending sync” queues are created.

3.11 · Handoff & Synchronization Governance

Govern package submission, human acceptance, immutable accepted versions and changed-input review. No pending synchronization for a module not purchased or intentionally disabled. Open it at /peek/customers/tenant-a/3-11 (any tenant ID you can access works in place of tenant-a). The primary action is Publish handoff governance profile, which requires handoff_policy.publish.

How 3.11 works

  1. 1. Configure package types, submit and acceptance capabilities, separation rules and changed-input review behavior

Screen 3.11 contract

Fields shown
Package contract, submitter and acceptor roles, version pin, change policy, source-use limits, review state
Primary action
Publish handoff governance profile
Required capability
handoff_policy.publish
Validation
Accepted versions are immutable. Absent or intentionally disabled peers are not synchronization targets.
Successful outcome
Publish handoff rules that Core and the agency application enforce identically.
Screen states
Loading; empty; ready; restricted; stale; error; review pending
Audit event
admin.screen.3.11.action (acceptance test AT-UI-3.11)
Requirements
R32, R34, R35, R39, R40, R42, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-3.11
Boundary — Govern package submission, human acceptance, immutable accepted versions and changed-input review. No pending synchronization for a module not purchased or intentionally disabled.
Rejected even if the browser allows it — Publish source v4 after accepted v3; preserve v3 and create review-required lineage without automatic adoption.

Related guides

Acquisition lifecycle workflow templates

Screen 3.4 — define workflow stages, transitions, decision points and external-input paths for each module combination.

Administrative roles and delegation

Screen 2.1 — publish agency administrative role templates, delegation ceilings, combination rules and maximum durations.

Data access and permitted use

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