---
slug: saving
title: "Saving"
description: "It saves only when you command it with `ak`. The conventions that make memories worth having, and how to correct or retire one afterwards."
lang: en
---


# Saving

Memory doesn't get better on its own. **Consistency in how you save** decides the
quality of the graph.

## When it saves: only on an `ak` command

AiAkiv does not save your conversation automatically. It saves **only when you
explicitly command it with `ak`** (any language: "ak save this" works fine).

- Simply saying "remember this" or "save that" **does not save.**
- This is the guard that keeps stray chatter and secrets out of your graph by
  accident.
- AI clients follow the same rule → [For AI agents](for-ai-agents).

## Conventions that make a memory worth having

### 1) Record a decision as four parts

When you save a decision, leave four things so it can be retraced later.

1. **What** you decided
2. **Why** (the reasoning)
3. **The alternatives you considered and why you rejected them**
4. **The related commit hash** (on a code project)

> Without the alternatives and the rejection reasons, nobody can later tell why
> you didn't take a different road. This is the most valuable part of the graph.

### 2) Save a bug together with its cause

When you save while fixing a bug: **symptom / root cause (the past event or
decision that caused it) / the fix / commit hash.** Tie the root cause to the
past event and causal questions like "which past decision caused this bug?"
become answerable later.

### 3) One name per entity

Always call the same thing by the same name (if you settled on "save format",
keep saying that). If the name wobbles, one entity splits into several and the
connections break.

### 4) Attach tags

A kind tag (decision / bug / balance / retro …) plus tags for the system or
topic. The more consistent the tags, the better search gets.

### 5) If it's long, chain it: don't trim it

Don't cut important content just to make it shorter. If the text is long, chain
it. Search gives you the summary, but the original has to be preserved for you
to recover it later.

A single save takes up to **50,000 characters** of body text. Past that, split
it, but **chain the pieces into a thread** so they don't scatter: pass the
previous save's `event_id` as `prev_event_id` on the next one and they link in
order. As a person, "**ak continue saving**" is all you need to say. Details and
caveats in [Threads](threads).

## Only save what's safe

AiAkiv is an **outside service** and what you store stays (→ [What to
store](what-to-store)). So only put in what's safe to put in
from the start. Don't include:

- Real names (use aliases) or personal data
- API keys, tokens, secrets
- Company confidential information or sensitive figures
- Chatter unrelated to the topic

## Correcting a save afterwards: edit and retire

Don't re-save because you got something wrong. **You'll end up with two copies of
the same content.** There are two handles for a memory that's already saved, and
**they do different things.**

| | Edit | Retire |
|---|---|---|
| What it touches | Entities · tags · chaining (thread links) | The whole memory |
| The original text | **Can't be changed**: it's preserved as is | Stays as is |
| Result | It matches search better | **Drops out of recall**: gone from search, neighbors, and traversal |
| How you say it | "ak fix the tags on what I just saved" | "ak retire what I just saved" |

### Edit: when what the AI extracted is wrong

The original text is yours, so there's no reason to touch it. What can be wrong
is **the part the AI produced**: the entities it auto-extracted, the tags it
suggested, and its judgment about whether a save continues the previous one.

- An entity was caught wrongly or missed (this is also where you repair a broken
  one-name-per-entity rule)
- You want to attach or detach tags
- Two saves should have been chained and weren't, or were chained and shouldn't
  have been

> **If you need to change the original text itself,** editing won't do it.
> **Retire that memory and save it again.**
>
> **Structural links created by ingesting a whole document** (chunk, file, and
> folder order) cannot be cut. That information can't be rebuilt, which is why.
> if it's refused, don't retry.

### Retire: taking it out of recall

Use it when something was saved by mistake, went to the wrong project, or has
gone stale and you'd rather it stopped coming up.

**⚠ Retiring is not deleting.** It drops out of search and recall, but **the data
itself remains.** And **undoing it is an operator action**, not something a tool
can do. Retiring is effectively one-way.

- You can only retire **your own team's** memories. Another team's are refused.
- **There is no way for a user to physically delete a single memory.** The only
  things that remove the original are **deleting the team** and **closing your
  account** (console → Danger zone, not reversible → [Console](console)).

**So retiring does not solve personal data or secrets.** That's exactly why not
putting them in is the only sure method (see [Only save what's
safe](#only-save-whats-safe) above and [What to
store](what-to-store)).

## persona: the project dictates the saving style

A project can carry a **persona** (a standing instruction set by its owner). For
example: "always save decisions together with the alternatives considered and the
reason for rejection." An AI saving into that project follows it. A persona only
changes the style of saving; it **does not override the `ak` command rule.**

## Next

- Getting what you saved back → [Searching](searching)
- Where it gets saved → [Teams and projects](teams-and-projects)