Skip to content

Gravity Field

The gravity field is the mass accumulation model that drives traversal re-ranking in Leliel. Every record in the store carries a scalar utility mass. Records with high mass are suppressed by the quantum walk without explicit exclusion: the walk's Born-rule probability distribution concentrates amplitude away from high-mass nodes naturally.

The analogy: traversals are light rays. Nodes are massive objects. High-mass (problematic) nodes bend the path. Traversal ordering emerges from the accumulated mass field rather than being hardcoded.


Three-component mass field

The effective mass used by the walk Hamiltonian has three contributing components, each with a different timescale and role:

Component Source Role
Utility mass REINFORCE feedback from signal quality Primary signal; accumulates on negative signal, decays on positive signal and via Hawking decay
Structural mass Wormhole edges via Fiedler eigenvector proximity Latent topology: ER=EPR bridges between structurally equivalent high-mass nodes
Semantic mass IDF feature similarity from extra_data field-value pairs Cold-start prior: biases walk seed toward semantically similar records before utility signal accumulates

Utility mass is the dominant term at steady state. At cold start (before traversal history accumulates), semantic mass provides the initial routing bias.

Structural mass operates via wormhole edge injection rather than as an additive term in the Hamiltonian diagonal. Two high-mass nodes that are Fiedler-proximate receive a wormhole edge in the walk snapshot, shortcutting their graph distance. This is the ER=EPR mechanism: records that are topologically equivalent (same Fiedler eigenvector component) may exhibit correlated behaviour and benefit from the shortcut.


REINFORCE feedback

Every time a record is ingested, the store applies an interim REINFORCE mass update:

Signal quality Mass delta Effect
High signal (near declared_upper_bound) Negative delta Mass decreases; record scores higher in walk results
Low signal (far below declared_upper_bound) Positive delta Mass increases; record scores lower in walk results

Callers can also push explicit REINFORCE signals via POST /api/v1/gravity/julia/reinforce:

Outcome Mass delta Use case
+1 Negative delta Explicit reward: this record was useful
-1 Positive delta Explicit penalty: this record was problematic

The REINFORCE update rule is policy-gradient weighted by the Born-rule amplitude at the record's position during the most recent walk: delta_M(v) = eta * |psi(v)|^2 * |outcome|. High-amplitude nodes receive stronger updates; low-amplitude nodes are updated weakly.


Hawking decay

Mass decays continuously according to the Hawking decay law:

alpha_H = ln(2) / 86400 seconds
mass(t) = mass(0) * exp(-alpha_H * elapsed_seconds)

Decay is applied lazily on each write event rather than via a background scheduler. The half-life is fixed at one day. Accumulated failure signal fades if a record is no longer associated with low-quality outcomes.


Schwarzschild threshold

The Schwarzschild threshold M_s is the mass above which a record is a black hole:

M_s = lambda_2(L) * log(1/epsilon) / (G * K)

Where lambda_2(L) is the Fiedler eigenvalue of the live graph Laplacian, epsilon is the amplitude suppression floor (default: 0.05), G is the lensing coupling constant (default: 1.0), and K is the Chebyshev degree (default: 3).

M_s is derived from the live graph topology. It is not a configurable constant. As the graph grows and topology shifts, M_s adjusts automatically. A record above M_s is not explicitly excluded from results; the walk's Born-rule probability distribution concentrates amplitude away from it so it falls to the bottom of the ranking.


Wormhole detection (ER=EPR)

After each ingest, the store caches the Fiedler eigenvector v2 of the graph Laplacian. For any two records both above M_s (both black holes), if their Fiedler components satisfy:

|v2[i] - v2[j]| < WORMHOLE_ALPHA * std(v2)

then a wormhole edge is injected between them in the walk snapshot at query time. The constant WORMHOLE_ALPHA = 0.2 controls the proximity threshold.

Wormhole edges encode the ER=EPR principle: black hole nodes that are structurally equivalent in the Laplacian embedding are connected by a latent edge. The walk can traverse this shortcut even though no explicit co-occurrence or co-failure edge exists between the two records.


Gravity field API

The gravity field endpoints expose the live mass index and graph health metrics. See API Reference for full endpoint documentation.

Endpoint Description
GET /api/v1/gravity/julia/black-holes Records above the Schwarzschild threshold
GET /api/v1/gravity/julia/field Full mass vector: all records and their current mass
GET /api/v1/gravity/julia/lensing-arcs Lensing arc deflection geometry per black hole
GET /api/v1/gravity/julia/stats Graph statistics: node count, edge count, M_s, spectral gap
GET /api/v1/gravity/mesh Live mesh health: SLEM, spectral gap, mixing time, certainty
GET /api/v1/gravity/mesh/history Append-only SLEM trend log from the analysis worker
POST /api/v1/gravity/julia/reinforce Explicit REINFORCE feedback: push +1 or -1 for a record

Persistence

Leliel persists the following state to DuckDB across restarts:

State Persisted Restored on warm start
All ingested records (columnar fields) Yes Yes
REINFORCE-learned utility mass per record Yes Yes
Field weight map (PUT /api/v1/config/field-weights) Yes Yes
Lensing arc geometry (black hole deflection angles) Yes Yes
extra_data blobs Yes Yes
In-memory factor graph topology (edges, co-occurrence) No Rebuilt from records on warm start
Semantic IDF index No Rebuilt from persisted extra_data on warm start
SLEM and Ricci cache No Recomputed by the analysis worker after restart

Warm start: on boot, the server reads all records and their accumulated mass from DuckDB and rebuilds the in-memory store before accepting traffic. The first analysis worker cycle after restart recomputes SLEM, Ricci bottlenecks, and mesh health.

Mass persistence: utility mass is written to DuckDB synchronously on each REINFORCE call and on each auto-REINFORCE triggered by list_records. Mass is not written to disk on every ingest to avoid write amplification; it is flushed at the next write event. If the server crashes between a mass update and a flush, the most recent REINFORCE deltas may be lost. Hawking decay is reapplied on the restored mass values at first query time after restart.

Configure the DuckDB file path with the DUCKDB_PATH environment variable. See Configuration Reference for details.


Lensing and over-fetch

The quantum walk fetches up to limit * 2 candidate records, evolves the wavefunction, re-ranks by Born-rule amplitude, and trims to the requested limit. High-mass records fall to the bottom of the ranking without being explicitly excluded. The over-fetch ensures the returned page is always full even when several high-mass records are present.

The quantum eraser penalises nodes the walk assigned near-zero amplitude. Each query accumulates a small eraser mass penalty on records that the walk suppressed, reinforcing the lensing effect over time without requiring explicit REINFORCE calls.