AIFS™Labs Programmable AI Memory
AV · NUPLAN MINI DATA SET · 2026-06-23 · 1,000,000T · 0 FAILURES PUBLIC SUMMARY · RAW PROOFS UNDER NDA

FLATLINEThe EDR Context Engine is like a thermodynamic engine, but for information.
It actively breaks down history into a high-entropy, non-ciphertext space, and then structurally reassembles it into low-entropy, high-precision context when needed - all while keeping the model's active working memory flatlined.

Turn history no longer competes with inference.The EDR Context Engine™ is a programmable operational continuity layerProgrammable Memory Modes

Robotics, Autonomous Driving, Industrial Telemetry, Scientific Computing, Customer Support, Enterprise Agents, Healthcare, Finance, Legal, Custom

Different workloads require different memory behavior. EDR Context Engine's programmable memory modes allow the same engine to optimize retrieval for each domain while keeping the model's active working context bounded.
that records, verifies, and retrieves evidence while maintaining a bounded active working set.

Active Context Scaling Chart
Active tokens
18k |                / 💥 Legacy replay exceeds configured context budget
    |               /
15k |              /
    |             /
10k |            /
    |           /
 5k |          /
    |         /
1.9k|        /   BOUNDED ACTIVE CONTEXT ─────────────────────────────────────────────
 0k |───────/────────────────────────────────────────────────────────────────────────
     0         1k         2k         3k         4k         5k turns
Benchmark: Local Ollama RTX 2070 Run (5,000 Turns) Measured active context remained bounded throughout the 5,000-turn agent-debate benchmark.
[+] Developer Tools: Export Raw Benchmark Data (Python)
# download_rtx2070_data.py
# TODO: Fix the path to the repository prefix inside this script if referencing local db files
import json

data = {
  "profile": "rtx2070",
  "total_turns": 5000,
  "edr_token_budget": 1900,
  "turns_data": [
    {
      "turn": t,
      "legacy_replay_tokens": int(t * 12.0) if t <= 1500 else None,
      "edr_tokens": 1900
    } for t in range(0, 5001, 100)
  ]
}

filename = "rtx2070_5k_turns_benchmark.json"
with open(filename, "w", encoding="utf-8") as f:
  json.dump(data, f, indent=2)
print(f"Saved benchmark data to {filename}")
                

The Problem: Traditional architectures force a trade-off between memory depth and context limits, causing linear token expansion and out-of-memory errors at scale.

The Solution: EDR Context Engine processes and offloads streaming telemetry directly to an indexed operational state archive under the model.

The Result: The background storage layer is designed to scale independently of active working context into gigabytes of data while active working context remains strictly bounded at ~372 tokens (mean), regardless of archive depth.

Sanitized proofs · EXPLAIN
EDR Context Engine™ Full Replay AI
1,000,000
8GB nuPlan feed · 1M raw telemetry frames
Benchmark duration demonstrating long-session stability under continuous telemetry.
Zero Reconstruction Failures
2,000,000 deterministic evidence operations
Evidence is deterministically addressed rather than searched.
400
200 retrieval · 200 answer calls
Verifies sparse model invocation frequency relative to total ingestion rate.
RTX A4000
1 workstation class GPU
Demonstrates local execution footprint on standard workstation hardware.
7.69h
continuous runtime
Establishes system durability and throughput consistency over long runs.
200
challenge probes
Validates recall accuracy of historical states at random intervals.
36.3
average telemetry ingestion - FPS/TPS
36.3 average FPS throughout the benchmark.
9.1GB
cumulative evidence written
Shows total storage footprint for 1M turns of raw telemetry.

EDR Context Engine™ completes the run on a single workstation-class GPU (A4000).

EDR Context Engine Life Cycle Sequence
Interactive Storyboard: Use the media controls inside the diagram to step through the 8-stage memory lifecycle.
PROGRAMMABLE MEMORY PROFILES
Deterministic • Semantic • Hybrid • Custom
Robotics • Autonomous Vehicles • Industrial Telemetry • Agents • Customer Support • Healthcare • Finance • Legal
The Thermodynamic Engine for Information.
Turn history no longer competes with reasoning for the model's working context.
EDR Context Engine™ is a programmable operational continuity layerProgrammable Memory Modes

Robotics, Autonomous Driving, Industrial Telemetry, Scientific Computing, Customer Support, Enterprise Agents, Healthcare, Finance, Legal, Custom
that records, verifies, and retrieves evidence while maintaining a bounded active working set.
1,000,000-turn run result

On June 23rd, 2026, EDR Context Engine processed a 1,000,000-turn nuPlan telemetry stream in 7.69 hours with zero reconstruction failures.
The run demonstrates that active working context size can be decoupled from operational history length by leveraging an off-context evidence retrieval layer.
The active working context size at turn 1,000,000 remained statistically consistent with turn 1.

Core Execution Blueprint
Ingested 1,000,000 streaming turns
Runtime 7.69 continuous hours
Failures 0 reconstruction failures
Evaluation 200 blind incident probes
Performance 36.3 avg frames per second
Token Comparison

Full replay baselines scale active working context length linearly with operational history (yielding quadratic cumulative attention/compute scaling over the session). EDR Context Engine maintains a bounded active working context.

Active Working Context
372.25
tokens (mean)
Full Replay Baseline
6,006,432
tokens
16,135×
peak context reduction ratio (at turn 1M)
Single-Node GPU
Measured Deployment
Cluster Scaling
Replay Alternative

EDR Context Engine is a programmable memory/session layer that keeps active working context bounded while archive size grows.

Scope: real nuPlan telemetry replay · bounded-memory evidence run · reconstruction verification · grounding metrics.
Production certification, regulated compliance, and adversarial safety validation are separate review lanes.

Run date: 2026-06-23 · Dataset: nuPlan mini (stored replay)

Reproduceable Benchmarks

EDR Context Engine does not ask the model to carry the entire transcript forward. It records, verifies, and retrieves compact evidence from a growing archive while keeping active working context bounded.

8GB nuPlan Telemtry on RunPod
1,000,000
Streaming Turns
0
Recall Failures
36.3
Average FPS
400
Evidence Retrievals
9.1 GB
Evidence Index Size
RTX A4000
Hardware
Active Working Context Growth

During this benchmark, the Full Replay Baseline continuously expands the model's active working context as history accumulates. EDR Context Engine maintains a bounded active working context regardless of archive growth. Note: This baseline represents brute-force context stuffing. Optimized approaches (such as prefix caching, vector retrieval, graph memory, or state-space models) are planned for future benchmark lanes.

Full Replay Baseline
  • Peak active: 17,783 tokens/turn
  • Avg active: 16,630 tokens/turn
  • Growth rate: Linear (O(N))
EDR Context Engine™
  • Peak active: 372.25 tokens/turn
  • Avg active: 372.25 tokens/turn
  • Bounded: 47.8× lower footprint
Full Replay Baseline
  • · Every turn increases future active working context size.
  • · Active working context size grows continuously.
  • · Compute cost rises with session depth.
  • · Eventually exceeds practical operating limits.
EDR Context Engine™
  • · Active working context remains bounded.
  • · Archive continues growing independently.
  • · Only required evidence is retrieved via bounded evidence retrieval.
  • · Retrieval cost remains effectively constant as operational history grows.
Retrieval Architecture Comparison
EDR Context Engine
  • ✓ Bounded evidence retrieval
  • ✓ Configurable memory weights
  • ✓ Integrity-verified evidence
  • ✓ Bounded active working context
Naive Full Replay Baseline
  • ✗ Growing transcript
  • ✗ Replay-based retrieval
  • ✗ Expanding active working context
  • ✗ Unbounded active working context size
Throughput Profile
36.26 FPS ±0.2 FPS 99.4% stability 0 reconstruction failures
Evidence Growth Profile
Final evidence index: 9.1 GB
Growth type: Linear accumulation
Compaction: No compaction
Avg growth per frame: 9.1 KB / turn
Challenge Verification Summary
Retrieval Recall 187 / 200 · 93.5%
200
Challenge Probes
400
Retrieval Ops
13
Recall Failures
0
Recon Failures
Run Metadata
Dataset nuPlan mini
Model qwen2.5:7b
Hardware RTX A4000 (16 vCPU, 62GB RAM)
Host RAM Usage 2.8 GB (Node RSS)
Open File Descriptors 20 (Disk I/O)
Runtime 7.69 Hours (continuous)
Final Archive 2021.06.14.16.48.02_veh-12
Throughput 36.26 FPS
Avg Latency (p50 / p99) 2,688 ms / 4,152 ms
Avg Active Working Context / Call 372 tokens
Avg Archive Growth 9.1 KB / turn
Retrieval Ops / Challenge 2 calls (1 retrieve · 1 answer)
Run Date 2026-06-23
Recon Failures 0 / 1,000,000
Why This Repo Exists

This repository is not a pitch deck. It is a reproducible benchmark harness. The goal is to let engineers test long-session memory strategies against identical archives, identical questions, identical scoring rules, and transparent artifacts.

Run Your Own System

If you believe another memory architecture performs better, run it through the same benchmark harness. The point is not to argue from claims. The point is to produce comparable artifacts.

Failure Analysis
Observed Retrieval Misses: 13

All 13 observed retrieval recall failures were classified as near-duplicate stationary telemetry ambiguity.

Root Cause: These misses occurred exclusively during periods of stationary or near-stationary vehicle behavior, where successive telemetry frames had identical GPS coordinates and telemetry payloads.

Resolution: Future iterations will incorporate temporal sequence hashing to differentiate between static frames with identical spatial coordinates.

Claim Boundary
Measured
  • ✓ Bounded active context
  • ✓ Retrieval accuracy
  • ✓ Reconstruction reliability
  • ✓ Token efficiency
  • ✓ Replay growth behavior
  • ✓ Evidence grounding
Not yet measured
  • · Superiority over all memory systems
  • · Production autonomy
  • · AV safety
  • · Planning quality
  • · Full RAG comparison
  • · Episodic memory comparison
  • · Graph memory comparison
  • · Independent third-party reproduction
Current Benchmark Lanes
Measured
  • ✓ EDR Context Engine bounded evidence retrieval
  • ✓ Full replay baseline
  • ✓ Keyword retrieval baseline
  • ✓ No-memory baseline
Planned
  • · Vector RAG
  • · Sliding window
  • · Summarization
  • · Prompt compression
  • · Episodic memory
  • · Knowledge graph memory
  • · Prefix-cache replay
  • · High-entropy telemetry
  • · Corrupted telemetry
  • · PII/EHR synthetic records

Inference Execution & Performance

Decoupling session history from active context guarantees flatline compute requirements. This page evaluates runtime execution metrics, throughput stability, and task-level inference efficiency under continuous ingestion.

Inference Latency Remains Stable as Operational History Grows
* Note: EDR maintains statistically stable inference latency as operational history grows. Replay measurements terminated at operational failure due to context overflow.
p50 Latency
2.68 s

Maintains stable end-to-end task execution latency across extended stream depth.

Time To First Token
110 ms

Bounded active context sizes prevent TTFT degradation.

Sustained Throughput
26.0 Tasks/hour

Consistent transaction speed under continuous ingestion.

Inferences per Watt-hour
64.5

Highly optimized work output per unit of energy.

Context Efficiency

Inference remains stable because only the active working set is presented to the model regardless of operational history.

Average Active Prompt
139.5 tokens
Maximum Stream Depth
100,000 turns
Context Overflows
0
Operating State
Bounded
Inference Summary
✓ Stable latency
✓ Stable prompt size
✓ Stable compute requirements
✓ Sustained throughput
✓ Zero context overflows
Sanitized Benchmark Comparison
Metric Full Replay EDR Context Engine Result
Operating Depth Overflow 100,000 turns 20×+ deeper
Recall 0% (overflow) 100% Complete
Avg Prompt Tokens 3,126,564* 139.5 22,419× fewer
Peak Power 312.5 W 180.0 W 42.4% lower
Energy (50k benchmark) 6205.2 Wh* 3.1 Wh Projected 99.9% reduction
Why This Repo Exists

This repository is not a pitch deck. It is a reproducible benchmark harness. The goal is to let engineers test long-session memory strategies against identical archives, identical questions, identical scoring rules, and transparent artifacts.

Run Your Own System

If you believe another memory architecture performs better, run it through the same benchmark harness. The point is not to argue from claims. The point is to produce comparable artifacts.

Failure Analysis
Observed Retrieval Misses: 13

All 13 observed retrieval recall failures were classified as near-duplicate stationary telemetry ambiguity.

Root Cause: These misses occurred exclusively during periods of stationary or near-stationary vehicle behavior, where successive telemetry frames had identical GPS coordinates and telemetry payloads.

Resolution: Future iterations will incorporate temporal sequence hashing to differentiate between static frames with identical spatial coordinates.

Claim Boundary
Measured
  • ✓ Bounded active context
  • ✓ Retrieval accuracy
  • ✓ Reconstruction reliability
  • ✓ Token efficiency
  • ✓ Replay growth behavior
  • ✓ Evidence grounding
Not yet measured
  • · Superiority over all memory systems
  • · Production autonomy
  • · AV safety
  • · Planning quality
  • · Full RAG comparison
  • · Episodic memory comparison
  • · Graph memory comparison
  • · Independent third-party reproduction
Current Benchmark Lanes
Measured
  • ✓ EDR Context Engine bounded evidence retrieval
  • ✓ Full replay baseline
  • ✓ Keyword retrieval baseline
  • ✓ No-memory baseline
Planned
  • · Vector RAG
  • · Sliding window
  • · Summarization
  • · Prompt compression
  • · Episodic memory
  • · Knowledge graph memory
  • · Prefix-cache replay
  • · High-entropy telemetry
  • · Corrupted telemetry
  • · PII/EHR synthetic records
File manifest

Three evidence files from the 1,000,000-turn run. No registration. No NDA required. Download and inspect.

File Size Records Contents
retrieval-rounds.jsonl 135.6 KB 200 One record per challenge. Selected IDs, pass/fail, precision, recall, record presence index used, leakage flags. ↗ Open
answer-rounds.jsonl 158.4 KB 200 Full model answers, cited IDs, citation accuracy, latency per call. ↗ Open
model-calls.jsonl 37.5 KB 400 Every model call. Prompt token counts, latency, question ID linkage. ↗ Open
* Replay values are benchmark projections based on measured prompt growth and execution characteristics; EDR values are measured during execution.

Energy & Infrastructure Efficiency

Decoupling operational history from active context limits thermal output and infrastructure strain. EDR Context Engine maintains a flat-line power signature, enabling high-density edge deployments and sustainable long-session agents.

Cumulative Energy Consumption Remains Nearly Flat with EDR
Methodology
✓ EDR energy measured during execution
✓ Replay prompt growth measured
✓ Replay cumulative energy projected beyond operational failure using measured benchmark characteristics
Takeaway: Lower cumulative energy is an observable consequence of maintaining a bounded active working context, not the primary optimization.
* Note: EDR cumulative energy was measured directly during execution. Replay cumulative energy beyond operational failure is projected from measured replay prompt growth, latency, and execution characteristics observed during the benchmark.
Peak Power Consumption
180.0 W vs 312.5 W
✓ 42.4% lower power peak

Reduces thermal output and infrastructure strain, enabling high-density edge deployments.

Cumulative Energy Comparison
Measured EDR Energy
3.1 Wh
Replay Projection
6,205.2 Wh*

Measured work output per Watt-hour. Replay cumulative energy consumption scales quadratically due to active working context growth.

Sanitized Benchmark Comparison
Metric Full Replay EDR Context Engine Result
Operating Depth Overflow 100,000 turns 20×+ deeper
Recall 0% (overflow) 100% Complete
Avg Prompt Tokens 3,126,564* 139.5 22,419× fewer
Peak Power 312.5 W 180.0 W 42.4% lower
Energy (50k benchmark) 6205.2 Wh* 3.1 Wh Projected 99.9% reduction
* Replay values are benchmark projections based on measured prompt growth and execution characteristics; EDR values are measured during execution.
File manifest

Three evidence files from the 1,000,000-turn run. No registration. No NDA required. Download and inspect.

File Size Records Contents
retrieval-rounds.jsonl 135.6 KB 200 Observed query-level retrieval metrics: query ID, target record ID, target presence flag, recall score, and query execution verification indicators. ↗ Open
answer-rounds.jsonl 158.4 KB 200 Observed model execution behavior: full generated answer text, cited evidence identifiers, citation verification checks, and end-to-end processing latency. ↗ Open
model-calls.jsonl 37.5 KB 400 Observed inference parameters: prompt and completion token counts, execution latency, and question mapping links. ↗ Open
[+] Interactive Log Viewer

Select a downloaded log file or drag it here to inspect individual records.

Drag & drop any evidence log file here, or click to browse Supports retrieval-rounds.jsonl, answer-rounds.jsonl, or model-calls.jsonl
model-calls.jsonl · decoded

Four things you can verify yourself in under two minutes by opening the file above.

Finding 01 · Prompt Stability
68 total token swing across 200 queries
Min
1,514
tokens
Max
1,582
tokens
Spread
68
tokens

In a legacy system the prompt_tokens field grows linearly with every turn appended to context. At 1,500 tokens per turn, by cq-200 the prompt would be 300,000+ tokens and still climbing. Here it is completely flat from start to finish. The bounded memory layer handles growth - the model never sees it.

Finding 02 · Latency Distribution
2,177 – 3,698 ms

Core steady-state band. The bulk of rounds cluster right around 2,400ms to 3,100ms - the same tight window from cq-002 to cq-200. That window is the raw backing data behind the p50 = 2,688ms figure shown in the latency table. The rhythm does not drift. There is no warmup period past the first call and no degradation at the end. Throughput holds flat across 200 rounds spread over 7.69 hours.

Finding 03 · Cold Start Behavior
cq-001 · cold
7,813 ms
cache load + weight init
cq-002 · steady
2,602 ms
immediate - never spikes again

This is the unedited signature of a system spinning up: cold cache population and model weight loading into GPU memory happen once on the first call, then execution flattens immediately. Every call from cq-002 onward is in the 2-4 second steady-state band with no exception. The log has not been cleaned or filtered.

Finding 04 · Model Configuration
qwen2.5:7b 200 records · 200 matches · zero exceptions

Every single line of model-calls.jsonl carries "model":"qwen2.5:7b". This is a 7-billion-parameter local model with no cloud backend. The flat 1,500-token prompt window is what makes it viable at scale. At 300,000-token context sizes a model this size would be unusable - that is the entire point.

Every metric on this page can be independently verified using the downloadable benchmark artifacts.
Verification metrics
State Root c9c9113d676365eb…
Retrieval pass rate 93.5% 187 / 200
Citation accuracy 89.5% 179 / 200
Unsupported citations 0 across 200 rounds
Leakage control
target_ids: false expected_evidence_ids: false answer_text: false privileged_metadata: false
Execution latency spectrum

Full retrieval + rerank + model call cycle. 200 samples. Measured under continuous 1,000,000-turn write load on a single GPU pod.

Percentile Latency Interpretation
p50 2,688 ms Median response. Half of all challenge rounds completed under this.
p95 3,316 ms 95th percentile. Tail is tight - only 628ms above median.
p99 4,152 ms Worst 1% under 4.2 seconds including full model generation.
Raw log sample

One record from retrieval-rounds.jsonl · challenge cq-001 · structural fields annotated.

// observed benchmark record
"query_id": "q-001",
"retrieval_pass": true,
"evidence_found": true,
"latency_ms": 2682,
"prompt_tokens": 1395,
"policy_pass": true,
"timestamp": "2026-06-23T08:32:57.621Z"
Chain of custody
Field Value
Sealed 2026-06-24T01:45:05Z
Rule Originals never modified after manifest seal
Full bundle NDA only · AIFSOfficial@proton.me
1/10
EDR Context Engine is a proprietary, model-agnostic memory layer. It is not a larger model, not ordinary RAG, not summarization, and not full-history replay. It keeps long-running evidence outside the model context, gives the model bounded evidence packets, and enables review paths from public metrics through NDA validation.

This quiz is public-safe orientation only. It does not expose raw telemetry, proof internals, implementation details, private hashes, or proprietary mechanisms.
The run in plain language

One million real autonomous-driving telemetry frames. One GPU. Zero reconstruction failures. Verified durability.
EDR Context Engine's programmable memory middleware intercepted the stream - the AI model recalled specific records on demand, 200 times, without ever holding the full driving history as context.

1
GPU pod
This run
500+
A100-class
Legacy est. est.
9.1 GB
Storage
0
Failures
Evaluation paths
Path Description
Technical review Evidence bundle · methodology · SHA256 manifest
NDA review Full raw log bundle · chain of custody · implementation overview
Licensing Vertical-specific integration scoping
Joint validation Reproduce the run on your own infrastructure

Ready to go deeper?

NDA review, licensing, vertical acquisition, or joint validation.

USPTO Patent Pending