MMoolBase by RASVAIDEVELOPER PREVIEW
OriginWhat it solvesEvidence LabDecision layerBuild with it

MOOLBASE / TEMPORAL EPISTEMIC DATABASE

Facts don’t arrive finished.

MoolBase began with a database question: when evidence arrives over time, from different sources, and sometimes disagrees, can the database help determine what should be treated as established now — without losing how it got there?

Evidence → convergence → challenge → re-convergence → currently established fact.

Read the originRun the live Evidence Lab
Embedded C++20Actual WebAssembly engineApache-2.0No API key

THE CORE IDEA

ASource AAn observation arrives at T₁
BSource BIndependent support arrives at T₂
CSource CContradictory evidence arrives at T₃
ROUND 1Converge
→
CHALLENGEDiverge
→
ROUND 2Re-converge
CURRENTLY ESTABLISHEDFact F₁ — for nowsupported under the current evidence policy · opposition retained · revisable when evidence changes

WHY I STARTED MOOLBASE

The idea came before “AI memory”.

THE ORIGINAL PREMISE

“I wanted a temporal database that could take facts from different sources, reason across them, diverge when they conflict, converge when support becomes strong enough, and establish a new current fact without erasing the path that produced it.”

That is the shape MoolBase started from. The problem was not just remembering more data or retrieving the nearest chunk. Real evidence has time, lineage, independence, contradiction and revision. A system can store every record correctly and still fail to answer the question an operator, analyst or agent actually cares about:

Given everything we know right now, what fact is currently established — and what would make us change it?

01ObserveEvidence arrives over time.
02ConvergeIndependent support strengthens candidates.
03DivergeContradictions and alternatives stay alive.
04Re-convergeThe leading fact must survive challenge.
05ReviseNew evidence can reopen the result.
01

Time changes meaning

A fact that was reasonable at T₁ may become superseded at T₂. Temporal order and revision history are part of the evidence, not metadata to throw away.

02

Sources are not equal

Ten records can still represent one underlying source. MoolBase preserves provenance and evidence families so copied claims do not become artificial corroboration.

03

Convergence is not enough

A leading explanation can still be wrong. The system needs a deliberate divergent phase that preserves opposition and tests what could overturn the apparent winner.

04

Facts need a lifecycle

Observed, candidate, contested, established and superseded states should remain inspectable rather than collapsing into an opaque final answer.

HOW THE IDEA GREW

The original database problem forced two reasoning layers to emerge.

MoolBase stores the evidence state. HypoKosh exists because one evidence state can support multiple plausible explanations. DWM exists because even a converged explanation should be challenged before the system settles.

01

MOOLBASE CORE

What happened, when, and where did it come from?

Preserve observations, provenance, typed relationships, causal context, supersession and durable state so later reasoning has a trustworthy temporal substrate.

02

HYPOKOSH

What explanations are still plausible?

When several interpretations fit the same evidence, premature certainty is the failure mode. HypoKosh keeps competing hypotheses alive and allows convergence or abstention.

03

DWM / DIALECTIC ENGINE

What would make us change our mind?

DWM introduces material opposition, bounded reopen and targeted re-expansion so the apparent winner has to survive a deliberate divergent phase before re-convergence.

A SIMPLE EXAMPLE

A normal database stores the records. MoolBase asks what they establish together.

Imagine multiple observations about an overheating machine. Two sensors agree, an alert is derived from one of them, and another sensor disagrees. The interesting question is not “can I retrieve all four records?” It is whether the combined temporal evidence is sufficient to establish an overheating event.

Sensor A · 94°Sensor B · 95°Alert · derived from ASensor C · 61°
↓
CONVERGENCECandidate: machine is overheating
↓
DIVERGENCE / CHALLENGEDiscount copied evidence · retain contradiction · seek adjacent readings
↓
RE-CONVERGENCEEstablished under policy: overheating event occurredOpposition and provenance remain attached to the receipt.

WHAT MOOLBASE ACTUALLY SOLVES

It answers a different question from retrieval, graphs or event storage.

MoolBase is not trying to replace those systems. It focuses on the evidence process between raw observations and a revisable current fact state.

System focusThe question it is good at answering
Vector / semantic databaseWhat stored information is most similar to this query?
Knowledge graphWhat entities and relationships are represented?
Event storeWhat happened, and in what order?
Agent memoryWhat should this agent retain and retrieve later?
MoolBaseGiven changing evidence, what fact is currently established — why — and what could reopen it?

MoolBase is designed to complement retrieval, graph and event infrastructure. “Established” means established under the configured evidence policy and available evidence — not objective truth.

SHOULD YOU USE IT?

You probably do not need MoolBase for simple retrieval.

USE SOMETHING SIMPLER WHEN

The answer does not depend on evolving evidence.

If you only need key-value lookup, semantic search, ordinary graph traversal or an append-only event history, specialised systems already solve those jobs well.

MOOLBASE BECOMES INTERESTING WHEN

Your system must explain why the answer changed.

Use it when facts can become stale, sources disagree, copied evidence must not count twice, multiple explanations remain plausible, or a conclusion may need to be reopened later.

See that happen in the browser

EVIDENCE LAB / LIVE DATABASE

Do not take the story on faith. Watch the answer move.

The lab runs the actual MoolBase C++ engine in WebAssembly. Choose a scenario, add evidence one observation at a time, and inspect exactly why the current result changes.

Actual C++ engine · WebAssembly
Isolated browser session · synthetic fixtures · no API key
STEP 1Pick a scenarioIncident investigation, agent memory or conflicting reports.
STEP 2Add evidenceNotice copied sources, independent support and contradictions.
STEP 3Inspect the changeSee the current state, opposition, provenance and downloadable receipt.

0 eventsLoading database…

NEXT OBSERVATION

WHEN TO USE IT

THE SIMPLER ALTERNATIVE

CURRENT DATABASE RESULTStarting

Waiting for evidence

An operative answer is the current selection. Only a resolved status indicates sufficient support under this demo’s configured policy.

Snapshot—
Bundle hash—
Visited states—
Why MoolBase reached this state

PROVENANCE, NOT JUST VOLUME

Evidence ledger

Copies sharing one evidence family do not become independent corroboration. Retired evidence remains visible in this ledger and in nonoperative audit records.

ObservationEvidence familyEffectCertificateLifecycle
Add an observation to begin.
Try your own evidence

Use the same evidence family for copies of one source. Choose a new family only for an independently established source.

THE NEXT RESEARCH QUESTION

Could this become the world-state layer beneath a decision system?

That is the direction worth testing next.

MoolBase currently focuses on establishing and revising an explicit evidence-backed state. A decision runtime could sit above that state and ask a second question: “Given what is currently established, what should we do?”

This is a research direction, not a capability claim for the current developer preview. The present release does not claim utility optimisation, policy selection or autonomous action execution.

01Established world state
→
02Candidate actions
→
03Constraints + challenge
→
04Act · Abstain · Escalate

The outcome becomes new temporal evidence and can change the next decision ↺

INSTALL → RUN → CONNECT

Download MoolBase

Start with the compiled DB. Add the examples to try agent memory, incident investigation and conflicting reports. Cloning the full repository is optional.

v0.6.0-alpha.2 developer preview · Packaging revision 1 · Compiled download: Linux x86_64 only. Use source for other supported build environments.

Run your first application

Download and extract the DB and examples ZIPs in the same directory. With C++20, CMake and Python 3:

export MOOLBASE_PREFIX="$PWD/moolbase-0.6.0-alpha.2-linux-x86_64"
cd moolbase-0.6.0-alpha.2-examples
cmake -S . -B build-showcase -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_PREFIX_PATH="$MOOLBASE_PREFIX"
cmake --build build-showcase -j2
python3 examples/customer_showcase/python_memory.py
python3 examples/customer_showcase/python_http.py \
  --server "$MOOLBASE_PREFIX/bin/graphenedb_server"

Memory correction: EU resolved → no operative answer → US resolved. The HTTP example also checks persisted evidence after restarting the server. Fixtures are synthetic; these are not customer case studies.

Complete install and integration guideGitHub release

The browser demo uses the actual engine with session-local files; refreshing starts fresh. Native examples persist to disk. Applications establish provenance, verification and retirement of stale copies. Prior reasoning state requires separate application persistence.

Developer and agent guide · Verification boundaries · Release notes