Qirava DMS docs

Architecture overview

This is the single source of truth for how the DMS is built — the whole system on one screen. Two pillars run through everything: security and performance. The access model is uniform (a function is reachable only through execute(), only via a worker, and no write path skips the planner), and capabilities are layered on top without ever weakening it. This page gives you the request flow with its three checkpoints, the module map and its one-way dependency rule, and a map of the deep-dive pages.

The whole system on one screen#

Every request follows the same path. A protocol front-door (HTTP/WebSocket) hands the request to a worker; the worker runs before -> handle -> after; the handler runs through execute() on the bounded executor; data work goes through the planner into the tables and write-ahead log. The three checkpoints sit on that path.

Request          Worker                  execute()           Planner            Tables + WAL
browser·SDK·peer  before→handle→after      bounded executor    QQL plan→execute   storage
      │                │ [L1]                  │ [L2]               │ [L3]               │
      └────────────────┴───────────────────────┴────────────────────┴────────────────────┘

Request flow with the three access checkpoints

L1 — Worker before-auth: Authentication runs as a before-function: it verifies a session or an HMAC-signed key and writes the caller's identity into the shared context. Every auth/RBAC scenario extends this chain.
L2 — Execute function scope: The executor checks the target function's declared scope — public vs internal (global/scoped/owner) — against the caller before any handler runs. Only Public functions are schedulable by a worker.
L3 — The planner: Database and table RBAC is enforced in the planner as app-scope INTERSECT principal-grant, deny-by-default. The planner is the only door to read or mutate; no write path skips it.

The module map#

The repository composes five products plus the brand crate. Each is its own repository; products share the q* substrate, and the dependency arrow only ever points toward it.

Crate	What it is	State
qpkgs	The zero-dependency q* stdlib — qexec (the bounded executor + function runtime) and qvalue (the value model) plus focused utility crates. Products depend on it; it depends on no product.	built
qquill	The Rust-native UI/app framework: styled components over headless state machines, native SSR + islands + SSG. Its own repo, a sibling to the DMS — and it does not depend on q*.	built
qdms	The product: src holds exactly functions/ and workers/. Governance, KMS, the database, jobs, and replication are function groups; Studio (the default admin app) ships under workers/apps/.	built
qirava	The marketing + docs + architecture site, a Quill app that dogfoods the framework end to end. Serves over a worker, or exports a static dist/ that runs with no DMS.	built
qcloud	The managed, multi-tenant control plane — a DMS that manages other DMSes. Control plane v1 is built (_cp_* catalogs, cloud.* functions, RBAC-gated Cloud Console); the live infra effect is simulated/planned.	partial
qbrand	The single source of brand assets — the ink-Q mark, lockups, and favicon. Every product pulls its mark from here.	brand

Where the code lives#

Inside qdms, src is just two trees plus thin re-exports. The function runtime itself (registry + execute + chain/all + helper pool) lives in the shared qexec crate and is re-exported, so any function package can register against it without depending on the DB.

src/functions/ — the internal function groups: planner, read, write, search, graph, vector, inline, auth (RBAC/governance before-functions), db (engine/QQL/WAL/tables), docs (the docs-site app).
src/workers/ — the OUTWARD worker layer: the request pipeline, RequestContext, route/group model, the response envelope, HTTP/WebSocket/epoll front-doors, the scheduler/reactor, and workers/apps/ (Studio, the default admin app).
src/lib.rs — re-exports qexec (ExecConfig, FunctionRuntime, FunctionScope, ResponseCode, ...) and qvalue (bignum, model) so historical crate paths keep working.

The deep dives#

Each page below is self-contained and shows honest status — what is built, what is a working seam, and what is designed but not yet built.

Security & governance architecture — the custodian M-of-N trust root, the master seed, the recovery split, and confidential computing.
Embedded & sync — the in-process library mode and bidirectional WebSocket sync for backup/restore.
Core concepts, the access model, the worker pipeline, and the execute model — the four foundational pages earlier in this section.