Playbooks

Playbooks are standard operating procedures (SOPs) for PPM. Use calls.md for payload shape and required fields.

Surface availability (explicit)

• API Gateway: Available.
• Direct Lambda: Not offered.
• CLI: Available (g3n ppm ..., API Gateway).
• MCP: Available.

Playbook: Price list + price resolve

Goal: Define pricing structures and resolve prices for a given context.

Why this sequence:

• Price zones and lists provide the context for pricing.
• Price entries and approvals determine what resolves for a request.

Preconditions

• Logical facilities and channels exist (OFM).
• PVM variants/SKUs exist for pricing.

SOP (happy path)

1. Create price zone (POST /price-zone/set) and assign logical (POST /price-zone/assign).
   • Reason: price zones scope pricing by facility/region.
2. Create price list (POST /price-list/set).
   • Reason: price lists hold price entries.
3. Assign price list (POST /price-list/assign) to customers or channels.
   • Reason: determines which list is used for resolution.
4. Create price entry (POST /price/set) for a SKU/variant.
   • Reason: provides the actual price values.
5. Submit/approve price (POST /price/approval/submit, then /price/approval/approve).
   • Reason: ensures controlled price activation.
6. Resolve price (POST /price/resolve).
   • Reason: returns the effective price for a given context.
7. Verify (POST /price/get, /price/list).
   • Reason: confirm entries and approval status.

Outputs

• Active price entries tied to zones/lists.
• Successful price resolution for sales flows.

Failure modes / remediation

• invalid-state: ensure approvals are completed before resolve.
• Missing assignments: verify price zone/list assignment.

Cross-service relationships

• OFM: facility/channel context.
• PVM/SCM: item identifiers and sales flows consume price results.

Playbook: Promotions + dynamic rules

Goal: Run time-bound promotions and dynamic pricing adjustments.

Why this sequence:

• Promotions and dynamic rules are separate controls that layer on pricing.

Preconditions

• Base price entries exist and are active.

SOP (happy path)

1. Create promotion (POST /promotion/create).
   • Reason: defines promotion eligibility and parameters.
2. List/verify promotions (POST /promotion/list, /promotion/get).
   • Reason: confirm the promotion is active and scoped correctly.
3. Set dynamic pricing rule (POST /dynamic-rule/set) if applicable.
   • Reason: enables real-time price adjustments based on inputs.
4. Resolve price (POST /price/resolve) to confirm promo/rule effects.
   • Reason: validates end-user pricing.
5. End promotion (POST /promotion/end) when the window closes.
   • Reason: ensures promotions do not leak past their intended window.

Outputs

• Promotions applied during their active window.
• Dynamic rules influencing price resolution as intended.

Failure modes / remediation

• conflict on updates: re-read and retry with current revision.
• Unexpected price: inspect active promotions/rules and assignments.

Cross-service relationships

• SCM: order/tender flows consume resolved prices.