What it touches
Order status, estimated ready time, fulfillment type, and payment mode.
Customer side / Shown in proof
Order status page
A customer can check whether the order was accepted, rejected, or is ready for pickup.
For a pizzeria
Reduces the need for status phone calls when the restaurant updates the order state.
Where it fits
What the customer sees
These are the public surfaces a customer can actually open during discovery and ordering.
This page is the readable P4P explanation for one module. It is meant to be understandable before you open the raw manifest.
What it does not own
It does not expose operator notes, customer contact data, or the full event log.
Current state
Shown in proof
available in the pilot-node public order-status route when enabled
Current declared data-access summary: Order id, public order status, estimated ready time, fulfillment type, and payment method. No customer contact data, customer name, operator notes, or full event log.
Read next
Do not stop at one module page.
Start at the order surface first
If you landed here early, read the menu module first so the order-status page makes sense in context.
Then look at the kitchen side
The status page only changes when the restaurant updates the order behind the counter.
Keep payment simple
The first live shape still avoids deeper payment handling and keeps the edge small.
Technical identity
p4p.customer.status
If you need the developer-facing version, open the GitHub module reference or the raw manifest. The public P4P page stays focused on what the module means operationally.
Open provider page / Open GitHub module reference / Open GitHub provider reference / Open raw manifest
Contact
This module page is still part of the same narrow proof story.
Questions about this module, the provider layer, or the live-pilot boundary: hedegreen.research@gmail.com.
Public proof front door: https://pizza4people.com/.
Broader protocol-family direction: https://protocols4people.com/.