Baobab Lacuna · Use-Case 1

1. Executive summary

Lacuna ships a stack for publishing-class retrieval: pulling hundreds of structured sources every hour, normalising and enriching the output, and serving a fast, image-rich, audit-traceable surface to a global audience. The execution layer is a Rust worker — baobab-worker-rs — that compiles to two targets (Cloudflare Workers / WASM and a Fly native binary) and runs Scheme plans emitted by the Lacuna brain. Tools are capability-gated. Every side effect is audited. Plans are textual contracts, versionable and replayable.

This document is the SRE-grade view of one use case — the news refresh path that powers Baobab — and treats it as a worked example of the larger Lacuna playbook. The same shape applies to every other content-heavy operator we'd onboard: civic dashboards, vertical newsrooms, market-data sites, internal knowledge portals.

Three claims this document defends:

1. The worker is the right shape for retrieval at the edge: cheap, fast, safe, and auditable in ways a generic Node-on-Fly box is not.
2. Firecrawl is a capability, not a competitor. The worker calls Firecrawl when it needs a real browser; the worker itself is the orchestration layer that decides when.
3. Loam — the world-building cache between crawlers and the LLM — is what keeps the per-operator cost model viable as the surface scales.

2. The customer

2.1 Baobab as the reference deployment

Baobab (baobab.lacunalabs.ai) is a pan-diaspora portal: news, markets, library, rooms, and a small wallet. It pulls ~150 RSS feeds across five continents, surfaces them in a gazette-style layout, and runs a client-side tagging pass against ~150 diaspora-domain vocabulary terms. It is the canonical first deployment for the Lacuna stack — a real product with a real audience, not a demo.

Production shape, today:

Baobab works. It also makes a strong case for the Rust worker, because the seams where it strains today — image-proxy fan-out, RSS fan-out, tagging budget on the device — are exactly what an edge-resident Scheme worker relieves.

2.2 Customer shape beyond Baobab

Beyond Baobab itself, the realistic Lacuna customer is any team that:

• Aggregates from many public sources on a periodic clock.
• Cares about provenance — they need to show, at every render, where a fact came from and when it last refreshed.
• Cannot afford a six-figure scraping team but cannot tolerate the "vibes" outputs of a generic LLM scraper either.
• Wants edge latency for a globally-distributed reader-base without re-architecting the application tier.

The shortlist: civic-tech newsrooms, vertical trade publications, market-data dashboards, internal corporate knowledge portals, NGO field reports, sports stat sites, cultural archives. The same five-substrate stack serves all of them; the operator brings the source list and the brand.

2.3 What the existing market gets wrong

Three failure modes we see in the wild:

1. Generic LLM "scrapers" that hallucinate provenance. The output looks structured. The citations don't survive a click. Operators discover this when their auditors do.
2. Hand-rolled fan-out on a single Node box. Works for ten feeds. Cracks at fifty. The image proxy starts returning 415s under load, the worker hangs on a slow CDN, the page renders without pictures. Familiar?
3. Heavyweight ETL frameworks. Airflow, Dagster — great for batch warehouses, wrong shape for a sub-second-latency reader-facing surface. The ops cost dominates.

Lacuna's answer to all three is a small, fast, auditable execution layer at the edge, fed by a brain that emits a textual plan the worker runs.

3. The five substrates, briefly

Use-case 1 sits inside a five-substrate architecture. The other four are context, not the subject of this document; you'll see them referenced.

The worker is the execution layer that feeds — and is fed by — these substrates. It is not itself a substrate; it is the cheap, fast actor that makes the substrates load-bearing.

4. baobab-worker-rs: the execution layer

4.1 Why a Rust worker at all

The retrieval shape we want for Baobab — and any Lacuna customer — has four properties:

1. Concurrent. A hundred-feed refresh should run in under ten seconds, not a hundred sequential seconds.
2. Cheap. Sub-cent per refresh cycle. Edge compute, not a long-running VM.
3. Sandboxed. The worker should be unable to take an action the operator didn't grant. No clever LLM completion can talk it into one.
4. Replayable. Given the plan, the time, and the audit log, we should be able to reconstruct what happened — for debugging, for compliance, for the operator's own memory.

A Rust crate compiled to WASM at the Cloudflare edge, embedding a Scheme interpreter, hits all four. Node-on-Fly hits maybe two of them; Lambda hits three but loses the audit story. We picked the shape that buys the most properties for the least surface area.

4.2 Two targets, one source

baobab-worker-rs is a single Rust crate with two compilation targets:

The library exposes run_plan(src: &str) -> Result<PlanResult, WorkerError>. The mailbox surface and the tool registry live behind mailbox and tools modules. Both targets produce the same PlanResult shape — the operator's downstream code does not know (and should not know) which backend ran the plan.

Crate layout

Cargo profile choices

[profile.release]
opt-level    = "z"    # optimize for size — WASM target dominates
lto          = true
codegen-units = 1
strip        = true

WASM size is the binding constraint: Cloudflare Workers has a hard cap, and every kilobyte spent on bloat is a kilobyte we cannot spend on the Steel VM and the tool registry. opt-level = "z" with full LTO and one codegen unit gives the smallest binary; we accept slightly slower native performance in exchange.

4.3 Mailboxes: Durable Objects vs tokio

The mailbox is the actor abstraction. Each named mailbox processes messages serially, in arrival order, and emits one response per message. The two backends:

• Cloudflare Workers: each mailbox is a Durable Object keyed by name. DOs guarantee single-writer semantics globally — there is exactly one instance of baobab-news-fetcher on the planet at any moment, and Cloudflare routes messages to it. State survives restarts.
• Native (Fly / local): each mailbox is a tokio task with an mpsc inbox. Same serial-processing semantics, no edge-distributed state. For a single-region operator this is fine; for a global operator the Cloudflare target is the right one.

The wire shape is identical in both cases:

{
  "id":       "<uuid>",
  "from":     "lacuna://baobab-news",
  "to":       "actor://baobab-news-fetcher",
  "plan":     "(begin (for-each refresh-source sources))",
  "caps":     ["net", "cache", "firecrawl", "audit"],
  "deadline": 1747920000000
}

The Lacuna brain owns "plan" and "caps". The mailbox owns ordering and resource limits. The worker owns execution and the audit log.

4.4 PlanResult + audit log

Every plan run returns the same shape:

pub struct PlanResult {
    pub ok:          bool,
    pub value:       serde_json::Value,
    pub audit:       Vec<AuditEntry>,
    pub duration_ms: u64,
}

pub struct AuditEntry {
    pub ts:     u64,
    pub op:     String,
    pub detail: serde_json::Value,
}

value is whatever the plan's last expression evaluated to. audit is the list of (audit ...) calls the plan made during execution. Lacuna writes both to JSONL alongside the plan source. Given those three artefacts — plan text, audit log, value — you can reconstruct the run.

5. Plans as contract: why Scheme

Three reasons. Each one is non-obvious until you've felt the absence.

1. Auditable by reading. The plan is a few dozen lines of parenthesised text. A new engineer (or, more importantly, a customer's compliance reviewer) can read it. They cannot read a JIT-compiled Node program with the same confidence. Auditability that depends on "trust the framework" is auditability that fails the first audit.
2. Portable by construction. The same plan runs on every backend. We can move a customer from Cloudflare to Fly to a local laptop without changing the plan. The plan is the contract; the backend is an implementation detail. (This is the same property Terraform plans have, and for the same reason.)
3. Dumb workers, smart brain. Reasoning lives in Lacuna (Python, where model integrations are mature). Execution lives in the worker (Rust, where the safety story is mature). The worker cannot reason on its own and cannot be talked into autonomous behaviour by clever Scheme — it can only run the tools it has been given capabilities for.

We embed Steel (steel-core 0.7) as the VM. It's a mature R7RS-ish interpreter, WASM-compatible, with a Rust embedding model that matches our tool-registry plan. Alternatives considered: Janet (smaller but less mature WASM story), Lua (different syntax tradition, harder to express homoiconic plans), WASM-itself (right answer for the long run, wrong answer for the year-one DX). Steel is the right answer for v1.

6. Tool registry & capability model

The tool registry is the only side-effect surface Scheme can reach. Every primitive is a Rust function bound to a Scheme symbol; every primitive declares the capability it requires; every plan declares the capabilities it claims. The worker rejects plans at parse time that ask for capabilities they have not been granted.

6.1 Capabilities

6.2 Tools (selected)

The full registry is in src/tools.rs. The discipline is: pure helpers (parsing, encoding, hashing) require no capability; anything that talks to the outside world or persists state requires one.

6.3 Why the boundary is in Rust, not Scheme

If the capability check lived in Scheme — say, as a wrapping macro — a sufficiently clever plan could rebind the wrapper and break out. By checking in Rust before the tool runs, the Scheme program physically cannot reach the network without the cap; the function it would call is gated by a Rust caps.require(":net")?; at the top of the body. There is no Scheme expression that can bypass that check.

This is the same insight that makes capability-based OS designs (KeyKOS, seL4) defensible: the permission boundary lives one layer below the language the user can program.

7. The plan, line by line

The canonical plan for the news refresh, as checked in at workers/baobab-worker-rs/plans/news-refresh.scm:

;; news-refresh.scm
;;
;; The Scheme plan Lacuna sends to a baobab-worker-rs instance to
;; refresh the news cache. Stable, inspectable, replayable, audit-
;; loggable — the textual contract between brain and worker.
;;
;; Required capabilities:
;;   :net :cache :audit :threads :channels

(define sources
  '(("AllAfrica"           "https://allafrica.com/tools/headlines/rdf/latest/headlines.rdf" africa     news)
    ("Daily Maverick"      "https://www.dailymaverick.co.za/section/business-maverick/feed/" africa     news)
    ("Premium Times"       "https://www.premiumtimesng.com/feed"                              africa     news)
    ("Jeune Afrique"       "https://www.jeuneafrique.com/feed/"                                africa     news)
    ("BBC Africa"          "https://feeds.bbci.co.uk/news/world/africa/rss.xml"               africa     news)
    ("BBC Caribbean"       "https://feeds.bbci.co.uk/news/world/latin_america/rss.xml"        caribbean  news)
    ("Africa Is a Country" "https://africasacountry.com/feed"                                 africa     longform)
    ("Jacobin"             "https://jacobin.com/feed"                                         diaspora   longform)
    ("Aeon"                "https://aeon.co/feed.rss"                                         diaspora   longform)
    ("Monthly Review"      "https://monthlyreview.org/feed/"                                  diaspora   longform)
    ("Africa at LSE"       "https://blogs.lse.ac.uk/africaatlse/feed/"                        africa     longform)
    ("ROAPE"               "https://roape.net/feed/"                                          africa     longform)
    ("The Root"            "https://www.theroot.com/rss"                                      diaspora   diaspora)
    ("Black Agenda Report" "https://www.blackagendareport.com/rss.xml"                        diaspora   diaspora)
    ("Haitian Times"       "https://haitiantimes.com/feed/"                                   caribbean  diaspora)))

;; ---- Stage 1: fetch + parse, in parallel across all sources ----

(define (refresh-one src)
  (let* ((name  (car   src))
         (url   (cadr  src))
         (cont  (caddr src))
         (lane  (cadddr src))
         (t0    (now))
         (xml   (fetch-rss url))
         (items (parse-rss xml))
         (took  (- (now) t0)))
    (audit 'fetch-rss
           (list (cons 'src   name)
                 (cons 'count (length items))
                 (cons 'took-ms took)))
    (map (lambda (it)
           (append it (list (cons 'source name)
                            (cons 'continent cont)
                            (cons 'lane lane))))
         items)))

(define all-items
  (apply append (parallel-map refresh-one sources)))

;; ---- Stage 2: og:image fallback ----

(define needing-image
  (filter (lambda (it) (not (alist-ref 'image it))) all-items))

(define (enrich-image it)
  (let* ((og (fetch-og-image (alist-ref 'url it))))
    (if og
        (cons (cons 'image og) it)
        it)))

(define enriched
  (parallel-map enrich-image (take needing-image 80)))

;; ---- Stage 3: classify + cache ----

(define classified
  (map classify-entities all-items))

(define cached-count
  (cache-news classified))

;; ---- Final return: summary to Lacuna ----

(list (cons 'sources  (length sources))
      (cons 'items    (length all-items))
      (cons 'enriched (length enriched))
      (cons 'cached   cached-count)
      (cons 'at       (now)))

7.1 What the plan says, in English

1. Stage 1. For each of 15 sources, fetch the RSS feed and parse it; tag every item with its source, continent, and lane. All 15 fetches run in parallel up to the worker's concurrency cap (default 8; bump via :concurrency=N). Each fetch audits a small record: source, count, milliseconds.
2. Stage 2. Of the resulting items, filter to those missing an image; cap at 80 (the worker's per-cycle time budget); fetch the og:image for each and patch it in. Also parallel.
3. Stage 3. Run a classifier pass over every item, then write the enriched list into KV (or, for the Cloudflare target, Workers KV).
4. Return. A small alist with the counts and the timestamp. Lacuna logs this alongside the plan source and the audit entries.

7.2 Why this is the right factoring

The plan is forty lines. It describes a behaviour any operator can read. There is no hidden control flow, no buried setTimeout chain, no leaking event listener. If the cycle takes too long, you read the audit log: every fetch-rss entry has its source and its millisecond count. You find the slow source. You either drop it from the list, raise the per-source timeout, or push it onto its own less-frequent schedule. The change is one edit to the plan, not a code deploy.

7.3 What it does not say

The plan does not describe retry policy, deadline-budget enforcement, or output schema. Those are properties of the worker, not the plan. A plan written by a customer cannot accidentally redefine the deadline budget — the budget is set by the message envelope, not the plan body. The plan is the what; the worker enforces the how-much.

8. Cloudflare deployment

8.1 Bindings

Cloudflare-side, the worker needs four binding categories:

8.2 wrangler.toml

name = "baobab-worker"
main = "build/worker/shim.mjs"
compatibility_date = "2026-05-01"

[build]
command = "worker-build --release"

[[durable_objects.bindings]]
name = "BAOBAB_DO"
class_name = "Mailbox"

[[migrations]]
tag = "v1"
new_classes = ["Mailbox"]

[[kv_namespaces]]
binding = "BAOBAB_KV"
id      = "<kv-namespace-id>"

[[r2_buckets]]
binding     = "BAOBAB_R2"
bucket_name = "baobab-images"

[triggers]
crons = ["0 * * * *"]  # hourly news refresh

8.3 Cron-triggered refresh

A Cloudflare Cron Trigger fires every hour. The handler enqueues the news-refresh plan into the baobab-news-fetcher mailbox:

// Pseudocode, post-cargo-build
export default {
  async scheduled(event, env) {
    const plan = await env.BAOBAB_R2.get("plans/news-refresh.scm").then(o => o.text());
    const mailbox = env.BAOBAB_DO.get(env.BAOBAB_DO.idFromName("baobab-news-fetcher"));
    await mailbox.fetch("https://internal/run", {
      method: "POST",
      body: JSON.stringify({
        id:       crypto.randomUUID(),
        from:     "cron://hourly",
        to:       "actor://baobab-news-fetcher",
        plan,
        caps:     ["net","cache","audit","threads","channels"],
        deadline: Date.now() + 60_000,
      }),
    });
  },
}

8.4 What we get from Cloudflare specifically

• Edge presence in 300+ POPs. A reader in Lagos and a reader in Toronto see the same sub-50ms response.
• Durable Objects. Single-writer mailbox semantics, free. We do not run a Redis or a per-actor task table.
• KV + R2. Cache tier and image tier without an extra bill from a third vendor.
• Cron Triggers. The scheduler is part of the platform.
• Cost. Cloudflare's request-priced model fits the retrieval shape: one plan run per hour per operator dominates the bill, and a plan run is dozens-not-thousands of subrequests.

9. Fly.io native deployment

The same crate, compiled native, runs as baobab-worker on Fly:

cargo build --release --bin baobab-worker
./baobab-worker mailbox-serve --addr 0.0.0.0:8080

The mailbox-serve mode accepts the same JSON message envelope over HTTP POST, processes it on a tokio task with an mpsc inbox, and returns a MessageResponse. Same plan, same contract.

9.1 When Fly is the right target

• Single-region operator (one paper, one country).
• Plans that need filesystem (:fs) access — the WASM target doesn't have it.
• Local development and the CI test loop.
• Plans that exceed the WASM CPU budget (Cloudflare's per-request CPU limit is generous but finite).

9.2 When Cloudflare is the right target

• Global reader base.
• Operators who don't want to think about regions.
• Plans dominated by network fan-out (the edge advantage is real).
• Cron-scheduled workloads at small per-run footprint.

We expect most production deployments to be Cloudflare-default with Fly as the dev-and-staging path and as the escape hatch for operators whose plans don't fit the WASM budget.

10. baobab-worker-rs vs Firecrawl

This is the question that needs the clearest answer, because it's the one the customer will ask before any other.

10.1 They are different things

10.2 The composition

In a real deployment, the worker calls Firecrawl when it needs a real browser:

(define (refresh-one src)
  (let* ((url     (cadr src))
         (kind    (caddr src))         ; 'rss | 'browser
         (body    (cond ((eq? kind 'rss)     (fetch-rss   url))
                        ((eq? kind 'browser) (crawl-url   url))
                        (else                (fetch-url   url)))))
    ...))

(crawl-url url) is the tool that goes to Firecrawl behind the scenes; it requires :browser :net. The Scheme plan stays clean; the operator decides at the source-list level whether a given source is RSS-fetchable or browser-rendered. The worker absorbs the difference.

10.3 Why this is good news commercially

Firecrawl is a partner, not a competitor. We pay Firecrawl for browser rendering when we need it (a small fraction of the source list, the JS-heavy ones), and we don't pay anyone for the 90% of sources that are plain RSS or static HTML. The operator's per-cycle bill is dominated by the small browser fraction; the long tail of plain RSS is essentially free.

And: an operator who only has the budget for plain RSS still gets the audit log, the capability boundary, the parallelism, and the edge latency. Firecrawl as an add-on, not a prerequisite.

11. Where Loam fits

Loam is the world-building cache between the crawlers and the LLM. It sits on the read path:

11.1 Why Loam is load-bearing

Without Loam, the LLM is asked to re-discover the world on every call. "Who is the Premier of South Africa?" gets re-derived every cycle from the raw headlines. With Loam, the entity exists as a node; subsequent references resolve to it; the LLM is asked to summarise or classify, not to remember.

The effects on the cost model are large:

• Token spend per refresh drops. The LLM sees a pre-resolved entity graph, not a million tokens of overlapping headlines.
• Provenance gets real. A claim in the rendered page points at a Loam node; the node points at the audit log entries that produced it. Click-through provenance.
• Cross-source consensus emerges. When five sources independently mention the same entity, Loam's confidence score rises. The operator can render a "well-sourced" badge.

11.2 The Loam-worker boundary

The worker writes into Loam via a tool primitive ((loam-ingest ...), gated by :loam) and reads out via (loam-query ...). Both go over a Memgraph Bolt connection or, for the WASM target, a small JSON RPC the worker performs over HTTPS. The plan does not know it is talking to Memgraph; it sees Scheme primitives.

11.3 What Loam is not

Loam is not the operator's personal memory (Cortex) and not the shared canonical reference graph (Atlas). It is the intermediate layer where the world is built up en route between crawl and model. Operators who never look at Loam directly still benefit from it; their LLM bills shrink and their provenance gets crisp. Operators who want to look — there's an inspection surface for that.

12. Lacuna's value-add surface

What does the operator pay Lacuna for, beyond Cloudflare + Firecrawl + Memgraph at retail? Eight things; each is a real engineering surface and not a marketing slogan.

The operator brings the source list, the brand, and the editorial decisions. We bring the rest. The deal is: you operate a publishing-class retrieval system without staffing a retrieval team.

12.1 Extensions the operator can plug in

• Custom Scheme tools. Operators can ship their own tool registry crate (a Rust dynamic library on the native target; a WASM module on the Cloudflare target). New primitives, gated by new capabilities, available to their plans.
• Custom plans. The plan registry is theirs to edit. We provide canonical plans; they fork.
• Custom Loam schemas. The operator declares the entity types they want tracked; Loam ingests against that schema.
• Custom LLM backends. The (summarise text) tool resolves to whichever model the operator has bound. DeepSeek, Claude, a local Sakura instance — same Scheme call.
• Custom audit-log sinks. The audit log can fan out to S3, BigQuery, Datadog, or any HTTP endpoint the operator runs.

13. Tiering & commercial model

The tier shape we're proposing for v1, subject to design-partner feedback:

Cost shape: the Hobby tier is roughly Cloudflare's free / starter tier plus a small Lacuna fee for the brain. The Newsroom tier is dominated by Firecrawl calls and LLM ops; the worker itself is a small fraction. The Enterprise tier is what we negotiate.

14. Security model

14.1 Threat model

The realistic attackers, in priority order:

1. A malicious plan author. Someone the operator trusted enough to give plan-edit rights, who is now trying to exfiltrate secrets or pivot to other operator systems.
2. A compromised upstream source. A scraped page or RSS feed whose author is now trying to ship a payload through the worker into Loam or the LLM.
3. A compromised LLM response. A prompt-injection attempt that tries to coax the brain into emitting a plan with escalated capabilities.
4. A network observer. Standard TLS-only edge story.

14.2 Defences, mapped

14.3 Key separation

The worker holds three classes of key material, with three different lifecycles:

• Operator API keys (Firecrawl, LLM): per-operator, stored as named secrets, accessed only via the :secrets capability. Rotation: operator-driven.
• Worker signing keys (ed25519): per-worker instance, used to sign the audit log and message responses. Rotation: every 90 days by Lacuna ops.
• Mailbox-to-mailbox auth tokens: short-lived JWTs signed by Lacuna's control plane, scoping which mailbox can talk to which. Rotation: every 24 hours.

14.4 The plan-replay property

Replay protection on the message envelope: every Message carries an id (a UUID) and a deadline (a unix ms timestamp). The mailbox rejects messages whose id it has seen within the last 2 × max-deadline, and rejects any message whose deadline is already past. Combined: replay-resistant without a heavy nonce database.

14.5 What the audit log does not contain

By default, the audit log captures: tool name, source URL (host only), result size, duration, and a hash of the response body. It does not capture: full request bodies, full response bodies, secret values, user-identifying information from upstream content. If an operator wants the verbose audit (for incident forensics), they enable :audit-verbose and accept the storage cost.

15. SRE: SLOs, SLIs, error budgets

15.1 Service level indicators

15.2 Service level objectives

15.3 Error budgets

At 99.5% availability, the monthly error budget is ~3.6 hours. We split that 50/50: 1.8h for planned-change burn (deploys, schema migrations), 1.8h for unplanned burn (incidents, upstream outages). If the planned-burn half is exhausted, the deploy gate trips and we freeze plan-registry changes until the window rolls.

Source-fetch success at 90% is deliberately loose because the upstream RSS world is unreliable; we treat falling under 90% as a signal to either drop the source from the plan, raise its individual timeout, or move it to a less-frequent schedule.

16. Observability & the audit-log discipline

16.1 Three tiers of signal

16.2 The audit log is the trace

Unlike a generic OpenTelemetry trace, the audit log is the contract. Every gated tool emits one entry; the entries are ordered; the plan source plus the entries reconstruct the run. A distributed tracing system gives you the same information for the network calls; the audit log gives you the same information for the semantic operations (an entity was classified, an image was enriched, a cache was written).

16.3 Sample audit-log entry

{
  "ts":     1747920003012,
  "op":     "fetch-rss",
  "detail": {
    "src":     "AllAfrica",
    "url":     "https://allafrica.com/tools/headlines/rdf/latest/headlines.rdf",
    "host":    "allafrica.com",
    "status":  200,
    "count":   42,
    "took-ms": 311,
    "hash":    "sha256:9b18..."
  }
}

16.4 Dashboards we'll ship

• Plan-run health. Heatmap of plan-name × hour; cell colour by ok fraction.
• Source health. Per-source rolling fetch success and median duration; sortable.
• Capability use. Counter of distinct caps requested per plan, with diff-since-yesterday. New caps in a plan is an audit trigger.
• Cost burn. Cloudflare requests, Firecrawl calls, LLM tokens, R2 bytes — per-operator, daily.

17. Capacity planning

17.1 Per-cycle worst-case

For an operator with 500 sources and 80 image enrichments per cycle:

At those numbers the Cloudflare bill is dominated by Workers KV writes and outbound bandwidth, not Workers CPU. The LLM bill is dominated by the summarise step, which Loam is designed to suppress over time (repeat entities skip the LLM).

17.2 Headroom & throttles

• Per-source concurrency cap: default 8, raisable to 32 with :concurrency=32.
• Per-plan deadline: default 60s; the operator can lower but not raise without a Lacuna grant.
• Per-mailbox in-flight cap: 1 (mailboxes are serial by design).
• Per-operator daily LLM token cap: configured in the operator console; defaults to tier-limit.

18. Incident response & runbooks

18.1 Standing runbooks

18.2 The "two instances" incident pattern

A specific failure mode worth calling out: the operator running two browser tabs against the same Baobab deployment. Each tab has its own Web Worker, its own IntersectionObserver, its own AbortController; they share localStorage. Concurrent writes from two tabs can stomp the cortex.v1 key, retag mid-render, and produce a "now you see it, now you don't" experience for image cells. Mitigations:

• Use BroadcastChannel to coordinate between tabs: one tab owns the refresh; the other defers to it.
• Wrap localStorage writes with a version field; reject writes whose base version is stale.
• Render-pipeline guard: if a render started while a tag-batch was mid-flight, queue the second render rather than racing.

18.3 Postmortem template

1. Window: when did it start, when did it end, who saw it.
2. Impact: SLI delta in the window.
3. Cause: the plan, the audit log, the offending entry.
4. Detection: which alert fired, or which human noticed.
5. Response: what we did, in order, with timestamps.
6. Action items: changes to the plan, the worker, the dashboards, the runbook.
7. What we got right.

19. Unit economics

A rough back-of-envelope for the Operator tier (≤100 sources, 24 plan runs/day, BYO LLM key):

The Hobby tier is a leader-priced loss-leader. The Operator tier is profitable at modest volume. The Newsroom tier carries the company.

20. Roadmap to general availability

Week 1–2 — Worker bodies

• Wire Steel into plan.rs.
• Implement first-class tools: fetch-rss, fetch-url, parse-rss, parallel-map, audit, now, kv-get, kv-put.
• Native CLI runs news-refresh.scm end-to-end.

Week 3 — WASM target

• worker-build --release green.
• Durable Object mailbox implementation.
• Wrangler deploy of baobab-worker behind a feature flag on Baobab production.

Week 4 — Lacuna integration

• Python brain emits the news-refresh plan from a template.
• Audit log fans out to a JSONL store.
• Operator console shows last-run summary.

Week 5–6 — Loam

• Memgraph cluster provisioned.
• (loam-ingest ...) and (loam-query ...) tools implemented.
• Worker writes entities through Loam; LLM step reads from it.

Week 7–8 — Second customer

• Onboard a non-Baobab design partner.
• Their plan, their source list, their console.
• Hardening from the cross-tenant lessons.

Week 9–10 — SRE polish

• SLO dashboards live.
• Pager rotation for the three Newsroom-tier alerts.
• Runbook drills.

Week 11–12 — GA

• Hobby tier opens.
• Documentation site at workers.lacunalabs.ai.
• Pricing page; signup flow; first paying customer.

21. FAQ

Why not Lua / Python / WASM-direct?

Lua: viable, but its parenless syntax fights the homoiconicity we want (plans-as-data, plans-as-text). Python: too big for the WASM target. WASM-direct (handing operators a wasm module per plan): right answer for v3 or v4; wrong answer for v1 DX — operators don't write WASM.

Why not just write the worker in Node?

Three reasons. (1) Audit-log discipline is much easier to enforce in Rust where we can put the cap check on the function body, not in a linter. (2) WASM size budget matters and Rust wins it. (3) The threading model — fork/join/channels — is straightforward in tokio and awkward in Node's single-threaded event loop.

Isn't a custom DSL a maintenance burden?

The DSL is R7RS Scheme. We didn't invent it; we picked it because the operator's plan is small enough that they should be able to read it, and Scheme is the smallest readable thing. The tool registry is our custom surface; the language is not.

What happens when a plan exceeds its deadline?

The plan run is cancelled cooperatively. Tools whose body is in flight see their deadline drop to now and may abort their I/O. The mailbox response is ok: false with a deadline-exceeded error. The audit log up to the cancellation is preserved.

How do we test plans?

The CLI runs plans against a real worker. We also ship a --dry-run mode that runs the plan against a mocked tool registry; tools return canned values, and the audit log shows the call shape. CI runs every canonical plan in dry-run on every push to the plan registry.

Can a plan call another plan?

Yes — via (send mailbox-name message). This is how compound workflows are built: the news refresh sends a message to the Loam-ingest mailbox; the Loam-ingest mailbox sends a message to the LLM-summarise mailbox; results trickle back. Each mailbox has its own capabilities; cross-mailbox capability escalation is not possible.

What if Cloudflare goes down?

The Fly native target is the failover. Operators on the Newsroom and Enterprise tiers can be configured for active-active across both backends; the Lacuna brain picks the healthy one per cycle. Hobby and Operator tiers degrade to "next cycle will retry."

22. Glossary