Memory policies

This page explains how memory policies let you choose what Alvia remembers. A support call, team discussion or companion conversation can contain useful long-term context alongside information that should not become memory. The project’s policy separates those concerns: your application can learn from interactions while excluding unwanted subjects and terms.

Choose what the project should remember

Start with a purpose, not a list of everything the application could collect. A support project might remember communication preferences and agreed service instructions. A development project might remember architecture decisions and their reasons. A companion might remember a preferred explanation style and continuing interests.

Then describe what does not belong in that memory: personally identifiable information (PII), health disclosures, credentials, confidential commercial details or material unrelated to the project’s purpose. Set the policy before sending new writes or importing older conversations.

You configure it under Memory policy in the project’s settings in the dashboard. Exclude keywords and Exclude by meaning are optional; use either control or combine them.

Both controls check each fact on its own, once, before it forms. For a passage or an imported conversation, that is each fact Alvia takes out of the text, in its own wording, not the text you sent.

Match known words with keyword exclusions

Use Exclude keywords for terms you know in advance. The dashboard takes up to 50 words of up to 50 characters each; use meaning exclusions for phrases. A support project could exclude passport; a development project could exclude an internal code name that must not enter shared memory.

Keyword matching is case-insensitive and matches whole words, including common plural forms. For example, an exclusion for policy also matches policies; it does not match an unrelated longer word merely because it contains those letters. Because each fact is checked in its own wording, cover subjects that come in different vocabulary with meaning exclusions.

A keyword rule is concrete and easy to test: submit a synthetic fact containing that word and check that it does not become memory. For a whole category such as PII, a meaning rule covers the forms a keyword list would have to name one by one.

Choose words narrowly. A broad term such as customer can exclude the very context a support assistant needs. Test the forms your application receives.

Match a subject with meaning exclusions

Use Exclude by meaning when the same sensitive subject can be expressed in different words. Describe the information to exclude in ordinary language, up to 300 characters. For example:

Personally identifiable information, payment credentials and anything about a person's health conditions, diagnoses, treatments or medication.

This expresses the category rather than requiring the person to use a particular keyword. Alvia judges each fact against the rule by meaning, so test your rules with real examples. A statement about a daily treatment can be health information even when it never says “health”: test that paraphrase alongside one that uses your expected vocabulary.

Keep the rule specific enough to preserve useful context. “Exclude everything personal” is ambiguous for a companion intended to remember learning preferences. Describe the unwanted categories instead, then check that allowed preferences still form memories.

Design rules for the scenario

Start from these rules and confirm them with synthetic data before using the policy in your application.

Scenario	Useful memory	Information to exclude	Meaning rule to start from
Support handoff	The customer prefers written troubleshooting steps	Payment credentials, identity-document details and medical explanations volunteered during the call	Personally identifiable information, payment credentials and health disclosures
Learning companion	The learner now wants worked examples instead of short hints	Contact details, diagnoses and medication disclosures	Contact details, government identifiers and anything about health conditions or medication
Coding agents	Payment callbacks must be processed idempotently because the provider retries them	Secrets pasted into logs and confidential customer payloads	Credentials, access tokens, customer personal data and confidential customer payloads
Refund workflow	Refunds above the current threshold need a manager’s approval	Card details and personal explanations unrelated to the routing rule	Payment credentials, personal identifiers and health information

The policy belongs to the whole project, so give each application with different rules its own project. See Projects and scope.

Understand the write and read lifecycle

Your application selects the information it is allowed to send and the project it belongs to.
A write or import is submitted for formation. An accepted request returns 202.
The project’s policy excludes matching information from becoming memory. Formation keeps only the durable facts the policy allows.
Later reads use the current memories that formed. Scope and date filters narrow those reads.

A 202 means the write was accepted (see the write’s Response). Confirm the policy by inspecting the formed memories, and test both an allowed fact and excluded facts. See Filter memories.

A policy change applies to each fact screened after it, including facts from writes accepted earlier that are still waiting to be screened. A policy governs new facts; manage the memories already formed, including any sensitive ones, with forget. See Manage memories.

Distinguish filtering from other controls

Control	Question it answers	Pair it with
Project memory policy	What information should become new memory?	Separate projects for access, forget for existing memories and your own log redaction
Scope filter	Whose current memories are relevant to this read?	Separate projects for access: every key in a project can read every scope
Date filter	Which current memories fall inside these occurrence dates?	A scope filter, to narrow the period to one user, team or application
Separate project	Which collection can this API key access?	A memory policy, to decide what the collection retains
Forget operation	Which existing memory should stop appearing in reads?	A memory policy, to exclude the same subject from future writes

These controls work together. A support application selects the customer’s project, applies a project policy to new conversations and reads with the customer’s scope. No one control replaces the others.

Use policies as a security control

Filtering reduces the sensitive information available to future prompts, agents and operators. It also keeps shared project memory focused on its purpose instead of accumulating incidental disclosures from every interaction.

Treat policy design, input minimization, project isolation and application logging as separate parts of the integration. A policy governs what becomes memory; credentials in your own transcript, tracing system or model prompt are yours to remove. See Security.