Memories

This section covers the Memories tab and associated aspects of viewing and managing the Knowledge Base Memories.

For more general information on Memories and their functions, see our guide on Memories.

Overview

This tab let's you both view the list of memories, by their status, as well as investigate each memory individually.

Memories List

This is the selection panel within the tab, where you can filter on different statuses and select an individual memory for observation or action (see Patterns below).

Record Types (Statuses)

Memories have four possible statuses:

• Proposed -- Memories that have been recently proposed by members of the Knowledge Base and not yet reviewed/endorsed.

• Committed -- The only memories that have direct influence in any workflow. Positive or negative, these are available for reference in a workflow, dynamically identified and used.

• Rejected -- Memories that have been reviewed and have been determined invalid for endorsement. The record is kept but listed as "Rejected/Ignored".

• Invalidated -- Memories that are no longer applicable to the evolving Knowledge Base are visible here, for posterity. For more information on invalidation see guide on Memories.

Record Details

Each record has several components:

<image pending>

1. Original Thread Name -- The name of the thread from which this memory record originated.

2. Identifier Prompt -- The main prompt of the message. (Note: This is a "rephrased prompt" so may not be an exact match of the user's original prompt, for more accurate representation of user intent amongst other reasons. For more information see Prompt Rephrasing.)

3. Created By -- The User that created/proposed the memory. This person created the message and identified the feedback and any other information with the proposal.

4. Created At -- The date the memory proposal was created.

5. Feedback Type -- Identifies if the feedback was positive ("Thumbs Up") or negative ("Thumbs Down").

Memory Details

A memory is more than a response, it has similar memories (which are suggestive of how many competing memories might apply in practice in a workflow), dependencies, and other properties available for reference.

Response

This is the main artifact of a memory, which shows the output from the prompt. The key element is the QueryBlock, which influences workflows when the memory is applicable.

As mentioned in the overarching guide on Memories, although all "blocks" are shown, only the "query" block has any effect in future workflows as a memory. The rest is for context only and future applicability.

Similar Memories

These are all other memories that are related by prompt affinity (i.e., by contextual similarity of the Identifier Prompt). Similar memories will likely compete ("likely", as it is contextual) for relevance in future prompts and their workflows.

Similar memories can be viewed directly in the display by expanding the record.

<image pending>

Similar memories alternatively can be compared in a side-by-side view for more direct A/B comparison with the target record.

<image pending>

Having too many similar memories may cause excessive competition in practice when a workflow seeks to determine which memories are applicable. The minimum distinct relevant set are warranted (typically 5 and under). If there are many, Knowledge Base Contributors should consider rejecting some based on applicability, recency, and overall relevance.

Dependencies

These are all the Knowledge Base context objects (Tables, Model, and Business Context elements) that are relevant to the memory. If any of these change, the memory will be invalidated when the KB is saved (the action and impacts will be flagged).

See our broader guide on Memories for understanding Dependencies and see the Updating / Saving section for more information on the action flow and impacts.

Properties

These are all other helpful properties relevant to the memory itself. These include:

• Original Prompt -- As opposed to the Identifier Prompt (which is the Rephrased Prompt), the user's original prompt appears here as reference. See Prompt Rephrasing for more information about differences in prompts.

Patterns

There are two primary usage patterns for memories:

• Browsing memories as a Viewer

• Endorsing and otherwise managing memories as a Contributor

Browsing

When browsing memories, use the list panel to view memories by status. Most recent memories will be positioned closer to the top of the list.

Click on any individual memory to see its properties. You can also click on the individual blocks or similar memories to view the particulars of those objects further.

No actions/edits are applied when browsing (i.e., when not in Edit mode in the Knowledge Base).

Endorsement

When in Edit mode in a particular Knowledge Base, in addition to the browse actions, each memory record under proposed (as well as committed and rejected) can have it's status changed.

<image pending>

The following patterns are available:

• Proposed -> Committed or Rejected -- Endorse or ignore the memory as applicable. The Proposed status should be treated as an inbox or needs-review status, thus ideally all Proposed memories are Committed or Rejected.

• Committed -> Rejected -- A Committed memory can be later rejected if it either competes for relevance, is no longer applicable but did not trigger invalidation, or was committed in error.

• Rejected -> Committed -- A Rejected memory can later be committed if it was rejected in error.

There is no pattern to influence or change status of Invalidated memories; these are available for reference only.