RURALDATABASE
Search⌘ K Try the API
RURAL / INSIDE THE DATABASEv0.0.0 / Pre-release

A closer look.
A clearer picture.

Good systems make their promises visible. A stable past, an explicit commit, an answer with evidence. Follow three ideas through the machinery that makes them possible.

Open the playground Watch the idea. Then try the model.
THREE IDEAS. MADE VISIBLE.01Share the past.
Own the next change.02Accept with meaning.
Measure with context.03Compute close.
Return what matters.
AN INTERACTIVE FIELD GUIDE

Conceptual stories play as you explore. Pause, inspect a step, or take the controls. Each story distinguishes the existing foundation from planned capabilities.

WRITE PATH / VISIBILITY BOUNDARY

A commit earns its acknowledgement.

Follow one illustrative update from validation through journal sync and publication. A response belongs after the state becomes visible.

DESIGN MODEL
01Requestexpected head
02Validatescope + limits
03Prepareno visible change
04Journal + syncdurability point
05Publishnew read root
06Receiptmeaningful reply
JOURNAL / COMMIT SEQUENCE 0041

The request names the expected head. No state has changed yet.

r₀
  1. Check request scope, expected head and resource limits.
  2. Prepare the complete candidate before persistent writes.
  3. Append and synchronize the journal record; recovery must resolve uncertain outcomes.
  4. Publish the new root, then return a receipt tied to the committed change.
THE DATABASE PHILOSOPHY / ONE COHERENT CHANGE

Change the work.
Keep the world consistent.

Move a project to ready. Record the event. Connect the two. A transaction gives those changes one visible outcome, while an existing reader keeps its earlier view.

BROWSER ILLUSTRATION · INTENDED PRODUCT MODEL
PROJECT / LAUNCHONE ATOMIC BATCH
  1. 01 Check

    Authorize the actual operation. Check the expected branch head, input limits, and the planned schema and relationship rules.

  2. 02 Prepare

    Build a candidate root and receipt. Validate and allocate the prospective changes before journal I/O; nothing new is visible yet.

  3. 03 Synchronize

    Append the exact intent at its expected sequence and complete the journal's declared OS synchronization boundary.

  4. 04 Publish

    After successful synchronization, publish the prepared state without further allocation. The batch becomes visible together.

  5. 05 Read

    A new reader may retain the published root. An earlier reader still owns its old root and continues seeing its earlier coherent view.

  6. 06 Acknowledge

    Return the scoped receipt after publication. A lost reply requires a matching, reauthorized retry rather than blindly repeating the effect.

THE COMPLETED MODEL

One change. A coherent result.

The project, event and relationship become visible as one batch. Acknowledgment follows journal synchronization and state publication. An earlier snapshot remains unchanged.

RECEIPT RETURNED
EXISTING READERr₀
PROJECTlaunch
statedraft
Its retained view stays the same.
PREPARED CHANGES+3
Update projectdraft ready
Create eventrelease_ready
Link the recordsproject event
One batch, published together.
BRANCH CURRENT ROOTr₁
PROJECTlaunch
stateready
release_ready · linked
New reader retains r₁.
JOURNAL BOUNDARYOS synchronization confirmed
CALLER OUTCOMEScoped receipt returned
STATIC WALKTHROUGH / SIX ORDERED STEPSILLUSTRATIVE PACING · NO ENGINE CONNECTION
01 / ORDINARY CRUD

Make one coherent change.

Update records and their relationships within a defined transaction boundary.

02 / BRANCHING WORK

Keep an earlier view.

Retain data roots for independent work. Git and working-copy changes require separate coordination.

03 / CONTEXT & ANALYTICS

Build on accepted facts.

Link operational events to their context. Analytical projections report their own progress and freshness.

04 / SCOPED AI

Ask within a known view.

The bounded Oracle/MCP path queries authorized snapshots and returns compact results with inspectable evidence.

Where the model stands. Documents, schemas, graphs, local service access, branches, merges and analytics have completed implementation packets. Final acceptance and production qualification remain open. A local synchronization boundary is not replicated durability.

When an outcome is uncertain. A journal or publication failure after writing must stop normal continuation and enter recovery. A missing reply does not prove a rejected transaction.

Read the transaction and recovery contract
01 / IMMUTABLE ROOTS

A shared beginning.
Independent futures.

STATE-LAYER FOUNDATION

A branch begins with the same immutable data root. Later writes create a new view for that branch; the other branch and a retained snapshot keep their own view.

EXPERIMENT 01 / ROOTS & READ VIEWSILLUSTRATIVE DATA
Parent, child and retained snapshotTwo branches share root R0. A child write creates R1 and a parent write creates R2. Both can share unchanged records while the retained snapshot continues to read R0. PARENTCHILD CHILD ROOTR1price: 27 PARENT ROOTR2theme: moss ORIGINAL ROOTR0 RETAINED SNAPSHOT UNCHANGED RECORDS STRUCTURAL SHARING / CHANGED PATHS GET A NEW VIEW
READ THE SAME RECORD
product / field-notebook
Parent R2
20 · mossprice · theme
Child R1
27 · fernprice · theme
Snapshot R0
20 · fernretained original view

Each view keeps the state it owns.

READY WHEN IN VIEW05 / 05
05

History stays where you left it.

The retained R0 snapshot still reads price 20 and theme fern. Neither later write changes the data that snapshot owns.

  1. Retain original root R0: price 20, theme fern.
  2. Fork a child that initially shares R0.
  3. Write price 27 in the child, creating its R1 view.
  4. Write theme moss in the parent, creating its R2 view.
  5. Read the retained R0 snapshot: price 20, theme fern.

Why this matters. Explore changes while retaining a stable read view. Unchanged data can remain shared; branch catalogs, memory retention and eventual merges still need explicit limits.

Read the branching model
02 / DURABLE INTAKE

An event arrives.
A promise begins.

LOCAL PATH IMPLEMENTED

A durable receipt, a queryable record and a complete analytical view describe different milestones. The local implementation makes each position visible; production capacity remains unqualified.

EXPERIMENT 02 / ONE EVENT, SIX STAGESSYNTHETIC EVENT E041
  1. 01ReceiveBound the incoming eventComplete
  2. 02ValidateIdentity, schema, quotaComplete
  3. 03Journal + syncEstablish the durability boundaryComplete
  4. 04ReceiptAcknowledge accepted workComplete
  5. 05ProcessPublish the canonical query viewComplete
  6. 06WarehouseComplete the derived warehouse viewCurrent
JOURNAL SYNCED41local durable position
ACKNOWLEDGED41producer receipt position
QUERY-VISIBLE41canonical query position
WAREHOUSE COMPLETE41derived view position

The receipt, canonical query view and selected warehouse view have all reached 41.

READY WHEN IN VIEW06 / 06
06

The warehouse catches up, explicitly.

The selected derived warehouse view reaches position 41. Its completion is tracked separately from the durable receipt and the canonical query view.

  1. Receive synthetic event E041 while prior work is visible through position 40.
  2. Validate the event's source, schema and limits.
  3. Append and sync the accepted event; the journal reaches position 41.
  4. Send the durable receipt; the acknowledged position reaches 41.
  5. Process and publish the canonical query view at 41; the selected warehouse view remains at 40.
  6. Complete the selected derived warehouse view at position 41.

Why this matters. A producer can know what was accepted while canonical queries and warehouse projections report their own freshness. Bounded queues and explicit backpressure remain essential; local sync is not protection against losing the entire host.

Follow the intake design
03 / THE ORACLE BOUNDARY

A small answer.
A traceable foundation.

BOUNDED MCP IMPLEMENTED

AI can translate the question outside the database. RURAL validates the scope and bounded plan, computes against a defined data view, and returns the result with evidence you can inspect.

EXPERIMENT 03 / QUESTION TO EVIDENCELOCAL CONCEPTUAL MODEL
THE QUESTION

How many signups are tagged with release r17?

Example project: Atlas

Language becomes an explicit question about a defined set of records.

THE VALIDATED PLAN
scope
Atlas
filter
r17 · signup
operation
count
work limit
100 records
Computed within the chosen scope
THE COMPACT ANSWER
3signups

Atlas · release r17
3 matching synthetic records

RESULT + EVIDENCE
Inspect the evidence
  1. E041Atlas · r17 · signup
  2. E042Atlas · r17 · signup
  3. E043Atlas · r17 · signup

Example snapshot S1. Evidence expansion must recheck current authority in the proposed service.

READY WHEN IN VIEW05 / 05
05

The answer travels with its evidence.

Return the computed count, its scope and snapshot, with handles for the three matching records. Open the evidence to see exactly what contributed.

  1. Ask about signups tagged with release r17.
  2. Resolve the authorized Atlas project and example snapshot S1.
  3. Validate a count query with an explicit release, event kind and work limit.
  4. Filter the synthetic records and count three matching signups.
  5. Return three with its scope and inspectable evidence E041, E042 and E043.

Why this matters. Filter and aggregate near the data, then send a compact answer with the qualifications that matter. Token savings must be measured through real model usage; this illustration claims no savings percentage.

Explore Oracle & MCP
A MAP OF THE IDEAS, WITH THE BOUNDARIES IN VIEW

Understand the model.
Then inspect the details.

These controls run deterministic examples in your browser. They do not connect to a database or an AI service. Branching, local analytics and bounded Oracle/MCP views have implementation evidence; full acceptance and production-scale qualification remain open.

What exists today

Find your way.

A GOOD PLACE TO STARTIntroduction Branches & snapshots Oracle & MCP
Search the documentation, not your database.RURAL / INDEX