Most retrieval systems search an index. DMM doesn't have one.

When you call storeDoc, your document is encoded directly into high-dimensional associative memory — no index built, no embeddings generated, no GPU touched.

searchDoc doesn't look anything up. It reconstructs the pattern from memory. That's why retrieval time doesn't grow with dataset size.

At 65 milliseconds across multi-million encrypted records, DMM operates at the speed of inference. That means memory retrieval stops being a bottleneck and becomes a live component of your AI pipeline — called in real time, mid-inference, as your model needs it. Not pre-loaded. Not cached. 

Retrieved on demand, encrypted end-to-end, from wherever the data lives.

The API is standard form POST over HTTPS, JSON responses, any language, any stack.

But the architecture opens up something more interesting — the ability to span multiple silos of knowledge in a single retrieval pass. Clinical records, legal documents, financial data, operational logs — different datasets, same API, sub-100ms response.

The complexity lives in your application. DMM just makes sure the memory is always there when you need it.

# Store a document
curl -X POST https://your-dmm-host/v1/storeDoc \
  -F "tqnnAPIKEY=your-key" \
  -F "tqnnAPISECRET=your-secret" \
  -F "dataset=my-bucket" \
  -F "filereference=url://docs/patient-001.pdf" \
  -F "pattern={\"title\":\"Patient Admission\",\"year\":2024}"


# Search by association
curl -X POST https://your-dmm-host/v1/searchDoc \
  -F "tqnnAPIKEY=your-key" \
  -F "tqnnAPISECRET=your-secret" \
  -F "dataset=my-bucket" \
  -F "pattern=cardiac symptoms admission"


# Response
{
  "function": "searchDoc",
  "tqnn_response": "MATCH",
  "matches": 1,
  "misses": 0,
  "time_used": 0.0657,
  "filelist": "records_0001.jsonl::line736::REC-00010736",
  "energy": {
    "energy_usage_kWh": "0.0000001278",
    "carbon_emissions_mg": "0.0297816530"
  }
}