Study progress and review history
These records describe existing study state for backup and migration. Do not invent past reviews, success statistics, or scheduler memory for newly generated cards. Omit these directories for new material; Flashnerd initializes newly imported cards linked to a set as New. Overriding an existing collection can retain existing progress; omission is not a reset command. Restoring progress requires the archive import workflow and Include study progress, which starts off. See Back up and restore.
The comprehensive download contains synthetic schedules and review events to demonstrate every shape. Importing that example with progress enabled adds demonstration history to the collection; it is not evidence of real study. Schedule snapshots are authoritative; the app does not replay the history to reconstruct a schedule. If supported content is valid but progress cannot be converted, the app can report a warning and omit all schedules and both history collections.
The short examples below share these companion records. Save each compact object in its named JSONL file; include all three when using the short schedule or SRS-history examples. Normal-history examples need only the deck and card.
content/decks/tokyo.jsonl:
content/cards/tokyo.jsonl:
srs/srs_sets/daily.jsonl:
Schedules
Schedule purpose and location
Schedules store the current scheduler state. Save progress/schedules/*.jsonl, for example progress/schedules/current.jsonl, with one object per line. Any direct-child .jsonl filename is accepted. This collection is optional and exported only with the backup profile. Import discovers it without a manifest.
Schedules are authoritative: history is not replayed to reconstruct them. A package creating fresh cards can omit progress and history.
Schedule basic example
Write this record in the location above:
Schedule full example
Download the comprehensive example’s progress/schedules/00000.jsonl, or read its expanded records below. Each object occupies one physical line in the file; the formatting here is for reading.
These are separate schedules for five different cards, not multiple snapshots for one card. Include their cards, decks, and sets from the full source tree. Each state has different allowed null values; a New record cannot have the populated memory fields shown by Relearn. The initial-learning example uses card-read-line from the linked full card file.
Relearning with a complete memory snapshot
New: no memory snapshot
Learning after a review
Review: no learning step
Initial learning before a first review
Schedule fields
Extra properties are ignored. Use timestamp rules. The format does not impose extra numeric ranges on step/counts/stability/difficulty; supply meaningful scheduler values. Missing decay stays unknown and is not filled from current settings.
The two due fields are mutually exclusive. A record with both populated or neither populated is rejected, even when a supplied timestamp could agree with a supplied date. No due value is inferred from another field. Learn, Review, and Relearn accept either due representation; New accepts only a timestamp. Suspension and disabling do not change this contract.
scheduledIntervalMs is independent of the due representation: either kind can have an unknown nominal interval. A nominal one-day interval is 86,400,000 milliseconds even when the effective wait until the next reset is shorter. The application resolves dueReviewDay using its current study-day reset and timezone; changing either can change the effective instant without changing the stored date. The stored dueReviewDay is preserved without a timestamp fallback. The import preview evaluates it using the current review timezone and the reset settings that will apply after import.
State constraints
suspended, disabled and struggle are not valid schedule states. Use the boolean flags alongside one of the four phases.
Schedule relationships and another example
Include the referenced card, its deck, and an SRS set whose deckIds includes that deck. Each card can have only one schedule. Cards, sets, and this schedule need explicit IDs when another record references them. Cards whose own ID was omitted cannot be targets. SRS history refers to this record's id through srsCardId. With Override Existing, Flashnerd updates the schedule owned by the referenced card and keeps that local schedule ID.
Anonymous schedule for an explicit card. Reimporting it creates a new schedule row unless Override Existing updates the schedule already owned by that card:
For a recorded New-state snapshot, replace the basic record with this complete minimal schedule; do not include both records for the same card:
SRS reviews
SRS review purpose and location
Each record is an SRS answer event. Save history/srs_reviews/*.jsonl, for example history/srs_reviews/reviews.jsonl, with one object per line. Any direct-child .jsonl filename is accepted. This optional collection is exported in backups; import discovers it directly.
SRS review basic example
Write this record in the location above:
SRS review full example
Download the comprehensive example’s history/srs_reviews/00000.jsonl, or read its expanded records below. Each object occupies one physical line in the file; the formatting here is for reading.
The two log types share the same record shape. Both examples include all optional snapshot values and link to schedules in the full package. The linked JSONL file also has Hard and Easy native reviews, so its four records show all rating strings. Review history does not replace the authoritative schedule snapshot.
Native review with every snapshot field
Archived review
Review with a separately assigned review day
This event occurred on March 1 in UTC but belongs to the March 2 review day. Preserve reviewPeriodKey as supplied; it is not derived from the UTC date of occurredAtUtc.
SRS review fields
Extra properties are ignored. The format does not apply additional numeric bounds to the duration, interval, stability or difficulty fields. Missing historical values stay unknown. The app preserves supplied values but may estimate missing stability from a nextReviewIntervalMs of at least one day when srsState is omitted or review. When the resulting stability is positive and finite, missing decay is filled from the source schedule’s usable decay or the default FSRS decay. These are 90%-target approximations, not a replay of historical scheduling. Missing difficulty remains unknown. Decay does not require a manifest feature declaration on import.
Use only new, learn, review, or relearn in historical srsState, or omit it. suspended, disabled, and struggle are not importable history states: the app omits all schedules and both review-history collections when it encounters one in retained history. Valid content may still be imported with a warning. Record suspension with wasSuspended.
The app imports native and archive events the same way and exports stored SRS reviews as native. That label distinction does not survive an app import/export cycle.
SRS review relationships and review dates
Include the referenced schedule and its content card, deck and SRS set. The schedule must supply its own id. History does not replace the schedule, and it cannot target an anonymous card or anonymous schedule.
Anonymous event against an explicit schedule. Importing the same line again adds another event:
occurredAtUtc and reviewPeriodKey are independent and required for both native and archive records. A review near midnight can belong to a different review day because of timezone or rollover preferences. Do not derive the day from the UTC date. See timestamp and calendar-date rules.
This complete archived event demonstrates a different assigned day and optional fields. It may be added as another line with its distinct event ID:
Normal reviews
Normal review purpose and location
These are answer events from flashcard or matching study, outside SRS. Save history/normal_reviews/*.jsonl, for example history/normal_reviews/reviews.jsonl. Any direct-child .jsonl filename is accepted; use one complete object per line. This optional collection is exported in backups.
Normal review basic example
Write this record in the location above:
Normal review full example
Download the comprehensive example’s history/normal_reviews/00000.jsonl, or read its expanded records below. Each object occupies one physical line in the file; the formatting here is for reading.
These separate events show both supported modes and both correctness values. Their cards and historical decks are included in the full package. All optional duration and identity fields are populated.
Correct flashcard review
Incorrect matching review
Normal review fields
Extra properties are ignored. Normal reviews do not use SRS ratings, schedule snapshots, or logType.
Normal review relationships and another example
Include the referenced card and deck. Both must supply their own IDs. An SRS set or schedule is not needed for normal history.
Anonymous event against an explicit card. Importing the same line again adds another event:
The assigned day is independent of the answer's UTC date and is never recalculated on import. Both values are mandatory; see timestamp and calendar-date rules.
A matching answer can be another line with a distinct event ID: