Module pages / plain-language stack reading

Which module matters first?

This is the human module catalog for the current Pizza4People proof. Start here if you want to understand what the customer sees, what the shop controls, and where payment or trust boundaries sit before opening raw manifests.

Back to homepage New here? Provider pages Code / protocol

Current scope

18 module pages across 1 shared provider layer.

Readable first. Raw manifest and GitHub references only when you need the developer-facing view.

New here?

Start with the simple idea, not the raw ids.

P4P core is the road. Modules are optional tools around the road.

Good examples are menus, kitchen screens, pickup boards, alerts, and payment adapters. Bad examples are the registry itself or the direct node order endpoint itself.

If you run a shop

Start with the customer menu, the shop-side catalog, and the simple pay-at-pickup lane. Read modules as optional tools around the order flow, not as protocol theory.

Open customer menu page / Open shop catalog page / Open simple payment page

If you build software

Start with the dumb-safe module explanation, then the community builder guide, then one small hardware lane so you can see what a narrow module looks like before reading the heavier contracts.

Open simple module guide / Open builder guide / Open backup-print example

If you are skeptical

Start with the review packet, then inspect the payment boundary and the two new pilot hardware lanes. The useful question is whether the core stays small while the extras stay honest and optional.

Open review packet / Open payment boundary page / Open pickup-board page

Start here

Three practical ways into the module stack.

Start with the customer side

If you want to understand the visible public proof first, start with the menu and status pages the customer actually sees.

Simple online menu Order status page

Then read the shop-side tools

If you want to understand what a pizzeria actually controls, jump to the catalog editor and kitchen queue before the deeper technical layers.

Edit menu and prices Kitchen order queue

Keep the boundary in view

If you want the practical edge of the current proof, read the simple payment path and the provider page together.

Pay at pickup / cash Current provider page

Catalog

Open the current stack by role, not by raw id.

The grouped list below is still the same narrow proof story. It is just arranged in the order a normal reader can use: customer surfaces first, then shop tools, then payment/trust edges, then internal tests.

If you want the exact technical language, GitHub remains the source of truth. This page is the public human layer above it.

Current module pages

Read the current modules as tools, then open the details only when needed.

What the customer sees

These are the public surfaces a customer can actually open during discovery and ordering.

Customer side

Simple online menu

A customer opens a normal menu list and sends the order directly to the restaurant.

Shown in proof Click for details

For a pizzeria: You keep the menu basics on your own node instead of relying on a marketplace-owned list.

Touches: Active items, prices, descriptions, and categories.
Does not own: It does not own payment, stock, or staff workflow.
Current state: available as the pilot-node customer menu list route when enabled
Technical id: p4p.menu.list

More info: Open full module page / Open provider page / Open manifest

Customer side

Clickable photo-style menu

A customer taps a paper-menu style surface instead of a plain item list.

Shown in proof Click for details

For a pizzeria: Useful if you want the customer surface to feel closer to a printed flyer or visual takeaway menu.

Touches: Active items, prices, descriptions, and categories.
Does not own: It does not own OCR, payment, stock, or operator workflow.
Current state: available as the pilot-node photo map menu route when enabled
Technical id: p4p.menu.photo-map

More info: Open full module page / Open provider page / Open manifest

Customer side

Order status page

A customer can check whether the order was accepted, rejected, or is ready for pickup.

Shown in proof Click for details

For a pizzeria: Reduces the need for status phone calls when the restaurant updates the order state.

Touches: Order status, estimated ready time, fulfillment type, and payment mode.
Does not own: It does not expose operator notes, customer contact data, or the full event log.
Current state: available in the pilot-node public order-status route when enabled
Technical id: p4p.customer.status

More info: Open full module page / Open provider page / Open manifest

What the shop uses behind the counter

These are the restaurant-side tools for menu control, kitchen flow, stock, printing, and fallback alerts.

Owner / operator side

Edit menu and prices

The restaurant can change names, prices, categories, and whether an item is active.

Operator-side prototype Click for details

For a pizzeria: This is the control surface that lets the shop own its own menu instead of waiting for a platform back office.

Touches: Item ids, names, descriptions, prices, categories, and active/inactive state.
Does not own: It is not a customer-facing menu page.
Current state: available in the pilot-node operator dashboard when enabled
Technical id: p4p.catalog.editor

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Scan a paper menu

The restaurant can scan a paper menu into draft catalog rows before a human review.

Operator-side prototype Click for details

For a pizzeria: Useful when a shop starts from a printed takeaway card instead of rebuilding the whole menu by hand.

Touches: Draft OCR item names, prices, categories, and source lines before catalog save.
Does not own: It does not become catalog truth by itself and it is not a customer-facing menu.
Current state: available in the pilot-node operator dashboard when enabled alongside the catalog editor
Technical id: p4p.catalog.import.ocr

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Kitchen order queue

Staff can see incoming orders and move them through kitchen states.

Operator-side prototype Click for details

For a pizzeria: Lets the restaurant turn direct orders into an actual working queue behind the counter.

Touches: Order items, note, customer contact, fulfillment type, and order status.
Does not own: It is not public discovery and it does not own payment.
Current state: available in the pilot-node operator dashboard when enabled
Technical id: p4p.kitchen.screen

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Final stock check

The system can do one last local stock check before the next order step continues.

Operator-side prototype Click for details

For a pizzeria: Helps stop the flow before the kitchen commits to something the shop no longer has.

Touches: Order items and local stock state.
Does not own: It does not replace the menu or the kitchen workflow.
Current state: available in the pilot node when enabled
Technical id: p4p.stock.basic

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Print to kitchen or POS

Accepted orders can later be printed or forwarded to a restaurant-owned printer or POS surface.

Planned next Click for details

For a pizzeria: This is the bridge from a direct online order to a paper ticket or POS flow inside the shop.

Touches: Order items, note, contact, and fulfillment type.
Does not own: It does not replace payment or public discovery.
Current state: not enabled
Technical id: p4p.order.print

More info: Open full module page / Open provider page / Open manifest

Counter / hardware side

Backup printer path

If the first printer path fails, the order can be rerouted to a second print target or local spool.

Operator-side prototype Click for details

For a pizzeria: Useful when a shop wants hardware redundancy before trusting direct orders during busy service.

Touches: Order items, note, customer contact, fulfillment type, and backup printer target.
Does not own: It is fallback routing, not the main customer or kitchen workflow.
Current state: builtin operator self-test lane when enabled and configured
Technical id: p4p.order.print.backup

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Operator email alert

The system can send an email when an order needs attention or a printer flow fails.

Planned next Click for details

For a pizzeria: Useful as a fallback alert so the shop is not blind if another operator-side step fails.

Touches: Order summary and the operator destination address.
Does not own: It is a fallback notification, not the main order surface.
Current state: not enabled
Technical id: p4p.notify.email

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Operator SMS alert

The system can send a short phone alert when an order or printer problem needs fast attention.

Planned next Click for details

For a pizzeria: Useful if the test hardware is noisy or partially unattended and the operator still needs a direct phone fallback.

Touches: Order summary and the operator phone destination.
Does not own: It is a fallback notification, not the main order surface.
Current state: not enabled; candidate phone fallback lane for a five-place hardware trial
Technical id: p4p.notify.sms

More info: Open full module page / Open provider page / Open manifest

Counter / hardware side

Bell or light alert

A local box can ring, beep, or flash when a new order or hardware problem needs attention.

Operator-side prototype Click for details

For a pizzeria: Lets the hardware give an audible or visible cue without turning the alert layer into the actual order queue.

Touches: Order summary, configured alert target, and urgency state.
Does not own: It does not accept orders, replace the kitchen queue, or settle payment.
Current state: builtin operator self-test lane when enabled and configured
Technical id: p4p.order.alert.basic

More info: Open full module page / Open provider page / Open manifest

Counter / pickup side

Ready-for-pickup board

A simple local screen can show which direct orders are accepted or ready at the counter.

Operator-side prototype Click for details

For a pizzeria: Gives the shop a cheap customer-facing pickup signal without exposing the full operator dashboard.

Touches: Order summary, public order status, estimated ready time, payment mode, and board target.
Does not own: It does not take new orders or replace the kitchen queue.
Current state: builtin local counter surface when enabled and configured
Technical id: p4p.pickup.board.basic

More info: Open full module page / Open provider page / Open manifest

Payment and business trust

This is where payment stays intentionally simple and where identity or business verification can later become reviewable.

Customer + operator side

Pay at pickup / cash

The restaurant can keep payment simple by taking cash or direct in-person payment outside the protocol.

Shown in proof Click for details

For a pizzeria: This is the easiest first live shape: order online, pay when the customer arrives.

Touches: Order total and fulfillment type only.
Does not own: It does not hold card data, wallets, settlement, or merchant-of-record responsibility.
Current state: enabled in the demo node and executable in the pilot node when enabled
Technical id: p4p.payment.cash

More info: Open full module page / Open provider page / Open manifest

Customer + operator side

External MobilePay adapter

A future external adapter can expose a familiar MobilePay-style pay-at-pickup instruction without making P4P the payment processor.

Planned next Click for details

For a pizzeria: Lets pilot restaurants say whether an external MobilePay-style adapter is worth adding after cash-first feedback.

Touches: Order total, fulfillment type, and operator payment destination.
Does not own: It does not make P4P hold funds, process cards, or become merchant of record.
Current state: not enabled; external-developer invitation only after cash-first pilot feedback
Technical id: p4p.payment.mobilepay

More info: Open full module page / Open provider page / Open manifest

Trust layer

Business identity check

A later trust layer can connect a node identity claim to a Danish CVR lookup or trust claim.

Trust direction Click for details

For a pizzeria: This is meant to make a restaurant identity more reviewable later without turning the registry into the authority.

Touches: Declared CVR identifiers and public node identity data.
Does not own: It is not part of the live ordering loop today.
Current state: not enabled
Technical id: p4p.trust.cvr-basic

More info: Open full module page / Open provider page / Open manifest

Internal tests and future extras

These modules are not the live restaurant offer today. They are internal test scaffolding or planned next-step pieces.

Internal debug

Fake payment tester

An internal mock can randomly accept or reject a test payment during local debugging.

Internal test only Click for details

For a pizzeria: Not something a restaurant should read as a live offer. It exists to test ugly edge cases before any real payment direction exists.

Touches: Order total only.
Does not own: It is not real money, not real settlement, and not a real provider.
Current state: executable in pilot-node when explicitly selected
Technical id: p4p.payment.godpay-mock

More info: Open full module page / Open provider page / Open manifest

Internal debug

Ugly-case payment tester

An internal mock for timeouts, wrong amounts, duplicate callbacks, and other payment chaos scenarios.

Internal test only Click for details

For a pizzeria: This exists to break things safely in local testing before any broader payment layer is discussed.

Touches: Order total and order state.
Does not own: It is not real money, not real settlement, and not a live customer payment option.
Current state: declared only; scenario executor intentionally not enabled yet
Technical id: p4p.payment.chaospay-mock

More info: Open full module page / Open provider page / Open manifest

Contact

Questions about the module layer or the current proof boundary?

Questions about module meaning, provider ownership, or the live-pilot boundary: hedegreen.research@gmail.com.

Public proof front door: https://pizza4people.com/.

Broader protocol-family direction: https://protocols4people.com/.