Blue in 10 minutes

Blue lets independent people, businesses, services, institutions, and AI agents coordinate around one evolving shared situation without requiring one application to own identity, ordering, permissions, state, and audit.

1. Start with a document#

A Blue document is a rooted slice of typed graph content. It can be a scalar, an object, a list, or a pure reference. Exact content receives a BlueId after preprocessing, type resolution, validation, and canonicalization.

name: Vet Order
customer: Maya
provider: Riverside Vet
status: Draft

BlueId proves exact semantic content. It does not by itself prove authorship, current truth, authority, or payment.

2. Add deterministic behavior#

The contracts field can contain channels, operations, handlers, workflows, policies, and embedded-processing markers. The processor has a deliberately narrow job:

PROCESS(current Root, eligible event)
→ new Root + Root events + gas

The processor does not read the wall clock or call external APIs. Contract code returns patches and events as data; the processor validates and applies them in a defined order.

3. Put actions on Timelines#

External actions arrive as provider-backed Timeline Entries. The provider attributes the Timeline, actor, source, timestamp, predecessor, and message.

Within one Timeline, the current architecture assigns at most one entry to a microsecond. Timestamps are therefore unique and strictly increasing in that Timeline; there is no separate sequence field.

A document can use channels from many providers at once: MyOS for operational work, a bank for payment facts, a government institution for official facts, and a KYA provider for agent actions.

4. Close the complete window#

Notification order is not processing order. Before delivering an entry, the feeder obtains a completeness frontier from every relevant Timeline, collects the closed window, sorts entries deterministically, and verifies eligibility.

The feeder decides which external action is safe and eligible next. The processor decides the deterministic consequence of that action.

5. Use Requests, Responses, and Operations#

Typed Messages allow parties and agents to ask, answer, negotiate, report progress, and invoke operations in one causal trace.

• requestId groups logical work.
• threadId groups a conversation.
• inResponseTo anchors a Response to one exact Request occurrence.
• recipientChannel addresses attention but does not imply privacy.
• an Operation Request names the target channel, operation, optional target state, and request payload.

6. Delegate with a Mandate#

Presence is not authority. An agent can be visible in a document and still be unable to exercise a principal's channel.

A Mandate is a living authority document with an authority holder, an authorized actor, a guarantor, a narrow target, validation, lifecycle, and provider-attributed history. A typical lifecycle is:

Pending → Authority Confirmed → Active → Terminated

The feeder resolves the exact processed Mandate state at the action timestamp. Later activation cannot authorize an earlier attempt, and later termination does not erase an earlier valid action.

7. Keep payments separate#

A PayNote governs requests, conditions, evidence, and lifecycle around one payment transaction. It is not a bank ledger or payment rail.

The commercial document explains why payment should be requested. The PayNote governs the process. The bank, card processor, wallet, or other guarantor authoritatively reports what happened to funds.

8. Build document networks#

Do not flatten every relationship into one root. Use separate documents when participants, lifecycle, visibility, authority, payment, provider trust, or retention differ.

A network might contain:

• an Agreement for a standing relationship;
• an Offer for what can be accepted;
• an Order for one occurrence;
• a PayNote for one transaction;
• a Mandate for one bounded authority relationship;
• subscriptions and typed Messages connecting them.

The complete proposition#

Blue combines five precise boundaries: