Applications that know, not guess.

• Groundedanswers walk real stored rows, not fuzzy vectors
• Traceableevery fact points back to where it came from
• Isolateda physically-separable schema per seat / per patient
• Validatedno unsupervised model writes — every fact passes the gate

The calls

Build the field, load a unit, then ask — over the /v1 API with the course account's key:

# 1 — grow the concept map for the subject (build the PLACE facts live in)
POST /v1/learn   Authorization: Bearer flk_…
  { "text": "/expand chemistry online" }
  ✓ ontology grown · concepts related, not memorized

# 2 — load a validated curriculum unit (extracted + gated + cited)
POST /v1/documents
  { "text": "Acetic acid is a weak acid with a pKa of 4.76 …",
    "source_ref": "CHEM-201 · Unit 4 · Acids & Bases" }
  ✓ stored · facts committed · validated

# 3 — a student asks; the aide answers from a real row
POST /v1/recall
  { "query": "is acetic acid a strong or weak acid, and its pKa?" }
  → "Acetic acid is a weak acid; its pKa is 4.76."
    ← traceable to CHEM-201 · Unit 4, not a paraphrase

Leans on: /expand to build the domain, ingest_document to load validated, cited material, and recall_memory's deterministic walk — it doesn't guess, it knows. Anything the curriculum didn't state comes back as a miss, so the aide never fills the gap with a plausible-sounding invention. (Illustrative course content — the point is the path: teach, load, recall.)

The calls

Two mentions captured, then a question — each request carries the student's own seat token:

# the agent captures what the student says, verbatim
POST /v1/memories   Authorization: Bearer flu_…  (this seat)
  { "text": "My Chem 201 final exam is May 3rd." }
  ✓ committed · event_date resolved → 2026-05-03

POST /v1/memories
  { "text": "I have a physics lab every Tuesday at 2pm." }
  ✓ committed · recurring lab captured

# later — the student asks; recall walks their own schema
POST /v1/recall
  { "query": "when is my Chem exam and when's my next lab?" }
  → "Your Chem 201 final is on May 3rd, and you have a
    physics lab every Tuesday at 2pm."  ← their rows only

Leans on: remember_facts with FaultLine's deterministic date/temporal capture, recall_memory for the grounded read-back, and per-seat schema isolation keyed off the connection token. Over MCP the same thing happens through OpenWebUI, which stamps the seat via the X-OpenWebUI-User-Id header. (A seat can be a person or an agent — same isolation either way.)

The calls

Mint an isolated patient seat, then address that patient's memory by the opaque handle — the app holds one elevated key; the clinician never does:

# 1 — mint an ISOLATED patient schema (opaque id — NEVER a name/DOB)
POST /v1/patients   Authorization: Bearer flk_…  (provision_patients)
  { "external_patient_id": "chart-9F3A2" }
  ✓ 201 · patient_id issued · schema provisioning · attributed to doctor

# 2 — record history INTO that patient (validated, addressed by handle)
POST /v1/memories   X-FaultLine-User-Id: <patient_id>
  { "text": "Patient reports a penicillin allergy; last A1C was 6.1%." }
  ✓ committed through the WGM gate · this patient's schema only

# 3 — the assistant recalls, traceably, in the clinical voice
POST /v1/recall   X-FaultLine-User-Id: <patient_id>
  { "query": "any drug allergies on record, and the last A1C?" }
  → "On record: a penicillin allergy. Most recent A1C: 6.1%."
    ← each item traces to a real row; nothing on record → it says so

Leans on: the clinical elevated lane (a schema per patient, fail-closed provisioning, opaque handles), the WGM write-gate, search_path isolation without public, the per-tenant encrypted BYO brain, deterministic traceable recall, and the clinical recall voice. Confidence here is traceability plus isolation, not a slogan — every answer resolves to a real, walled-off row. See the clinical lane on the Business page for governance and pricing.

• Bearer flk_account / control-plane key — the tenant & provisioning context
• Bearer flu_per-seat token — what a client connects with, scoped to that seat
• Server-derived tenanta caller can never address another seat's memory (BOLA-safe)
• Same result, either doorno memory logic in the client — the engine decides

The connection is the identity: an flk_ key is the account/upstream/control-plane credential (mint seat tokens, provision, account ops); an flu_ token is what a seat connects with to read and write its own memory. Want the deeper architecture — validated writes, the epistemic firewall, the temporal dual-clock? That's the Geek page and the Research deep-dive.