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:

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

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:

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

Example Entry:

1type: Timeline Entry
2timeline:
3  type: MyOS Timeline
4  timelineId: "alice-tl-550d7714"
5  account: "alice@example.com"
6prevEntry:
7  blueId: "8BqE4SiVtoJsYKDgHLmzCdWqVN2r5fup7wV"
8timestamp: 1699625239856734
9message:
10  type: Set Price
11  amount: 1500
12actor:
13  type: Principal Actor
14

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

1type: Purchase Agreement
2status: pending
3price: null
4currency: USD
5contracts:
6  buyerChannel:
7    type: Timeline Channel
8    timeline:
9      type: MyOS Timeline
10      account: alice@example.com
11  sellerChannel:
12    type: Timeline Channel
13    timeline:
14      type: MyOS Timeline
15      account: bob@example.com
16  setPriceWorkflow:
17    type: Sequential Workflow
18    channel: buyerChannel
19    event:
20      message:
21        type: Set Price
22    steps:
23      - type: Update Document
24        changeset:
25          - op: replace
26            path: /price
27            val: ${event.message.amount}
28  confirmShipmentWorkflow:
29    type: Sequential Workflow
30    channel: sellerChannel
31    event:
32      message:
33        type: Confirm Shipment
34    steps:
35      - type: Update Document
36        changeset:
37          - op: replace
38            path: /status
39            val: "shipped"
40

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?

1Alice's Timeline:
2- Event A1: timestamp = 1699625239000100, message = {type: "Set Price", amount: 1500}
3- Event A2: timestamp = 1699625240000300, message = {type: "Approve Purchase"}
4
5Bob's Timeline:
6- Event B1: timestamp = 1699625239000200, message = {type: "Confirm Shipment"}
7- Event B2: timestamp = 1699625240000400, message = {type: "Request Refund"}
8

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:

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

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.

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

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.

1Query Bob's Timeline Provider: "Confirm no entries with timestamp < 1699625240000300"
2Response: {
3  guarantee: "no-entries-before",
4  timeline: <timeline details>,
5  timestamp: 1699625240000300,
6  proof: <cryptographic attestation>
7}
8

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

1If Bob's provider returns: Entry B1 with timestamp = 1699625239000200
2Then process order: B1 (1699625239000200) -> A2 (1699625240000300)
3

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

1type: Purchase Agreement
2status: pending
3price: null
4currency: USD
5contracts:
6  aliceChannel:
7    type: MyOS Timeline Channel
8    timelineId: 12345
9    email: alice@example.com
10  bobChannel:
11    type: CitiBank Timeline Channel
12    account: bob-account-456
13  setPriceWorkflow:
14    type: Sequential Workflow
15    channel: aliceChannel
16    event:
17      message:
18        type: Set Price
19    steps:
20      - type: Update Document
21        changeset:
22          - op: replace
23            path: /price
24            val: ${event.message.amount}
25  confirmShipmentWorkflow:
26    type: Sequential Workflow
27    channel: bobChannel
28    event:
29      message:
30        type: Confirm Shipment
31    steps:
32      - type: Update Document
33        changeset:
34          - op: replace
35            path: /status
36            val: "shipped"
37checkpoint:
38  type: Channel Event Checkpoint
39  lastEvents:
40    aliceChannel:
41      blueId: "7UEBwTmRMfQ92rGt4vHkzPa8Ypd5KJsLNcA3FV6xDqbn"
42      timestamp: 1699625235000000
43    bobChannel:
44      blueId: "9CrF5TjWupKtZlEphMnDxDfXkWoO3s6gvq8Z"
45      timestamp: 1699625230000000
46

Processing Trigger

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

Step 1: Fetch New Entry from Alice's Timeline

1type: Timeline Entry
2timeline:
3  type: MyOS Timeline Channel
4  timelineId: 12345
5  email: alice@example.com
6prevEntry:
7  blueId: "7UEBwTmRMfQ92rGt4vHkzPa8Ypd5KJsLNcA3FV6xDqbn"
8timestamp: 1699625240000000
9message:
10  type: Set Price
11  amount: 1500
12actor:
13  type: Principal Actor
14

Step 2: Query Bob's Timeline Provider for Completeness

1Processor -> CitiBank Timeline API:
2"Confirm no entries with timestamp < 1699625240000000"
3
4CitiBank -> Processor:
5{
6  guarantee: "no-entries-before",
7  timeline: {
8    type: CitiBank Timeline
9    account: bob-account-456
10  },
11  timestamp: 1699625240000000,
12  proof: {
13    type: "Signed Attestation",
14    signature: "bank-cryptographic-signature",
15    certificate: "bank-tls-certificate"
16  }
17}
18

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

1checkpoint:
2  type: Channel Event Checkpoint
3  lastEvents:
4    aliceChannel:
5      blueId: "8BqE4SiVtoJsYKDgHLmzCdWqVN2r5fup7wV" # New entry
6      timestamp: 1699625240000000
7    bobChannel:
8      blueId: "9CrF5TjWupKtZlEphMnDxDfXkWoO3s6gvq8Z" # Unchanged
9      timestamp: 1699625230000000
10

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:

1type: Principal Actor
2

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:

1type: Agent Actor
2

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:

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

API Principal Actor:

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

MyOS Agent Actor:

1name: MyOS Agent Actor
2type: Agent Actor
3onBehalfOf:
4  type: Text
5  description: The principal's accountId - whose authority the agent is using.
6agentRef:
7  type: MyOS Document Session Reference
8  description: >
9    A reference to the Blue document defining the AI agent (Worker) that executed the
10    action. Observers can use this to inspect the agent's configuration, defined
11    capabilities, and operational history.
12delegation:
13  type: MyOS Document Session Reference
14  description: >
15    A reference to the document that formally grants this agent its permissions. This
16    creates an unambiguous audit trail detailing the precise scope of authority that
17    was delegated.
18

Example Timeline Entry with Full Attribution:

1type: Timeline Entry
2timeline:
3  type: MyOS Timeline
4  account: "alice@example.com"
5timestamp: 1699625240000000
6message:
7  type: Operation Request
8  operation: submitPurchaseOrder
9  request:
10    vendor: "Office Supplies Inc"
11    amount: 450.00
12actor:
13  type: MyOS Agent Actor
14  onBehalfOf: "alice@example.com"
15  agentRef:
16    blueId: "alice-procurement-agent-v2.1"
17    sessionId: "d_agent_abc123"
18  delegation:
19    blueId: "alice-agent-delegation-2024"
20    sessionId: "d_grant_def456"
21

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:

1contracts:
2  actorPolicy:
3    type: Actor Policy
4    operations:
5      # Critical operations MUST be performed by human principal
6      authorizeFunds:
7        requiresActor: principal
8      captureFunds:
9        requiresActor: principal
10      cancelContract:
11        requiresActor: principal
12      # Lower-risk operations can be performed by any actor
13      specifyPayee:
14        requiresActor: any
15      addNotes:
16        requiresActor: any
17      requestInformation:
18        requiresActor: any
19

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:

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

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

8.5 Advanced Policy with Specialization Details

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

1contracts:
2  actorPolicy:
3    type: Actor Policy
4    operations:
5      approveExpense:
6        actor:
7          type: UI Principal Actor
8          uiSesstionDetails:
9            strongAuthentication: true
10

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:

1celineChannel:
2  type: Timeline Channel
3  timeline:
4    type: Ethereum Timeline
5    contract: "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
6    chainId: 1
7    owner: "0xCelineEthereumAddress"
8    finalityBlocks: 12 # Requires 12 confirmations before entries are considered final
9

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:

1contract TimelineRegistry {
2    struct Entry {
3        bytes32 prevEntryHash;
4        bytes message; // Encoded Blue document
5    }
6
7    mapping(address => Entry[]) public timelines;
8
9    function appendEntry(bytes32 prevEntryHash, bytes memory message) external {
10        Entry memory newEntry = Entry({
11            prevEntryHash: prevEntryHash,
12            message: message
13        });
14        timelines[msg.sender].push(newEntry);
15    }
16}
17

Timeline Entry Retrieved by Processors:

1type: Timeline Entry
2timeline:
3  type: Ethereum Timeline
4  contract: "0x742d35Cc..."
5  owner: "0xCelineAddress"
6  finalityBlocks: 12
7prevEntry:
8  blueId: "4FnJ8K2mLvNpQrRsStUvWxYz..."
9timestamp: 1699625239000000 # block.timestamp * 1,000,000 (converted to microseconds)
10message:
11  type: Approve Transaction
12  transactionId: "tx-789"
13actor:
14  type: Principal Actor
15  accountId: "0xCelineAddress"
16blockNumber: 18234567
17transactionHash: "0xabc123..."
18

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:

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

Step 2: Identify Safe Processing Window

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

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

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:

11. Alice's entry timestamp: 1699625240000000
22. Safe Window: 1699625096000000
33. Alice's timestamp > Safe Window
4-> CANNOT PROCESS YET
5-> WAIT for blockchain finality to advance
6

Step 4: Wait and Batch Process

1[~2-3 minutes later]
2Blockchain advances:
3- Latest Block: 18234591 (timestamp: 1699625384)
4- Finalized Block: 18234591 - 12 = 18234579 (timestamp: 1699625240)
5- Finalized Timestamp: 1699625240000000
6
7Safe Window now: 1699625240000000
8
9Alice's entry timestamp (1699625240000000) is less than or equal to the safe window
10-> CAN PROCESS NOW
11
12Query all Timeline Providers:
13- Alice (MyOS): "Confirm no entries less than 1699625240000000" [OK]
14- Bob (Bank): "Confirm no entries less than 1699625240000000" [OK]
15- Celine (Ethereum): Read finalized blockchain state up to block 18234579 [OK]
16
17Process all collected entries with timestamps less than or equal to 1699625240000000
18

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:

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

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":

1Query: "Confirm no entries with timestamp less than T"
2
3Process:
41. Convert T (microseconds) to seconds: T_seconds = T / 1,000,000
52. Determine which block corresponds to T_seconds
63. Verify that block is finalized (has required confirmations)
74. Read all entries from Timeline smart contract up to finalized block
85. Return entries found (if any) OR completeness confirmation
9
10Response:
11{
12  guarantee: "no-entries-before",
13  timestamp: T,
14  proof: {
15    type: "Blockchain Finality Proof",
16    finalizedBlock: 18234567,
17    blockHash: "0xdef456...",
18    confirmations: 12,
19    entriesInTimelineUpToBlock: [] # Empty = no entries found
20  }
21}
22

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~~