UNDERLAY
← Atlas indexInvestigation 001

An ordinary action

What happens after you click Buy Now?

A checkout button appears to finish a purchase. In practice, it begins a distributed negotiation between software, institutions, people, and machines.

Opening model

This demonstration performs no purchase and collects no information. Scroll freely, or cross the threshold using the simulated order button.

SurfaceFictional checkout / Final step

Review your order

One last action.

On the visible surface, the purchase has been reduced to a product, a price, and one decisive button.

Object 01

Field Lamp

Graphite / Quantity 1

$84.00
DeliveryStandard · 3–5 working days
Chapter 01The signal leaves

Below the interface

The button does not move an object. It creates a message.

Before payment, packing, or delivery can begin, an intention must be translated into data and accepted by systems beyond the screen.

  • Digital
  • Financial
  • Physical
  • Data

Sequence model

Logical order only — not a measurement of a real checkout

  1. Input

    Intent becomes an event

    The browser receives a pointer or keyboard event generated on the visitor’s device.

  2. Interface

    Local state changes

    Checkout code reads the current order state and changes what the interface displays.

  3. Boundary

    A request is assembled

    The application prepares the information the merchant needs to evaluate the order.

  4. Network

    The signal leaves

    An encrypted request travels beyond the device toward the merchant’s infrastructure.

  5. Merchant edge

    The request is tested

    Server-side systems validate the request before any visible confirmation can be trusted.

Fact boundary

What this model holds constant

  • The interaction begins on the visitor’s device.
  • The checkout application reads an existing order state.
  • A server must validate what the interface submits.
  • A visual success state alone is not authoritative.

Simplification

What a real checkout may add

  • Several network requests instead of one.
  • Telemetry, fraud, tax, and payment services in parallel.
  • Different timing based on device and network conditions.
  • Merchant-specific infrastructure and validation rules.

Next layer / Chapter 02

The merchant reconstructs the order.

The next chapter will follow the message as product identifiers, customer context, inventory, and risk signals are assembled into something the merchant can act on.

Chapter 02Merchant reconstruction

A usable representation

The merchant reconstructs the order—and a partial version of you.

The request arrives as structured fragments. Together they describe an item, a buyer reference, a destination, and the context in which the action occurred.

Incoming fragments04 detected

Inspect the record inputs

Product identifiers, quantity, and the displayed price describe what is being requested. Server-side systems still need to verify them.

Merchant-side order objectIllustrative schema
order {line_item: "FIELD-LAMP-01",quantity: 1,displayed_price: "84.00",customer_ref: "guest_7F2",contact_state: "provided",delivery_zone: "ZONE-04",shipping_method: "standard",locale: "en",session_ref: "sess_demo",status: "pending_validation"}

Fictional values. The record demonstrates relationships, not a universal database schema.

Next layer / Chapter 03

Money asks permission.

The order can now be described, but description is not authorization. The next chapter follows the payment request through the institutions that decide whether it may proceed.

Chapter 03Authorization relay

The financial thread

Money asks permission.

For this fictional card payment, the merchant cannot approve its own request. A message travels through financial intermediaries to an institution capable of returning a decision.

Card authorization / Simplified routeFixed demonstration outcome: approved

  1. Merchant

    Requests approval for the amount and payment reference.

    Waiting

  2. Payment service

    Formats and routes the request. Exact responsibilities vary.

    Waiting

  3. Acquirer

    Processes card transactions on the merchant side.

    Waiting

  4. Card network

    Routes the request toward the appropriate issuer.

    Waiting

  5. Issuer

    Returns an approval, decline, or request for another action.

    Waiting

Issuer response

Not requested

This animation sends no network request and uses no payment information.

The authorization model is ready.

Outbound request
Amount
USD 90.72
Merchant reference
ORDER_DEMO_001
Payment credential
Tokenized reference
Context
Card-not-present
Returning response
Decision
Approved or declined
Response code
Implementation-specific
Authorization reference
When provided
Next state
Capture, retry, or action

Next layer / Chapter 04

The order splits.

One approved purchase can become several operational records: inventory reservations, fulfillment work, receipts, notifications, and sometimes multiple shipments.

Chapter 04Operational fan-out

One action, several queues

The order splits.

A single customer-facing order can become several records owned by different systems. They share an origin, but they do not necessarily move at the same speed.

Order dispatch / Illustrative model05 possible workstreams
Accepted order

Merchant record

ORDER_DEMO_001

Line items
01
Quantity
01
Authorization
Approved
Fulfillment
Unassigned

Selected workstream

Inventory

The item may move from sellable inventory into a committed or equivalent state so competing orders do not rely on the same unit. State names vary by platform.
Likely owner
Inventory service
Illustrative timing
Seconds
Example output
available → committed

Next layer / Chapter 05

The database becomes labor.

A fulfillment record is still only data. The next chapter follows the moment when a location, queue, screen, and worker turn that record into physical action.

Chapter 05Data becomes work

The human and physical layer

The database becomes labor.

A fulfillment record cannot lift, inspect, or move an object. Its fields must become instructions that a person, machine, or combination of both can act on in physical space.

Fulfillment task / Field-to-action modelNo worker identity or productivity score
  1. Physical instructionAccept assigned work
  2. Physical instructionTravel to aisle 17, bay 04
  3. Physical instructionIdentify the expected item
  4. Physical instructionSelect one usable unit
  5. Physical instructionScan or confirm the item
  6. Physical instructionMove the item to packing

Model boundary

Software records the expected path. Work resolves the actual one.

What this task can encode

  • An expected item and quantity.
  • A suggested source location.
  • A destination or next queue.
  • A confirmation or exception event.

What this simplified task omits

  • Congestion and distance through the workspace.
  • Damaged, missing, or ambiguous items.
  • Interruptions, coordination, and judgment.
  • The physical cost of repeatedly moving objects.

Next layer / Chapter 06

The parcel enters a network.

After picking and packing, one object becomes a labeled logistics unit. The next chapter follows its movement through carrier scans, facilities, routes, and handoffs.

Chapter 06Event-based visibility

The logistics thread

The parcel enters a network.

The physical object and its tracking page are not the same thing. Tracking is assembled from identifiers, scans, operational events, and periods in which no new observation is visible.

Parcel event trail / Illustrative route07 events · timing intentionally variable
01 / 07

Before handoff

Label created

What the event observes

A shipment identifier and electronic record now exist.
Recorded location
Merchant system
What it cannot prove
This does not prove that the carrier physically possesses the parcel.

Critical distinction

The tracking interface is an event model—not the parcel itself.

Observed

  • An identifier was created or scanned.
  • An event was associated with a time and place.
  • A carrier system published a status.

Inferred between events

  • The parcel continues along an expected route.
  • No visible update does not necessarily mean no movement.
  • An estimated arrival remains subject to later events.

Next layer / Chapter 07

The transaction outlives the click.

Delivery ends the parcel route, but not the system’s memory. The final chapter follows receipts, settlement, retention, returns, disputes, and records that persist after the object arrives.

Record afterlife / persistence and revision

The transaction outlives the click.

Delivery can finish the visible journey. Behind it, records continue to explain, reverse, contest, and remember what happened.

Time lens

Move the transaction into its possible futures.

Select an event to see which earlier records become active, supporting, or subject to review.

Persistent record field

What the event rereads

03records in focus

  1. 01

    Order record

    FulfilledAnchors the products, amount, destination, and later adjustments.
  2. 02

    Payment record

    Payment recordedPreserves the payment events associated with the order.
  3. 03

    Fulfillment record

    CompletedRecords the pick, pack, and carrier handoff workflow.
  4. 04

    Parcel events

    DeliveredAdds the carrier’s final observed delivery event.
  5. 05

    Customer communication

    Notice sentRecords the confirmation or delivery message shown to the customer.

Primary references