Continuum PHOTOS
MenuClose

The Photo Library / Schema 6

A place for every detail.
A record you can read.

A schema is simply a shared set of labels and rules. It explains where each piece of information belongs, what it means, and how to read it again—without needing the app that wrote it.

This guide walks through the Catalog format used by Continuum’s schema 6. You don’t need to learn it to use Continuum. It’s here so you, or someone working with your Photo Library years from now, can understand what’s been saved.

See a Realistic Example

01 / The structure

A folder of folders.

The Photo Library is your main folder. Inside it are Groups: the collections you choose to keep together. Each Group folder contains its digital Photos and one Catalog, a text file ending in .toml.

My Photo Library
A Group folder1948-08-XX-PRT_HARDCOPY-0007/
  • Photo filesThe digital images themselves.
  • One Catalog1948-08-XX-PRT_HARDCOPY-0007.tomlThe Group’s details and a record for every Photo.
continuum.photos/Shared library information, including the schema and virtual albums.

The Catalog has the same name as its Group folder, with .toml added. TOML is a structured text format: labels on the left, values on the right, and headings to keep related details together.

The shared continuum.photos folder is separate from the Groups. Its schema.toml describes the Catalog format. It can also contain settings, virtual albums, operation history, and recovery material created by the app. Keep this folder when copying the whole Photo Library.

The Catalog is not the image. A Photo can have a record before its scan exists. The Catalog preserves what you know about it while the image file is still pending.

02 / Reading the record

One Photo, explained.

Imagine a packet developed in August 1948. One picture was taken in July, and its print is now in a blue album. Here is an invented, valid Catalog showing those distinctions.

[group] starts the details for the whole Group.

[[photo]] starts a Photo record. Repeat it for the next Photo.

[[photo.print]] adds a physical print to the Photo above it.

# An invented example: one Group, one Photo, and one physical print.
[group]
schema_version = 6
catalog_updated = 2026-09-09
medium = "PRT_HARDCOPY"
group_number = 7
status = "ARCHIVED"
date_earliest = "1948-08-XX"
date_latest = "1948-08-XX"
size = "4x6"
inscription = 'Summer at the lake, 1948'

[group.subject]
event = "A summer at the lake"
place = "Willow Lake"

[[photo]]
photo_id = "153b689f-5e9e-4a91-bdba-d33d370264ce"
seq = 1
scan = "PRESENT"
scan_source = "PRINT"

[photo.subject]
date_earliest = "1948-07-18"
date_latest = "1948-07-18"
notes = "The date was written in the family diary."

[[photo.subject.person]]
name = "Alex Morgan"
x = 0.35
y = 0.42
notes = "Identified by a relative."

[[photo.print]]
copy = 1
print_location = "ALBUM"
print_location_note = "Blue album, page 12; hall cupboard, upper shelf."

# introduces a comment. Quoted values are text; seq = 1 is a number. The unquoted catalog_updated value is a full calendar date. Double brackets mean “another item of this kind,” so a Photo can have several people and several physical prints.

Keep the people and print sections after the Photo they describe and before the next [[photo]]. That placement is how the text file associates them.

Download This Example

03 / Dates and uncertainty

You don’t have to invent a date.

date_earliest and date_latest describe the range you can support. Set them to the same value for a single known date. Use X where a digit is unknown.

Saved valueMeaning
1948-07-18July 18, 1948.
1948-07-XXJuly 1948; the day is unknown.
1948The year is known.
194X-XX-XXSomewhere in the 1940s.

Three dates can describe three different things.

The dates under [group] describe the developing packet or the date range of an assembled collection. Dates under a subject heading describe when the pictures were taken. catalog_updated is when the record was last changed.

For Photo filenames and chronological browsing, a Photo’s own taken-date takes priority; otherwise Continuum uses the Group’s main dates. The full range remains in the Catalog even when a filename can only summarize it.

Shared details, with room for exceptions.

A Group’s subject can supply shared place, event, and taken-date details. A Photo’s subject can override individual fields. If the Group says “Willow Lake” but one Photo says “On the train,” that Photo keeps its more specific place. Notes are different: Group notes and Photo notes both remain meaningful; one does not erase the other.

A sorting date is not new evidence. An uncertain date may be represented by a particular day when sorting or writing compatible photo dates. That does not make the original date exact. Keep the Catalog’s uncertainty and the notes explaining your evidence.

04 / The things on your shelf

One image. Several physical copies.

A Photo record describes a photograph. Its print entries describe the individual physical prints you have: one in an album, another framed on a wall, perhaps a third with a relative. Give each copy its own location and notes.

print_location is the broad category. print_location_note tells you which album, box, shelf, or person. Use OTHER for a location outside the standard categories and explain it in the note. A print’s own size overrides the Group’s default size; omitting both means it has not been measured.

Separate “where is it?” from “can I use it?”

  • scan = "PENDING": the digital file has not arrived yet.
  • print_location = "MISSING": a recorded physical print is unaccounted for.
  • condition = "NO_IMAGE": the print exists but has no usable picture.

Negatives have a Group-level custody summary and a per-Photo negative field for missing or unusable frames. A complete strip can still contain a blank frame. These are different facts and deserve different labels.

Keep the original words, too.

inscription is a transcription of writing on a packet or photograph. Preserve it as written. Use notes for your interpretation—“I think this means July,” for example. That lets future readers distinguish the evidence from your conclusion.

05 / Finding the same Photo again

A filename can change.
A Photo’s identity stays.

A Group ID combines the medium and its number: PRT_HARDCOPY-0007. Its folder adds a date prefix. A Photo filename adds its sequence number, such as 1948-07-18-PRT_HARDCOPY-0007-001.jpg.

Dates, Group membership, and sequence positions can change as you learn more. That is why schema 6 gives each Photo a separate photo_id: a permanent UUID, the long identifier in the example. It stays with the Photo when it moves, is reordered, or receives a replacement scan. It identifies the Photo, not the exact bytes of one image file.

Virtual albums refer to Photos; they don’t move them.

An album has its own small TOML record in continuum.photos/albums/. It contains an album ID, a name, and a list of Photo IDs. A Photo can belong to several albums while its image and Catalog stay in their Group. Album records currently have their own format version, 1; that is separate from Group Catalog schema 6.

Names can point to faces.

Each person entry can include a name and optional x and y positions. In the example, 0.35 means 35% of the way across the picture; 0.42 means 42% down. This works at different image resolutions. Cropping or rotating the picture can require updating the positions. A name without a face position is also valid.

06 / Progress and checks

“Archived” doesn’t mean
“nothing left to learn.”

The usual Group milestones are PLANNED, SCANNING, DIGITIZED, and ARCHIVED. They record progress from a collection awaiting work to digital files and filed physical originals. Open tasks can remain at any stage.

MERGED is a separate state. When a Group is merged, its old record can remain as a signpost, with merged_into identifying the destination. That helps old references keep their meaning.

The schema also defines checks: required fields, allowed values, valid numbers, and conditions. For example, a present scan needs a source, and an OTHER print location needs an explanation. Additional library checks look at files and relationships. Passing a check means the record follows the rules—not that a remembered name or estimated date is historically certain.

Let the app maintain identifiers. Group numbers, Photo IDs, sequence numbers, print-copy numbers, and update stamps are managed by Continuum. When experimenting by hand, use a copy of the library and verify it before replacing anything.

07 / Preservation beyond the app

Three layers of information.

01

Names and folders

Show dates and Group organization in an ordinary file browser.

02

The Catalog

Keeps the detailed, structured record: people, date ranges, originals, locations, inscriptions, and tasks.

03

Metadata inside a Photo

Can carry information into compatible photo apps. EXIF date updates are one example. Writing metadata is a separate action, and support depends on the file and the receiving app.

Saving a Catalog does not automatically embed all its fields into every image. A phone may understand an embedded date without understanding a Group, an uncertain range, or a physical print’s location. Keep the Catalog even when you also write image metadata.

What would another application need to do?

  1. Read the library’s schema and the version recorded in each Group Catalog.
  2. Use a TOML reader to load each Catalog and its nested Photo, person, and print records.
  3. Match image files using the naming rules, and use permanent Photo IDs for references such as virtual albums.
  4. Preserve unknown dates, original inscriptions, and any fields it does not yet understand.

That still takes an importer. A readable format is a practical starting point, not a promise that every existing photo app already understands it.

The schema can grow.

The app version and the schema version are different numbers. The schema’s rules allow new optional fields and new allowed values without removing older ones. Breaking changes require a new schema version and a migration. The copy saved with your Photo Library helps explain the records even after the app changes.

Back up the whole Photo Library: the Photos, each Group Catalog, and the shared continuum.photos folder. If Continuum disappears, retained image files can still open in compatible viewers and the Catalogs can still be read. If the Catalog itself is lost, details stored only there are lost unless you have another copy. The image cannot give back information it never contained.

08 / When you want the detail

Every field, in plain English.

These lists come from the schema 6 definition included in the downloadable sample Photo Library. Expand a section when you need it. Optional usually means “leave it out when you don’t know,” but some fields have specific defaults or meanings when absent, as described above.

The Group group 14 fields
FieldWhat it meansWhen it is needed
schema_versionThe format version this record follows. Written by Continuum.Required
catalog_updatedThe date Continuum last changed the saved Catalog. This is not the photo date.Required
mediumThe kind of original material: 35mm film (135), 110 film, Kodak Disc (DSC), hardcopy prints (PRT), instant photos (PLR), or digital originals (DIG).
Allowed values: 135_NEGATIVE, 110_NEGATIVE, DSC_NEGATIVE, PRT_HARDCOPY, PLR_INSTANTS, DIG_ORIGINAL
Required
group_numberThe Group number within its medium, assigned by the app. From 1 to 9999.Required
statusThe milestone reached by the Group, or a record that it was merged elsewhere.
Allowed values: PLANNED, SCANNING, DIGITIZED, ARCHIVED, MERGED
Required
date_earliestThe earliest date supported by what you know. Unknown digits can be X. At Group level this records the developing/packet date, or the range for an assembled collection.Required
date_latestThe latest date supported by what you know. Match the earliest date for a single date. At Group level this records the developing/packet date, or the range for an assembled collection.Required
photo_ownerWhose packet or collection this was.Optional
sizeThe print dimensions, such as 4x6 or 3.5x5. Put the smaller dimension first. This is the default for prints without their own size.Optional
negatives_custodyWhether the Group’s negatives are all accounted for, partly missing, or entirely missing.
Allowed values: ARCHIVED, PARTIAL, MISSING
Required when the medium is a negative; omitted otherwise
merged_intoThe destination Group ID after a merge; for example, PRT_HARDCOPY-0007.Required when the Group has been merged
inscriptionAn exact transcription of writing on the packet or photograph.Optional
notesYour explanation or observations. Separate from the original inscription.Optional
tasksA list of things still to do. Tasks can remain after a Group is archived.Optional
What the Group’s Photos show group.subject 5 fields
FieldWhat it meansWhen it is needed
placeWhere the photograph was taken; this is not the storage location.Optional
eventThe occasion or event shown in the photographs.Optional
date_earliestThe earliest date supported by what you know. Unknown digits can be X.Optional
date_latestThe latest date supported by what you know. Match the earliest date for a single date.Optional
notesYour explanation or observations. Separate from the original inscription.Optional
Each Photo photo 9 fields
FieldWhat it meansWhen it is needed
photo_idA permanent UUID identifying the Photo through moves, reordering, and replacement scans.Required
seqThe Photo’s position in its Group, starting at 1. Assigned and maintained by the app.Required
scanWhether a digital image file is present or still pending.
Allowed values: PRESENT, PENDING
Required
scan_sourceWhether the file came from a negative, a print, or a digital original.
Allowed values: NEGATIVE, PRINT, NATIVE
Required when the image file is present
developer_codeAn original lab or print-order code, kept as written. Not an app-generated ID.Optional
negativeAn exception for this Photo’s negative: missing, or present without a usable image.
Allowed values: MISSING, NO_IMAGE
Optional
inscriptionAn exact transcription of writing on the packet or photograph.Optional
notesYour explanation or observations. Separate from the original inscription.Optional
tasksA list of things still to do. Tasks can remain after a Group is archived.Optional
What this Photo shows photo.subject 5 fields
FieldWhat it meansWhen it is needed
placeWhere the photograph was taken; this is not the storage location.Optional
eventThe occasion or event shown in the photographs.Optional
date_earliestThe earliest date supported by what you know. Unknown digits can be X.Optional
date_latestThe latest date supported by what you know. Match the earliest date for a single date.Optional
notesYour explanation or observations. Separate from the original inscription.Optional
People in this Photo photo.subject.person 4 fields
FieldWhat it meansWhen it is needed
nameThe person’s name as known or recorded.Required
xHorizontal face position: 0 is the left edge and 1 is the right edge.Optional
yVertical face position: 0 is the top edge and 1 is the bottom edge.Optional
notesYour explanation or observations. Separate from the original inscription.Optional
Each physical print photo.print 6 fields
FieldWhat it meansWhen it is needed
copyThis physical print’s number within the Photo, starting at 1.Required
print_locationWhere this particular print is, including an explicit missing state.
Allowed values: ARCHIVED, DUPLICATE_BOX, ALBUM, DISPLAY, OTHER, MISSING
Required
print_location_noteThe specific album, shelf, box, relative, or other location.Required when the print location is OTHER
conditionAn exception for a print with no usable image. Missing belongs in print_location.
Allowed values: NO_IMAGE
Optional
sizeThe print dimensions, such as 4x6 or 3.5x5. Put the smaller dimension first.Optional
notesYour explanation or observations. Separate from the original inscription.Optional

Reference: Catalog schema 6, released September 6, 2026. The example has been checked against that schema. The schema definition describes field rules; filenames, virtual albums, and library operations also have rules in the application.