Docs/Customers & tenants

Module capabilities and dependencies

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

PEEK Platform Administrator · PEEK Technical Reviewer

/peek/customers/tenant-a/1-10

Live walkthrough · Module capabilities and dependencies

The capability manifest describes what each module needs, independent of commercial SKU names. It is a global catalog object published through the catalog lifecycle (capability type, catalog.publish). Existing accepted evidence stays pinned to the contract version it was accepted under.

1.10 · Module Capabilities & Dependencies

Declare Core requirements, optional peer cooperation, feature prerequisites and manual alternatives independently of commercial SKU names. Open it at /peek/customers/tenant-a/1-10 (any tenant ID you can access works in place of tenant-a). The primary action is Publish reviewed capability manifest, which requires catalog.publish.

How 1.10 works

1. Describe Core requirements, optional peers, per-feature prerequisites and manual alternatives
2. Validate and version the catalog

Screen 1.10 contract

Fields shown: Capability ID, Core requirements, optional peers, per-feature prerequisites, manual path, catalog version
Primary action: Publish reviewed capability manifest
Required capability: catalog.publish
Validation: Reject cycles, unknown capabilities and mandatory paid peers for a base workflow. Commercial SKU mapping is separate.
Successful outcome: Publish a catalog version for eligible adoption; existing accepted evidence remains pinned to its contract version.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.1.10.action (acceptance test AT-UI-1.10)
Requirements: R31, R32, R33, R38, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-1.10

Boundary — Declare Core requirements, optional peer cooperation, feature prerequisites and manual alternatives independently of commercial SKU names.

Rejected even if the browser allows it — Submit a manifest requiring Planning for base Market Research; reject the hidden dependency.

Related guides

Modules and subscriptions

Screen 1.4 — record purchased module entitlements, terms and quotas with commercial evidence; the module catalog explained.

Catalog lifecycle: draft, review, publish

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

Acquisition lifecycle workflow templates

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