Why RURAL

Status: Development. RURAL's advantages start with connected records, independent branches and questions grounded in operational evidence. Their implementation packets are complete; whole-prototype acceptance and production qualification remain open.

A project has tasks, code, decisions and outcomes. Those records change together, but people also need to revisit a stable version, explore another direction and understand what happened after a release. RURAL is designed to make that combination ordinary database work.

RURAL is designed for applications where project records, tasks, decisions and business events are connected. People can use ordinary create, read, update and delete operations, then follow relationships or ask bounded questions across those records.

Try the idea with real inputs

The API playground runs a small browser-memory model. Create, read, replace and delete records; fork a branch and compare its values with its parent; retry an event without counting it twice; and compute a scoped answer with evidence. Edit the JSON to inspect validation errors and atomic failure. These are interactive design examples, not a connection to the database engine or a stable public API.

The transaction story shows why publication matters: prepare a complete change, synchronize its intent, then make one new committed view available while an earlier reader retains its original snapshot.

Keep everyday work connected

The benefit is a coherent application model: a task can belong to a project, reference a decision and lead to a deployment whose outcomes can be inspected. Applications should be able to work with each record directly and follow its relationships when the question needs more context.

The planned mechanism combines nested documents, optional schemas and typed graph relationships within explicit transaction and snapshot boundaries. Schemas define expectations; graphs preserve connections; ordinary CRUD makes both useful in daily work.

Git and repository files still own code and source documents. RURAL is intended to own application transactions and accepted observations, with provenance linking the two. Connected data does not require a second authority for repository contents.

Today: document, schema and graph implementation packets are complete; whole-prototype acceptance is still in progress. Relationships require careful validation: endpoint deletion, uniqueness and schema changes must remain correct together. Read documents and CRUD and queries and graphs.

Branch without copying everything

A proposed release, a revised plan or a data correction can begin from a stable world and branch again. The useful property is independence: later parent writes do not silently change a child's starting view, and a child can evolve without changing its parent.

RURAL's persistent map retains an immutable root and shares unchanged nodes and values. An update copies affected tree paths instead of the entire map. Retaining the data root takes constant work, and reads descend a balanced tree rather than walking an ever-growing chain of parent branches.

Today: structural sharing, retained snapshots, recursive data forks and bounded merge work have completed implementation packets. Final integration and acceptance remain open. Retained history consumes resources. Git working-copy coordination remains later work. See worlds and branches.

Read a stable world while work moves on

A report or interface should be able to finish reading one committed view while later changes are prepared. This is especially useful when operational writes and longer analytical questions share the same data.

The architecture gives readers retained immutable roots and gives mutations one ordered owner. The owner validates and allocates prospective state, journals its exact intent, then publishes the new root. A short publication boundary protects ownership acquisition; a reader uses its retained root outside that boundary.

Today: immutable ownership and prepared state are implemented. The integrated native acceptance and mixed-load checks are still running. Ordered writes make sequencing and failure behavior explicit, but can limit write throughput. Readers and writers also share CPU, memory and I/O capacity. Resource budgets and workload measurements matter more than a promise that every operation runs without contention. Read the architecture overview.

Accept events, then build useful answers

An accepted business event should have a meaningful receipt even when a dashboard needs more time to catch up. Separating those responsibilities lets intake and analysis have different work budgets and progress indicators.

The implemented local path validates and records an observation before acknowledging its declared durability level. Projections then advance through accepted history and expose their processed position, coverage and freshness. Expensive aggregation does not belong in every event's acceptance path.

Correctness carries through the whole flow: retried events need stable identities, replacement reports must replace earlier values, and refunds need explicit correction rules. A report changing from 100 to 103 must yield 103, not 203.

Today: analytics intake and exact metric implementation packets are complete, while mixed-load qualification remains underway. Local synchronization has a local failure envelope. Protecting accepted events from destruction of a host requires stronger replicated durability. Read analytics and warehouse and durability and recovery.

Give AI the answer and its evidence

“What changed after this release?” should produce a scoped result with enough evidence to inspect it. Sending every task, deployment and event into a prompt creates avoidable work before the model can address the question.

The Oracle design puts filtering, joins and aggregation close to the data. It discovers relevant schemas, executes authorized bounded plans and returns compact results with branch, time range, metric definition and freshness. Evidence handles let the user or model expand selected sources when more detail is needed.

AI can help interpret a question; RURAL handles deterministic data operations. Ordinary database work remains usable without model inference.

Today: bounded Oracle and MCP implementation packets are complete, but final prototype acceptance remains open. Token and latency savings remain unmeasured. Smaller responses must preserve missing-source qualifications and other evidence that changes an answer's meaning. Read Oracle and MCP.

Make memory and dependencies explicit

RURAL's Zig core makes allocation, ownership and resource limits visible in the implementation. That control is useful for bounding requests, understanding retained snapshots and deciding which work belongs on a transaction's critical path.

The existing storage foundation uses Zig’s standard library and operating-system APIs. For the native prototype, third-party dependencies are permitted when pinned and documented; first-party executable code remains Zig. Keeping these boundaries explicit makes the design inspectable.

The tradeoff is engineering responsibility: storage formats, indexing, interoperability, recovery and security still need to be implemented and maintained. Zig and a smaller dependency graph do not establish speed or reliability by themselves. The separate Go + HTMX documentation website has its own dependency contract. Read dependency boundaries.

Prove the advantage on real work

The next meaningful evidence is a fully accepted application flow: create and query ordinary records, branch them, recover acknowledged changes, ingest source-bound events and ask an evidence-backed question.

Measurements should capture branch memory growth, mixed read/write latency, intake and projection lag, recovery time, and Oracle calls and token usage for equivalent answers. RURAL has no published benchmark showing an advantage over SurrealDB or another database.

Explore the interactive technology diagrams to see how the mechanisms fit together. The project status records the implemented boundary, and the roadmap describes the acceptance gates ahead.