Description

GLITHER

// policy, compiled to a sandbox

GLITHER

policy language · the RAGBAZ stack

A declarative policy DSL that compiles Glither → Gleam → Rust → WASM and runs inside a WASI/OCI/WIT container, so enforcing a rule is as safe as running any sandboxed wasm component.

GLITHER · MAILGUARD · GLEAM · RUST · WASM · WASI · OCI · WIT

GLITHER is the policy core of the RAGBAZ stack. It began as Mailguard's rule engine and generalises to segment encryption, decision councils, API admission and data-flow redaction — one language, many dialects, all enforced through the same sandboxed virtual machine.

Architecture at a glance

   author (.glith, literate)
        │  weave → human doc (bazweave-kit)
        │  tangle ↓
   typed core IR  (Roux core; WIT types: segment, receipt, outcome, …)
        │  transpile
        ▼   Gleam   ── reference lowering: typed, exhaustive pattern-match
        ▼   Rust    ── production lowering: no GC, predictable memory, mature wasm
        ▼   WebAssembly Component  (WIT imports = the ONLY capabilities)
        ▼   WASI + OCI container   ── capability sandbox inside an OS boundary

A

Glither

1

the policy language

A rule is a comprehension over an artifact — artifact | predicate | … => disposition, read "artifact such that …, therefore …". The author lists conditions; the compiler infers cheap selectors from audited crossing-guards, and every rule ends in exactly one named state.

Technical choices. Comprehension surface with phase inferred (predicate pushdown, like a SQL optimiser); boxes vs ladders (into <box> terminal-only, raise detail to full for graded lattice climbs, occlusion never written); one information-flow lattice doing both downgrade-checking and promotion; triggers as pure guards over ligands (when/on/after, with a liveness lint for any awaiting arm lacking a deadline); a shared Roux core grammar (EBNF + Pest) with per-dialect vocabulary (mail, segment, decision, api, flow).

The transpilation pipeline (the load-bearing choice). Glither is not interpreted in-process. tangle produces a typed IR whose types are expressed in WIT; the IR lowers to Gleam (auditable reference, exhaustive case maps dispositions 1:1), then to Rust (no GC, deterministic memory, mature wasm32), then to a WebAssembly Component whose WIT imports are its only capabilities.

✓WHY THE VM MAKES IT ROBUST

A wasm Component can touch nothing it was not handed through a WIT import — no filesystem, clock, network or syscalls (WASI is capability-based). Linear memory is bounds-checked and control-flow is structured, so the memory-corruption → RCE → break-out chain has no first rung. The WASI boundary sits inside an OCI container boundary, so an escape must defeat the wasm VM and the OS isolation, independently. The upshot: rule authors need not be trusted with host access — the worst a hostile rule can do is return a wrong verdict (caught by review/tests), not break out of the VM.

valueProse policy → a statically-checked, sandboxed, auditable artifact; one source woven into a doc and tangled into a deployable wasm component.

functionalitySelection · audited crossing-guards · terminal boxes · graded promotions · coupled (symport) moves · fan-out (for) · time-as-ligand deadlines · interim + settlement receipts.

interoperabilityWIT component model (embeds in any wasmtime/jco host) · Gleam & Rust lowerings (BEAM / native) · rendered by bazweave-kit · diagrammed by diabaz.

usabilityLiterate by default (/// woven) · four-domain highlighting with a deduced-phase overlay · faithful aliases (baz, dsl).

securityWASI capability sandbox + OCI isolation + WIT-typed I/O · pure/total policies → deterministic, replayable, trustworthy audit.

work in progress§11.8 ratifications (authority rungs, api probation, flow suspension); maturing Gleam→Rust→wasm codegen + IR↔WIT conformance suite; a lower-lawfulness checker; closed-world dialect declarations.

RAGBAZ platform map

Adjacent products, exposed via the MCP gateway. Each should carry its own docs/DESCRIPTION.mdx in its repository.

Product	Role	Interop
Mailguard	policy-driven mail control plane (proton-bridge)	runs glither.mail rules; mailstack data-plane — has its own docs/DESCRIPTION.mdx
mailstack	mailboxes, domains, aliases, DKIM	data-plane under Mailguard
provision	tenant lifecycle, custom domains	multi-tenant substrate for policy sets
articulate	headless CMS + Next.js export	publishing surface for BAZ.Weave docs
frog	repo/workspace task & lock orchestration	monorepo CI/agent coordination

iCROSS-CUTTING DIRECTION

A unified policy substrate: Glither (glither.api, glither.flow) governing admission/redaction in front of provision and articulate, compiled to the same WASI/OCI/WIT artifact — every product enforcing policy through one sandboxed VM, with per-tenant capability budgets wired from provision into the WASI imports.