paco.org Media Architecture

Status: EI-2 media architecture series completed through EI-2.5 on 2026-08-08.

Principle

Google Drive is the archival/master media repository. GitHub contains only production assets required to build and serve paco.org. paco.org does not hotlink production media from Google Drive.

Production flow

1. Preserve the best available original/master in the scoped paco.org Google Drive archive.
2. Export or optimize a web-appropriate derivative when needed.
3. Store that derivative under images/ in idtprof/pacodotorg.
4. Reference the GitHub-hosted derivative from Jekyll content.
5. Record provenance and disposition in docs/media-manifest.yml.

Repository organization

• images/loudmouth/ — production scans used by The Loudmouth issue galleries.
• images/blog/ — controlled historical assets recovered from WordPress media and used by retained posts.
• images/ — current site/UI assets and older media not yet normalized into a subdirectory.

Future cleanup may introduce images/site/, but path changes should occur only when their value outweighs URL churn.

Dispositions

• KEEP — required by production or retained conservatively until provenance/reference checks are complete.
• REPLACE — regenerate or substitute before removing the old copy.
• REMOVE — delete after dependency and archival/editorial checks.

Archive confidence

• VERIFIED — exact or directly corresponding Drive archival file identified.
• COLLECTION_VERIFIED — belongs to an identified archival collection.
• UNVERIFIED — exact archival provenance not yet recorded; this does not mean absent from Drive.

Loudmouth

The Loudmouth remains an intact historical collection. Production scans stay in GitHub because they directly render published galleries. The archival/master collection is the scoped Google Drive HS Loudmouth Scans corpus recorded in the manifest.

The Drive archive may contain originals, scans, WordPress derivatives, and duplicates. GitHub retains only versions required by the site. EI-2.3 removed seven unused duplicate Vol. 1 No. 8 scans while preserving the eight files used by the gallery.

Historical WordPress media

EI-2.1 migrated recoverable retained-post dependencies from obsolete wp-content/Jetpack URLs into images/blog/, including AudacityTest.mp3. Those GitHub copies are production assets; Drive remains the archival source.

Cleanup policy

A media file may be deleted from GitHub when:

1. no retained/current page requires it, or a canonical production duplicate remains;
2. archival preservation is established when the file has historical value; and
3. deletion does not reintroduce an external WordPress or Drive dependency.

For third-party tutorial/demo material with no live dependency and no paco.org editorial or historical value, archival preservation is not required merely to justify production deletion.

EI-2.3 removed ten redundant/orphaned files. EI-2.5 removed images/step1.gif, an unreferenced Jekyll Now tutorial animation. The user-provided Downloads copy was SHA-256 identical to the repository file, confirming its identity; inspection established that it had no meaningful paco.org archival value.

Delivery optimization

EI-2.4 reviewed production assets above roughly 750 KB and avoided blind recompression. Loudmouth scans are historical documents; legibility takes precedence over arbitrary byte targets. A derivative may replace a scan only after visual comparison against the Drive master shows no material loss.

All images inside .gallery receive browser-native loading="lazy" and decoding="async" hints. Existing compatibility code rewrites legacy WordPress-style Loudmouth image markup to controlled local GitHub assets.

images/avatar.jpg remains the active configured avatar and a candidate for a future visually verified web derivative.

Privacy boundary

Media associated only with an EI-1.5 DELETE item is not eligible for production restoration. Material associated only with protected Ben/Sophie posts must not be reintroduced to paco.org. Private archival retention does not imply production eligibility.

Operational rule

Before adding media to GitHub:

1. Does a retained or current paco.org page actually need it?
2. Is the archival/master copy preserved or its provenance recorded when preservation is warranted?
3. Is it production-eligible under the editorial/privacy classification?

If the first answer is no and the asset has archival value, it belongs in Drive rather than the production repository. If it has neither production nor archival/editorial value, it should be deleted rather than accumulated.

For performance work, optimize delivery before destructively recompressing historical material. When a smaller binary is warranted, create it from the archival master, compare it visually, and record the derivative in the manifest.