Capture Items

A capture item is the first bounded object created from a capture.

It is not yet necessarily an artifact.

It exists so the system can classify, review, merge, promote, archive, or discard captured material without treating every output as equally durable.

Capture items make the downstream handling of capture explicit while keeping the framework compact. They preserve the core logic already used elsewhere in this manual:

• threads process
• artifacts persist
• promotion is selective
• not everything deserves preservation

Why capture items exist

A raw capture often contains material that is still partial, repetitive, uncertain, or too local to deserve durable preservation.

Without an intermediate object, the system tends to make one of two mistakes:

1. treating every captured output as if it were already artifact-worthy
2. letting useful but unstable material accumulate as ungoverned note clutter

Capture items solve this by giving the system a small, reviewable unit that can be handled before durable promotion.

Core distinction

Object	Role	Best for
Thread	Processing container	active work, ambiguity, back-and-forth
Capture item	Reviewable bounded unit	triage, merge, promotion, discard
Artifact	Durable output	reuse, reference, re-entry

A thread is where work continues.

A capture item is what gets reviewed.

An artifact is what persists for future reuse.

Minimal rule

Every capture should first produce one or more capture items.

A capture item may then:

• remain ephemeral
• stay working
• merge with another item
• promote into an artifact
• archive
• discard

This keeps promotion selective without requiring a heavy workflow layer.

Allowed actions

The downstream action set should remain small.

A capture item can be:

• edited
• merged
• promoted
• archived
• discarded

This is intentionally narrow. It should be possible to govern most downstream handling with these few actions rather than introducing many custom operations.

Lifecycle

The basic downstream lifecycle is:

Capture -> Capture Item -> Review -> Merge / Promote / Archive / Discard

This should be read as a practical path, not as a large state machine.

Relation to threads and artifacts

Capture items sit between capture and durable promotion.

They do not replace threads, and they are not a second kind of artifact.

They are the bounded units the system uses to decide what should stay local, what should become durable, and what should quietly leave the active surface.

In practice:

• a thread may contain many capture items during active work
• some capture items may never become artifacts
• some artifacts may be created by promoting one item
• some artifacts may be created by merging several related items first

Minimal schema

The schema should be stable and small enough that assistants can already return capture items in a shape that fits the future app naturally.

capture_item:
  id: string
  created_at: datetime
  source_capture_id: string
  title: string
  body: string
  lane: enum
  mode: enum
  likely_artifact: enum | null
  retention: enum(ephemeral, working, durable, canonical)
  status: enum(active, archived, discarded, promoted, merged)
  parent_thread_id: string | null
  promoted_artifact_id: string | null
  merge_parent_id: string | null
  review_reason: string | null
  confidence: float | null

Field notes

id

Stable identifier for the capture item.

created_at

Timestamp for when the item was created.

source_capture_id

Reference back to the originating capture event.

title

Short bounded summary of the unit.

body

Main content of the item.

lane

The lane this item belongs to.

mode

The capture mode used to create or classify it.

likely_artifact

The most likely artifact destination, if one is already visible.

If unclear, leave it null rather than forcing an early commitment.

retention

Reuse the existing retention vocabulary:

• ephemeral
• working
• durable
• canonical

This avoids introducing a second permanence ontology.

status

A small lifecycle field for downstream handling:

• active
• archived
• discarded
• promoted
• merged

This is intentionally tiny.

parent_thread_id

Optional link to the thread where this item is being processed.

promoted_artifact_id

Optional link to the artifact created from this item.

merge_parent_id

Optional link to the merged representative item if this item was merged into another.

review_reason

Short explanation of why the item is being surfaced or held for review.

This is especially useful when AI is doing first-pass triage.

confidence

Optional confidence estimate for the assistant's classification or recommendation.

What the schema does not include

The schema intentionally does not include:

• tags
• queue names
• urgency scores
• novelty scores
• custom metadata blobs

Those may become useful later, but they are not required to stabilize the system now. They can be derived or added later if needed.

Working rule for assistants

When assistants create capture items, they should:

• use canonical lane and mode vocabulary only
• keep the item bounded and reviewable
• assign a likely artifact only when it is genuinely visible
• prefer the lighter state when uncertain
• avoid inventing extra categories

Practical interpretation

A capture item is not meant to be cherished by default.

It is meant to be handled well.

The goal is not to preserve all captured material. The goal is to preserve what is worth preserving, merge what becomes clearer together, and let the rest leave the active surface without friction.