PKPEEK Docs
Docs/Policies & workflows

Acquisition lifecycle workflow templates

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

PEEK Platform Administrator · PEEK Technical Reviewer

/peek/customers/tenant-a/3-4
Live walkthrough · Acquisition lifecycle workflow templates
/peek/customers/tenant-a/3-4

Workflow templates (catalog type workflow) describe stages, transitions, required role capabilities, evidence and escalation. Each template must remain a reachable human workflow with Core alone, using external-work intake and human handoff where a peer module is absent — no linear purchase of every acquisition module is forced.

3.4 · Acquisition Lifecycle Workflow

Define permitted workflow templates and decision points. Open it at /peek/customers/tenant-a/3-4 (any tenant ID you can access works in place of tenant-a). The primary action is Release workflow template, which requires workflow_catalog.publish.

How 3.4 works

  1. 1. Define stages, decisions, role capabilities and external-input paths for each purchased module combination

Screen 3.4 contract

Fields shown
Stages, transitions, role requirement, evidence, escalation
Primary action
Release workflow template
Required capability
workflow_catalog.publish
Validation
Validate reachable human workflow with Core alone, required evidence and supported handoff contract.
Successful outcome
Publish a workflow template; agency adoption and official business decisions occur separately.
Screen states
Loading; empty; ready; restricted; stale; error; review pending
Audit event
admin.screen.3.4.action (acceptance test AT-UI-3.4)
Requirements
R02, R06, R07, R28, R31, R32, R39, R40, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-3.4
Boundary — Support each module with Core alone using external-work intake and human handoff. Do not force a linear purchase of every acquisition module.
Rejected even if the browser allows it — Run Planning without Market Research using external research; the workflow must remain usable.

Related guides

Handoff and synchronization governance

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

Module capabilities and dependencies

Screen 1.10 — publish the capability manifest: Core requirements, optional peers, per-feature prerequisites and manual alternatives.

Catalog lifecycle: draft, review, publish

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