Memory in the console¶
Memory is what applications, models and the organisation's own conversations have taught Core: a customer's preference, an earlier decision, a fact a model picked up, something somebody promised. Each record is for one person, or shared with everyone. Memory is a section of its own in the rail, after Knowledge, because a memory store is an index used as memory. You read the records here and set up how they are kept; you cannot change or delete a record.
Writing memory happens through the API, with a key whose policy allows it: see Memory through the API, and add a Permit rule about Writing memory to the key's policy. The organisation's own policy has to permit it too.
You need an administrator account of the organisation, and the memory and knowledge
capabilities have to be on in the organisation's ceiling.
The section has three segments.
| Segment | What it is for |
|---|---|
| Stores | how each index is kept as memory: decay, maintenance, search and extraction |
| Records | every record, with what happened to it |
| Commitments | what was promised, to whom and by when |
Stores¶
Stores lists your indexes. A store belongs to an index; one nothing has configured runs on the default settings, and its row says so. The row shows whether Extraction and Maintenance are on and when maintenance last ran. Select a row to open the store.
A store's settings belong to the organisation, not to a key. Each card is saved with Save, and only the cards you changed are sent.
| Card | What you set |
|---|---|
| Decay per type | after how many days the confidence of a record of that type has halved; a type you do not list never decays. A key's own decay setting goes first for what that key reads |
| Maintenance | a periodic pass that merges duplicates and archives records that have faded and not been used. Duplicate threshold is how alike two records of the same person and type must be to count as one fact; the weaker is replaced by the stronger. Check for contradictions lets the organisation's helper model judge near records; each judgement is a metered model call, and Core only flags a contradiction, never settles it |
| Search | a Knowledge graph whose entities, found in the question, rank the records that name them, and an optional model that reranks the best hits, which is a metered model call per search |
| Commitments | whether a turn always carries its person's open commitments, and how many, the one due soonest first |
Nothing is deleted by maintenance: a merged or archived record stays readable under Records with the matching state.
Extraction from conversations¶
Switch Extraction on and Core reads this organisation's conversations on a schedule, lets a model pick out what is worth remembering and writes it as records. A fact said again confirms the record; a correction replaces it and keeps the old one in its history. It is off until you switch it on. While it is on, the store's index cannot be deleted; switch extraction off first.
| Setting | What it does |
|---|---|
| Model | the chat model that reads the conversations; required once extraction is on |
| Instructions | what is worth remembering for your organisation; empty leaves that to the model |
| Types | which kinds of record it may write, separated by commas; commitment adds a status, a due time and who it is owed to |
| When | every so many minutes, or a cron expression with a time zone |
| Which conversations | only some keys' conversations, a minimum number of messages, how long a conversation must have been quiet, how far back to look, and how many messages are read at once |
Under the form, Last pass says how the last read went, and the counts say how many records were Written, Confirmed, Superseded and Dropped as invalid. Extraction is ordinary knowledge: it makes a collection of conversation windows, a connector that reads them and a pipeline that writes memory. Open collection and Open pipeline go to them under Knowledge.
Reading is recorded¶
Every list and every record you open is written to the audit trail under your name, with the ids of the records you were shown. The screen says so above the table. Open a record when you need to, not to browse.
Records¶
The filters sit in the card at the top. Everything you set is in the address, so a link you send someone shows them the same rows.
| Filter | What it narrows to |
|---|---|
| Index | records in one index; All indexes is where you start |
| State | Current, which is where you start because only a current record reaches a model; Superseded, Archived or All |
| Type | records of one type, such as preference; the type is whatever the application chose |
| Minimum confidence | records at least this confident, from 0 to 1 |
| Metadata | records carrying every key and value you add; a row without a key is ignored |
Clear filters puts everything back.
Each row shows:
| Column | What it says |
|---|---|
| Type | the type the application gave the record |
| Content | the start of the text; structured content as JSON. Superseded, Archived and Contested chips say what became of it |
| Index | where the record lives, while you look at all indexes |
| For whom | the person it was written for, or Shared |
| Trust | Trusted with a lock, or Untrusted with a warning sign |
| Confidence | the confidence as stored |
| Updated | how long ago the record was written or last changed |
| Written by | the key that wrote it, or The model above the key whose conversation it came from |
A shared record is read by every turn of this organisation, whoever it is for. A record for a person is read only in turns for that person.
Contested means the maintenance pass judged the record to contradict another. Core never picks a winner; the record's page names the other one.
Read one record¶
Select a row to open the record. Its page shows the whole text or the structured content, the metadata, and the facts: type, index, for whom, confidence, when it was created and updated, and the key. Under them is the record's life: its Labels, one badge per value (the labels rules about Memory records read; the console shows them and does not change them), its state, the time it was valid from and until (Still valid while it is current), when it was last confirmed and recalled and how often, the record that replaced it, and the one it contradicts. A commitment also shows its status, when it is due and who it is owed to.
Confidence is shown as stored. How fast it decays depends on the decay setting of the key that reads the record; the clock starts at Updated. See Confidence decay.
History¶
The History card lists every version of a fact, oldest first, each with the time it was valid and a link to its own page. A correction or a newer fact replaces a record instead of overwriting it, so the old wording stays readable here and no longer reaches a search or a turn.
Commitments¶
Commitments are the records of type commitment: what somebody promised. Each row shows a
Status chip (Open, Fulfilled or Cancelled), when it is Due, who it is Owed
to and which person it belongs to. An open commitment whose due time has passed also carries an
Overdue chip, and Core announces it on the event feed. Filter on
Status, or switch on Overdue only. You read them here; you cannot change them.
A turn is told of open commitments only. A fulfilled or cancelled commitment stays in this list and in search, and is never placed in a turn's context. Where a person has more open commitments than the store's Most carried, the turn gets the ones due soonest and not the rest.
Trust and origin¶
The Trust and origin card says who added the record and whether Core vouches for it.
| Origin | What it means |
|---|---|
| Written explicitly | an application stored the record with a key; no conversation is behind it, and Core trusts it |
| Derived during a turn | the model wrote it with the index's write tool; it is as trustworthy as the least trustworthy item that fed it |
| Written outside a turn | an outside client called the write tool with no conversation around it; nobody reviewed the text, so Core does not vouch for it |
Whatever its origin, a record that is injected into a turn reaches the model as data: in a
message of its own, one line of JSON per record, and never as a system instruction. Whether the
model is also told that it is data depends on the key the turn runs under: with
trust_envelope the records are wrapped in
<untrusted source="memory">, and without it the model reads them between a line [memory] and
a line [/memory].
For a derived record the card also names the model, the conversation (a link to that conversation's page under Traces), and the id of every item that fed the record with that item's own trust. It shows only the ids: what the items said is read in the conversation itself, and opening a conversation is recorded on its own.
Empty lists and access restrictions¶
- Nothing remembered yet: no application or model has written memory in this organisation.
- Nothing remembered in an index: pick another index, or All indexes.
- No record found: your filters match nothing; select Clear filters.
- No commitments: nothing has been promised yet, or your filters match nothing.
If memory is disabled, Memory per user is off in the organisation's ceiling. The administrator of the organisation above turns it on under Permitted capabilities on Settings; for an organisation with none above it, your operator does. Memory needs knowledge enabled as well.