Media Organization — Planning Memo

Created 2026-03-27

Tags infrastructuremediaplanning

Status: Draft for discussion — to be refined into formal guidelines Date: 2026-03-27 Context: Following successful setup of B2 + Cloudflare CDN + NAS media pipeline

Two Systems: Storage vs. Discovery

Storage (B2 + NAS) — organized by origin

Where a photo came from determines where it lives on disk. This is the physical filing system.

baseworks-media/
├── campaigns/                    ← photos produced for a specific campaign
├── newsletters/                  ← copies used in sent emails (permanent, never reorganize)
├── blog-articles/                ← article-specific diagrams, illustrations
├── study-groups/                 ← session/cohort documentation photos
├── website/                      ← site-specific hero images, page visuals
├── forms/                        ← reference photos of Baseworks forms (organized by form)
├── brand/                        ← logos, icons, recurring assets
└── incoming/                     ← unsorted staging area

Discovery (Obsidian manifests) — organized by meaning

What a photo depicts and how it connects to Baseworks concepts. This is the searchable, linked layer.

Each collection of photos gets a media manifest — a markdown file in the vault that lists every image with:

CDN URL (for rendering inline)
Description (what’s depicted)
Tags (forms, principles, people, contexts)
Wikilinks to related vault concepts

## Star Form — Standing Variation

![Patrick demonstrating Star Form standing](https://media.baseworks.com/forms/star-form/baseworks-patrick-star-form-standing-01.webp)

**Depicts:** Patrick demonstrating Star Form (standing variation), arms extended, emphasis on shoulder activation
**People:** [Patrick Oancia](/areas/method-admin/core/patrick-oancia/)
**Forms:** [Star Form](/star-form/)
**Principles:** [Spatial Awareness](/areas/method-admin/core/key-definitions-repo/spatial-awareness/), [Transit Focus](/transit-focus/)
**Source campaign:** [2026-03-winter-study-group-campaign](/areas/communications/campaigns/2026-03-winter-study-group-campaign/2026-03-winter-study-group-campaign/)
**NAS original:** `/volume1/baseworks/media/forms/star-form/originals/_PMP3341.jpeg`

This means:

Searching for “Star Form” in Obsidian finds all photos tagged with it
The Star Form page has backlinks to every manifest that references it
Claude Code can browse manifests to find the right photo for any context
The same photo can appear in a campaign manifest AND a forms reference manifest

The Incoming Photos Workflow

When new photos arrive (from Andrew via Google Drive, or from any source):

Drop into NAS /volume1/baseworks/media/incoming/ — raw files with original filenames
Review and sort — Claude Code can view photos via NAS SSH, user browses via Finder
Rename using Baseworks naming convention (see below)
Move to destination folder on NAS (e.g., forms/star-form/originals/, campaigns/2026-04-spring/originals/)
Process via /compress-photos — creates WebP + JPEG, uploads to B2
Create or update manifest in Obsidian — descriptions, tags, wikilinks

Photo Naming Convention

baseworks-{person}-{action-or-form}-{qualifier}.{ext}

Examples:

baseworks-patrick-oancia-star-form-standing-01.webp
baseworks-asia-shcherbakova-kneeling-form-demonstration.webp
baseworks-study-group-floor-practice-wide-shot.webp
baseworks-primer-print-cyclical-diagram.png

Why rename: Andrew’s originals (_PMP3341.jpeg) are meaningless. Descriptive names make photos findable by filename alone, improve SEO when used on the web, and are readable in B2/NAS without needing to open each file.

Forms Reference Library (New)

A dedicated section for reference photos of each Baseworks form, organized by form name:

forms/
├── star-form/
│   ├── originals/
│   ├── baseworks-patrick-star-form-standing-01.webp
│   └── baseworks-patrick-star-form-standing-01.jpg
├── kneeling-form/
├── standing-form/
├── seated-form/
└── ...

Each form gets a manifest in the vault (e.g., 03-resources/media/forms/star-form-photos.md) that links to the form’s page in the educational content area. This creates bidirectional links between the form documentation and its visual references.

How Claude Code Learns the Visual Library

Manifests are searchable — Claude Code can grep across all manifests to find photos by description, form, principle, or person
Photos are viewable — Claude Code can fetch any CDN URL and visually inspect the image
Context accumulates — over time, through viewing and describing photos, Claude Code builds understanding of what each form looks like, who is depicted, and which photos work best for specific contexts
NAS is browseable — Claude Code can SSH to NAS and list/discover photos not yet indexed in manifests

Open Questions for Tomorrow

Should the forms reference photos be a separate B2 folder (forms/) or filed under study-groups/ or campaigns/ where they were originally shot?
How granular should manifests be? One per campaign? One per form? One per topic?
Should we create a skill (/organize-media) that handles the incoming → sort → rename → process → manifest workflow?
How to handle photos that are relevant to multiple forms or principles — just tag them in the manifest, or cross-link across multiple manifests?
Batch test: process a set of photos through the full pipeline (NAS → rename → compress → B2 → manifest) to validate the workflow end to end

media-storage-plan — technical infrastructure (B2, Cloudflare, NAS setup)
/compress-photos skill — processing and upload pipeline