ADR-0008: Processing Decision Taxonomy

Context

• Inbox items are raw text captures; they must be classified during the processing/clarification step.
• The app must support a small, well-defined set of post-capture outcomes so downstream features can rely on typed data.
• Processing happens on-device; UI/UX details are out of scope for this ADR.

Decision

We will adopt a lightweight two-tier taxonomy during processing:

• Top-level: Actionable vs Non-actionable.

• Actionable sub-decisions (one of): Do (execute now), Delegate, Defer.

• Non-actionable sub-decisions (one of): Trash, SomedayMaybe, Reference.

• Additive non-actionable subtype: Reflection — captures short personal notes or journal-like items intended for reflection rather than reference.

Behavioral rules:

• While processing an InboxItem the user may edit the text; the edited text becomes the canonical content used when creating the ProcessedItem.

• Each processed item will be assigned a ProcessedType enum capturing the chosen outcome (e.g., Task, Reference, Someday).

• Each processed item will be assigned a ProcessedType enum capturing the chosen outcome (e.g., Task, Reference, Someday, Reflection).

• The processing UI will present metadata fields (tags, category, context) that may be attached to the resulting ProcessedItem; the first ADRs accept these as optional metadata only.

Scope boundaries:

• This ADR defines decision taxonomy and resulting ProcessedType. It does not define UI surfaces or exact persistence schemas (covered in ADR-0009), nor background scheduling behavior.

Rationale

• Minimal, orthogonal set: Actionable vs Non-actionable matches common capture workflows (e.g., GTD). Sub-decisions cover the typical outcomes.
• Explicit Do vs Defer vs Delegate provides clear signals for downstream handling (immediate execution vs scheduling vs assignment).
• Allowing text edit during processing preserves user intent and eliminates mismatch between capture and processed content.
• Keeping metadata optional avoids early over-design; allows later extension.

Consequences

• Positive:

  • Simpler downstream consumers because ProcessedType is explicit.
  • Easier analytics and filtering (e.g., count of actionable items).

• Downsides:

  • A small taxonomy may not cover niche outcomes (future ADR for additional types/lenses).
  • UI must enforce exclusive sub-decisions to keep the model consistent.

Alternatives Considered

• More granular taxonomy (e.g., separate Reminder, Meeting, Purchase types) — rejected for MVP complexity.
• Allow multiple simultaneous outcomes (e.g., both Reference + Task) — rejected to keep a single canonical processed type and predictable downstream behavior.

Notes

• Metadata fields considered for later ADRs: tags (many-to-many), category (single value), context (location/people). See ADR-0011 for extensibility.