Concepts

Audit and memory

Every run leaves a local, attributable record; memory links and timelines make that record useful.

If you want to know why Recued did something — and undo it — the audit record is where you look. Audit is written by the server as actions happen, stays on the server, and never syncs to the cloud.

#What a run records

Every execution writes an audit entry: which recipe or tool ran, which actor asked for it and over which channel, what it read and wrote, and how it ended. Actions taken by an external agent are attributed to that agent — origin travels with the record, so "who did this" always has one answer.

Reactive recipes that fire many times a day roll up into one process view with per-iteration detail, so a busy watcher reads as one line, not a thousand.

#Provenance and the timeline

Audit is a first-class collection that links each entry to the records it touched. Those links power the timeline — one chronological feed per entity (a contact, a deal, a thread) across raw data, annotations, and run history. "What happened around this person" is answered from recorded provenance, not reconstructed by a model.

#Memory is a different thing from audit

Two stores, easily confused, deliberately separate:

  • Audit is the run record. The server writes it as things happen, it is quota'd, and the oldest entries are evicted when it grows.
  • Memory is your knowledge — facts, decisions, preferences, product notes you wrote or imported, plus anything an AI saved with your permission. You own it, nothing prunes it, and it is what recall searches when you or an agent asks a question.

Memory lives under Data → Memory, where you can add, edit, forget, import and export entries.

#Writing an entry that gets found

Recall searches the whole entry — summary and body together — matching on the words it contains. It widens a query that finds nothing (dropping filler words, then trying any word rather than all of them), and it understands word endings, so cancel finds cancelled. What it cannot do is guess a word you never wrote: nothing matches 2FA against an entry that only ever says two-factor authentication.

So the single most effective thing you can do is end an entry with a keywords line:

How do I enable two-factor authentication?

Security settings, then scan the QR code with an authenticator app.

keywords: 2FA, MFA, OTP, login security, second factor

There is no separate keywords field and none is needed — the line is just part of the body, and recall indexes it like everything else. Measured on the entry above, adding it makes 2FA, MFA and second factor login all find it exactly, where without it they find nothing at all.

Two habits that help:

  • Phrase the summary as the question someone would ask, not as a filing label. "How do I get a refund?" is found by more real queries than "Refund policy".
  • Put keywords last. The feed shows the opening of each entry, so a keywords line at the top makes every entry read as a list of terms.

#Two kinds of time

Every entry carries when Recued recorded a fact and, where known, when the underlying event actually happened — a mail's send date rather than its sync date. Timelines read in real-world order by default, so backfilling a year of history does not shuffle your feeds.

Runs are also tagged by mode — live, manual, or backfill — so a historical re-processing pass does not pollute recent activity.

#Reversibility and control

Consequential actions are gated before they run and recorded after; the record is what makes undo meaningful. Long-running work shows up in a live activity list and can be killed from any paired surface you allow. If a gated call fails between decision and confirmation, it is parked as in doubt and Recued asks you rather than retrying — see Grants and approvals.

#Where to look

In the webclient, Runs is the audit surface: live and past executions, reactive processes rolled up with their iterations, and the approvals queue. Any entry expands to its full record — actor, channel, reads, writes, outcome. Per-entity history is on the entity itself, as the timeline.

#Retention and export

Audit history is yours: retention is a user setting, and entries can be exported. There is no cloud copy — the audit authority is your server.

Memory is kept differently, and on purpose: it has no quota and is never pruned. Knowledge you took the trouble to write down should not age out because a busy week filled the run log. It exports as JSON and imports back the same way, so a pool is portable between your own servers.

Recued is local first; your server remains the authority.

Recued Docs

Search documentation

Start typing to search the documentation.