FUSE
A database usually introduces a private boundary. Every program must learn its wire protocol, install a client library, or call a service that translates on its behalf. Even simple work such as reading one document then depends on database-specific code. A filesystem removes much of that integration work because operating systems already give programs a shared interface for paths, directories, files, and permissions.
One interface already reaches almost every tool
FUSE lets a userspace process implement a filesystem. Stardust uses it to present the database as a mounted directory instead of placing an exported copy beside the real data. A shell, editor, build tool, backup tool, or programming language can open the same paths through the operating system's ordinary file operations. These tools need no Stardust client library to discover the database or read and write documents.
The directory tree explains what is available. format/json and format/dust contain two projections of the same facts. Data, definitions, patch endpoints, transaction history, runtime information, generated SDKs, executable tools, and agent skills each have a stable place in the mount. Discovery becomes directory traversal rather than a separate metadata API.
stardust/format/json/data/entities/0000/0000/001/63.jsonschemas/user/entities/0000/0000/001/63.jsontransactions/definitions/schemas/user.jsonqueries/patch.jsondust/the same tree, as DUSTobjects/sdks/skills/
An entity has a numeric ID and a stable file path. Entity 163 uses data/entities/0000/0000/001/63.json in the JSON projection.
The path depends only on the ID, so database growth does not change it. Flat paths such as data/entities/163.json do not resolve.
The entity tree includes definitions, transactions, and reserved IDs. A definition's named file contains its authored document.
Its entity file also shows structural facts, such as stardust/type and stardust/path/name. Definition containers have read-only entity documents.
A transaction's entity document contains its metadata. Its file under data/transactions contains the full patch for that commit.
A write to patch.json or patch.dust can create entities with #_name temporary names. The patch file always reads as empty.
SDK patch methods give the resolved IDs. The entity-create command and generated mutation targets can also allocate IDs.
The mount rejects direct creation or removal of entity documents and ID folders under data/entities.
Definitions keep names under definitions/<kind>/. Each schema also has a data/schemas/<name>/entities/ view with the same stable ID paths.
That view contains entities whose authored documents conform to the schema. A sibling patch file provides schema-checked writes.
Configuration
A mount has no configuration file. The id tree needs no setting, because
the id fixes the path. The one tuning knob caps the compiled expression
cache that each evaluating thread keeps, stardust mount --expression-cache N.
Without it, each cache is bounded by memory.
Derived views stay attached to their source
A mounted file does not have to contain bytes from a conventional file. Stardust can render an entity on read and validate a definition on write. It can also generate an SDK from the current definitions. The file path remains familiar while the database keeps authority over the result. There is no export step that can leave a stale copy behind.
JSON and DUST also remain one database rather than two synchronized trees. Reading either projection renders the same facts, and writing either one commits through the same validation and history rules. Existing tools can select the notation they understand without creating another source of truth.
Valid content, limited errors
The mount validates content before it commits a write, so ordinary filesystem access does not weaken the database's contracts. It rejects invalid syntax, schema violations, and conflicting changes before they enter history. This keeps the content valid even when the writer knows nothing about Stardust.
The kernel boundary has little room to explain why a write was rejected. A filesystem error code cannot identify the invalid value or the schema rule. It also cannot point to the source range that needs attention. The mount can protect data at save time, but the file interface gives little diagnostic detail.
Composition replaces integration code
The filesystem boundary lets common tools work with the database before a specialized integration exists. A person can inspect a document with a pager or compare it with a diff tool. An editor can change a document, and a filesystem walker can copy a collection. Programs can begin with these operations and adopt generated types or richer protocols when necessary.
FUSE requires a host with a compatible kernel interface, and ordinary file operations do not provide a natural request-and-response shape for every computation. Precise validation feedback, queries, mutations, and live change delivery need a conversational channel. LSP adds that channel before and after a save.