Many watch-history systems can tell you that an episode was watched. The harder question is what they should do when it was watched again.

A single “watched” state is convenient for a checklist. A count is useful for a summary. Neither represents the experience that a second viewing creates. The earlier watch had its own date, sequence, notes, and context. Replacing it with the latest timestamp destroys that history; incrementing a counter keeps the quantity but not the journey.

CutSeen models each rewatch as a separate run.

The event is more important than the aggregate

An imported viewing export may contain repeated rows for the same episode. CutSeen sorts those records chronologically and places the first watch of each episode into the first run, the second into the second run, and so on. The run with the most-rewatched episode determines how many viewing histories the show needs.

That rule reconstructs a useful sequence from data that another system stored as duplicate activity. It does not pretend the export contains a perfect narrative. It gives each recorded watch a place without collapsing the earlier one.

The product can then attach observations to the viewing that produced them. A note from the first watch does not become a note from the second. A later interpretation can coexist with the earlier response instead of overwriting it.

This matters most when the purpose is analysis rather than completion tracking. What a viewer noticed, expected, or misunderstood can change across encounters with the same work.

Missing precision should remain visible

Imported dates are not equally reliable. A full timestamp can be preserved as exact. A date without a meaningful time is stored with day-level precision. An absent or unparseable value remains unknown.

The system can still place unknown-date records into backfilled history, but it cannot claim an exact chronology it did not receive. When duplicate watches lack usable dates, the dry run warns that the rewatch order may be approximate.

That warning is part of the feature, not an implementation footnote. A product that reconstructs history should tell the user which parts are reconstruction and which parts came directly from the source.

Preview the interpretation before writing it

Importing is not just file parsing. The system has to decide which rows count as viewings, which titles match existing records, how episodes group into shows, and how repeat activity becomes runs.

CutSeen produces a dry-run report before database writes. The report can identify unrecognized files, rows with unusable dates, movie-only exports that are not supported by the current release, skipped watchlist activity, and shows likely to produce rewatch runs.

This gives the user a chance to inspect the proposed interpretation of the source. A valid CSV is not automatically a valid history.

The importer also excludes non-watch activity such as watchlist or follow records from viewing history. That distinction seems obvious until an export uses one activity column for several kinds of intent. The parser must read the domain, not just the rows.

Recovery changes what can be attempted safely

An import that writes many related records needs a recovery design before the first write.

CutSeen records an authoritative batch as soon as the import begins. Recoverable states remain discoverable after an application relaunch. Rollback removes batch-owned records, and a verification step checks whether events or runs remain and whether the batch reached the expected state.

This does not guarantee that every import is correct. It changes the cost of discovering that one is wrong. The user can preview the plan, perform the import, and retain a path back to the prior state.

Product teams often describe rollback as an operational concern. Here it is part of the user promise: imported history should not become irreversible simply because it spans several tables.

The strongest alternative is a simpler model

A single latest-watch timestamp and a watch count would be easier to implement and easier to explain. For products focused on recommendation or completion, it may be enough.

It is not enough for CutSeen’s purpose. A count of three cannot show that a note belonged to the first watch, a correction to the second, and a comparison to the third. Once those events are flattened, the richer record cannot be reconstructed later.

The additional model has costs. Runs must be created deterministically. Imports need idempotency controls. Incomplete histories and approximate ordering must be communicated. Interfaces need to show multiple journeys without making a common first-watch workflow cumbersome.

Those costs are justified only because the repeated viewing is meaningful in the product domain.

A test for historical product data

When an application receives repeated activity, ask what kind of thing is being stored.

If the newest value corrects the old one, replacement may be appropriate. If the values describe independent events, overwriting loses information. If only the aggregate matters, a count may be sufficient. If the sequence changes the interpretation, the model needs chronology and precision.

Then test the import boundary:

  • Can a user see what the system plans to create?
  • Are unsupported and ambiguous records separated from routine ones?
  • Does uncertain time remain uncertain?
  • Can the write be retried without duplication?
  • Can it be rolled back and verified after interruption?

The questions apply beyond media software. Repeated reviews, approvals, measurements, and status changes all risk being flattened into a convenient current state.

The same distinction shaped a second studio tool, a browser-local application-history record that is being tested with people outside the studio. When an interview or assessment entry is corrected, the correction is appended and the original entry stays in the history. Elapsed-time observations take their date from the record that is current, so a later edit is not mistaken for fresh application activity. A correction can change what the system considers current without erasing how the record arrived there.

A rewatch deserves its own history because the second encounter does not correct the first. It adds another piece of evidence.

See the case record for preserving every viewing journey.