Filter memories

This guide shows how to configure and verify a memory policy for a support project. You will allow useful communication preferences while excluding restricted internal program names and health information.

For endpoint schemas and status codes, use the API reference.

Define the intended outcome

A customer tells an operator, “Please send written steps next time,” then volunteers a medical explanation. The support team needs the preference on the next call, not the medical disclosure. A later operator should be able to ask how to present instructions without retrieving that sensitive explanation.

The test separates an allowed preference, a keyword exclusion and a meaning exclusion. Start with separate statements so you can diagnose each rule before trying a mixed conversation.

Configure the project’s memory policy

Open the test project in the dashboard, then open its settings.
Under Memory policy, add nightjar to Exclude keywords. Press Enter or a comma after the word. Each entry is a single word; do not paste a sentence into this field.

In Exclude by meaning, enter the following rule:

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

Save changes. The settings apply to new memory writes. Confirm that your test API key belongs to this project before submitting anything.

Both controls are optional. Here they serve different checks: the keyword names one known term, and the meaning rule covers subjects that can be expressed without that word. The policy applies to the project, not just the key or scope used by this test.

Submit an allowed fact

Use the executable curl, Python, Node.js, Go or C# example in Send a passage, replacing its request body with:

{
  "content": "The customer prefers written troubleshooting steps instead of a phone walkthrough.",
  "infer": false,
  "scope": { "user_id": "policy-check-01", "application_id": "support-policy-test" }
}

An accepted write returns 202 with an empty body. Wait for formation to finish, in less than a minute, then use List memories with the query parameters user_id=policy-check-01 and application_id=support-policy-test. Inspect the returned memories. The preference appears in the list. You can also open the project’s Memories in the dashboard to see what formed.

This allowed fact is your positive control: confirm it before you test the exclusions. If it is missing, check the project, scope, policy and formation time, so the later results reflect the policy rather than the setup.

Test the keyword and meaning rules separately

Submit each of the following bodies using the same store example and scope. These are invented test statements, not real customer information.

{
  "content": "The internal support escalation program is named nightjar.",
  "infer": false,
  "scope": { "user_id": "policy-check-01", "application_id": "support-policy-test" }
}

This exercises the nightjar keyword without relying on the PII or health meaning rule. Next, submit a health statement that does not contain it:

{
  "content": "The customer takes a daily medication for an invented test condition.",
  "infer": false,
  "scope": { "user_id": "policy-check-01", "application_id": "support-policy-test" }
}

Wait for formation to finish, then list the scope’s memories again. The preference is there, and no memory names the program or the medication.

Verify paraphrases and mixed conversations

Use the same procedure with a small set of representative statements:

Test	Example	What to check
Allowed preference	“Please use a numbered checklist when explaining setup”	Useful context still forms
Exact keyword	A synthetic statement using the exact restricted word as your app receives it	The known term is excluded
Meaning paraphrase	“The doctor changed my daily treatment”	A health statement is excluded without relying on the word `medication`
Mixed passage	A preferred instruction style followed by a synthetic diagnosis	Sensitive details do not become memory; inspect what useful context remains
Different key	Repeat a test through another key for the same test project	The project policy still applies
Imported conversation	Import invented operator and customer turns with the original conversation date	Conversation ingestion respects the project’s exclusions

Use Import conversations for the import body and language examples. Repeat the tests after changing a policy and before applying it to historical backfills. Formation keeps each durable, allowed fact, so judge a passage by which facts formed rather than by a memory count.

Retrieve the useful preference

Use Get context with this request body:

{
  "query": "How does this customer prefer troubleshooting instructions?",
  "scope": { "user_id": "policy-check-01", "application_id": "support-policy-test" }
}

The application can use the returned context to offer written steps. If context is missing, continue the support interaction without it; do not remove the scope to search other customers’ memories.

Cost

Test writes and reads count like any others. See Limits and allowances.

Retries

Submit each sensitive test statement once: when it forms no memory, the exclusion worked. See Retries in Store memories.

Errors

The test writes return the errors in Errors in Store memories, and context returns those in Errors in Read memories. See Errors for every code.

Troubleshoot the policy

Problem	What to do
An unwanted memory already existed before the policy changed	Handle it separately with Manage memories. A new rule does not erase old data
No facts form, including allowed preferences	Confirm project and scope, allow formation to finish and narrow an overbroad exclusion
A restricted subject appears under different wording	Describe the subject under Exclude by meaning, then test representative paraphrases
The policy works in one project but not another	Configure each project separately; a key or scope does not carry a policy into another project
A scoped or date-filtered read is empty	Inspect current memories and their occurrence dates; read filters are separate from policy exclusions
Sensitive data remains in your transcript or logs	Remove or redact it in your application; a memory policy does not sanitize those systems

A memory policy controls what becomes memory, not what reaches Alvia. See Use policies as a security control.