ADR-0009: One-to-one Transformation Model

Context

• Processing converts a raw InboxItem into an intentional ProcessedItem used by other app features.
• We need a clear data model and lifecycle for what happens to the original InboxItem during/after processing.

Decision

We will adopt a one-to-one transformation model where a processing operation produces a single ProcessedItem derived from the (optionally) edited InboxItem content. To keep storage simple and bounded, the originating InboxItem will be removed from the inbox store immediately after a successful transformation (no persistent link is kept).

Key rules:

• Creation: Processing creates one ProcessedItem from the edited InboxItem content and attached metadata.
• No origin link: ProcessedItem will NOT store originInboxId; tracing back to the original capture is intentionally omitted to avoid unbounded store growth.
• Atomicity: The transformation (create ProcessedItem then delete the InboxItem) should be performed as an atomic transaction where supported to avoid partial states.
• Outcome mapping:
  • If the decision is Do (execute now / thrash), no persistent ProcessedItem is required unless the action also needs tracking; the InboxItem will be deleted as part of processing.
  • For Delegate, Defer, and all Non-actionable outcomes (including Reflection), a ProcessedItem record is created and the original InboxItem is deleted immediately afterward.

Scope boundaries:

• This ADR specifies the transformation semantics and traceability. It does not define the full DB schema (columns are suggested below) or UI flows.

Rationale

• One-to-one mapping keeps model simple and predictable.
• Atomic transformations avoid partial states where an item appears processed but no ProcessedItem exists (or vice versa).

Suggested Persistence Shape (example)

• InboxItem (existing): id, rawText, capturedAt
• ProcessedItem: id, content (canonical text), capturedAt, processedAt, processedType (enum: e.g., Task, Reference, Someday, Reflection), tags (relation), category (string), context (string)

Consequences

• Positive:

  • Clear audit trail and ability to recover or show original capture.
  • Predictable mapping for business logic and reporting.

• Downsides:

  • Slightly more storage and schema complexity.
  • Need for migrations if the actionDetails shape changes; prefer an extensible key-value or JSON column for early iterations.

Alternatives Considered

• In-place mutation: modify InboxItem into a processed record — rejected because it loses the original capture and reduces traceability.
• Multi-output transforms (one inbox -> multiple processed items) — rejected for now; complexity reserved for future ADRs (processing lenses).