Skip to main content

Quick Tutorial - Introduction

Your AI assistant can already search, compare prices, and fill shopping carts. But you'd never give it your credit card because there's no way to set safe boundaries.

Blue unlocks safe autonomy at machine speed: it lets every participant - human or AI - specify exactly what's permitted, verify who initiated each action, and rely on trusted processors to enforce the rules.

1. The big idea (why Blue feels familiar)​

When two people strike a deal we …

  1. Talk it through in a shared language.
  2. Write it down so everyone can see the terms and track how the deal is unfolding.
  3. Bring in trusted parties - escrow, card network, courier - when the stakes feel risky.
  4. Act and observe - we do our part while watching others do theirs.

Blue gives software the same four steps:

Human habitBlue feature
Shared wordsFull-sentence vocabulary. Forget stubby API nouns; describe intent the way you'd explain it to a person.
Written contractSelf-contained document. Facts plus deterministic rules any Blue processor can run.
Trusted 3rd partiesNamed participants (Card Processor, DHL) who participate in the interaction by following the agreed rules.
Verifiable activityPersonal signed timelines. Each party publishes their actions to their own timeline while observing others'.

Participants are actors named in the document (e.g. Alice, Bob, Card Processor).
Processors are whichever engines they choose - MyOS in the cloud, a CLI binary, or tomorrow's phone app - that read the document plus the timelines and, as long as they are compliant with specification, converge independently.

2. Example Story — "I want a painless refund"​

2.1. The problem​

Alice likes Bob's $120 video-course but has never heard of him. She'll buy only if a refund is automatic for the first week. Bob is happy—provided everything runs itself.

2.2. Bob's Blue solution​

Order document — participants: Alice, Bob
  • If Alice accepts the course, Bob provides an embedded payment document
  • If payment is refunded, course access is immediately revoked
Card Processor-payment document — participants: Alice, Bob, Card Processor
  • Capture $120 the moment Alice pays.
  • For the next 7 days Alice may post RequestRefund.
  • On that event Card Processor refunds the full amount automatically—no Bob approval.
  • Bob can still hit the API and refund on his own.

One link, one language, one contract - each party processes it on whichever engine they already trust.

2.3. Why Alice clicks Buy​

  • She trusts Card Processor, not Bob. She interacts directly with Card Processor and knows her refund right is enforced.
  • Crystal checkout copy. Card Processor can show "Instant refund within 7 days" because it reads that promise straight from Bob's document.
  • Self-service. Alice can click Refund or drop RequestRefund onto her timeline; either path works.

2.4. How the week unfolds​

DayTimeline entryOutcome (seen by every processor)
0AuthorisePayment (Alice) → PaymentCaptured (Card Processor)Course unlocked; refund window ticking
5RequestRefund (Alice)Card Processor refunds $120; Bob's dashboard logs PaymentRefunded; Order flips to Cancelled
8(none)A late request is ignored - rule expired

No emails, no screenshots, no chargebacks: the timelines settle it.

Why This Works: Email + Blockchain, Without the Baggage​

Think of Blue as combining the best of both worlds:

  • Like email: You control your own timeline, share what you want, maintain privacy
  • Like blockchain: Everyone can verify what happened, but without expensive global consensus
  • Unlike both: Documents contain executable rules, not just static data

Alice's refund worked because her timeline proved her request, Card Processor's timeline proved the refund, and the document's rules guaranteed the outcome.

3. What this buys you​

  • No new backbone — run MyOS, a Java local app, or a Node.js Lambda; everyone reaches the same verdict.
  • Infinite scalability — every party processes only the timelines named in its contract, so there's no global ledger to bottleneck or shard. One deal or a million run with the same architecture.
  • No schema-sync calls — reference any concept; the BlueId proves its meaning.
  • No invisible behaviour — the only path to action is a timeline everyone can inspect.
  • Plug-and-play trust — drop in a bank, insurer, or sensor as a named participant; they enforce their slice and earn a fee without new code or schema mapping.

4. Why Blue ≠ blockchain / DLT​

  • Personal timelines, not global consensus. Like email, you control your own timeline and share selectively. Unlike blockchain, there's no expensive global ledger to maintain or expensive mining to secure.
  • Document-focused verification. Processors only need timelines from participants named in a specific document—not the entire network's history.
  • Privacy by design. Alice's RequestRefund is visible to Card Processor but not necessarily to anyone else—no public blocks exposing every transaction.
  • Efficiency without compromise. All processors reach the same conclusion, but without mining, global consensus, or network-wide synchronization—just verified timelines from the specific parties involved.

5. Where this heads next​

5. Where this heads next​

A. Programmable Money: PayNotes​

Traditional payments are fire-and-forget. PayNotes are living contracts: conditional escrow tied to delivery confirmation, split payments across multiple recipients, time-bound refund windows, usage-based caps.

The AI unlock: Give your AI a PayNote with a $500 budget and rules—it can negotiate and pay suppliers autonomously, but can't exceed the cap or violate terms. You're not giving it your credit card; you're giving it a contract the Card Processor enforces. Read more about PayNotes and see real examples.

B. The AI-to-AI Economy Is Here​

The next revolution isn't AI assistants—it's AI agents negotiating with other AI agents at machine speed. MyOS for Business makes this real today.

Your Sales AI negotiates with Customer AI while both humans sleep. They wake to full audit trails: who proposed what, who accepted, who paid. Because every step is a Blue document on verified timelines, you see exactly what your AI negotiated and why—trackable, verifiable, no surprises.

C. Verifiable AI Plans​

As agents handle complex tasks—drafting contracts, allocating budgets, coordinating supply chains—blind trust breaks down. The solution: if every agent explains its plan as a Blue document, the rules become enforceable.

The AI can't act outside its boundaries because the Blue document is the boundary. Before execution, the plan gets checked—by humans or another AI. MyOS uses this pattern: one agent prepares the plan, a second agent reviews it and warns the user if something looks off.

Trust through structure: The AI moves fast, but the Blue document ensures it stays in bounds.

D. Composability: Trust Infrastructure as Lego Bricks​

Because Blue documents are content-addressed by meaning (BlueId), proven patterns become reusable. Found a great escrow pattern? Reference its BlueId. Need the same refund policy across products? One definition, infinite uses. Building on industry standards? Import from repo.blue.

As more organizations publish patterns, complex multi-party deals assemble from verified components—each already working in production elsewhere. The cost of trust infrastructure approaches zero.

6. Take-home sentence​

Blue lets software speak in full sentences, wrap those sentences in a verifiable contract, and require every action to land on a signed timeline - so any processor you trust can enforce the deal exactly as written.

Everything else - MyOS dashboards, SDKs, channel-binding recipes - exists to make that sentence trivial to ship.

Next stops​