# ADR 002: Limit copies of financial content

- HTML version: https://robbiepalmer.me/projects/personal-finance-app/adrs/002-private-data-lifecycle-and-telemetry
- Project: Personal Finance App (https://robbiepalmer.me/projects/personal-finance-app.md)
- Status: Proposed
- Date: 2026-09-24
- Initiatives: Digital Twins for Everyday Life (https://robbiepalmer.me/initiatives/digital-twins-for-everyday-life.md)

## Context

The product policy in
[PDR 004](/projects/personal-finance-app/pdrs/004-portable-deletable-financial-data)
requires portable and deletable household data while excluding financial content from general
telemetry. Balances, transaction text, account names, tax assumptions, forecasts, imports, and
calculation inputs can otherwise spread into logs, analytics, exports, temporary processing, and
backups.

The architecture needs one governed storage boundary and a complete inventory of copies. It also
needs enough source provenance to meet
[ADR 000](/projects/personal-finance-app/adrs/000-financial-fact-and-calculation-provenance)
without treating immutable active records as exempt from household deletion.

## Decision

Keep financial content inside stores governed by household authorization and the household data
lifecycle. General analytics and operational telemetry accept only non-financial metadata. Their
schemas reject financial values, user-entered financial text, source documents, and stable domain
identifiers that could reconstruct household activity.

Maintain a store inventory for primary records, source artifacts, derived results, exports,
temporary objects, logs, analytics, and backups. Each entry names its data class, retention rule,
export behavior, and deletion mechanism. A household deletion operation uses that inventory and
records completion without retaining the deleted financial content.

Keep source material and calculation lineage only in inventoried stores that support the product's
explanation and reproducibility guarantees. Export reads from the governed records and emits the
document directly to the requesting household rather than creating an untracked permanent copy.
Retention periods and backup expiry belong in operating policy so they can change without revising
this storage boundary.

## Consequences

Operational systems cannot become an accidental second financial datastore. Schema controls and the
store inventory make copies visible enough to test export and deletion behavior. The application
will collect less detailed product analytics than a system that emits domain activity to an
analytics provider.

Complete export and deletion require an inventory of every store that may hold financial content.
Some historical calculations may become irreproducible after their source material is deleted. The
product must represent that limit as required by PDR 004.

## Alternatives considered

### Send financial domain activity to analytics

This would support richer product analysis. It was rejected because even structured transaction and
calculation events can reveal a household's financial behaviour without obvious personal fields.

### Exempt immutable history from deletion

This would preserve every audit trail. It was rejected because immutable financial records remain
personal data. Their storage model does not give them a separate lifecycle from the household.

---

Markdown index of this site: https://robbiepalmer.me/llms.txt