Mental model·Blocks

Mental model

Blocks

The simplest way to understand Blue is to think of every interaction as a block — a shared interaction between participants, governed by rules, with visible state and a record of what happened.

A block is the mental model. A Blue document is the technical object. A block is a document is a governed interaction.

What lives inside a block

Picture a single block. Participants sit around it. Timelines feed into it. Rules decide what can change. Current state is visible inside.

Participants

Who is part of the interaction: buyer, seller, payer, payee, guarantor, courier, service, agent, verifier, lawyer. Anyone with a role in the interaction is a participant.

Rules

What the participants can do: who may request a change, who may confirm a step, what conditions must be satisfied, what happens after an event, what is forbidden.

State

What is true right now: order status, current amount, delivery confirmed or not, refund window open or closed, approval pending or accepted.

Record

What happened. In Blue, actions come through timelines. The block changes because a participant acted — and that action is part of a permanent record.

Why this abstraction matters

Today, interactions all have different shapes. An email thread is one kind of thing. A payment is another. A contract is another. A support ticket is another.

In Blue, all of them become blocks. Different content. Same structure.

Examples

BlockParticipantsRulesState
Email threadSender, recipientsAnyone in the thread can reply; sender can recall before sendSubject, messages, read status
Chess gameWhite, blackOnly legal moves; alternating turnsBoard, turn, result
PaymentPayer, payee, bankWhen funds can be secured, completed, or reversedpending → secured → completed
OrderBuyer, sellerBuyer can place; seller can accept; only ship after acceptplaced → accepted → shipped → delivered
MandateOwner, agentAgent must act within limits and conditionsactive, allowed source, max amount, expiry
Service requestCustomer, providerProvider must accept; customer must approve completionrequested → accepted → in-progress → resolved

Same idea. Different rules.

What a block is not

  • Not a UI screen
  • Not a single API endpoint
  • Not a row in a database
  • Not a blockchain transaction
  • Not a static contract PDF

It is closer to a living agreement — a governed interaction with participants and rules.

A block is not a silo. It is scoped, but it can reference other blocks (by BlueId or session id), trigger operations in them, and depend on their state. See composition.

Why "block" is useful

"Document" is technically accurate. But "block" emphasizes self-contained interaction, composability, reusability, and structure. You can build worlds from blocks.