# How long the record is kept

Decision records are ordinary workspace data in PostgreSQL under row-level security, so their lifetime is the workspace's lifetime. No age-based deletion schedule for them is documented, and this page does not invent one. In practice what limits an investigation is not age but scope: the log keeps decisions and their rules, not the wording of messages.

- **Status:** Available
- **Audience:** both
- **In the app:** #/autonomy-audit
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/autonomy/audit-retention/

## What is actually known

- Decision records live in the workspace's own database rows, protected by row-level security like every other scoped record.
- They are therefore removed when the workspace itself is removed, along with the rest of its data.
- No published rule prunes them by age. If a workspace needs a specific retention period for a contractual or regulatory reason, that is a question to raise rather than an assumption to make.
- The related question of how long *other* categories of data are kept is covered by [Data retention](/docs/security/data-retention/), which is the right place for a policy answer.

> **Note** This page states the absence deliberately. A documentation set that guesses a number here would be quoted back at somebody during an audit, and a guessed number is worse than a stated gap.

## What limits an investigation in practice

Age is rarely the constraint people meet. Three other properties of the record decide whether a question can be answered, and all three are consequences of what the log is for.

| You want to know | The log gives you | Where the rest is |
|---|---|---|
| Who released this and when | The decision, the actor and the rule | Nothing further needed |
| What the message actually said | That a reply was released on that thread | The conversation itself |
| Why the customer says they never received it | The provider's acknowledgement, or the uncertain state | The provider's own records, beyond Connect |
| What Connect knew at the time | The rule in force, not the knowledge in force | Memory and Knowledge, which record their own history of changes |

## Working with the record over a long period

1. Capture the context you will want later at the moment of the decision, not afterwards.
   - Result: A note on the relationship saying why an exception was set is worth more in a year than any amount of log reading.
2. Investigate a disputed send while the provider still has its own records.
   - Result: Connect keeps its acknowledgement; the provider keeps the delivery detail, and that side has its own retention you do not control.
3. Before deleting a workspace, take what you need out of it.
   - Result: Deleting the workspace removes its records with it, and that is the one event with a certain effect on this data.

> **Careful** Do not treat the Decision Log as a substitute for a records-management policy. It is an accountability record inside one product; a business with a statutory retention obligation needs that obligation written somewhere that governs every system, not one screen.

## Why the record is durable by construction

The log is not a rolling application log of the sort that is rotated and discarded. It holds one row per decision, containing the decision, the actor, the rule and the outcome — not stack traces, not internal paths, not raw provider error text. That shape is what makes keeping it indefinitely reasonable, and it is also why it does not grow the way a diagnostic log does.

It is also why the record stays readable after the code that produced it has changed. An entry naming the rule in force at the time keeps meaning something after the settings screen has been redesigned, which a reference to a configuration that no longer exists would not.

## Questions

### So how many days are decision records kept for?

No such period is documented, and this page will not name one. What is documented is that the records are workspace data under row-level security and go when the workspace goes. If you need a contractual answer, ask for one rather than inferring it.

### Can I export the record for my own archive?

The Decision Log is a screen within the product; it is not one of the sheets in the Data grid, so there is no grid export of it. Treat any archive requirement as a question to raise before you rely on it.

### Does deleting a conversation remove its decisions?

The decision record is a separate row from the conversation. What removes it with certainty is removal of the workspace itself; anything narrower should be confirmed rather than assumed.

## Related

- [The decision log](https://connectbyjbrh.com/docs/autonomy/audit-trail/)
- [What is kept and for how long](https://connectbyjbrh.com/docs/security/data-retention/)
- [Who can read the audit trail](https://connectbyjbrh.com/docs/security/audit-access/)
- [Removing a workspace, end to end](https://connectbyjbrh.com/docs/workflows/workspace-deletion/)
- [Who may change what](https://connectbyjbrh.com/docs/autonomy/permissions/)
- [Files and data in Connect](https://connectbyjbrh.com/docs/files-data/)

## What this page is based on

- Connect source pack §2 — three layers of workspace isolation, including row-level security (`docs-source/sources/GENERAL.md`)
- Connect source pack §5 — what the audit trail records
- Connect source pack §9 — the thirteen sheets in the Data grid, which do not include the decision record
- Connect capability registry (`docs-source/facts.py`) — `audit_trail`, `rls_isolation`, `data_workspace`