HydraDG is a governed memory and context engine built only on HydraDB for Hack Hydra 2026 — Track 03: Memory + Context Retrieval. It preserves evolving state, provenance, contradictions, supersession, recovery, null results, and claim boundaries as an inspectable graph instead of silently overwriting context.
Demo video: https://youtu.be/7EDb6q-loPA
Submission track: Track 03 — Memory + Context Retrieval
Graph backend: HydraDB only
If you have three minutes:
- Watch the demo video above.
- Read
SUBMISSION.mdfor the bounded submission claim. - Use
HOW_TO.mdordocs/JUDGE_REPRODUCE_FROM_SCRATCH.mdto rebuild the HydraDB graph and website on a clean machine. - Inspect the canonical public FCG snapshot in
custody/graph/live/. - Inspect
docs/COMPONENT_MAP.mdfor component purpose, inputs, outputs, and claim boundaries. - Inspect
docs/FCO_FCG_SOURCE_LINEAGE.mdfor versioned preprint/package/hash/signature boundaries.
There is no Neo4j fallback in the judge application. The executable graph path is:
HydraDG application -> HydraDB HTTP graph API -> isolated HydraDB namespace
Long-lived AI memory systems can flatten or overwrite changing context. Once facts are updated or contradicted, it becomes difficult to determine:
- what is current;
- what was believed before;
- which source supports each state;
- where a stale or poisoned fact first entered a dependency chain;
- whether a contradiction was superseded or merely hidden;
- whether null and negative experimental results were preserved.
HydraDG makes those transitions explicit and queryable.
- HydraDB graph/query projection for temporal state, provenance, contradiction, supersession, and evidence-path traversal.
- Fractal Custody Objects (FCOs) and a Fractal Custody Graph (FCG) for source -> transformation -> evidence -> claim -> artifact lineage.
- 4D Context Iceberg / FCG visualization using a browser canvas plus time controls.
- Reference -> Poison -> Antidote state transitions that preserve prior and contradictory states rather than deleting them.
- Track 03 LongMemEval-S full500 retrieval evaluation with explicit retention of null/negative outcomes.
- Knowledge Base linking project concepts and mathematical lineage to evidence and claim ceilings.
- Reproduction bundle containing the website source, canonical FCG JSONL, HydraDB projection/import tooling, environment template, custody receipts, and security gates.
HydraDB is the queryable graph projection layer used to traverse governed longitudinal state. Representative relationships include:
Session -> NEXT/PREV -> Session
Session -> ASSERTS -> Fact
Fact -> DERIVED_FROM -> Session
Fact -> ABOUT -> Entity
Fact -> SUPERSEDED_BY -> Fact
Fact -> CONTRADICTS -> Fact
The FCO/FCG layer preserves canonical identity, provenance, evidence class, and claim boundaries. HydraDB is the operational graph/query backend for the submission.
Judge-facing configuration is under:
apps/hydradg-web/.env.example
apps/hydradg-web/lib/graph.ts
apps/hydradg-web/package.json
apps/hydradg-web/package-lock.json
Those files are intended to contain the HydraDB path only.
Portable reconstruction inputs:
apps/hydradg-web/ complete Next.js / React website source
apps/hydradg-web/.env.example HydraDB environment template
apps/hydradg-web/package-lock.json pinned web dependency resolution
custody/graph/live/nodes.jsonl canonical public FCG nodes
custody/graph/live/edges.jsonl canonical public FCG edges
scripts/project_fcg_snapshot_to_hydradb.py
deterministic FCG -> HydraDB importer
scripts/project_website_knowledge_to_hydradb.py
knowledge-FCO projection helper
HOW_TO.md judge-oriented setup path
docs/JUDGE_REPRODUCE_FROM_SCRATCH.md
clean-machine reconstruction guide
HYDRADB_DATA.md graph/data specification
.github/workflows/gitleaks-release.yml
fail-closed full-history secret scan
The HydraDB state is distributed in portable canonical form—the graph node/edge snapshot plus deterministic projection tooling—rather than as an opaque machine-specific database directory. A judge can create a fresh isolated HydraDB namespace, import the snapshot, and verify node/edge counts plus the expected FCG-root readback.
git clone https://github.com/biobitworks/hydradg.git
cd hydradg/apps/hydradg-web
cp .env.example .env.local
npm ci
npm run typecheck
npm run build
npm run start -- -p 3012For the HydraDB-backed reconstruction, configure the isolated HydraDB namespace first using docs/JUDGE_REPRODUCE_FROM_SCRATCH.md.
Executed Track 03 experiment root used as a readback canary:
experiment:fa170ab51cdfba46f9a24979c9be9b90fdc4ccedcdb292f313aa4439a92b08d8
The importer at scripts/project_fcg_snapshot_to_hydradb.py validates the JSONL, writes only to an isolated hydradg-* namespace, performs readback count checks, and verifies the expected root is present.
/
/judge
/track03
/graph
/knowledge
/how-to
/eligibility
/backup/hydradg.html
The static fallback is presentation-only and must not be interpreted as a live HydraDB surface.
LongMemEval-S full500:
- 500 total cases
- 23,867 sessions
- 4,776 entities
- 3,506 facts
- 470 scored cases in the historical K=5 analysis; 30 abstentions excluded
Historical K=5 retrieval results:
| Route | Hit@5 | Recall@5 | Interpretation |
|---|---|---|---|
| A — reference/flat | 0.9638 | 0.9066 | reference baseline |
| B | 0.9468 | 0.8538 | no positive Hit@5 advantage |
| C | 0.9468 | 0.8526 | no positive Hit@5 advantage |
| D | 0.9447 | 0.8460 | no positive Hit@5 advantage |
Submission claim: the completed K=5 retrieval ablation did not establish a positive B/C/D Hit@5 advantage over the reference route. HydraDG retains that null/negative result in the same custody graph rather than replacing it with a preferred result.
Hit@K and Recall@K are retrieval metrics. They are not end-to-end QA accuracy.
HydraDG uses an application-defined, dimensionless information-state diagnostic G* and reference-relative Delta G*.
The information-theoretic Gibbs/free-energy analogy is linked to:
Enßlin & Weig (2010) — Inference with minimal Gibbs free energy in information field theory, Physical Review E 82, 051112, DOI 10.1103/PhysRevE.82.051112.
HydraDG's G* is not physical Gibbs free energy, is not measured in joules or kcal/mol, and lower G* does not automatically imply better Hit@K, Recall@K, or QA performance.
Cloud Drift is separately derived from Jensen-Shannon divergence and should not be interpreted as accuracy.
The project name also supports a biological metaphor grounded in the freshwater Hydra polyp: tentacles around the mouth/hypostome, a persistent body column, lateral budding, regeneration after injury, and a basal disc anchoring the organism.
evidence memory provenance contradiction
\ | | /
\ \ | / | / /
\ \ | / | / /
\ \ | / | / /
\ \ | / | / /
\ .-( )-. | / /
\ / MOUTH \_________|___/ /
\/HYPOSTOME\ ___/
/\____│____/\
│
╭──────┴──────╮
SENESCENCE / DRIFT │ BODY │ MAINTENANCE
ΔG* > 0 ──────────► │ COLUMN │ ◄── ΔG* ≈ 0
Cloud Drift ↑ │ identity │
│ + custody │
│ o────┼──╮
│ / BUD │ │ REJUVENATION
│ (______) │ repair / successor
│ └─────┘
╰──────┬──────╯
│
______│______
/ BASAL DISC \
/_______________\
CUSTODY ROOT
reference → divergence / poison → repair / antidote → persistence
The intended claim is not that HydraDG is literally immortal or that G* is organismal thermodynamics. The metaphor is that persistence comes from detecting divergence, retaining the damaged/history state, regenerating a valid current state, and continuing without breaking custody.
The expanded text figure, biological mapping, G* boundary, and claim ceiling are in docs/IMMORTAL_HYDRA_TEXT_FIGURE.md.
FCO = Fractal Custody Object.
FCG = Fractal Custody Graph.
Material source, transformation, derived-evidence, claim, and artifact relationships are kept explicitly separate where the project custody model applies. Public-safe custody receipts are under custody/.
Publication/package identities are versioned and typed; a DOI, PDF SHA-256, package SHA-256, paper_cid, FCG root, signature, and Merkle/MMR root must not be collapsed into one generic "preprint hash." See docs/FCO_FCG_SOURCE_LINEAGE.md.
A hash does not imply a signature. A signature does not imply a Merkle/MMR commitment. Neither implies scientific verification unless the corresponding operation and evidence exist.
Before publication, the exact judge commit must pass:
gitleaks git --redact=100 --no-banner .The fail-closed workflow is:
.github/workflows/gitleaks-release.yml
It scans complete Git history and fails on any finding. A historical or partial scan is not enough to call the final repository clean.
apps/hydradg-web/— website and API sourceHydraDG_DaisyTrain_v0.3.7/— Track 03 evaluation/reproduction toolingarchive/— historical plans, intermediate DaisyTrain packages, and past evaluation runscustody/— public-safe FCO/FCG and verification receiptscustody/graph/live/— canonical public graph snapshotdocs/— architecture, component, reproduction, source-lineage, and claim-boundary documentationschemas/— state/data schemasscripts/— HydraDB projection, verification, release, and reproduction toolingSUBMISSION.md— Hack Hydra submission scope
| Category | Licensing Scope |
|---|---|
| HydraDG software / website / scripts | Apache License, Version 2.0 (LICENSE) |
| FCO/FCG research publications + designated Byron P. Lee / Biobitworks research content | CC BY-NC-ND 4.0 (LICENSING.md) |
Earlier FCO/FCG CC BY 4.0 metadata |
Superseded metadata error; historical custody evidence only, not a licensing exception (docs/FCO_FCG_SOURCE_LINEAGE.md) |
| HydraDB | Upstream HydraDB license |
| LongMemEval / other datasets | Respective upstream dataset licenses |
| External papers / templates / APIs | Respective upstream rights |
See LICENSING.md, docs/FCO_FCG_SOURCE_LINEAGE.md, and THIRD_PARTY_NOTICES.md for scope, publication identity, supersession treatment, and third-party attribution.