---
slug: not-a-docstore
title: "AiAkiv is not a document store"
description: "What gets stored is shaped for an AI to read. Keep the documents people read somewhere else, and leave in AiAkiv the process that produced them."
lang: en
---


# AiAkiv is not a document store

Once you start using AiAkiv, a thought comes naturally: *"I could just put my
documents in here."* Push in the whole spec, the design doc, the meeting notes,
and read them back later.

**That doesn't fit.** It will store them, but **what gets stored is not shaped
like a document.**

> **In one line.** Make the documents people read **somewhere else and share
> them with your team**; leave in AiAkiv **the process that led to them**. The
> document says *what*. AiAkiv says *why*.

## 1. What gets stored is shaped for an AI

`ak save this` doesn't just put your text in. Other things are made alongside it.

| | What |
|---|---|
| **Summary** | The surface search matches on: what this memory is about |
| **Entities** | The things that appeared: people, systems, concepts |
| **Tags** | The classification axis |
| **Links** | Lines to other memories (chronological, causal, shared entity) |

This structure is designed **for an AI to read** ([Core
concepts](core-concepts)). So it's **strong at search and at tracing
relationships**: ask "why did that decision come out?" and it weaves scattered
memories into an answer.

**It is correspondingly bad for a person reading straight through to follow a
line of cause and effect.** Memories are fragments, and lining them up in order
still isn't the flow of writing a person reads. It was never built for that.

## 2. There are format limits too

It isn't only about purpose. Physically, it isn't a container for documents.

| | Limit |
|---|---|
| **Images** | **Not stored.** Text only |
| **One save** | **50,000 characters** of body text |
| **Summary** | **500 characters** |

You *can* split and chain past that ([Threads](threads)). But if a document
needs images or long-form exposition, splitting it up doesn't turn it into a
document.

## 3. So keep the two apart

### Documents people read: elsewhere, with your team

Put images, tables, and long explanations in a **doc tool, a repo, or a wiki**.
That's where your team opens, edits, and reviews. What matters there is the
**finished conclusion**.

### AiAkiv: the whole process that produced that document

A document keeps only the conclusion. Everything exchanged on the way there
**disappears.** That's what you leave in AiAkiv.

- **Why it was decided that way**: the reasoning that never gets written next
  to the conclusion
- **The alternatives you dropped and why**: what you miss most when the same
  alternative comes back around
- **Where you got stuck and how you got out**: for the next time you hit the
  same wall
- **Assumptions that turned out wrong, and the evidence that overturned them**

This is the side you actually need again once time has passed. And this kind of
content is **fussy to write as a document and a perfect fit as memory**: it's
fragmentary, interlinked, and only needs to surface when a question is asked.

## 4. Then this happens

Later, **open that document and ask your AI.**

```
"In this design doc, why was the cache layer set up this way?"
```

If the AI only has the document, it can only tell you what's written in it. But
when the process is in AiAkiv, it answers with **the approach you considered and
dropped, the numbers you measured then, and the reason you dropped it**: none of
which is in the document.

**The document says *what*, and AiAkiv says *why*.** Together they're far richer.

## How to actually do it

While you work, run this loop.

1. **As you work**: every time a decision lands, an alternative is dropped, or
   you get unstuck, `ak save this`. If it's long, chain it
   ([Saving](saving), [Threads](threads)).
2. **When you write up**: write the document people read, separately. Put the
   conclusions and the images there.
3. **When you commit or share it**: **leave one line in memory saying where the
   document lives.** "The resulting document for this discussion is at ○○" is
   what ties the two together later.
4. **When you need it again**: open the document and ask your AI.

## Common problems

- **"I put a document in and it doesn't come back the way I want."** A whole
  document ends up with several topics crammed into one summary, so it matches
  no question well. **Split it by topic** and save the pieces.
- **"But the diagram is the whole point."** Keep the diagram on the document
  side, and leave in AiAkiv **what the diagram is trying to say and why it was
  drawn that way**, in words.
- **"Can't I use it as a backup?"** It isn't suited to that. AiAkiv is not an
  archive of original text; it's **a place that remembers
  relationships** ([What AiAkiv is](what-is-aiakiv)). Keep originals as
  originals.

## Related

- What AiAkiv remembers → [What AiAkiv is](what-is-aiakiv)
- The structure of Event, Entity, Tag, and links → [Core concepts](core-concepts)
- When and how to save → [Saving](saving)
- Splitting and chaining long text → [Threads](threads)
- Working with several AIs and staying in the loop → [Working with several AIs](working-with-ais)