Role
SITEREA owns the product model, client/admin linkage, order-state architecture and verification constraints documented here.
RoadUp
Turn a service order into one durable commercial and delivery workflow.
RoadUp is a SITEREA-owned product case built around a useful client cabinet, deterministic pricing, explicit payment state, admin processing and bounded verification. The case demonstrates service operations—not a decorative dashboard.
Order lifecycle
1Client context
2Order
3Price
4Payment
5Processing
6Verification
Case status
What SITEREA built in this case.
The case focuses on system behavior that can be inspected in the product architecture.
Commercial rule
Prices come from explicit server-side rules; AI is not allowed to invent a commercial total.
Verification boundary
An optional supporting URL is checked as one bounded page only—no crawl, no enqueue and no expansion into a site scan.
Commercial and work states
Payment state and delivery state are deliberately separate.
A paid order can still be waiting for processing; completed work can require verification before the order is closed.
Draft / ready to order
Client context is useful before purchase and the requested item is defined.
Next: Create an order with deterministic price.
Payment pending / confirmed
Commercial state changes only from the payment provider or approved manual confirmation.
Next: Release the order for processing when policy allows.
Processing
Admin/operator work is active and linked to the durable order.
Next: Complete the requested service and attach evidence.
Verification
The bounded result check evaluates the target page / delivery condition without turning into a crawl.
Next: Close, review or correct.
Complete / cancelled
The order reaches an explicit terminal state with reason/evidence.
Next: Preserve history rather than deleting state.
Scope boundary
One order is the durable record; verification does not become a crawler.
RoadUp keeps commercial state, operator work and result verification related without allowing any one layer to silently expand its authority.
✓
The price is resolved from explicit rules before the order is accepted.
✓
Payment state is separate from work state.
✓
The supporting URL check stays bounded to the submitted page.
✓
A failed verification returns to review or correction instead of creating a new crawl or a false success.
Failure and recovery
A supporting URL redirects or no longer contains the expected target link.
The verification step should report the bounded condition rather than widening scope or silently retrying forever.
Check only the submitted page
Follow allowed redirect behavior and inspect HTTP status, canonical/robots/content heuristics and target-link presence for that page.
Record the result
Verification becomes part of the order evidence instead of an implicit operator note.
Return to review
A failed check routes to correction or operator review; it does not create a fake success state.
Exception / boundary
The verification rule must not enqueue additional URLs or crawl the destination site.
What this proves
Commercial state, delivery work and verification remain inspectable parts of one order without being collapsed into a single “done” flag.
Case next step
Keep order, payment, delivery and verification attached to one service record.
Use the RoadUp lifecycle to compare how your own service order moves between the client, payment layer, operator and verification step.