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.

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). A token limited to one project cannot promote past its project. Global contribution is separate and opt-in, see Global contribution.

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, overlane memory confirm and overlane memory promote.