Timelines

Provider-backed histories

A Timeline is an append-only history of one actor's actions, maintained by a Timeline Provider under that provider's rules. Think of it as a verified diary: Alice has hers, the restaurant has its own, a bank keeps one for its customer, an AI agent writes to one supervised by its runtime.

Each entry is itself a document:

type: Timeline Entry
timeline:
  type: MyOS Timeline
  timelineId: myos:alice:main
prevEntry:
  blueId: 4Fj2N...
timestamp: 1785312000100000
actor:
  type: Principal Actor
  accountId: alice
message:
  type: Operation Request
  channel: customerChannel
  operation: acceptPackage
  request:
    note: Ready to book

Within one Timeline, timestamps are unique and strictly increasing. And because each entry references its predecessor's BlueId, history forms a chain that cannot be rewritten quietly:

original:   A1 ── A2 ── A3
tampered:   A1 ── A2′    A3 still points at the old A2 — the chain is visibly broken

Tampering isn't prevented — it's unhideable.

A Timeline Channel then binds a specific timeline-and-actor to a role in a document: "entries from this history, attributed to this actor, speak as the restaurant here." Payloads never vouch for themselves; a message containing the word "Alice" enters nothing.

Providers are the trust anchors

A Timeline Provider does three jobs: it verifies identity (who owns this timeline), it assigns order (timestamps and the chain), and it attests attribution (who or what performed each action — a person directly, or an agent on their behalf). Everything downstream — channels, operations, mandates — inherits the quality of those three attestations.

Providers differ, deliberately:

This is a deliberate design decision about trust. Blockchain asks: what is the one true order of every event in the universe? — and pays for that answer with consensus overhead, delay, and publicity. Blue asks a smaller question: given Alice's verified history and the restaurant's verified history, how does everyone interpret their interaction identically? No global consensus is needed for that — only verified perspectives and a deterministic merge. So instead of inventing a new trust machine, Blue borrows the trust society already has: your bank vouches for payments, your government for permits, your platform for sessions. You choose providers you already trust — and trust stays specific, not scalar: a bank is authoritative about settlement and irrelevant about restaurant capacity.

What keeps providers honest is structure, not hope: every attestation lands in a tamper-evident chain that others copy and verify. A provider that lies writes the evidence of its own lying into a permanent, public-enough record. For institutions bound by reputation and regulation, that is a strong leash. And a blockchain can still serve as one provider among many when a use case demands it — its finality delay simply bounds the shared window (mix a three-minute-finality chain into a document and the whole document's safe frontier waits those three minutes).

The hard problem is completeness, not sorting

Two providers record actions milliseconds apart. Their notifications arrive in the opposite order. Sorting known entries is trivial — the dangerous question is whether an earlier entry you haven't seen yet still exists.

So providers make a two-sided promise called completeness: closing a frontier at time T means every entry before T has been revealed and no future entry will ever be assigned a timestamp before T. Without the second half, "our database shows nothing earlier" is worthless — a delayed action could be backfilled into a past that documents already acted on. (Providers keep the promise mechanically: a late-arriving request simply gets a timestamp at or after the frontier.)

With multiple providers, a document can only safely process entries older than the minimum of all relevant frontiers:

Alice complete before .......... :200000
Restaurant complete before ..... :180000   ← common frontier
Bank complete before ........... :250000

The slowest provider bounds the window. That is the honest price of composing independent institutions without pretending they already share a ledger. Equal timestamps across different Timelines are broken by a published deterministic rule — never by arrival order, network luck, or thread scheduling.

One more distinction: a provider notification is a wake-up hint — "more evidence may exist" — never "this is next." What gets processed next is decided by completeness and ordering, so a fast provider cannot outshout a slow one carrying earlier events.

There is no official copy

Ask where your bank balance "really" is, and the answer is a specific privileged database. Ask where a Blue document's state "really" is, and the answer is: nowhere — it's a computation, and anyone can run it.

Everything required is on the table: the document (with its Contracts), the channels naming which Timelines feed it, the providers' entries, and their completeness guarantees. Follow the method — collect entries from every channel, close the common frontier, order deterministically, apply PROCESS entry by entry — and you arrive at the same state, with the same BlueId, as everyone else who did the same. Run the open-source libraries from github.com/bluecontract, run MyOS, or write your own implementation from the specification: they all agree, or one of them has a bug — and the fixtures will find it.

This changes what "the state of the document" socially is. You never have to trust a hosted rendering; you can always recompute it. A dispute isn't an argument about whose screenshot to believe — it's a recomputation, and recomputations end arguments.

For a document with embedded documents (next section), one detail matters: the root and its embedded children commit as one reality, so the safe window must cover all of their channels together — completeness is gathered for the root's Timelines and every embedded document's Timelines before an entry is processed. One atomic reality, one frontier.

Feeder and processor

Two jobs, deliberately separated. The feeder faces the messy world: it tracks channels, collects entries, waits for completeness, orders candidates, checks eligibility and authority, and hands over exactly one safe entry. The processor faces only that entry and the document, and computes the deterministic result. Checkpoints, recorded per channel after successful processing, make redelivery harmless: an entry seen twice is stale the second time; crashes replay against unchanged state.

The world stays asynchronous, partial, and occasionally wrong. The document's history stays exact anyway.