Cryptofabric Plans and Egglog

Status: research and architecture plan. Existing cryptofabrics, SQLite outbox state, Cap’n Web batching, WebRTC, HTTP fallback, and receipts provide the raw machinery. Typed plan IR and equality-saturation optimization do not yet.

A cryptofabric should be able to describe how an envelope, checkpoint, resource, continuation, or effect may move through machinery without turning one route into identity or authority.

The plan language should be readable as Lua tables and canonical S-expressions, stored and queried through SQLite, and rendered as the same PCB machinery the cockpit already uses.

The optimizer may propose equivalent or cheaper plans. It may not erase semantic boundaries merely because two boxes can be drawn closer together.

A typed plan, not a bag of arrows

A plan is a versioned Cursor Term with explicit operation types, inputs, outputs, evidence, costs, and semantic barriers.

(plan cryptofabric/v0
  (sequence
    (resolve
      (pointer state-a91)
      (constraints (curve family) (integrity sha256-root)))
    (choose-carrier
      (prefer local-cache lan webrtc http-webseed mailbox))
    (fetch
      (object state-a91)
      (budget (bytes 1048576) (round-trips 4)))
    (verify
      (content-root state-a91)
      (signature release-key))
    (resume
      (cursor cursor-83)
      (body-requirements continuation-v0))
    (await-receipt
      (effect effect-84))))

Equivalent restricted Lua-shaped source:

fabric.plan {
  version = 0,
  sequence = {
    fabric.resolve {
      pointer = "state-a91",
      constraints = { curve = "family", integrity = "sha256-root" },
    },
    fabric.choose_carrier {
      prefer = { "local-cache", "lan", "webrtc", "http-webseed", "mailbox" },
    },
    fabric.fetch {
      object = "state-a91",
      budget = { bytes = 1024 * 1024, round_trips = 4 },
    },
    fabric.verify { content_root = "state-a91", signature = "release-key" },
    fabric.resume { cursor = "cursor-83", requirements = "continuation-v0" },
    fabric.await_receipt { effect = "effect-84" },
  },
}

Both compile to one immutable plan IR. The source is not executed as arbitrary Scheme or Lua.

Plan operation families

The first vocabulary should remain small:

A carrier operation states how bytes or live calls move. It does not state who authored them, whether they are authorized, or whether an effect happened.

Semantic barriers

The plan IR must mark transitions that cannot be reordered without changing meaning:

SIGNATURE BARRIER
  unverified bytes cannot become accepted records

AUTHORITY BARRIER
  a candidate operation cannot become an authorized intent

TRANSACTION BARRIER
  durable state and outbox intent commit before post-commit execution

EFFECT BARRIER
  submission, acceptance, completion, observation, and receipt remain distinct

PRIVACY / CURVE BARRIER
  a rewrite cannot expose material outside the selected projection

CAUSAL BARRIER
  a successor cannot move before required parents or join inputs

These are first-class nodes, not comments an optimizer may misplace while feeling productive.

What equality saturation contributes

An equality graph, or e-graph, compactly records many equivalent expressions. Equality saturation repeatedly applies valid rewrite rules without immediately choosing one path. A cost model then extracts a preferred expression.

For Cursors, this is attractive because one semantic plan may have many local realizations:

resolve -> fetch -> verify

resolve+fetch over one local SQLite body -> verify

Cap’n Web pipeline(resolve, fetch) -> verify

parallel(local-cache, webseed, peer) -> first verified material

The key phrase is one semantic plan. Equality saturation is not permission to invent equivalence between delivery and execution, a bearer reference and a capability, or an outbox row and a completed effect.

Safe candidate rewrites

Examples to evaluate and prove with frozen fixtures:

Pipeline dependent live calls

(sequence
  (rpc resolve-pointer)
  (rpc mailbox-head)
  (rpc fetch-record))

=>

(capnweb-pipeline
  (resolve-pointer)
  (mailbox-head (result 0))
  (fetch-record (result 1)))

Valid only while the durable outputs and failure states remain the same. Cap’n Web stubs remain ephemeral.

Push relational constraints down

(filter (mailbox-scan) (family chat) (sequence > 90))

=>

(mailbox-query (family chat) (sequence > 90))

SQLite, a virtual table, or a remote interest may implement the pushed predicate. The resulting accepted rows must be equivalent under the same horizon and authorization policy.

Fuse local pure machinery

(sequence
  (sqlite-read object-root)
  (decode canonical-value)
  (hash-verify object-root))

=>

(sqlite-read-verified object-root)

Only if the fused component emits the same explicit verification evidence and error states.

Parallelize independent recovery sources

(sequence
  (try local-cache)
  (try webseed)
  (try peer))

=>

(race-verified
  local-cache
  webseed
  peer)

The winner is the first source whose material passes the same root verification. A fast corrupt source does not win.

Reconciliation planner

(reconcile sets (expected-difference small))

=> (minisketch capacity-8)

(reconcile sets (difference unknown))

=> (rateless-iblt bounded)

(reconcile ordered-area)

=> (range-reconciliation)

Planner decisions must expose estimates and fallback thresholds. Minisketch discovers differing identities; fountain/RaptorQ reconstructs bytes. Those jobs remain separate.

Forbidden rewrites

The optimizer must reject transformations such as:

reference reachable          => authority granted
message delivered            => continuation executed
outbox intent committed      => effect completed
bytes reconstructed          => bytes authentic
transport encrypted          => payload authorized
one body observed absence    => fact globally false
RPC session alive            => durable continuation exists
fast source                   => trusted source

Likewise, it may not move:

• effect submission before the transaction commit;
• execution before capability presentation;
• receipt creation before accepted observation;
• material outside the selected curve;
• a successor before required causal parents;
• a stale or hypothetical plan into observed history.

Egglog as a sidecar, not the authority root

Egglog combines Datalog-like rules with equality saturation. It is a strong candidate for a plan-research engine because it can express typed terms, rewrites, analyses, and extraction.

The initial use should be an offline or local sidecar:

canonical cryptofabric plan
          |
          v
    typed plan validator
          |
          v
      egglog experiment
   equalities / rewrites / analyses
          |
          v
      extracted candidate
          |
          v
 independent semantic verifier
          |
          v
   accepted local execution plan

Egglog output is a proposal. Cursors verifies the candidate against semantic invariants, capability requirements, horizons, and cost budgets before execution.

A later Nelua or Rust extractor may implement a smaller frozen rewrite set. The plan language and proof fixtures should not require a particular e-graph library at runtime.

SQLite representation

Suggested operational tables:

CREATE TABLE fabric_plans (
  plan_id TEXT PRIMARY KEY,
  version INTEGER NOT NULL,
  term_root BLOB NOT NULL,
  semantic_profile TEXT NOT NULL,
  horizon_id TEXT,
  status TEXT NOT NULL
);

CREATE TABLE fabric_plan_nodes (
  plan_id TEXT NOT NULL,
  node_id TEXT NOT NULL,
  operator TEXT NOT NULL,
  term_root BLOB NOT NULL,
  barrier_class TEXT,
  PRIMARY KEY (plan_id, node_id)
);

CREATE TABLE fabric_plan_edges (
  plan_id TEXT NOT NULL,
  from_node TEXT NOT NULL,
  to_node TEXT NOT NULL,
  edge_class TEXT NOT NULL,
  ordinal INTEGER NOT NULL,
  PRIMARY KEY (plan_id, from_node, to_node, edge_class, ordinal)
);

CREATE TABLE fabric_plan_candidates (
  candidate_id TEXT PRIMARY KEY,
  source_plan_id TEXT NOT NULL,
  extracted_root BLOB NOT NULL,
  optimizer_profile TEXT NOT NULL,
  status TEXT NOT NULL,
  verification_receipt TEXT
);

CREATE TABLE fabric_plan_costs (
  candidate_id TEXT NOT NULL,
  metric TEXT NOT NULL,
  value REAL NOT NULL,
  evidence_class TEXT NOT NULL,
  PRIMARY KEY (candidate_id, metric)
);

CREATE TABLE fabric_rewrite_evidence (
  candidate_id TEXT NOT NULL,
  rewrite_id TEXT NOT NULL,
  before_root BLOB NOT NULL,
  after_root BLOB NOT NULL,
  proof_class TEXT NOT NULL,
  PRIMARY KEY (candidate_id, rewrite_id, before_root, after_root)
);

Useful cost dimensions include:

• expected round trips;
• bytes and storage reads;
• CPU and Wasm crossings;
• Durable Object calls;
• energy or radio time;
• privacy exposure;
• number of trust boundaries;
• availability confidence backed by observations;
• expected recovery rank;
• explanation complexity.

Do not collapse these into one universal scalar too early. A Pareto frontier is often more honest than a magic cost score.

Plans as dataspace tuples

The plan and its execution state can appear in the attributed dataspace:

(plan-offer
  plan-id
  body-id
  supported-profile
  cost-vector
  lease-id)

(plan-selected
  cursor-id
  plan-id
  horizon-id
  authority-presentation)

(plan-stage
  plan-id
  node-id
  status
  evidence-id)

An interest may subscribe to plans matching constraints. A capability may attenuate which plan operations or destinations are permitted. Neither tuple presence nor plan selection performs an effect.

Cockpit rendering

The PCB is a projection of the typed plan:

POINTER IN
    |
[RESOLVER]---constraint bus---[CARRIER SELECT]
    |                              |
    |                  +-----------+-----------+
    |                  |           |           |
    |               [LOCAL]     [WEBRTC]    [HTTP]
    |                  |           |           |
    +------------------+-----------+-----------+
                               |
                         [HASH GATE]
                               |
                        [AUTHORITY GATE]
                               |
                     [SQLITE COMMIT BARRIER]
                               |
                       [EFFECT EXECUTOR]
                               |
                         [RECEIPT INPUT]

Each component exposes:

• canonical plan term;
• selected implementation body;
• inputs and outputs;
• barrier and capability requirements;
• measured and estimated costs;
• rewrite history;
• evidence supporting the current state;
• alternative candidates;
• reason the chosen candidate won;
• reason rejected candidates failed.

No photon moves unless a real stage event was observed or the view is explicitly marked simulated.

Cryptofabric Lego contracts

Every plan component should publish a small socket contract:

component type
input term/profile
output term/profile
required capabilities
side-effect class
idempotency contract
receipt profile
failure states
barriers crossed
cost evidence

Components can then be rearranged only when sockets, barriers, and invariants remain valid. This is the useful sense in which Cursors becomes Lego-like: pieces compose because their contracts fit, not because every rectangle accepts every wire.

Counterfactual extraction

A plan can be optimized under interventions:

WebRTC unavailable
Cloudflare disabled
local checkpoint missing
battery budget 5%
privacy policy forbids relay
peer loss 30%

The optimizer extracts a candidate for the simulated horizon and the cockpit displays what changed. This is useful for runbooks and model-checker counterexamples, but remains distinct from the plan actually selected during observed execution.

Smallest executable experiment

Use one existing place -> resume -> receipt demo and produce three candidates:

1. sequential local/HTTP calls;
2. one Cap’n Web HTTP batch;
3. MessagePort to local SQLite plus post-commit remote effect.

For each candidate:

• store one S-expression plan and one Lua-table rendering;
• validate semantic barriers;
• count round trips, bytes, crossings, and durable commits;
• extract a candidate under two latency assumptions;
• execute only through existing bounded adapters;
• compare accepted cursor/outbox/receipt results;
• render the selected plan and alternatives in the cockpit;
• explain why a lower-latency plan may cost more bytes.

Then add a recovery plan comparing exact HTTP range retrieval with multi-source fountain repair above a measured size/loss threshold.

Acceptance criteria

• Lua and S-expression plan sources compile to byte-equivalent plan IR.
• Every operation, edge, and semantic barrier has a typed contract.
• Equality rules cannot erase authority, causality, transaction, receipt, or curve boundaries.
• Extracted candidates pass an independent semantic verifier.
• Cost claims distinguish measurements, estimates, configuration, and unknowns.
• A selected carrier cannot change envelope, cursor, effect, or content identity.
• The browser retains a non-egglog baseline planner.
• Losing an optimizer or live RPC session does not lose accepted continuation state.
• Cockpit machinery corresponds to actual plan nodes and observed stage events.
• Counterfactual plans are visibly separate from observed execution.

Research lineage

• egglog: Better Together, Unifying Datalog and Equality Saturation
• egglog repository
• egg: Fast and Extensible Equality Saturation
• Volcano: An Extensible and Parallel Query Evaluation System
• Cascades query optimization
• SQLite virtual tables
• Cap’n Web
• Bundle Protocol v7
• RaptorQ

Related guides

• Cursor Logic
• Causal Horizons and Why-Not
• Cryptofabrics
• Cap’n Web Pipeline
• SQLite + Lua Cursor Machine
• Storage and Recovery Machinery