RecursiveDB

Your experience database, compacting into a model you own.

RecursiveDB is the learning plane of your Private Inference Cloud. Every request through the Gateway is captured into your tenant's experience database: the context, the action taken, the alternatives, and what happened next. That experience compacts upward through four tiers, and each tier is a form your model can take:

1. Memory: experience available in context.
2. Harness: prompts, examples, and skills distilled from what worked.
3. Adapters: lightweight fine-tunes trained on verified experience.
4. Weights: open-weight models you own, post-trained on your history.

Promotions are gated, reversible, and traceable

Nothing moves up a tier on vibes. A promotion must beat your private benchmark, built from your own history. Every promotion is reversible with a pointer flip, and every artifact traces back to the experience that produced it.

Rewards are evidence, not opinions

Outcomes arrive as signals: changes in your system of record, explicit outcome reports, and human actions like edits and approvals. Verification is ranked, and the higher tiers only train on the strongest evidence. Failures are kept as data, because a failed attempt with a known cause is training signal too.

Send a signal from your product

Your product knows what happened after the agent replied. Post it to POST /v1/signals with your API key. You address the session your product already has, not an internal id, and the gateway finds the turn it belongs to.

{
  "session": "ep_1f9a2c40-6b31-4c0e-9a77-2d8f5b1e4a90",
  "kind": "scan_completed",
  "value": 1,
  "observedAt": 1755820800000,
  "evidence": { "scanId": "sc_8842" }
}

kind is your own name for the outcome and becomes the signal's label. value is 1 for the good outcome and 0 for the bad one. observedAt is epoch milliseconds and defaults to now. evidence is any small object you want kept with the signal. Send up to fifty at once under a signals array.

Three outcomes, exactly as a health product sends them:

{ "session": "ep_...", "kind": "scan_completed", "value": 1 }
{ "session": "ep_...", "kind": "booking_kept", "value": 1 }
{ "session": "ep_...", "kind": "member_replied_24h", "value": 1 }

A value of 0 is the negative case. It does not just fail to help, it removes the turn from training:

{ "session": "ep_...", "kind": "booking_kept", "value": 0 }

A positive signal raises the turn's training weight, and a second distinct kind on the same turn raises it again, up to a ceiling. An unknown session returns 404, so a broken integration is loud on the first call rather than silent for a month.

Export the slice you want to train on

One agent id usually covers several kinds of work, and mixing them makes a worse model. Every captured turn records the route that served it, a hash of its system prompt, and an optional purpose label, so GET /v1/distill can narrow to the slice you mean:

• route= one or more route ids, comma separated.
• prompt= one or more prompt hashes. The hash is derived from the system message, so your prompt kinds split apart with nothing to wire.
• purpose= one of chat, note, gate, alarm, tool, other. Set it per request with the x-allocate-purpose header; an unlabelled call reads as other.
• agent= the agent id, as before.

Every exported record carries its prompt hash and purpose in meta, so you can see the mix before you train on it.

Yours end to end

The experience database lives inside your boundary and inherits your region. Its surfaces are read-only views, export, and replay: you can watch what the platform learned and take all of it with you. Your data and your weights are exportable at any time. See the RecursiveDB page in your dashboard for the live compaction map.