AITM keeps a fair amount of state locally so it can operate reliably and remember what it has learned about your projects. This is a plain-language map of what's stored, and why it matters to you.

What Data AITM Stores

The data map

Why local, persisted state matters

None of this is incidental bookkeeping — it's the mechanism behind everything covered elsewhere in this guide:

• The per-project database is what lets contracts, task history, and precedent lookups survive between sessions and between tasks, instead of resetting every time you close the app.
• Task data folders are what make the Archive a genuinely useful audit trail rather than a list of titles — every result, screenshot, and metadata field you see there is read straight from these folders.
• Worktrees are the mechanical foundation of the isolation guarantee described in The Pipeline — because each task gets a truly separate filesystem checkout, in-progress work can never leak into your main branch by accident.
• The knowledge graph documents are what turn "the AI happened to remember something" into "the project has a durable, inspectable record of its own behavior" — see Knowledge Sharing.

How database backups are protected from unbounded growth and silent data loss

Database backups need protection of their own — otherwise they could either fill up the disk or quietly disappear right when you need them most. AITM keeps them under a tiered retention policy and watches their size for anomalies:

• Tiered retention — instead of one flat cutoff that deletes every database backup older than N days all at once (which could wipe out every DB backup in one shot if a single daily run was missed), AITM thins backups out gradually: it keeps a handful of the most recent daily backups, a few older backups spaced several days apart, and one still-older weekly backup. The result is a small but spread-out set of recovery points, without letting backup storage grow without bound.
• Size-anomaly alerts — before any pruning happens, AITM compares today's database backup size against yesterday's. A significant drop (possible data loss) or a significant unexpected growth triggers an email alert including the previous size, the current size, and the percentage change, so you learn about the anomaly before an old, healthy backup would otherwise be overwritten or pruned.
• Verified pruning of incremental (delta) backups — incremental recovery backups older than 3 days are pruned on an ongoing basis, but only after the newest backup still being kept in that chain has been verified as intact. If that verification fails, pruning stops for that database and nothing older is deleted — so one corrupted newest backup can never cascade into deleting the older, still-good backups beneath it.