VA.2026.007 · Floor 0 · service · hall 02
“a framework is not a stack — it is an agreement about where everything lives.”
Exnest VA is not a product — it is the agreement every product in this collection signs. Resource-oriented, OData-shaped, multi-tenant by design: responses carry @odata.context, @odata.count, and @odata.nextLink; errors are ODataError with id/en messages; tenants arrive on an x-tenant-id header. Learn the convention once and every module reads the same.
The framework ships as two runtime cores with identical architecture. The NestJS core is the enterprise twin (NestJS 11, layered Controller → Service → store); the Elysia core is the fast twin (Elysia on Bun, same lib layout: endpoint, exception, odata). A feature module is always eight files — barrel, module builder, controller, service, dto, interface, i18n, spec — and a generator scaffolds it, wires the registries, and appends the model to the schema.
Engines are the collection's growth mechanism: framework-agnostic kernels with per-framework adapters (/nest, /elysia), so the same machine runs on any backend. VA-ORM persists, the video engine streams HLS, the PDF engine serves watermarked pages behind signed tokens — each one folder, same boundary: kernel clean of frameworks, adapters optional. Note the name: Exnest VA, under Void VA — not ExnestJS, which describes only half the building.
VA.2026.007
Exnest VA
Software Framework · OData V4 · NestJS + Elysia · Open Source
NestJS enterprise core and Elysia fast core established side by side — same module convention, same OData envelope, different runtimes.
Eight-file module standard frozen: barrel, builder, controller, service, dto, interface, i18n, spec. Generators for modules, OpenAPI, and Postman collections.
Kernel-plus-adapter pattern adopted: VA-ORM, HLS video-stream, and protected pdf-stream land as drop-in engines with /nest and /elysia adapters.
Downstream works (memory engine, timeline simulation) built entirely on the convention — proof the agreement holds. Renamed Exnest VA to describe the whole, not one runtime.
concepts — kept & discarded
kept — one convention across runtimes; learn once, read everything
rejected — single-stack identity; the framework is the agreement, not the runtime
held — engines as clean kernels; frameworks plug in, never the reverse
archive ref — VA.2026.007/CON
cross ref — timeline fig. 01
curator annotations
call it Exnest VA: the whole agreement, not one runtime's surname.
eight files, same order, every time — boring is the feature.
a kernel that imports a framework is a plugin with ambitions; keep it clean.
| materials | OData V4 envelope · NestJS enterprise core · Elysia + Bun fast core · declarative endpoint registry · module scaffolding · OpenAPI + Postman codegen · framework-agnostic engines | dimensions | runtime cores — 2 · engines — 3 · files per module — 8 · response envelope — OData V4 · tenancy — multi-tenant |
|---|---|---|---|
| condition | live · 2 runtime cores · 3 engines | acquired | 2026 |
| revision | Rev. A | archive location | DWG-007 · floor Floor 0 · service |
| internal reference | VA.2026.007/M | origin | drawn as a monorepo, kept as a promise, 2025 |
failed experiments
early docs described one stack; the second core forced the rename to Exnest VA and a monorepo that holds both.
Postman collections maintained by hand drifted within weeks. codegen from the registry killed the drift.
first engine draft imported framework internals. split into kernel plus adapters before a second consumer existed.
draft concepts
research notes
— identical architecture across two runtimes beats abstraction layers — copy the shape, not the code.
— generated specs stay honest because they derive from the route registry, not from memory.
— multi-tenancy at the service level keeps every downstream work isolated without extra thought.
Where a file lives is decided once, for every feature, forever. The eight-file module and the twin registries remove placement decisions so builders spend their judgment on behavior.
Enterprise and fast are deployment choices, not dialects. Identical architecture across cores means a module written against the convention reads natively in either runtime.
New capability arrives as a folder with a clean kernel and optional adapters — never as framework surgery. The collection expands without the foundation shifting.
within the collection
future vision
The collection grows one engine at a time — queue, transcode, live — each a folder with the same boundary. The cores stay twins, the envelope stays OData, and the agreement holds: Exnest VA is the room the tools share, not any single tool on its wall.