Skip to main content

Technical White Paper: Blue Timelines and Multi-Party Event Coordination

Blue: Timelines, Identity Attribution, and Deterministic Document Processing

Version 1.0 | October 2025

Abstract​

This paper addresses the fundamental challenge of deterministic multi-party computation: how can independent document processors, observing the same events from multiple sources, reach identical conclusions without coordination? We introduce Timelines as append-only, hash-chained logs of actions maintained by Timeline Providers, explain how Blue documents use multiple Timeline channels to enable multi-party interaction, and specify the temporal completeness guarantee and processing algorithm that ensure all document processors reach identical document states. We address actor attribution, showing how Timeline Providers distinguish between human principals and AI agents, and finally explain how blockchain-based timelines can be integrated with the completeness guarantee model despite their finality delays.

Part One: The Problem

1. What Is a Timeline?​

A Timeline is an append-only, cryptographically hash-chained sequence of events representing the actions of a single entity - a person, an organization, an AI agent, or a service.

Key Properties:

  • Individual Perspective: Each Timeline represents one actor's view of reality - their actions, statements, and observations.
  • Append-Only: Events can only be added to the end; history cannot be rewritten.
  • Hash-Chained: Each entry links to the previous entry's content hash, making tampering detectable.
  • Timestamped: Every entry has a timestamp establishing temporal order.
  • Authenticated: The Timeline owner's identity is verified by a Timeline Provider.

Conceptual Model:

Think of a Timeline as a personal ledger - a diary of verifiable actions. Alice has her Timeline. Bob has his Timeline. A bank has its Timeline. When they interact through a Blue document, each contributes events from their own Timeline, and the document processes all these perspectives together.

Structure:

Timeline: "Alice's Actions"
- Entry 1: timestamp = T1, prevEntry = null, message = "Request payment"
- Entry 2: timestamp = T2, prevEntry = hash(Entry 1), message = "Confirm delivery"
- Entry 3: timestamp = T3, prevEntry = hash(Entry 2), message = "Cancel order"

Each entry includes:

  • A timestamp (when it happened)
  • A link to the previous entry (forming the chain)
  • A message (what happened)

The first entry has prevEntry: null, establishing the beginning of the Timeline. This creates an immutable, verifiable record of everything Alice has done.

2. Timeline Entry Structure​

Every Timeline Entry is a Blue document with the following structure:

name: Timeline Entry
description: >
  A single immutable entry in an append-only Timeline, representing one action or statement
  by the Timeline owner. The entry is cryptographically linked to the previous entry,
  creating a tamper-evident chain. Timeline Providers assign timestamps and verify identity,
  enabling deterministic multi-party document processing.
timeline:
  type: Timeline
  description: >
    The Timeline this entry belongs to.
prevEntry:
  type: Timeline Entry
  description: >
    The previous entry in this Timeline. This creates the hash chain:
    each entry's blueId is calculated over its content, including this reference to the previous
    entry's blueId. The first entry in a Timeline has prevEntry: null. Any modification to a
    historical entry breaks the chain for all subsequent entries, making tampering detectable.
message:
  description: >
    The actual event content being recorded.
timestamp:
  type: Integer
  description: >
    Microseconds since Unix epoch (1970-01-01T00:00:00Z), assigned by the Timeline Provider.
    This establishes temporal order both within a single Timeline (must be monotonically increasing)
    and across multiple Timelines (enables deterministic event ordering in multi-party documents).
    The Timeline Provider guarantees that once a completeness guarantee is issued for timestamp T,
    all future entries will have timestamp >= T.
actor:
  type: Actor
  description: >
    Attribution of who performed this action.

Example Entry:

type: Timeline Entry
timeline:
  type: MyOS Timeline
  timelineId: "alice-tl-550d7714"
  account: "alice@example.com"
prevEntry:
  blueId: "8BqE4SiVtoJsYKDgHLmzCdWqVN2r5fup7wV"
timestamp: 1699625239856734
message:
  type: Set Price
  amount: 1500
actor:
  type: Principal Actor

The timeline field tells document processors where to query for more entries. The prevEntry creates the hash chain. The timestamp enables deterministic ordering. The actor field identifies who performed the action.

3. Documents with Multiple Timeline Channels​

Blue documents receive events through channels. In Blue, the only permitted channel type is a Timeline channel.

3.1 Example: A Simple Purchase Agreement​

type: Purchase Agreement
status: pending
price: null
currency: USD
contracts:
  buyerChannel:
    type: Timeline Channel
    timeline:
      type: MyOS Timeline
      account: alice@example.com
  sellerChannel:
    type: Timeline Channel
    timeline:
      type: MyOS Timeline
      account: bob@example.com
  setPriceWorkflow:
    type: Sequential Workflow
    channel: buyerChannel
    event:
      type: Set Price
    steps:
      - type: Update Document
        changeset:
          - op: replace
            path: /price
            val: ${event.amount}
  confirmShipmentWorkflow:
    type: Sequential Workflow
    channel: sellerChannel
    event:
      type: Confirm Shipment
    steps:
      - type: Update Document
        changeset:
          - op: replace
            path: /status
            val: "shipped"

This document has two channels:

  • buyerChannel receives events from Alice's Timeline
  • sellerChannel receives events from Bob's Timeline

When Alice posts "Set Price" to her Timeline, the document's setPriceWorkflow executes and updates the price. When Bob posts "Confirm Shipment," the confirmShipmentWorkflow executes and changes status to "shipped."

3.2 The Determinism Problem​

Here's the challenge: What happens when both Alice and Bob post events at nearly the same time?

Alice's Timeline:
- Event A1: timestamp = 1699625239000100, message = {type: "Set Price", amount: 1500}
- Event A2: timestamp = 1699625240000300, message = {type: "Approve Purchase"}

Bob's Timeline:
- Event B1: timestamp = 1699625239000200, message = {type: "Confirm Shipment"}
- Event B2: timestamp = 1699625240000400, message = {type: "Request Refund"}

Question: In what order should a document processor apply these events?

Looking at timestamps:

  • A1: ...239000100
  • B1: ...239000200 (100 microseconds after A1)
  • A2: ...240000300
  • B2: ...240000400

Correct order by timestamp: A1 -> B1 -> A2 -> B2

But here's the problem: How does a processor know it has seen all events up to a given timestamp?

When a Processor receives notification of Alice's event A1, how does it know Bob hasn't also posted an event with an earlier or simultaneous timestamp that it hasn't seen yet?

The Core Challenge: We need a mechanism to ensure every document processor knows when it has a complete view of all events up to a certain point in time across all Timelines.

This is the problem this paper solves.

4. Timelines vs. Blockchain: Personal Perspective vs. Global Consensus​

Before diving into the solution, it's important to understand how Timelines differ from blockchain:

Blockchain: Global Consensus​

A blockchain establishes a single, global ordering of all transactions through network consensus (Proof of Work, Proof of Stake, etc.). Every node agrees: "Transaction T1 came before T2 in the canonical history."

Cost: This global agreement is expensive (computation, energy, coordination) and slow (confirmation times).

Benefit: One universal truth that all participants accept.

Timelines: Personal Perspectives​

Blue Timelines represent individual perspectives without requiring global consensus. Alice records her actions on her Timeline. Bob records his actions on his Timeline. There's no single "canonical order" across all Timelines.

Cost: We need a deterministic algorithm to merge these perspectives when they interact.

Benefit: No coordination overhead. Each Timeline is independent, fast, and cheap.

The Philosophical Difference​

Blockchain asks: "What is the one true order of all events in the universe?"

Blue asks: "Given Alice's perspective and Bob's perspective, how do we deterministically interpret their interaction?"

This is the difference between:

  • One shared reality (blockchain)
  • Multiple verified perspectives that compose deterministically (Blue)

Why This Matters​

You don't need global consensus for most interactions. Alice and Bob don't need the entire world to agree on the order of their messages - they just need a deterministic rule so that anyone processing their conversation reaches the same conclusion.

This makes Blue:

  • Faster (no network consensus delay)
  • Cheaper (no global coordination cost)
  • More private (only participants see the relevant Timelines)
  • More scalable (thousands of independent Timelines vs. one global ledger)

Blockchains can still be used for Timeline storage (see Part Four), but Blue doesn't require them.

Part Two: The Solution - The Completeness Guarantee

5. Timeline Provider Responsibilities​

A Timeline Provider is an entity or service that maintains Timeline storage and provides services to both Timeline owners and document processors. Examples include MyOS (commercial provider), banks (institutional provider), and government digital identity systems.

5.1 Core Responsibilities​

Identity Verification: Verify the identity of the Timeline owner. The strength varies by provider:

  • Email-verified (MyOS)
  • KYC-verified (banks)
  • Government-verified (eIDAS, national ID systems)

Entry Storage: Persist Timeline Entries immutably and make them queryable.

Timestamp Assignment: Assign monotonically increasing timestamp values (microseconds since Unix epoch) that reflect physical time as accurately as possible.

Completeness Guarantees: The critical service that enables deterministic processing - explained in the next section.

Actor Attribution: Include actor field in Timeline Entries distinguishing between human principals and AI agents (explained in Part Three).

5.2 The Binding Completeness Guarantee​

This is the innovation that makes deterministic multi-party processing possible.

The Guarantee:

When a Timeline Provider responds to the query "Confirm no entries with timestamp less than T," it is making a binding commitment:

"There are no entries in this Timeline with timestamp less than T, AND any future entry I accept will have timestamp greater than or equal to T."

This is a promise about both past and future.

Why This Is Critical:

Without this guarantee, document processors can never be sure they have a complete view. With it, they can definitively close the window on all events before T.

Enforcement Mechanisms:

The Timeline Provider MUST ensure this guarantee is never violated. When it receives a request to append a new entry:

Option 1: Reject the request if the requested timestamp would violate an outstanding guarantee

Option 2: Assign timestamp >= T regardless of when the request actually arrived

Most providers use Option 2 - they simply never assign timestamps earlier than any guarantee they've issued.

Example:

11:00:00.100 - Provider issues guarantee: "No entries < 11:00:00.100"
11:00:00.050 - (Later) Provider receives append request
-> Provider assigns timestamp 11:00:00.101 (not .050)

The guarantee is preserved.

6. The Document Processing Algorithm​

When a document processor has a document in some state and receives notification that a new entry has arrived on one of the document's Timeline channels, it follows this algorithm:

Step 1: Retrieve the New Entry​

Fetch the new entry from the Timeline Provider for the channel that signaled a new event.

Example: Alice's Timeline Provider signals new entry available
Processor fetches entry A2 with timestamp = 1699625240000300

Step 2: Query Other Timeline Providers for Completeness​

For each other Timeline channel in the document, query its Timeline Provider:

"Confirm there are no entries with timestamp less than 1699625240000300."

This requests the binding completeness guarantee described in Section 5.2.

Query Bob's Timeline Provider: "Confirm no entries with timestamp < 1699625240000300"
Response: {
  guarantee: "no-entries-before",
  timeline: <timeline details>,
  timestamp: 1699625240000300,
  proof: <cryptographic attestation>
}

Step 3: If Older Entries Are Discovered​

If any Timeline Provider responds with entries having timestamp less than 1699625240000300, the document processor must:

  1. Collect all such entries
  2. Sort them with the new entry by (timestamp, then channelName for deterministic tie-breaking)
  3. Process them in that order
If Bob's provider returns: Entry B1 with timestamp = 1699625239000200
Then process order: B1 (1699625239000200) -> A2 (1699625240000300)

Step 4: Process Entries and Update Checkpoint​

Once all entries up to the timestamp are collected and sorted, they are processed in order according to the Blue Language Specification.

The completeness guarantees ensure that this ordering is final - no later discovery of older events can invalidate it, because all providers have committed that future entries will have timestamps greater than or equal to the queried timestamp.

7. Complete Processing Example​

Let's walk through a concrete example with two participants.

Initial Document State​

type: Purchase Agreement
status: pending
price: null
currency: USD
contracts:
  aliceChannel:
    type: MyOS Timeline Channel
    timelineId: 12345
    email: alice@example.com
  bobChannel:
    type: CitiBank Timeline Channel
    account: bob-account-456
  setPriceWorkflow:
    type: Sequential Workflow
    channel: aliceChannel
    event:
      type: Set Price
    steps:
      - type: Update Document
        changeset:
          - op: replace
            path: /price
            val: ${event.amount}
  confirmShipmentWorkflow:
    type: Sequential Workflow
    channel: bobChannel
    event:
      type: Confirm Shipment
    steps:
      - type: Update Document
        changeset:
          - op: replace
            path: /status
            val: "shipped"
checkpoint:
  type: Channel Event Checkpoint
  lastEvents:
    aliceChannel:
      blueId: "7UEBwTmRMfQ92rGt4vHkzPa8Ypd5KJsLNcA3FV6xDqbn"
      timestamp: 1699625235000000
    bobChannel:
      blueId: "9CrF5TjWupKtZlEphMnDxDfXkWoO3s6gvq8Z"
      timestamp: 1699625230000000

Processing Trigger​

Alice's Timeline Provider (MyOS) signals: "New entry available after checkpoint."

Step 1: Fetch New Entry from Alice's Timeline​

type: Timeline Entry
timeline:
  type: MyOS Timeline Channel
  timelineId: 12345
  email: alice@example.com
prevEntry:
  blueId: "7UEBwTmRMfQ92rGt4vHkzPa8Ypd5KJsLNcA3FV6xDqbn"
timestamp: 1699625240000000
message:
  type: Set Price
  amount: 1500
actor:
  type: Principal Actor

Step 2: Query Bob's Timeline Provider for Completeness​

Processor -> CitiBank Timeline API:
"Confirm no entries with timestamp < 1699625240000000"

CitiBank -> Processor:
{
  guarantee: "no-entries-before",
  timeline: {
    type: CitiBank Timeline
    account: bob-account-456
  },
  timestamp: 1699625240000000,
  proof: {
    type: "Signed Attestation",
    signature: "bank-cryptographic-signature",
    certificate: "bank-tls-certificate"
  }
}

Step 3: No Older Entries Found​

CitiBank confirms no entries exist before the queried timestamp. The processor can safely proceed knowing it has a complete view of all events up to timestamp 1699625240000000.

Step 4: Process Entry​

  1. Match entry message against workflows
  2. Find setPriceWorkflow matches the "Set Price" event type
  3. Execute: sets price: 1500
  4. Calculate new document blueId

Step 5: Update Checkpoint​

checkpoint:
  type: Channel Event Checkpoint
  lastEvents:
    aliceChannel:
      blueId: "8BqE4SiVtoJsYKDgHLmzCdWqVN2r5fup7wV" # New entry
      timestamp: 1699625240000000
    bobChannel:
      blueId: "9CrF5TjWupKtZlEphMnDxDfXkWoO3s6gvq8Z" # Unchanged
      timestamp: 1699625230000000

Result​

Every document processor following this algorithm reaches the identical final state:

  • price: 1500
  • status: pending
  • Same checkpoint blueIds
  • Same document blueId

The binding completeness guarantees from both MyOS and CitiBank ensure this ordering cannot be invalidated by late-arriving events.

8. Actor Attribution: The Foundation of AI Agent Trust​

A core responsibility of any Timeline Provider is actor attribution: the verifiable process of establishing who or what executed each action. Far from being simple metadata, this attribution is the bedrock on which Blue documents build and enforce policies governing automation, delegated authority, and the necessity of human oversight.

8.1 The Trust Model​

Within the Blue architecture, Timeline Providers function as trust anchors. When a document processor ingests a Timeline Entry, it inherently trusts the Provider's assertions regarding three key facts:

  1. Identity: The verified owner of the Timeline.
  2. Temporal Order: The precise time the action took place.
  3. Actor Attribution: The nature of the actor - whether a human principal or an AI agent.

This model intentionally concentrates trust in the Timeline Provider for practical reasons. Instead of resorting to computationally expensive global consensus mechanisms or complex zero-knowledge proofs, Blue leverages existing trust relationships. Participants inherently select Timeline Providers they already deem trustworthy, such as their bank, a government identity service, or a vetted commercial platform.

Actor attribution is the mechanism that makes this trust actionable. By providing a clear and verifiable distinction between actions taken by humans and those performed by AI agents, Timeline Providers empower documents to enforce granular policies that define what can be automated versus what demands direct human authorization.

8.2 Base Actor Types​

The Blue protocol mandates that all Timeline Providers support two fundamental actor types:

Principal Actor:

type: Principal Actor

Signifies a direct action taken by the Timeline's owner, whether through a user interface or via programmatic access (e.g., an API key) under the owner's direct control.

Agent Actor:

type: Agent Actor

Signifies an action performed by an AI agent operating on the Timeline owner's behalf, within a scope of delegated authority.

These base types establish the semantic distinction. Timeline Providers then specialize these types with their own implementation details.

8.3 Timeline Provider Specializations​

Individual Timeline Providers will implement actor attribution using methods tailored to their specific infrastructure and security requirements. The following examples from MyOS illustrate this specialization:

UI Principal Actor:

name: UI Principal Actor
type: Principal Actor
uiSessionDetails:
  type: UI Session Details
  description: >
    Includes details on the login session, such as authentication method and session ID.
    This allows the Provider to differentiate between login sessions and assess
    authentication strength (e.g., password, 2FA, biometrics).

API Principal Actor:

name: API Principal Actor
type: Principal Actor
apiKeyId:
  type: Text
  description: >
    The unique identifier for the API key used in the request. While potentially opaque to
    third parties, the Timeline owner can dereference this ID for auditing, allowing the
    provider to trace actions back to a specific integration or service.

MyOS Agent Actor:

name: MyOS Agent Actor
type: Agent Actor
onBehalfOf:
  type: Text
  description: The principal's accountId - whose authority the agent is using.
agentRef:
  type: MyOS Document Session Reference
  description: >
    A reference to the Blue document defining the AI agent (Worker) that executed the
    action. Observers can use this to inspect the agent's configuration, defined
    capabilities, and operational history.
delegation:
  type: MyOS Document Session Reference
  description: >
    A reference to the document that formally grants this agent its permissions. This
    creates an unambiguous audit trail detailing the precise scope of authority that
    was delegated.

Example Timeline Entry with Full Attribution:

type: Timeline Entry
timeline:
  type: MyOS Timeline
  account: "alice@example.com"
timestamp: 1699625240000000
message:
  type: Operation Request
  operation: submitPurchaseOrder
  request:
    vendor: "Office Supplies Inc"
    amount: 450.00
actor:
  type: MyOS Agent Actor
  onBehalfOf: "alice@example.com"
  agentRef:
    blueId: "alice-procurement-agent-v2.1"
    sessionId: "d_agent_abc123"
  delegation:
    blueId: "alice-agent-delegation-2024"
    sessionId: "d_grant_def456"

An observer of this Timeline Entry can perform a complete audit by:

  • Verifying the action was performed by an agent, not directly by Alice.
  • Retrieving the referenced agent document to understand its specific capabilities.
  • Inspecting the referenced delegation grant to confirm the scope of authority Alice conferred.
  • Tracing the full chain of authority from principal to agent action.

8.4 Actor Policy Enforcement​

Blue documents leverage Actor Policy contracts to specify which operations mandate human authorization:

contracts:
  actorPolicy:
    type: Actor Policy
    operations:
      # Critical operations MUST be performed by human principal
      authorizeFunds:
        requiresActor: principal
      captureFunds:
        requiresActor: principal
      cancelContract:
        requiresActor: principal
      # Lower-risk operations can be performed by any actor
      specifyPayee:
        requiresActor: any
      addNotes:
        requiresActor: any
      requestInformation:
        requiresActor: any

Enforcement by Document Processors:

A document processor enforces these policies as follows:

  1. It extracts the actor.type from the incoming entry.
  2. If the actor.type is a specialized form of Agent Actor, the action is classified as an agent action.
  3. If the actor.type is a specialized form of Principal Actor, the action is classified as a human action.
  4. It consults the document's Actor Policy for the operation being requested.
  5. If the policy mandates a principal actor but the action was from an agent, the entry is rejected and not processed.
  6. If the policy permits any actor or if the actor type matches the requirement, the entry is processed normally.

Example Scenarios:

# [OK] ACCEPTED: Agent performing allowed operation
actor:
  type: MyOS Agent Actor
  onBehalfOf: "alice@example.com"
message:
  type: Operation Request
  operation: addNotes
  request: "Vendor responded with delivery estimate of 5 days"

# [X] REJECTED: Agent attempting restricted operation
actor:
  type: MyOS Agent Actor
  onBehalfOf: "alice@example.com"
message:
  type: Operation Request
  operation: authorizeFunds
  request: {amount: 50000}
# Reason for Rejection: The 'authorizeFunds' operation requires a principal actor, but the entry was submitted by an agent actor.

8.5 Advanced Policy with Specialization Details​

Actor Policies can be made more granular by referencing the specialized details provided by the Timeline Provider:

contracts:
  actorPolicy:
    type: Actor Policy
    operations:
      approveExpense:
        actor:
          type: UI Principal Actor
          uiSesstionDetails:
            strongAuthentication: true

This capability allows for the creation of highly sophisticated policies, such as:

  • "All critical operations must be authenticated via biometrics."
  • "Payments cannot be authorized using API keys; they require an interactive UI session."

Timeline Providers that offer these specialized actor details unlock a more powerful and context-aware level of policy enforcement.

8.6 The Significance: Solving the AI Agent Trust Problem​

The rapid proliferation of AI agents presents a critical trust challenge: How can we grant agents the autonomy to be useful while ensuring strict accountability and preserving human oversight?

Prevailing methods are inadequate:

[X] Shared Credentials: Giving an agent your credentials grants it unlimited power and erases attribution.

[X] Constant Human Approval: Requiring manual approval for every action negates the benefits of automation.

[X] Unverified Claims: Relying on an agent's self-reported claim of authorization ("the user approved this") is unverifiable and insecure.

The Blue actor attribution model provides a robust solution:

[OK] Verifiable Attribution: Every action is cryptographically tied to its actor type - human or agent.

[OK] Bounded Autonomy: Documents enforce strict boundaries on which operations agents are permitted to perform.

[OK] Auditable Delegation: An agent's authority is explicitly defined in and linked to a verifiable delegation document.

[OK] Instant Revocation: Access can be revoked at the Timeline Provider level, immediately halting an agent's ability to act.

[OK] Immutable Audit Trail: A complete, tamper-evident history of every agent action and its authorizing delegation is preserved.

8.7 The Responsibility of the Timeline Provider​

In this model, Timeline Providers assume a significant and clearly defined set of responsibilities.

Their Core Mandates:

  1. Attribute Accurately: They must correctly distinguish between actions originating from principals versus agents.
  2. Verify Delegation: They must confirm that the principal has genuinely authorized an agent's access.
  3. Enforce Scope: They must ensure agents operate only within their explicitly granted authority.
  4. Honor Revocation: They must immediately stop processing entries from agents whose permissions have been revoked.

Participants place their trust in Timeline Providers to:

  • Never misrepresent an agent action as a principal's action, or vice-versa.
  • Reject any attempt by an agent to act without a valid delegation.
  • Maintain the integrity of timestamps in conjunction with actor attribution.

While this represents a concentration of trust, it is both manageable and practical for several reasons:

  • Participants self-select Providers they already trust for critical functions (e.g., banks, government agencies, reputable platforms).
  • These Providers are motivated by reputation and often bound by regulation to maintain trustworthiness.
  • The hash-chained structure of the Timeline makes any subsequent tampering with the record detectable.
  • If a Provider were to misbehave, the evidence of its failure would be immutably recorded for all relevant parties to inspect.

8.8 A Practical Framework for Trusting AI Agents​

Blue's approach to AI safety is not to solve the abstract problem of "AI alignment," but rather to solve the concrete, practical problem of trust in automation.

The Question: Can I safely delegate procurement tasks to an AI agent?

The Blue Framework Provides the Answer:

  • Yes, because the agent operates through a Timeline where every action it takes is indelibly marked as an agent action.
  • Yes, because your procurement documents explicitly define the boundaries of its autonomy, specifying which tasks it can perform (requestQuotes) and which require your direct approval (authorizeFunds).
  • Yes, because a trusted Timeline Provider (e.g., your company's IT department or a commercial service) guarantees the accuracy of this attribution.
  • Yes, because you have a complete, verifiable audit trail of everything the agent has done.
  • Yes, because you can revoke its access instantly at any time.

This framework fundamentally transforms the question from an intractable "Do I trust this AI's internal logic?" to a much more manageable "Do I trust this Timeline Provider's system of attribution?" The latter is a problem we are already equipped to solve, as we routinely place our trust in institutions for identity verification and authentication.

Actor attribution, guaranteed by trusted Timeline Providers, is the foundational mechanism that enables AI agents to become safe, accountable, and practical participants in the Blue ecosystem.

Part Four: Blockchain-Based Timelines

9. Blockchain as Timeline Storage​

Blockchains can serve as Timeline storage, providing maximum decentralization and tamper-resistance. However, they introduce unique challenges around finality delays and the completeness guarantee model.

9.1 Key Difference: No Provider Service​

Unlike MyOS or bank Timeline Providers, there is no centralized "Ethereum Timeline Provider" service. Instead:

  • Each document processor connects directly to the blockchain (via their own node or RPC endpoint)
  • The Timeline is defined as a smart contract address + owner identity
  • All processors read from the same on-chain data source

Timeline Definition:

celineChannel:
  type: Timeline Channel
  timeline:
    type: Ethereum Timeline
    contract: "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
    chainId: 1
    owner: "0xCelineEthereumAddress"
    finalityBlocks: 12 # Requires 12 confirmations before entries are considered final

9.2 The Finality Challenge​

Blockchains achieve consensus through a finality mechanism. For Ethereum:

  • Latest block: The most recently mined block (not yet final)
  • Finalized block: A block with sufficient confirmations (e.g., 12+ blocks later, ~2-3 minutes)
  • Pending transactions: Transactions that might still be included in upcoming blocks

The Problem:

The completeness guarantee model requires: "Confirm no entries exist with timestamp less than T, and all future entries will have timestamp greater than or equal to T."

A blockchain-based Timeline cannot provide this guarantee for recent timestamps because:

  • Pending transactions might get included in the next block
  • Block timestamps are assigned by miners/validators, not under the Timeline owner's control
  • The blockchain can only provide guarantees for finalized blocks (past events)

9.3 Blockchain Timeline Entry Structure​

Smart Contract Design:

contract TimelineRegistry {
    struct Entry {
        bytes32 prevEntryHash;
        bytes message; // Encoded Blue document
    }

    mapping(address => Entry[]) public timelines;

    function appendEntry(bytes32 prevEntryHash, bytes memory message) external {
        Entry memory newEntry = Entry({
            prevEntryHash: prevEntryHash,
            message: message
        });
        timelines[msg.sender].push(newEntry);
    }
}

Timeline Entry Retrieved by Processors:

type: Timeline Entry
timeline:
  type: Ethereum Timeline
  contract: "0x742d35Cc..."
  owner: "0xCelineAddress"
  finalityBlocks: 12
prevEntry:
  blueId: "4FnJ8K2mLvNpQrRsStUvWxYz..."
timestamp: 1699625239000000 # block.timestamp * 1,000,000 (converted to microseconds)
message:
  type: Approve Transaction
  transactionId: "tx-789"
actor:
  type: Principal Actor
  accountId: "0xCelineAddress"
blockNumber: 18234567
transactionHash: "0xabc123..."

The timestamp is derived from the block's timestamp (in seconds) converted to microseconds. Block timestamps have seconds precision only, meaning many entries could have identical timestamps.

9.4 Modified Processing Algorithm for Blockchain Timelines​

When a document includes blockchain-based Timeline channels, the processing algorithm must account for finality delays:

Step 1: Determine Finalized Timestamp

For each blockchain Timeline channel, calculate the finalized timestamp:

Latest Block: 18234579 (timestamp: 1699625240)
Finality Requirement: 12 blocks
Finalized Block: 18234579 - 12 = 18234567 (timestamp: 1699625096)
Finalized Timestamp (in microseconds): 1699625096000000

Step 2: Identify Safe Processing Window

The safe processing window is the minimum finalized timestamp across all Timeline channels.

Example:
- Alice (MyOS): Can guarantee up to NOW (1699625240000000)
- Bob (Bank): Can guarantee up to NOW (1699625240000000)
- Celine (Ethereum): Can only guarantee up to finalized (1699625096000000)
Safe Window: min(NOW, NOW, finalized) = 1699625096000000

Step 3: Process Only Finalized Events

Document processors can only process events whose timestamps are less than or equal to the safe window.

When Alice's Timeline Provider signals a new entry with timestamp 1699625240000000:

1. Alice's entry timestamp: 1699625240000000
2. Safe Window: 1699625096000000
3. Alice's timestamp > Safe Window
-> CANNOT PROCESS YET
-> WAIT for blockchain finality to advance

Step 4: Wait and Batch Process

[~2-3 minutes later]
Blockchain advances:
- Latest Block: 18234591 (timestamp: 1699625384)
- Finalized Block: 18234591 - 12 = 18234579 (timestamp: 1699625240)
- Finalized Timestamp: 1699625240000000

Safe Window now: 1699625240000000

Alice's entry timestamp (1699625240000000) is less than or equal to the safe window
-> CAN PROCESS NOW

Query all Timeline Providers:
- Alice (MyOS): "Confirm no entries less than 1699625240000000" [OK]
- Bob (Bank): "Confirm no entries less than 1699625240000000" [OK]
- Celine (Ethereum): Read finalized blockchain state up to block 18234579 [OK]

Process all collected entries with timestamps less than or equal to 1699625240000000

9.5 Practical Implications​

Inherent Delay:

When any Timeline channel uses blockchain storage with finality requirements, all document processing is delayed by that finality period.

  • Pure MyOS + Bank Timelines: Millisecond processing [OK]
  • Pure Ethereum Timelines: ~2-3 minute batch processing [OK]
  • Mixed MyOS + Ethereum: Forced to ~2-3 minute delay [X]

This is a fundamental trade-off:

  • [OK] Gain: Maximum decentralization, censorship-resistance, public verifiability
  • Cost: All processing waits for blockchain finality

Timestamp Collisions:

Block timestamps have seconds precision, converted to microseconds by appending zeros. Multiple entries in the same block will have identical timestamps:

Entry 1: timestamp = 1699625240000000 (block 18234579, tx index 15)
Entry 2: timestamp = 1699625240000000 (block 18234579, tx index 47)
Entry 3: timestamp = 1699625240000000 (block 18234579, tx index 103)

For deterministic ordering of entries with identical timestamps, processors sort by:

  1. timestamp (primary)
  2. channelName (secondary, alphabetical)
  3. blockNumber then transactionIndex (tertiary, for entries on same blockchain channel)

9.6 When to Use Blockchain Timelines​

Good Use Cases:

  • High-value, infrequent transactions where ~3 minute delays are acceptable
  • Public accountability requirements (anyone can verify on-chain)
  • Maximum decentralization requirements
  • Scenarios where participants strongly distrust each other and won't accept any centralized Timeline Provider

Poor Use Cases:

  • Real-time interactions requiring immediate processing
  • High-frequency events (cost and throughput limitations)
  • Privacy-sensitive data (blockchain is public)
  • When mixed with fast Timeline Providers (slows everything down)

9.7 Completeness Guarantee for Blockchain Timelines​

How Processors Provide the Guarantee:

When queried for "Confirm no entries with timestamp less than T":

Query: "Confirm no entries with timestamp less than T"

Process:
1. Convert T (microseconds) to seconds: T_seconds = T / 1,000,000
2. Determine which block corresponds to T_seconds
3. Verify that block is finalized (has required confirmations)
4. Read all entries from Timeline smart contract up to finalized block
5. Return entries found (if any) OR completeness confirmation

Response:
{
  guarantee: "no-entries-before",
  timestamp: T,
  proof: {
    type: "Blockchain Finality Proof",
    finalizedBlock: 18234567,
    blockHash: "0xdef456...",
    confirmations: 12,
    entriesInTimelineUpToBlock: [] # Empty = no entries found
  }
}

The Guarantee is Satisfied Because:

  • The queried timestamp T corresponds to a finalized block (immutable history)
  • All entries up to that block have been read
  • Future entries will be in later blocks with later timestamps
  • Block timestamps are monotonically increasing

This demonstrates that blockchain-based Timelines can provide the completeness guarantee, but only for timestamps in the finalized past, not for the recent present.

Conclusion​

Blue Timelines enable deterministic multi-party document processing through:

  1. Append-only, hash-chained Timeline Entries providing immutable, verifiable records of individual perspectives
  2. Binding completeness guarantees from Timeline Providers ensuring document processors can safely determine event ordering across multiple independent Timelines
  3. Actor attribution distinguishing between human principals and AI agents, enabling documents to enforce policies about which actions require human authorization
  4. Blockchain integration model showing how decentralized Timeline storage can be incorporated despite finality delays

Together, these mechanisms create a foundation for autonomous, verifiable interactions where:

  • Actions are cryptographically attributed to specific actors
  • Event ordering is deterministic across all document processors
  • AI agents can operate safely within defined boundaries
  • Participants can choose Timeline Providers matching their trust, privacy, and performance requirements
  • No central coordinator or global consensus is required for fast timelines
  • Blockchain storage provides maximum decentralization when finality delays are acceptable

The result is a flexible, composable trust model that scales from convenient managed services to maximum-security decentralized infrastructure.

End of Technical White Paper