Home / Reasoning / ATLAS

The reasoning engine
for your data.

ATLAS holds your entire dataset as a living map of how everything connects, and answers the questions no single record can: how are these two things related, what else behaves like this, and what is almost certainly missing.

Pure C, separate process Reads your data, never rewrites it 4.1M relationships Loopback-only

Interactive · drive the reasoning engine

Four ways of reasoning,
over one map

Pick a mode, then click nodes in the graph. These are independent layers — one being unavailable never stops the others.

ATLAS console · graph loaded

asserted fact

Follow the links

Neighbourhoods, routes and clusters — the relationships you actually recorded, traversed directly.

learned from use

Learn what matters

Relationships strengthen as they are used, so retrieval ranks by what proves useful — with the reasoning it walked returned alongside.

labelled a prediction

Predict the missing link

Two independent methods — shared-neighbour scoring, and a learned representation of every record — proposed together and cross-checked.

yours to author

Apply your rules

Rules live as ordinary rows you can read, edit and delete — not buried in code. ATLAS also mines candidate rules and shows you the evidence for each.

🧭

Every conclusion shows its work

ATLAS does not just state a finding — it records the exact chain of relationships it followed to reach it, and files that alongside the finding in a tamper-evident ledger.

traceable, hop by hop

🚧

It never rewrites your data

ATLAS reads your knowledge base and writes only into two areas of its own — its rules and its conclusions. Point it at a separate machine and derived knowledge stays physically apart.

what it concludes can never corrupt what you recorded

🔮

A guess is never filed as a fact

Anything ATLAS predicts rather than observes is labelled a prediction wherever it appears, and is never written into your records. Only the rule engine commits anything, and only with provenance.

possibilities stay possibilities until you promote them

The questions it exists to answer

A database answers
“which rows match”

These are the questions that need the shape of the whole dataset, not a lookup.

“How are these two connected?”

The strongest defensible route between any two records, every hop named and weighted, with alternative routes ranked beneath it.

~180 ms across 4.1M relationships

“What are we probably missing?”

Relationships that should exist on the evidence but were never recorded — plus the duplicates entered under two names.

whole-graph duplicate sweep in ~3 s

“What does our data look like?”

The clusters your organisation actually forms, the hubs everything hangs off, and the records whose connections look unlike their peers.

clusters the whole graph in ~2.5 s

“What follows from what we know?”

Rules you write in plain terms — or that ATLAS finds itself — fired forward until nothing new follows, confidence combined.

rules mined from your data in ~2.6 s

The reasoning tiers

Each answers a
different kind of question

Learns a strength per association from how the graph is traversed; fixed-point Q16.16, with lazy decay on a logical clock. This is the layer that would let ATLAS learn from the questions people actually ask.

/atlas/activate · /atlas/all/stats

A bounded top-K sketch of co-activated neighbours per hot atom. Ranks by count − error, so the tier stays deliberately conservative rather than over-reporting.

Beam- and budget-bounded retrieval over the learned weights. Every result carries the edge it arrived by — which is what makes a ranking defensible rather than merely plausible.

/atlas/rank · /atlas/neighbors · /atlas/path · /atlas/explain

Symbolic: Adamic-Adar / resource-allocation over shared neighbours — always available. Latent: DistMult / ComplEx / RotatE embeddings, calibrated and warm-startable — only once trained. Proposed together and cross-checked.

/atlas/predict · /atlas/ensemble · /atlas/why · /atlas/embed/{train,predict,similar}

Verb-transition prefetch P(next predicate | current), TinyLFU admission, UCB1 plan selection.

/atlas/transitions

Bounded rule mining · forward chaining to a fixpoint with noisy-OR belief combination · label-propagation communities · MinHash equivalence induction · degree anomalies · temporal profiling.

/atlas/rules/mine · /atlas/derive · /atlas/communities · /atlas/similar · /atlas/anomalies · /atlas/temporal

“Healthy” means working, not merely running. A built-in self-test exercises one real query per tier against the data loaded right now. Each check reports pass only when the tier RETURNED something, empty when it ran and legitimately had nothing to return, skip for an unmet prerequisite, and fail for a tier that cannot legitimately be empty.

How it fits

One extra process
beside your database

Nothing to migrate, nothing to re-model, no change to how data is written.

Your database

AtomicDB, unchanged. ATLAS only ever reads it — a 94 MB hierarchy snapshot, reloaded on mtime change.

The map, in memory

An in-memory CSR graph: 314,291 atoms, 4,095,046 edges, 21 predicates. Loaded once at start.

Ask it anything

From the ATLAS console (nine tabs), or from Ask in plain language — or let the local model call ATLAS as five tools and investigate for itself.

Conclusions filed

Into its own two knowledge areas — ATLAS_RULES and ATLAS_FACTS — each row carrying the provenance path it walked, written through the ordinary authenticated path so it is WORM-ledgered like any ingested record.

The ATLAS console

Derived facts, with provenance

The bounds that shape every answer

Bounded everywhere,
on purpose

ATLAS is an inspection surface, not a high-concurrency service. Each bound is reported in the reply that hits it.

Node listing — 4,000 per reply

Of 314,291. Pass ?q= to search the whole graph server-side; total reports the true size.

Neighbourhood — 250 atoms

Every top hub fills it at depth 0, so the reply carries capped and reached_depth.

Response ceiling — 1 MiB

A latched flag replaces the whole body with a clean error rather than emitting torn JSON.

Op log — 256 entries

One ring serves both the audit trail and the latency roll-up, so they cannot disagree.

Training the latent tier is the one expensive operation — about 48 s per epoch on this graph, and it runs on a worker thread off the accept loop, so the server keeps answering. Measured during a real train: 36 concurrent health polls returned in 58 ms or less. While it runs, the latent endpoints answer “training in progress”; everything else is unaffected.

What's next — designed, not yet shipped

Learning from real questions

ATLAS already strengthens a relationship each time it is used. Feeding every question answered in Ask back into that signal would make the map learn what your organisation actually asks about — so the connections your people rely on rank above the ones that merely exist.

Exploring the busiest records

The visual map is bounded so one query cannot serialise the whole graph. For the most connected records that bound is reached immediately, so those views are honest but partial today; representative sampling will open them up.

What still needs fixing

Stated, not hidden

One epoch costs ~48 s on this graph and the default wall-clock budget is 45 s, so a default train completes zero epochs and produces no model. It now says so plainly instead of flagging an untrained model as trained — but the default should fit the graph, so the latent tier is reachable without the caller having to know to raise max_seconds.

Every top hub saturates it at depth 0, so the depth control does nothing on exactly the nodes most worth exploring. A useful hub view needs sampling or pagination, not a larger fixed budget.

Deliberate — loopback-only, and no CORS header — but it means any local process can reach the state-changing endpoints.

Pure C, no third-party runtime, loopback-only. Everything above except the shaded panel is implemented and running today.

Ask it in plain language → Send a graph problem to a QPU

The reasoning enginefor your data.

Four ways of reasoning,over one map