Architecture

Each capability tierCapability TierHierarchical permission level for tasksA five-level permission hierarchy: FiberCap (compute-only), TaskCap (can spawn children), IoCap (network/filesystem access), RemoteCap (cross-machine communication), and SupervisorCap (can manage and restart other tasks). Each tier extends the one below it, enforcing the principle of least authority. extends the one below it. A task with FiberCapFiberCapMinimal capability: compute-only, no I/OThe lowest capability tier. A task with only FiberCap can perform pure computation — no spawning, no I/O, no timers. It's the most restricted permission level, ideal for untrusted or sandboxed computations. can only compute — it cannot spawn, perform I/O, or set timers. IoCapIoCapCapability for network and filesystem accessA mid-tier capability that extends TaskCap with permission to perform I/O operations: reading and writing files, opening network connections, and setting timers. Required for any task that needs to interact with the outside world. adds network and filesystem access. At the top, SupervisorCap can manage and restart other tasks.

This hierarchy ensures that if a task is compromised or buggy, its blast radius is limited to its granted capabilities. A compute-only fiber cannot exfiltrate data over the network. An I/O task cannot restart other tasks.

Cancel FuelCancel FuelMonotonically decreasing termination counterA counter that strictly decreases with each step of cancel propagation, serving as a termination proof. Like a rocket with a finite fuel tank — the cancel signal can only travel so far before the fuel runs out, mathematically guaranteeing that cancellation always finishes. is the key invariant. It's a counter that strictly decreases with each step of cancel propagation — like a rocket with a finite fuel tank. The formal proof is a supermartingaleSupermartingaleStochastic process proving terminationA mathematical sequence of values that, on average, decreases over time. Asupersync uses supermartingales as termination proofs: by showing that a certain measure of 'remaining work' is a supermartingale, it mathematically proves that tasks always make progress and eventually complete.: a mathematical sequence that, on average, can only go down. This guarantees that cancellation always terminates, even in adversarial workloads.

The five states — Running, CancelRequested, Cancelling (Drain), Finalizing, and Completed — form a strict total order. A task can only move forward through these states, never backward. Combined with the budget algebraBudget AlgebraProduct semiring for composing cancel budgetsCancel budgets compose algebraically as a product semiring. When regions nest, their budgets merge element-wise: min(deadlines), min(quotas), max(priority). This means the tightest deadline and smallest quota always win, while the highest priority propagates upward — guaranteeing consistent cancel timing across arbitrarily deep region hierarchies. that composes nested region budgets, this gives Asupersync its cancel-correctness guarantee.

Inspired by Google's Macaroons paper, Asupersync's capabilities use a decentralized attenuation modelMacaroonDecentralized capability token with attenuating caveatsA bearer credential (inspired by Google's Macaroons paper) where anyone holding the token can add restrictions (caveats) but can never remove them. In Asupersync, capabilities are Macaroon-based: you can delegate a capability to a child task while attenuating it (e.g., adding a deadline, restricting to a specific Region, or limiting to N uses). The 8 caveat predicates include TimeBefore, TimeAfter, RegionScope, TaskScope, MaxUses, ResourceScope, RateLimit, and Custom.. When you delegate a capability to a child task, you can restrict it by adding caveats — but you can never widen an existing capability. This makes delegation inherently safe: you don't need a central authority to verify that a delegated token is valid.

The 8 caveat predicates cover time bounds (TimeBefore, TimeAfter), spatial scoping (RegionScope, TaskScope), usage limits (MaxUses, RateLimit), resource patterns (ResourceScope), and a Custom escape hatch for application-specific restrictions.

Traditional statistical tests require a fixed sample size: you commit to N observations upfront, then compute a p-value. Peeking at intermediate results invalidates the guarantee. E-processesE-ProcessAnytime-valid statistical monitor using betting martingalesA betting martingale that lets you continuously monitor a hypothesis and reject it the instant the evidence is strong enough — without any penalty for peeking. Unlike traditional p-values (which require a fixed sample size), an E-process stays valid no matter when you check it. Asupersync's Lab runtime uses E-processes to monitor three oracle invariants (task leak, obligation leak, quiescence) with guaranteed Type-I error control via Ville's inequality. solve this using a betting martingale: E_t = E_(t-1) × (1 + λ × (X_t - p₀)).

Via Ville's inequality, if the E-value ever exceeds 1/α, you know with mathematical certainty that the null hypothesis is false — regardless of when you checked. The Lab runtime monitors three critical invariants (task leak, obligation leak, quiescence) this way, with bet size λ=0.5 and null rate p₀=0.001.

Multi-step operations (create account → send email → charge card) are modeled as SagasSagaDistributed operation with automatic compensation on failureA pattern for long-running operations that span multiple steps. Each step has a forward action and a compensating action. If any step fails (or cancellation arrives), the Saga automatically runs compensating actions for all completed steps in LIFO order. Asupersync's Saga engine classifies its 16 operation kinds into monotone and non-monotone using CALM analysis, minimizing the coordination overhead.. Each step has a forward action and a compensating action. If any step fails or cancellation arrives, completed steps are unwound in LIFO order — the last completed step compensates first.

What makes this unique is CALM analysisCALM AnalysisIdentifies which operations need coordinationConsistency As Logical Monotonicity — a principle that determines which operations can run coordination-free (monotone operations like Reserve and Send) and which require barriers (non-monotone operations like Commit and Release). Asupersync's Saga engine uses CALM to automatically batch consecutive monotone steps, inserting coordination barriers only where the math demands it.. The Saga engine classifies each of its 16 operation kinds as monotoneMonotone OperationOrder-independent operation that needs no coordinationAn operation whose result doesn't depend on the order it's executed relative to other monotone operations. Reserve, Send, Acquire, Renew, and CrdtMerge are all monotone in Asupersync's Saga engine. Because they're order-independent, they can be batched and executed without coordination barriers — a key performance optimization identified by CALM analysis. (order-independent, like Reserve and Send) or non-monotone (barrier-required, like Commit and Release). Consecutive monotone operationsMonotone OperationOrder-independent operation that needs no coordinationAn operation whose result doesn't depend on the order it's executed relative to other monotone operations. Reserve, Send, Acquire, Renew, and CrdtMerge are all monotone in Asupersync's Saga engine. Because they're order-independent, they can be batched and executed without coordination barriers — a key performance optimization identified by CALM analysis. are batched without any coordination barriersCoordination BarrierSync point required before non-monotone operationsA synchronization point that the Saga engine inserts before non-monotone operations (like Commit or Release). Monotone operations (like Reserve and Send) can execute without barriers because they're order-independent. CALM analysis determines exactly where barriers are needed, minimizing unnecessary synchronization. — synchronization is inserted only where the math demands it.