Life eras

Life eras organize the archive around overlapping personal contexts rather than a single folder tree. An item can belong to several eras. An owner explicitly includes or excludes it; a date range or contextual clue does not silently assign membership.

This page reflects source and operational documentation inspected on October 13, 2026, at revision e76e74c. It distinguishes implemented behavior from dated rollout evidence. It does not establish current production counts or the accuracy of model suggestions.

Membership is a decision

An invented photo might connect a work era, a friendship and a decade of life. Keeping those associations separate avoids forcing it into one exclusive category. Eras can have descriptive dates, text and linked clues; unknown years remain blank rather than being invented to complete a timeline. Era model and behavior (docs/LIFE_ERAS.md:3).

Membership can refer to photos, unique files, directories and projects. The mixed file browser reconciles historical photo/path decisions with unique-content/hash decisions, deduplicating exact content. An exclusion on either identity wins. Directory assignment does not recursively include everything beneath the directory, and excluding an item from one era does not delete it or exclude it from every other era. Membership identity (docs/LIFE_ERAS.md:47).

Browse the included material

Named era pages combine photos, videos, audio, documents and other included files. Search matches canonical path or content hash within the current era. Type, recorded capture year, GPS availability, size and sorting refine that set; unknown dates and missing previews remain visible rather than becoming guesses.

Some Flatiron location filters select GPS points within 250 metres of named campus coordinates. That means geographical proximity, not proof that a photograph was taken inside a school building. The October 1, 2026 rollout record reports an owner-approved manifest of 5,357 content hashes: 5,174 photos and 183 videos. It is a historical collection checkpoint, not a current gallery count. Browser controls and rollout record (docs/LIFE_ERAS.md:17).

Suggestions use metadata and context

Era analysis is a separate, bounded workflow. The owner selects 1–20 file contents, reviews outbound metadata and enabled clues, and confirms a batch. Inputs include scanner paths, hash, extension, size and occurrence count. This workflow does not read pixels, OCR or file contents.

Results provide independent probabilities for overlapping eras. They remain suggestions; accepting membership requires a separate owner action. Source digests and definition versions identify stale evidence when relevant inputs change. A token reservation ceiling limits application admission, not provider billing. Analysis implementation (app/services/life_eras/analyze_item.rb:29), operating specification (docs/LIFE_ERAS.md).

flowchart LR
  M[Selected file metadata] --> P[Reviewed outbound preview]
  C[Enabled context clues] --> P
  P --> A[Bounded analysis batch]
  A --> S[Versioned suggestions]
  S --> H[Owner include or exclude]
  H --> R[Production authority revisions]
  R --> L[Development mirror]

Shared context has its own authority

Production owns era definitions, clues, assignments and revision history. Development reads a mirror and forwards owner edits to the authority. Optimistic versions reject stale changes, request keys support idempotency, and revisions retain an audit trail. Authority writes (app/services/life_eras/authority.rb:19).

This flow runs in the opposite direction from ordinary archive metadata synchronization. Portable suggestions can travel with development’s incremental export, but definitions and memberships do not become local-owned rows simply because analysis ran locally. Operations explains the ownership distinction.

The result is a contextual organization layer whose meaning remains editable and explicit. It complements filename search and file classification without claiming automatic life reconstruction or archive-wide semantic retrieval.