Two-Plane Core
How SveltyCMS splits request handling into a compiled Wire Plane for safe published reads and a Domain Plane for everything else — and where each half is documented.
SveltyCMS answers reads through two explicit planes. The distinction exists so that a fast path can never quietly become a second implementation of the CMS:
- Domain Plane — the full engine: Drizzle ORM hydration, field-level access control (FLAC), draft/published revisions, lifecycle hooks, relational populates, GraphQL Yoga. It decides everything: visibility, redaction, shape.
- Wire Plane — an opt-in fast path for reads that are already known to be safe: compiled
engine-side JSON (
json_build_object/json_object/ lean Mongo projection) written straight to the response, skipping hydration andJSON.stringify. It may only decline; it never decides.
The asymmetry is the design. A Wire Plane result that is empty or inadmissible falls back to the Domain Plane, which re-applies the caller’s real permissions, publication clamp and field policy. That is what makes the fast path safe to keep fast.
Which plane answers a request
| Request class | Plane |
|---|---|
| Public/authenticated read of a published row with no custom query shape | Wire Plane |
Any filter / where, non-default sort / limit / page, stream=true |
Domain Plane |
Drafts, previews, review status, populate, non-default locale, mutating hooks |
Domain Plane |
Caller with a FIELD_PERMISSIONS policy or a readRoles-guarded field |
Domain Plane |
| Admin UI, writes, GraphQL, revisions, relations, exports | Domain Plane |
| Warm-session hits of an already-served response (L1 / HTTP 304) | Cache Plane |
The Wire Plane is guarded by six fail-closed checks evaluated before any cache lookup:
operational state, endpoint parity (collections:read), grant freshness (permRev epoch), FLAC
exemption, publication clamp (requirePublished), and the wire admission predicate itself. They are
tabulated with their rules in the collection read lane section of the hooks
reference.
Where each half is documented
| Topic | Canonical doc |
|---|---|
| Lane mechanics, bypass policy, gate table, lane threat scan | Server Hooks & Middleware |
| Benchmark classification (Cells 1–4) and the honest yardstick | Performance Architecture |
| Tenant isolation: shared pool + RLS, bounded dedicated DSN pools | Multi-tenancy |
| What is shipped per phase, and the open decisions | Roadmap 2026 |
| How this came to be — including what was rejected and why | Achievements 3.29–3.31 |
Permission evaluation (permMask, permRev, the unused permBits) |
src/databases/auth/permission-bitmask.ts + the roadmap’s Phase-2 item |
Deliberate trade-off
Lane-served reads skip the security hook. Before a cache or database read they run the same path,
query, and header threat scan as handleSecurity, including the honeypot and non-local scanner
response. Heap shedding and the Redis WAF limiter stay on the full hook. Rate limiting is unchanged:
the API read pipeline already skips it for GETs.
Status
The compiled point path ships on all four adapters; list-wire is defined but not routed; no Cell-3 matrix has been published. Treat “Wire Plane” as partial until the roadmap’s Phase-5 acceptance criteria are met — the phase table and criteria live in the roadmap.