Adapting the design

Avichive grew from a personal inventory into a system for interpreting and recovering an archive. Its reusable ideas are the boundaries between discovery, identity, evidence, decisions and presentation. Adapting it starts with understanding those boundaries, then changing the part that owns the information you need.

Begin with your discovery policy

The Go scanner’s extension maps, exact directory exclusions, sensitive-path patterns and worker limits are concrete customization points. They determine what enters the catalog and which initial clues accompany it. A skip rule is consequential: omitting a Git directory may discard local history that exists nowhere else. Review exclusions against your archive’s purpose rather than assume every dependency or system-looking folder is disposable. Scanner implementation (scanner/main.go).

Resume skips known paths. Changing a category map and scanning again does not update existing observations. A metadata migration or an explicitly designed reconciliation pass is a separate operation; deleting the catalog is not a substitute for planning how references and human work survive.

Add evidence without disguising it as a decision

Extension category, sampled AI type, person identity and era membership answer different questions. Keep an extractor’s observations and provenance separate from the owner’s choices. Avichive’s file pipeline records structured evidence before applying an eligible automatic keep/skip decision, and its decision service protects human overrides. File-analysis submitter (archive-browser/app/services/file_analysis_batch_submitter.rb), decision service (archive-browser/app/services/analysis_decision.rb).

A new extractor should explain its input limits, unavailable-source behavior and output schema. If it only samples the beginning of a file, describe it as sampling. If it proposes context, give the owner a way to review that proposal. The existing era workflow demonstrates that suggestions need not become memberships automatically.

Keep originals and working representations separate

A preview, browser-compatible video or restored website can be more useful than its historical source format while still being a different representation. Preserve source identity independently of the derivative. Avichive’s original service can materialize preserved content from cloud storage and separately verify a full download against its hash; media services attach display assets separately. Ordinary materialization does not imply a hash check. Original service (archive-browser/app/services/archive_originals.rb).

This also makes restoration honest. Recovered writing can become Markdown, or a vanished service can become a curated demonstration, without claiming the old runtime has been revived. The restoration cases show different fidelity limits.

Treat synchronization as part of the feature

A schema addition is incomplete if its meaning disappears between environments. Incremental archive sync uses an explicit column allowlist; new fields must enter that contract deliberately. Display attachments remain environment-owned, curated eras have production authority, and reviewed people data follows a distinct local-owned replacement path. Sync contract (archive-browser/app/services/db_sync/tables.rb), deployment ownership (archive-browser/docs/DEPLOYMENT.md).

Use these patterns as implementation examples, not a promise of ready-made OCR, automatic tagging or semantic search. Those additions need their own evidence, processing budgets and review design. Capability status identifies the current boundaries.

Implementation notes refer to repository sources reviewed at e76e74c on October 13, 2026.