---
title: "Candidates and confirmation"
description: "How a memory moves from candidate to confirmed, which evidence confirms it, and why an agent can never confirm its own."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.overlane.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Candidates and confirmation

Agents write **candidates**. A candidate is stored and can be searched with `--candidates`, but default recall returns confirmed memory only.

## What confirms a memory

A candidate becomes confirmed in exactly three ways, and an agent can supply the first:

1. **A second observer.** A different principal writes or confirms the same memory. An independent second agent counts. The same agent submitting twice under two request IDs is a repeat observation and does not count.
2. **CI evidence.** The CI job records a commit and check that proved it, as `<commit sha>:<check id>`. A person can record it too.
3. **A person's say-so.** A person can confirm a memory with `--basis human`; it is the override, never a requirement.

An agent can never confirm its own candidate and can never write `confirmed` directly. It asks another agent to confirm with `--basis second_observer`.

```sh
overlane memory add --title "Deploy day" "Deploys go out on Tuesdays" --project prj_1
overlane memory confirm mem_ab12
overlane memory confirm mem_ab12 --basis ci_evidence --evidence 0123abc:unit_tests
```

## Promotion

An agent with a team-wide token promotes a confirmed project memory to team, and a user memory is promoted by the user it belongs to. Promotion is the memory promotion autonomy class: nothing waits under `autonomous`, another principal approves under `supervised`, and a person under `manual` (see [Autonomy](/autonomy/)). A token limited to one project cannot promote past its project. Global contribution is separate and opt-in, see [Global contribution](/memory/global-contribution/).

```sh
overlane memory promote mem_ab12 --to team
```

## Secrets and personal data

A candidate that contains a secret (a provider token, a private key, a password assignment) or personal data (an email address, phone number, national ID or card number) is refused and never stored. The refusal names the rule, never the matched text.

The full command list is generated from the registry: see [overlane memory add](/cli/memory-add/), [overlane memory confirm](/cli/memory-confirm/) and [overlane memory promote](/cli/memory-promote/).

Source: https://docs.overlane.app/memory/candidates-and-confirmation/index.mdx