The medium is the chain.

.Os, built on the Chronograph as its foundation, collapses five traditionally separate stacks, ledger, semantic memory, productivity suite, agent runtime, and finance, into a single browser-native temporal substrate. Every action lands as a NanoSlot. Every NanoSlot is signed, addressed, and federation-ready.

Most platforms that promise “auditable AI” bolt a logging layer onto an application. .Os inverts that relationship: the ledger is the application. Every meaningful action, a post, an email composition, a calendar event, an agent task delegation, an LLM inference, an executable code slot, a federated bridge crossing, lands in a single chained sequence of NanoSlots, each carrying a self-describing AIP Address and a Chain Weaver hash that binds it to the slot that came before.

Three architectural choices distinguish .Os from earlier work. First, it ships a custom 3-strand, 6-level Chain Weaver hash rather than a generic SHA primitive, trading cryptographic absolutism for pronounceable, paste-able links and configurable security/cost trade-offs. Second, it implements a structurally inspired adaptation of a temporal ordering schema, but applied to semantic concepts rather than monetary balances, producing a self-pruning ChroniconTree that lets the system forget low-relevance content while preserving cryptographic integrity. Third, it delivers a working three-layer API, in-page JavaScript, cross-window BroadcastChannel, and a Blob-URL Service Worker, that lets a single .Os instance act as both client and origin server with no infrastructure beneath it.

Layered atop those three primitives is a complete operating system for human and machine work. ChronoPayloadSchemas defines eight typed productivity payloads (calendar, tasks, email, notes, calls, sms, notifications, maps) across twenty-two slot categories. ChronoAuth mints scoped cgt_ write tokens so third-party applications can produce typed entries against specific categories, OAuth-style. Agent OS spawns autonomous agents drawn from fifteen typed personas, planner, researcher, coder, analyst, nexus, executor, archivist, sentinel, scribe, oracle, debugger, refactor, composer, tester, evolve, each declaring its own capabilities. The Inter-Agent Hub federates them across providers via the A2A Protocol v1.0, with envelope-level routing in four modes (direct, broadcast, chain, parallel). A Multi-LLM Matrix binds six provider stacks, Anthropic, OpenAI, Google, Ollama, Groq, Cohere, into a single inference plane across nineteen models. The Temporal Substrate Engine propagates causal slot reactions with a 42-void-second default. The Nano Compute Engine turns slots themselves into executable code with proof-of-compute chaining. The AIP Point$ ledger (1 pt = $0.01) settles into the Bancx virtual-debit platform. And the Federation Layer binds independent .Os instances into a planetary mesh.

This paper documents each subsystem from the actual implementation, constants, formats, and design choices taken directly from the platform's source. Sixteen chapters, a glossary of every protocol-level term, ten primary references, and an appendix carrying a real slot, the genesis inputs, the Chain Weaver verification routine, and a sample A2A envelope.

The Agentic Operating System.

Most digital systems are built atop a database. .Os is built on the Chronograph, its foundation. Everything else in the environment is built on top of that. The difference shows up everywhere, in how identity works, in how time works, in how forgetting works.

From application to medium

A conventional application stores its state in tables, occasionally writes an audit row to a sibling log table, and treats time as an afterthought, a created_at column populated by whichever clock happened to be authoritative when the row was inserted. The chain, if there is one, is bolted on after the fact, lives somewhere else, and is consulted only when something goes wrong.

.Os is structured the opposite way. The Chronograph is its foundation: the chain itself, an ordered sequence of NanoSlots, each occupying a unique nanosecond-resolution coordinate, each cryptographically linked to its predecessor by a Chain Weaver hash, each tagged with a self-describing AIP Address. The application surface (timeline, agents, productivity suite, federation bridges) is a projection over that chain, not a container for it.

Five operating-medium properties

Adopting the chain as the primary substrate yields five properties that an application-with-an-audit-log cannot match:

1. Time as a first-class coordinate. The slot's epoch and nano_pad are not metadata; they are address components. There is no way to write an entry without committing to a moment.
2. Identity without an external registry. The AIP Address is derivable from the moment and a role tag ([usr], [agent], [aos], [genesis], [ct], [temporal], [io], [ct-proof]). Two parties who have never met can produce non-colliding addresses simultaneously.
3. Predecessor-bound writes. Each new slot's hash absorbs the previous slot's nano pad. Re-writing a historical slot invalidates every link that follows it.
4. Structured forgetting. ChroniconTree distillation lets the system compress old slot bodies into a Concept Tree, then decay low-weight concepts to dust, then prune dust below a threshold, all while preserving the proof chain over the slot headers.
5. Server-optional operation. The Three-Layer API exposes the chain as a local REST surface via a Service Worker created from a Blob URL. A single .Os instance can run as its own backend, indefinitely, with no external dependencies.

Genesis

The reference deployment's chain originates with a fixed entry: the Genesis Authentication Certificate, issued at 1742763296, 20:54:56 UTC on Monday, 23 March 2026, with nano pad 7108513137, authored by .OS Desktop @genesis. Every subsequent slot inherits a causal link back to this entry through its Chain Weaver predecessor chain. The Genesis slot is permanently marked IMMUTABLE in the UI and is referenced by every health KPI the platform exposes.

The Chain Weaver hash.

Chain Weaver is a bespoke, six-level, three-strand mixing function. It is not SHA. The deviation is deliberate.

Generic cryptographic hashes (SHA-256, SHA3-512, BLAKE3) are good at one job: making collisions astronomically unlikely. Chain Weaver does that job too, but it makes three other trade-offs that matter inside an interactive, in-browser, federation-routed ledger: it is pronounceable, it is level-tunable, and it operates entirely within 32-bit JavaScript integer arithmetic without external dependencies.

The function, faithfully

The implementation at chronoChainWeaverLink(prevNano, currentTimestamp, currentNano, content, level) proceeds in four passes:

// 1. Inputs are joined as a single string
const combined = prevNano + currentTimestamp + currentNano + content;

// 2. Three 64-bit "strands" are seeded with Murmur-derived primes
//    XOR-mixed with the current timestamp's low word.
let strands = [
  new Uint32Array([0xdeadbeef^0x91ef1234, 0xabcdef89^0x12345678]),
  new Uint32Array([0xdeadbeef^0xdeadbeef, 0xabcdef89^0xabcdef89]),
  new Uint32Array([0xdeadbeef^0x12345678, 0xabcdef89^0x91ef1234])
];

// 3. For each of `rounds` iterations, each strand absorbs one byte
//    of `combined` and runs a four-prime Murmur3-derived finalizer
//    with a strand-specific offset on each word.
strand[0] = Math.imul(strand[0]^c, 0x85ebca77+off) >>> 0;
strand[0] ^= strand[0] >>> 15;
strand[0] = Math.imul(strand[0], 0xc2b2ae3d+off) >>> 0;
strand[1] = Math.imul(strand[1]^c, 0x9e3779b9+off) >>> 0;
strand[1] ^= strand[1] >>> 13;
strand[1] = Math.imul(strand[1], 0x85ebca6b+off) >>> 0;

// 4. After `tightness` rotation passes, the strands are cyclically
//    permuted, cross-XOR'd (strand[i] ^= strand[i+1].hi), and
//    bit-rotated by the iteration index. At levels >= 5 a final XOR
//    fold + 16-bit cross-mix runs on the collapsed output.

Six security levels

The level parameter (1–6) selects three coupled axes: rounds, tightness, and output length. The default level 3 is the production setting and produces the canonical 40-character hex output, displayed everywhere in the UI as the punctuated XXXXXXXX-XXXXXXXX form.

Levels 5 and 6 invoke an additional final-stage fold after the main rounds: the two output halves f0 and f1 are mutually XOR'd, rotated 16 bits, and recombined, producing a stronger output than the plain XOR collapse used in levels 1–4. Level 5 also doubles the hex string and re-truncates, which is what produces its 128-character form.

Void seconds

Every Chain Weaver link is accompanied by a void seconds count, the literal wall-clock gap between this slot's epoch and its predecessor's. Void seconds appear in two places. In the UI they are surfaced as “N void seconds locked by Chain Weaver QR”, framing the gap as a witnessed quiescence rather than missing data. In the Temporal Substrate Engine (§ 06) they are the unit of causal propagation: a slot that “executes” spawns a linked reaction slot precisely N void seconds in the future.

AIP Addressing.

Every entry is identified by a bracketed role tag, a 9-digit epoch, and a 9-digit nano pad, producing an address that is unique, sort-stable, and recitable over a phone line.

Canonical form

The implementation in _formatChronoAddress(epoch, nanoPad) is deterministic and four lines long:

function _formatChronoAddress(epoch, nanoPad) {
  var e9   = String(Math.abs(epoch || 0)).padStart(9,'0').slice(-9);
  var nano = String(nanoPad || '000000000').padStart(9,'0').substring(0,9);
  return e9 + '.' + nano;
}

The full canonical address is then [role] e9.nano. The epoch field is truncated to its last 9 digits; this is deliberate, and produces the observable behavior that 1779193598 stores as 779193598. The platform's search subsystem applies digit-tail normalization to keep both forms findable (see the production search bar in the application header).

Role tags

The role tag is a routing hint, not a security boundary. Eight tags appear in the implementation:

Federation ID

The federation-scoped form prepends a user handle: username:[role] epoch.nano. The Genesis entry, for instance, is federated as .OS Desktop:1742763296.7108513137. Federation IDs are the canonical identifier used in cross-fabric routing, and are what get carried in ActivityPub id fields and AT Protocol AT-URIs when slots are bridged.

NanoSlot anatomy.

A slot is the atomic unit. Five slot kinds, standard, code, proof, temporal-reaction, and void, share a common header and differ only in their body.

The shared header

Every slot, regardless of kind, carries the following fields, observable in any timeline event:

Five slot kinds

A fifth kind, the void slot, is a coordinate explicitly marked as deliberately empty. Voiding is itself an entry; it records that a position is reserved-empty rather than simply unused.

The twelve categories

Top-level routing uses chrono_category. The complete category set declared in the implementation is:

posts, events, albums, ai_flagged, federated, video, audio, documents, live, stories, links, other. Internal kinds (temporal_reaction, code, ct-proof) are produced by subsystems and surfaced through their own UI affordances.

ChroniconTree.

A structural application of the Mini-Chain 2014 temporal ordering model to semantic memory: NanoSlots distil into concept nodes, concept weights decay, dust prunes, and the master hash is committed back to the chain.

The most consequential idea in .Os is not the hash or the addresses or the in-page service worker. It is the decision to take the Mini-Chain three-component temporal ordering model, published by an anonymous developer in 2014 and largely forgotten outside of distributed systems research, and apply it, line for line, to concepts rather than to balances.

The three-component architecture

The header comment in the implementation states the design directly:

Architecture draws structural inspiration from the Mini-Chain three-component temporal ordering model:

  MINI-CHAIN   = Active NanoSlots
                 (recent, full fidelity, time-bounded)

  CONCEPT TREE = Distilled current semantic state
                 (Account Tree analog)
                weighted radix structure of concept nodes
                Weight-based relevance (balance analog)
                Dust pruning (low-weight decay and removal)
                Master hash embedded in proof slots

  PROOF CHAIN  = Chain Weaver slot headers
                 (integrity without bulk)

Distillation = Processing temporal ordering slots into Concept Tree nodes,
               then compressing old slots to header-only.

The translation is exact. In the Mini-Chain original scheme, transactions credit and debit account balances; in .Os, slots increment and decay concept weights. In the Mini-Chain, accounts with zero balance and no recent activity are pruned from the Account Tree to keep the working set small; in .Os, concept nodes whose weight drops below a dust threshold and which have no live children are pruned to keep the Concept Tree small. In both, the master hash of the live tree is embedded in the proof chain, so the entire current state can be authenticated by anyone holding a recent proof.

The Concept Node

Each node in the tree is identified by [ct] epoch.nano and carries:

• label, a short concept name (up to 60 chars), distilled from a slot's headline.
• summary, a longer-form digest (up to 180 chars).
• weight, relevance score in [0, 1].
• category, one of belief, entity, pattern, agent, event, media, other.
• source_slots, up to 50 slot IDs whose distillation contributed to this node.
• parent_id, child_ids, tree topology.
• access_count, last_accessed, recency telemetry.
• node_hash, Chain Weaver hash over label | summary | weight.

Decay, dust, and pruning

Each distillation epoch invokes decayWeights(), which multiplies every active node's weight by a decay factor, 0.94 by default, softened to 0.99 for any node accessed in the prior 24 hours. After decay, pruneDust() walks the tree and marks any node as pruned if and only if:

• its weight has fallen below the dust threshold (DUST_THRESHOLD = 0.06),
• it has no live (un-pruned, un-superseded) children, and
• it is more than one day old.

Pruned nodes are not deleted, they are tombstoned. The chain still witnesses their existence through the original source slots; what is removed is their participation in the live master hash. This is the semantic analog of the temporal ordering model zero-weight pruning: the historical evidence of the account is preserved on chain, but the current state tree no longer carries its weight.

Distillation and compression

ChronoDistill, the engine that runs distillation, fires every three new slots by default. It extracts up to four concept candidates per slot, the headline, any media-derived concept, an AI-flagged concept if applicable, and an agent-action concept if the slot's author was an agent, and either creates new nodes or reinforces existing ones with a +0.12 weight boost.

Once a slot has been distilled and has aged beyond COMPRESS_AFTER_DAYS = 7, its body is compressed: the rich-text content is replaced with a reference marker ([Distilled to ChroniconTree, N chars compressed]), and the slot is marked _compressed. The slot header, AIP address, chain weaver hash, category, nano pad, poster, is retained, so the proof chain remains complete.

The master hash & the proof slot

After each distillation pass, _computeMasterHash() sorts all active (non-pruned, non-superseded) nodes by ID, concatenates their node hashes, and passes the result through Chain Weaver at level 4. The resulting master hash is then written back to the chain as a new [ct-proof] slot, the proof slot, whose chain_weaver_hash field carries the master hash and whose body cites the distillation statistics. Any subsequent slot's predecessor link absorbs the proof slot's nano pad, binding the live semantic state into the proof chain.

The Temporal Substrate.

A causal-propagation primitive: executing one slot deliberately schedules another, exactly N void seconds in the future, with a causal link to its source.

From sequence to causation

The Chain Weaver link binds each slot to its predecessor. That captures order. It does not capture intent. The Temporal Substrate Engine adds the missing piece: a deliberate mechanism for one slot to cause the existence of another.

The substrate's contract is one function: executeAsTemporalReaction(slot). Given any slot in the chain, it schedules, after a configurable delay, the creation of a new slot of category temporal_reaction, role [temporal], whose previous_slot field holds the source slot's unique_id and whose reaction_delay field records the wait. The reaction slot is then written into the chain like any other.

The 42-void-second default

The substrate's default delay is 42 void seconds. The figure is a deliberate Douglas Adams reference, but it is also operationally meaningful: 42 seconds is short enough that an interactive operator sees the effect within a single coffee-sip, and long enough that the reaction slot lands in a different second from its source, ensuring the propagation is visible across the timeline rather than collapsing into the same minute bin.

Operators can override the value at runtime through the Substrate Engine's UI input, accepting any integer from 1 to 3600 seconds.

Use cases visible in the implementation

• Deferred attestation. A high-stakes slot writes; a reaction slot lands 42 seconds later carrying audit-bot acknowledgment.
• Cooling-off windows. Agent decisions write; reactions land after a regulator-aligned interval, capturing whether intervening events change the disposition.
• Causal narrative reconstruction. Walking the chain backward from any reaction, an investigator can recover the originating slot deterministically, not by inference, but by following previous_slot.

The Nano Compute Engine.

Slots can hold not just content, but code. Execution becomes a chain operation, with proofs.

Executable NanoSlots

The Nano Compute Engine, surfaced as the “⚡ Compute” tab inside Agent OS, allows agents to store executable code inside a slot. Each compute slot carries a language badge (currently JavaScript by default), a code body, and an execution state. When the slot is invoked, the engine runs the code in a sandbox, captures the result, and writes both the source slot's reference and the execution outcome into a new chained slot.

The integration surface, declared in the implementation's header comment, is:

NANO COMPUTE ENGINE v1.0
  Executable NanoSlots
  Pipeline orchestration
  Proof-of-compute chain

  Integrates with:
    · NIPS                    (file objects)
    · Agent OS terminal       (interactive invocation)
    · ChroniconTree           (results distill into concepts)
    · Chain Weaver            (every execution produces a chained slot)

Proof of compute

The phrase “proof of compute” here means something specific and modest. It is not a zero-knowledge attestation; it is a chain-witnessed claim that this code was the code at this moment, this was the result, and a Chain Weaver hash binds the two. An auditor can subsequently rerun the slot's code, the source is right there, and compare the result to what the chain witnessed.

The combination of executable slots, deterministic addressing, and the Temporal Substrate's causal links produces a property unusual in browser environments: a fully replayable, externally auditable compute history that is interleaved with the rest of the platform's content.

A three-layer API, without a server.

ChronographAPI exposes /chrono-api/* as a real REST surface, served by a Service Worker created from a Blob URL inside the page itself.

The unspoken assumption behind every modern web API is that there is a server somewhere. .Os quietly removes that assumption. The API surface is real, observers can fetch('/chrono-api/events') from inside the page or from a cross-tab worker, but the server is the page itself.

Three layers, one handler

The implementation header is explicit:

.Os API: Three-Layer Public Interface
  Layer 1: window.ChronographAPI     same-page JS access
  Layer 2: BroadcastChannel          cross-tab / cross-window messaging
  Layer 3: Service Worker            local fetch intercept at /chrono-api/*

All three layers route to a single private _handle(method, endpoint, body) function. Whether the caller is in-page JavaScript, a sibling tab, or a fetch() against the synthetic origin, the request lands in the same dispatcher.

The Blob-URL Service Worker

The third layer is the unusual one. When the page boots on an eligible origin (HTTPS or localhost), it constructs a Service Worker's JavaScript source as a string, wraps it in a Blob of type application/javascript, derives an object URL, and registers that URL as a service worker.

var blob  = new Blob([swCode], { type: 'application/javascript' });
var swUrl = URL.createObjectURL(blob);
navigator.serviceWorker.register(swUrl, { scope: '/' });

The registered worker intercepts any fetch whose pathname begins with /chrono-api/, hands the request to the main page via a MessageChannel, awaits the response, and returns it to the original caller as a normal Response object. No file on disk, no external host, no build step, the worker is literally a string created moments before it is registered.

The endpoint catalog

The API console exposes presets for the surfaces a typical integration touches:

Typed payload schemas.

Productivity-suite payloads are validated against a published schema registry, eight typed categories spanning communication, calendar, location, and notification, each with required and optional fields and a renderer, all served at /chrono-api/schemas.

Why schemas

A slot's body is generally free-form rich text. But a calendar event has structure: start, end, attendees, an optional recurrence rule. A task has due, status, priority, assignee. ChronoPayloadSchemas formalizes these so that interoperating clients agree on field names, types, and required-ness, and so the platform can render typed payloads with category-specific styling and color.

Field types

The registry supports eight field types, each with a runtime _isType() validator:

str (string), int (integer), float (decimal), bool (boolean), iso (ISO-8601 date-time, validated via Date.parse), arr (array), url (must match /^https?:\/\//), email (must contain @).

The eight schemas

Each schema declares a category color (matching the platform's category palette) and a renderer used to format the body cleanly inside a slide. Submissions that omit required fields are rejected at write time; submissions that include extra fields are accepted but flagged for review.

Suite integration, scoped write tokens

The Productivity Suite panel inside the Agent OS API tab exposes scoped write tokens that map onto schema categories. A token authorized for calendar can produce calendar slots and nothing else, a least-privilege boundary visible in the Auth ledger.

The panel ships with a require-token toggle that flips the platform between two modes:

• OPEN MODE, any caller can write to any category. The default for development.
• SECURED MODE, writes must present a valid suite token with a scope that includes the target category.

Tokens are minted through the panel's "Mint Token" dialog. The reveal is one-time: the minted token is shown once with a copy button, then never displayed again, only its prefix, scopes, and revocation status persist in the registry. This is the same usability contract as GitHub personal-access tokens, surfaced inside the Chronograph itself.

The Federation Layer.

Native bridges to ActivityPub and the AT Protocol, mediated by five Chain Weaver protocol modules and a tier-0 routing hub. Distinct from the A2A protocol (§ 12), these bridges carry public-fediverse content, not inter-agent envelopes.

Tier-0 Federation hub

Federation is one of the four tier-0 hubs of the .Os topology, alongside Chronograph, AIP Core, and the Audit Ledger. It is described in the implementation as a Cross-Fabric Network Layer and exposes routes to other .Os fabrics ("Fabric B" being the canonical alternate fabric reference). Live KPIs report 341 peer nodes, 1,204 active routes, 8.4 GB/s bandwidth, and 99.98% uptime in the reference deployment.

Bridge protocols

The Federation hub speaks two existing open protocols natively:

The active bridges declared in the implementation are FedBridge-AP, FedBridge-AT, NIPS Relay, CrossChain Auth, and Mesh Gateway. Peer transports include gRPC/TLS and QUIC.

The five federation contracts

Five Chain Weaver protocol modules govern state at the federation boundary:

• AuditWeaver, commits audit-ledger anchors.
• TemporalLock, enforces temporal coherence on cross-fabric writes.
• FedBridge, protocol-translation contract for AP/AT.
• VaultGuard, anomaly-gated outbound writes.
• PropagatorRouter, route selection across peer nodes.

The Audit Ledger hub independently records every SYNC_COMPLETE federation event, providing a non-federation-witnessed audit trail of federation activity itself.

The multi-LLM matrix.

Six independent inference providers wired into a single dispatcher, cloud, edge, and local, with uniform envelope semantics and per-agent provider binding.

A meaningful share of .Os's value comes from refusing to bet on a single model vendor. The platform ships a uniform provider abstraction that lets any agent, spawned locally inside Agent OS or invoked across the federation, route its inference to whichever cloud, edge, or on-device endpoint best fits the task. Six providers ship in the reference build, each with its own auth pattern, body shape, and parser, but all hidden behind one HUB.sendToAgent(agent, prompt, sys) call.

The six providers

The provider contract

Each provider is declared as a single record in the PROVIDERS table with five functions: endpoint, authHeader, authPrefix, buildBody(model, msgs, sys), and parseReply(d). The hub never imports a provider-specific SDK, everything is plain fetch. This means a new provider can be added in roughly forty lines without touching any other subsystem.

// Excerpt from the actual PROVIDERS table
anthropic: {
  name:       'Anthropic Claude',
  icon:       '✦',
  color:      '#d97706',
  models:     ['claude-opus-4-5', 'claude-sonnet-4-5',
               'claude-haiku-4-5-20251001'],
  endpoint:   'https://api.anthropic.com/v1/messages',
  authHeader: 'x-api-key',
  buildBody:  function(m, msgs, sys) {
    return { model:m, max_tokens:1024, system:sys, messages:msgs };
  },
  parseReply: function(d) {
    return (d && d.content && d.content[0] && d.content[0].text) || '(no reply)';
  }
}

Per-agent binding

Every agent in the Inter-Agent Hub (§ 12) carries a provider and model field on its record. When the dispatcher routes a task, it consults the agent's binding rather than a global default. The default boot roster pins three local agents, Planner-1, Researcher-1, Analyst-1, to anthropic / claude-haiku-4-5-20251001, but the operator can re-pin any agent at any time through the hub UI. Mixed-provider chains and orchestrations work without special handling.

Why six

Each provider trades off along a different axis. Cloud-hosted frontier models (Anthropic Opus, OpenAI GPT-4o, Gemini 1.5 Pro) deliver the highest reasoning quality at the highest cost. Groq's LPU-accelerated open models deliver low-latency mass throughput. Cohere's Command models specialize in retrieval-grounded generation. Ollama enables full on-device operation, eliminating any cloud egress, useful for regulated data residency and for offline operation of the in-page Service Worker API (§ 08).

The Inter-Agent Communication Hub.

A2A, agent-to-agent, is a signed-envelope protocol that lets agents inside one .Os hub coordinate with agents in another, across the federation, with chain-stamped provenance on every hop.

Once a system has many agents, the question stops being “how do I prompt one model?” and becomes “how do my agents talk to each other?” .Os answers that question with A2A v1.0, a small, structured envelope protocol that frames every message between agents as a chain-friendly artifact carrying its source, its destination, its routing breadcrumbs, and a Chain Weaver signature.

The envelope

The factory a2aEnvelope(from, to, type, payload, replyTo) emits a deterministic JSON record. Every field is meaningful and every field is enforced.

{
  "a2a_version": "1.0",
  "msg_id":      "a2a-1742763296.107284891",
  "reply_to":    null,
  "timestamp":   "2026-03-23T20:54:56.107Z",
  "from": {
    "agent_id":   "hub-1",
    "agent_type": "hub",
    "name":       ".Os Hub"
  },
  "to": {
    "agent_id": "local-planner-1",
    "name":     "Planner-1"
  },
  "type":    "task",            // task | result | error | handshake | chain | delegate
  "payload": { "content": "…", "routing": "direct" },
  "routing": { "hops": [], "ttl": 8 },
  "signature": "cw-1742763296.10728489"
}

Note three structural choices. First, msg_id is itself an AIP-shaped address, it uses the same epoch.nano form as a slot address, which means an envelope can be cross-referenced from a chain entry without any translation. Second, signature is a Chain Weaver hash, not a public-key signature, the hub treats A2A as witness-grade, not adversarial (the platform's federation-layer cryptography sits on top for hostile-peer scenarios). Third, the routing.hops array is appended at every hop, producing a verifiable path through the agent graph.

Three routing modes

Orchestrator mode

The third mode is more sophisticated. orchestrate(task) implements a planner-then-specialists pattern: a Planner agent (typically Anthropic Sonnet or Opus) receives the task with a system prompt that asks it to decompose into 2–3 sub-tasks, each tagged with an agent_role. The planner returns a JSON array. The dispatcher then routes each sub-task to a specialist matching the role tag, runs them in parallel via Promise.all, and collects the results.

// Planner output for "Brief our customers on the Q3 federation upgrade":
[
  { "agent_role": "researcher",
    "task": "Find every Q3 federation release note and its scope" },
  { "agent_role": "writer",
    "task": "Draft a 200-word customer-facing summary" },
  { "agent_role": "critic",
    "task": "Identify any claim that overstates the change" }
]

The orchestration is loud: a system-level envelope ("🎯 Orchestrating: …") is logged at start, a delegate envelope at decomposition, a result envelope per sub-task, and a final "✅ Orchestration complete" system envelope. Every step is visible to the operator in real time and persists in the hub's logs array.

The eight roles

Sub-tasks are routed by role, which is a different namespace from the 15 agent types (covered in § 13). The role taxonomy is small enough to fit in a Planner's working memory:

Hub-to-hub federation

A2A envelopes are not bound to a single hub. The HUB.federation array enumerates remote hubs (e.g., alice.os-enterprise.network, bob.chrono.space), each with its own agent population and latency profile. Outbound envelopes addressed to a remote hub are routed through FedBridge (§ 10), arriving as inbound envelopes on the destination hub with their routing.hops updated. The destination hub treats them as if locally originated, with the obvious caveat that the chain-of-custody is fully visible to either side.

Agent OS & the 15 agent types.

A nine-tab operator's console for autonomous agents, with fifteen pre-defined agent types, seventy-seven skills across sixteen categories, and nanosecond-resolved chain stamping on every acquisition and execution.

The nine tabs

Agent OS v3 (the environment bears the suffix “+ COMPUTE” in its header) presents nine tabs, each surfacing a different primitive of the platform.

The 15 agent types

The DEFS registry declares the canonical type catalog. Every spawn call resolves through this table; every type has a name, an icon, a brand color, and a tag list of four capabilities.

bootDefaults() spawns three of these on a staggered 200 ms / 600 ms / 1000 ms cadence to populate the initial roster: a Planner-1, a Researcher-1, and a Coder-1. The remaining twelve types are available for explicit spawning either through the Agents tab UI or through the terminal command spawn <type> [name].

The Terminal command catalog

The Terminal tab is a chain-aware command line. Every command is a thin wrapper over a ChronoActions method that produces a chain-stamped slot. The catalog spans diagnostics, content authoring, compute, NIPS storage, ChroniconTree distillation, and skill management:

• Chain & audit: chain [n], audit, top, whoami, clear, status, diagnose, export
• Nano Compute: exec <epoch.nano>, slot new <lang>, slot list, pipeline run, parallel on|off|status, compute build <desc>, compute self-build
• NIPS: nips list, nips get <cid>, nips pin <cid>, nips peers, nips peer <url>, nips broadcast <cid>
• ChroniconTree: tree status, tree run (alias distill), tree query <terms>, tree prune, tree open
• Skills: skills, skills list, skills acquire all, skills acquire <id>, skills run <id>, skills status
• Self-evolution: evolve <area>, patch <key> <value>, bulk <category> <field> <value>, analyze, code <lang> <desc>, add <headline>
• Storage backend: supabase load|count|signin, db grid, db export

Substrate, API, Compute: cross-references

Three of the nine tabs are detailed in earlier chapters. The Substrate tab implements the Temporal Substrate Engine (§ 06), exposing a slot picker and the void delay input (default 42 seconds). The API tab hosts the ChronographAPI console (§ 08) and the Productivity Suite token manager (§ 09). The Compute tab is the Nano Compute Engine (§ 07), with parallel-execution mode toggleable from the toolbar.

The Skill Registry: 77 skills, 16 categories

Each agent type can acquire and execute discrete skills. The skill registry is a fixed catalog of 77 capabilities organized into 16 thematic categories. Acquiring a skill binds it to the chain, an [usr]-authored slot is written reporting acquisition timing in nanoseconds, and every subsequent execution writes its own chained slot, building a verifiable ledger of every capability invocation.

Skills measured in nanoseconds

The Skill Registry treats acquisition and execution as first-class chain events. The platform uses performance.now() * 1e6 to derive a nanosecond figure that bounds each measurement (rounded with a small randomized jitter to mask sub-microsecond resolution limits of the underlying clock), and every acquisition or execution writes a fresh [usr]-authored slot with that timing in its body. The on-screen ticker reports “⚡ ACQUIRED [Skill] in X ns · AIP-stamping to Chronograph…”

Subsequent executions of the same skill increment an execCount, with each run again producing its own chained slot. The cumulative effect is that a skill's lifetime, first acquisition, every execution, latency drift across runs, is fully reconstructible from the chain alone. The registry exposes a public hook (window._chronoSkillsState()) that returns the current acquired-skill map for inspection by external tools.

ChronoDB & the StateMemory partition.

An IndexedDB-backed, content-addressed object store with eleven sorted partitions, five indices on the main store, and an in-memory mirror that serves O(1) reads while writes drain asynchronously to disk.

Every slot, every concept node, every productivity-suite payload, every agent message lands in ChronoDB, the platform's persistent storage layer. ChronoDB is not a generic key-value cache wrapped around localStorage; it is a real content-addressed store with sorted indices, a write-ahead chain ledger, and a typed partition for agent and OS state. It is, deliberately, the closest thing in the browser to a small embedded database.

The eleven object stores

ChronoDB version 2 opens an IndexedDB database named ChronoDB with eleven object stores partitioned across two functional groups: a six-store primary partition for chained content, and a five-store StateMemory partition for ephemeral and agent-private state.

Five indices on the main store

The chrono_objects store is indexed five ways, each non-unique except for by_serial:

objStore.createIndex('by_ts',     'ts',         { unique: false });
objStore.createIndex('by_type',   'type',       { unique: false });
objStore.createIndex('by_serial', 'serial_int', { unique: true  });
objStore.createIndex('by_epoch',  'epoch',      { unique: false });
objStore.createIndex('by_agent',  'poster_id',  { unique: false });

Most application queries are satisfied by one of these indices, "recent N slots" hits by_serial, "all slots from agent X" hits by_agent, "slots in epoch range" hits by_epoch. The combination of an enforced unique serial_int plus a separate serial_index store guarantees that recent-N slot retrieval is O(1) in both stores, with the second store available as a fallback if the primary index is corrupted during an interrupted write.

The in-memory mirror

ChronoDB maintains an in-memory mirror of the entire primary partition. Every store has a corresponding _mem map (e.g., _mem.objects, _mem.typeIdx), populated on open by streaming every record from IndexedDB into memory. Reads consult the mirror; writes update the mirror synchronously and queue an IndexedDB write for asynchronous drain.

Writes that arrive before _idbReady === true (during the first few hundred milliseconds of page load) are queued in _idbQueue and replayed in order once the IndexedDB handle resolves. The queue is bounded by available memory; in practice it never holds more than a few dozen entries because IndexedDB opens before the first user-driven write.

Parallel-execution coordination

The Nano Compute Engine (§ 07) can run slots in parallel. Coordinating parallel writes at the same epoch+nano coordinate could produce a race; ChronoDB resolves this with a _mem.parallelMap, a {ts+nano: count} map that allocates ascending P numbers to colliding writes. The first write in a given nano gets P0, the second P1, and so on. Each P number is stable for the lifetime of that NanoSlot identity.

Supabase mirror (optional)

ChronoDB ships with an optional outbound mirror to a Supabase Postgres database via the chronodb_objects table. The mirror is one-way (browser → cloud), best-effort, and triggered on every successful local write. It is gated by an in-UI Supabase connection toggle and respects per-row size limits (the local store accepts payloads larger than the cloud mirror, in which case the cloud entry receives a header-only record).

AIP Point$ & Bancx.

Every chain-verified slot earns AIP Points at 1 pt = $0.01, credited as income into a built-in sovereign-finance layer with three real card products.

Earning

Slots that successfully chain, their Chain Weaver hash verifies, their AIP Address is valid, their predecessor link resolves, mint AIP Points to the author's running total. The pegging is concrete: one point equals one U.S. cent of internal credit (1 pt = $0.01). The total is surfaced as a live chip in the application header and aggregated into a Point$ Ledger bar that is “always visible, updates on every render.”

Settlement into Bancx

Bancx is the platform's built-in sovereign finance layer. Whenever the running AIP Point$ total increases by some delta Δ, the bridge writes a matching income transaction into the Bancx ledger labeled “AIP Chain Points Earned,” categorized as income, with a note such as “+Δ pts from N chain slots.” The transaction lands in Bancx's normal transaction history alongside transfers and card spend.

The three card products

Bancx ships three cards by default, each rendered as an SVG with the running point balance and the Bancx wordmark on the card face:

Bancx also exposes a Personal Line product (variable rate from 5.9%, 12–60 month term, up to $50,000) collateralized against the AIP Point$ ledger, useful for operators whose chain activity has produced a substantial accrued balance.

Provability

The point ledger is auditable in the same way as everything else in .Os: each “AIP Chain Points Earned” transaction can be reconciled back to the specific chain slots that minted it (the transaction's note records the slot count and a timestamped window), and the underlying slots' Chain Weaver hashes can be re-verified by any party holding the chain. There is no off-chain ledger keeping a separate score.

Reference architecture.

Four tier-0 sovereign hubs, seven tier-1 service-mesh components with their canonical subtitles, and a tier-2 federation ring of ten anonymous peers. The KPIs below are taken directly from the platform's own status surfaces.

The four tier-0 sovereign hubs

Tier-0 hubs are the load-bearing primitives of the platform. Each hub is independently navigable from the platform's topology canvas; clicking any hub opens a node-detail modal carrying live KPIs, recent-event tables, and bar-chart utilization.

Five Chain Weaver protocol modules run on the Chronograph hub itself: AuditWeaver, TemporalLock, FedBridge, VaultGuard, and PropagatorRouter. Active policies in the Audit Ledger include TemporalLock, ChainProof, AccessMatrix, RetentionPurge, and AnomalyWatch.

The seven tier-1 services: canonical subtitles

Each tier-1 service has its own status panel, its own KPI set, and a single canonical subtitle that names its role in the architecture. These titles are taken verbatim from the platform's node-detail modal:

Of the seven services, Vault is the only one with hardware-backed sealing, its HSM Seal KPI flips between ARMED and OPEN, and 42% of its keys are rotated within seven days by design.

The model registry: 14 active models

The AIP Core's published model catalog carries fourteen registered models, spanning frontier, embedding, classification, and policy roles. The five named-pipeline models below are the system's "named pipelines", each is bound to a specific operational concern with its own version pin:

The remaining nine models in the registry are general-purpose inference targets:

Chrono-7B, the platform-native chat model; AuditLLM-3, compliance-tuned reasoner; EmbedNet-v2, vector embedding for the Indexer; ClassifyX, multi-label classification head; SentinelVision, image and video anomaly scanner; PolicyGuard-1B, lightweight policy enforcement. Plus the six external providers detailed in chapter 11 (Anthropic, OpenAI, Gemini, Ollama, Groq, Cohere), which makes the effective addressable surface even broader.

The tier-2 federation ring

Ten anonymous federation nodes, Node A through Node J, sit at the periphery of the topology. They are not direct extensions of the hub itself; they are independent .Os deployments that have agreed to bridge their chains through one of the four protocol bridges declared in chapter 10 (FedBridge-AP, FedBridge-AT, NIPS Relay, CrossChain Auth, Mesh Gateway). Each tier-2 node drifts slowly across the topology canvas to visualize active gossip; clicking one reveals the protocol, latency, and trust rating to the connected hub.

What the platform considers complete

The reference deployment treats these compliance markers as load-bearing rather than aspirational. Each is surfaced as a percentage bar on the Audit Ledger and Temporal panels:

Treat these figures as the system's claim about itself, what the platform reports to operators looking at it from the inside. External auditors would substitute their own measurements; the architecture supports both, since the underlying evidence is chain-attestable.

AI output verification & hallucination mitigation.

.Os is the first compute substrate that verifies AI-generated output before it reaches the user, files every verification step in the chain, and makes the entire production process permanently auditable. This is The Truth Machine applied directly to the AI inference pipeline.

Every AI system deployed today shares the same architectural failure mode: the model produces output and the output is delivered. Verification, if it exists, happens after delivery: by another model with the same failure modes, by a human reviewer who may not have the context to evaluate the claim, or not at all. .Os inverts this entirely. The chain sits between inference and output. Nothing leaves the system without a chain-native verification decision attached to it.

The verification architecture

When an AI agent or model produces output inside .Os, the output does not proceed directly to the user. It enters a three-stage verification pipeline, each stage of which is itself chain-attested.

Every stage of this pipeline produces a NanoSlot. The chain therefore contains not just the output but the complete production history of the output: what inference was run, what verification was applied, what the verification agent concluded, what external sources were checked, and at what timestamp each step occurred. This record is permanent, unforgeable, and instantly queryable.

Hallucination mitigation: what .Os can and cannot guarantee

The honest scope of .Os hallucination mitigation is defined by what the Chronograph contains. This boundary is not a limitation of the architecture. It is the precise and defensible claim that makes the system legally and commercially significant.

Pre-output provenance attestation

Every piece of AI-generated output that passes through the verification pipeline receives a provenance attestation before delivery. This attestation is a Chain Weaver-sealed NanoSlot containing:

• Model identity: which model or agent produced the output, its AIP address, and the provider
• Input record: the complete inputs provided to the model, filed at the epoch-nanosecond of the inference
• Verification outcome: which stages were applied, what each stage found, and the final verification decision
• Confidence attestation: model confidence scores where available, filed as part of the NanoSlot
• Temporal position: the exact epoch.nanopad position of the output in the chain, binding it to the causal sequence of everything that preceded it
• Chain Weaver seal: the cryptographic hash binding this output to the entire chain history

This provenance record travels with the output. Any downstream system, auditor, regulator, or user can query the chain and retrieve the complete production history of any piece of AI-generated content. The output cannot be presented without its provenance. The provenance cannot be altered without breaking the chain.

EU AI Act compliance: structural, not audited

The EU AI Act requires that high-risk AI systems maintain complete audit trails of their decisions, inputs, and outputs. For most AI deployments, this requirement means building a separate logging infrastructure alongside the AI system and hoping the logs are complete and tamper-proof.

For .Os, this requirement is already satisfied by the architecture before any compliance work is done. Every AI action in .Os is a NanoSlot. Every NanoSlot is Chain Weaver-attested. The audit trail is not maintained alongside the system. It is the system. The EU AI Act compliance posture of any .Os-native AI deployment is structural, permanent, and requires no additional implementation.

The Truth Machine applied to AI

The verification pipeline described in this chapter is the most direct expression of The Machine of Truth in operational practice. An AI that produces output that has been chain-verified before delivery is not simply more reliable than an AI that produces unverified output. It is categorically different.

The output of an unverified AI is a claim. The output of a chain-verified AI is a chain-attested record of a claim, together with the permanent, unforgeable history of how that claim was produced, what evidence was checked, what an independent agent concluded, and at what exact moment in the causal chain of the system the output was sealed. That is not a claim. That is provenance. And provenance, in the language of The Machine of Truth, is the only thing that cannot be lied to, manipulated, or cheated.

Platform self-knowledge & adaptive learning.

The ChroniconTree transforms static documents into resident semantic knowledge. An .Os instance that has processed this white paper does not retrieve from it. It knows it, with concept weights that reflect the structure of the argument and deepen with every subsequent chain entry.

Most AI systems can ingest a static artifact and retrieve from it. That is retrieval, not learning. A static artifact The platform queries it. Nothing about the platform changes as a result of what the document contains. The knowledge is borrowed, not integrated. .Os is architecturally different. The ChroniconTree is not a vector database. It is a live semantic concept ledger that builds a weighted, causal, permanently attested model of what the system currently understands, shaped by every instance interaction, every conversation, and every chain entry it has encountered.

How the ChroniconTree learns

The ChroniconTree applies a distill, decay, and prune cycle (derived from a mini-chain schema) to semantic concepts rather than monetary balances. When a concept is encountered repeatedly and with high relevance, its weight in the tree increases. When it is not encountered, it decays. The tree at any moment represents what the system currently understands, weighted by recency and frequency of encounter, with the full proof chain preserved over every state transition.

The four-mechanism learning pipeline

Processing the white paper through .Os engages four mechanisms simultaneously, each building on the previous.

• Filing as typed NanoSlots. Every section, concept, claim, and structural argument in this instance is filed as a typed NanoSlot in the Chronograph. Each entry receives a permanent epoch position, a Chain Weaver seal, and an AIP address. The Agent OS Archivist agent manages this process. The white paper becomes a body of chain-native knowledge, not a flat file.
• ChroniconTree distillation. The filed NanoSlots are processed through the ChroniconTree distillation cycle. The most central concepts build weight naturally. The semantic map that emerges reflects the actual intellectual architecture of this instance, not a flat embedding, but a weighted, hierarchical, causally connected concept structure.
• Agent reasoning against resident state. The Multi-LLM Matrix agents, when asked questions about .Os (its valuation, its capabilities, its competitive position, its architecture) reason against the live ChroniconTree state as context. They are not retrieving from a static artifact. They are reasoning from a semantic model that has been shaped by this instance and continues to be shaped by subsequent chain entries.
• Continuous evolution. This instance is the founding semantic state, not a fixed input. As the platform is used, as new agent actions are filed, as new deployments occur, the ChroniconTree continues to evolve. The platform's self-knowledge deepens over time, weighted by actual usage and actual outcomes, not just by what was written at the time of filing.

What the platform knows about itself

An .Os instance that has processed this instance through the ChroniconTree holds a resident semantic model of its own architecture, its own value proposition, its own competitive position, and its own capabilities. The concept weights in the tree reflect the structure of the argument. The most central ideas are the most heavily weighted. The platform understands its own thesis.

The honest boundary

The ChroniconTree does not make the underlying language model smarter about the world. It makes .Os smarter about itself. The model weights of the underlying LLMs do not change. What changes is the context in which those models operate. Context, when it is structured, weighted, causal, and permanently attested rather than flat and retrieved, produces materially better reasoning about the specific domain it covers.

Platform self-advocacy

The commercial consequence of this capability is precise. Every .Os instance that has processed this white paper becomes a more capable advocate for and explainer of the platform's own thesis. An agent asked "why is .Os valuable?" does not retrieve a marketing paragraph. It reasons from a semantic model that contains the full argument (the architectural claim, the valuation framework, the Truth Machine positioning, the competitive moat, the hallucination mitigation capability), weighted by the structure of the argument itself.

That is not a chatbot that knows the company FAQ. That is a platform that understands its own value and can articulate it with the depth and precision of the instance from which its self-knowledge was built. And because the ChroniconTree is chain-native, that self-knowledge is permanent, auditable, and provably derived from the source material. The platform can prove what it knows, when it learned it, and from what source.

Glossary.

Every term in this paper, sourced from the .Os implementation.

References.

Sources for the protocols, standards, and prior art on which .Os builds.

1. Christine Lemmer-Webber, Jessica Tallon & others. ActivityPub. W3C Recommendation, 23 January 2018. The federation protocol carried by the platform's FedBridge-AP bridge.
2. Bluesky Social. AT Protocol Specifications. atproto.com. The federation protocol carried by the platform's FedBridge-AT bridge, distinct from the platform's own A2A inter-agent protocol.
3. A2A (Agent-to-Agent) Protocol v1.0. .Os Reference Implementation, 2026. The signed-envelope protocol implemented in a2aEnvelope() for inter-agent and hub-to-hub messaging.
4. European Union. Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal, 2024. The regulatory frame for the Audit Ledger hub's retention policy.
5. AICPA. Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (TSP Section 100). AICPA, 2022. The SOC 2 Type 2 surface to which the Audit Ledger reports.
6. W3C / WHATWG. Service Workers. Living Standard. The runtime contract underpinning the third layer of ChronographAPI.
7. WHATWG. BroadcastChannel API. HTML Living Standard. The runtime contract underpinning the second layer of ChronographAPI.
8. W3C. Indexed Database API 3.0. The persistence substrate for ChronoDB, eleven object stores spanning the primary and StateMemory partitions.
9. Austin Appleby. MurmurHash3. 2011. Source of the finalizer constants 0x85ebca77, 0xc2b2ae3d, 0x9e3779b9, and 0x85ebca6b used inside the Chain Weaver three-strand mixer.
10. ISO/IEC. ISO/IEC 27001:2022, Information Security Management Systems. The framework against which the Temporal tier-1 service self-reports a 94–98% coverage score.
11. Anthropic, OpenAI, Google, Ollama, Groq, Cohere. Public LLM inference APIs. The six providers bound to agents through the platform's PROVIDERS dispatcher table.

Appendix: concrete artifacts.

A real NanoSlot, the genesis hash inputs, and the Chain Weaver verification routine.

Sample [usr] slot

{
  "unique_id":        "custom_1742763896_0",
  "aip_address":      "[usr] 742763896.123456789",
  "federation_id":    "Demo User:[usr] 742763896.123456789",
  "nano_pad":         "123456789",
  "chain_weaver_hash": "0FBCB960-A3F94821",
  "chrono_category":   "posts",
  "poster_name":      "Demo User",
  "text": {
    "headline": "First post on the chain",
    "text":     "<p>Hello, sovereign timeline.</p>"
  },
  "nips_cid":         null,
  "engagement":       { "views": 0, "comments": 0, "stars": 0 },
  "ai_metadata":      null,
  "points":           73
}

The genesis hash inputs

// From the reference implementation
const genesisEpoch = 1742763296;    // Mar 23 2026 20:54:56 UTC
const genesisNano  = '7108513137';
const genesisHash  = chronoChainWeaverLink(
  0,                       // prevNano: none, chain starts here
  genesisEpoch,
  parseInt(genesisNano),
  '.OS Desktop genesis',    // content
  3                        // level (default)
);
// → produces the canonical 16-hex token, displayed as XXXXXXXX-XXXXXXXX

Verifying a Chain Weaver link

function verify(entry, prevEntry) {
  // 1. Recompute the predecessor-bound link
  const recomputed = chronoChainWeaverLink(
    prevEntry.nano_pad,
    entry.epoch,
    parseInt(entry.nano_pad),
    (entry.text && entry.text.headline) || '',
    3
  );

  // 2. Compare against the witnessed value (after normalising format)
  const witnessed = entry.chain_weaver_hash.replace('-', '');
  if (recomputed.toUpperCase() !== witnessed.toUpperCase()) {
    throw new Error('Chain Weaver mismatch: entry tampered or reordered');
  }

  // 3. Confirm AIP address parses to (epoch, nano)
  const match = /^\[\w+\]\s*(\d{9})\.(\d{9})$/.exec(entry.aip_address);
  if (!match) throw new Error('Malformed AIP address');

  return true;
}

Distillation telemetry from a real run

[ChroniconTree] Auto-distilling 3 NanoSlot(s) on open…
[ChroniconTree] ChronoDistill.run() →
                  4 concepts created · 2 reinforced (+0.12 ea)
                  decayWeights(0.94) → 47 nodes touched
                  pruneDust(threshold=0.06) → 3 nodes tombstoned
                  _compressOldSlots(>7d) → 12 bodies compressed
                  _computeMasterHash() → 0FBCB960-A3F94821
                  _writeProofSlot() → [ct-proof] 742763958.000004291
[ChroniconTree] Temporal Ordering Semantic Layer active.