RAID filesystem spine sketch · parked for tomorrow’s sketch session (2026-05-29)

DARE.CO.UK · PARKED SKETCH · 2026-05-30

Mirrored from ~/.claude/.../memory/parked_sketch_raid_filesystem_spine_2026-05-29.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

Dan and I sketched a first-pass RAID folder structure 2026-05-29 — domain-first for documents (work / projects / university / personal / family) + media-type-first for assets (photos / video / audio / email). Dan parked it (“we should sketch it tomorrow and work on it”) before locking the two open edge cases. Resume when Dan opens the topic tomorrow, walk through the first-pass proposal, get his two decisions, then write up as a proper project memory.

Dan 2026-05-29: “We should sketch it tomorrow and work on it”. The RAID folder structure question — opened after the household NAS stack discussion (Synology 8-bay + QNAP 4-bay racked-and-ready). Wants real co-design on the structure rather than committing to my first-pass.

What we agreed on this pass

The five domains Dan named (verbatim): work / projects / university / personal / family. He volunteered these as the top-level life-sections.

Design principle I proposed and he didn’t push back on: domain-first for documents and projects, media-type-first for cross-domain assets. Photos / video / audio / email get their own top-level folders because Immich semantic search + maildir grep work across all life-sections. Documents and project files DO benefit from domain context, so those nest under the 5 named domains.

Top-level structure proposed:

/Volumes/RAID/
├── photos/                ← Immich external library (year/month)
├── video/                 ← (year/month)
├── audio/                 ← music + voice
├── email/                 ← maildir per account
├── work/                  ← employment by employer/role
├── projects/              ← creative + technical builds
├── university/            ← academic by institution/period
├── personal/              ← individual paperwork + journals
├── family/                ← shared household (Dan + Audrey)
├── intake/                ← data.gf.cx Gate B scratch
├── docker/                ← container persistent vols
└── _archive/              ← cold / retired

Two open edge cases parked for tomorrow

Where does Audrey’s content live? Three options: - audrey/ as separate top-level (cleanest identity separation) - family/audrey-shared/ (jointly-owned only; her solo content elsewhere) - work/audreyinc/ + work/audreylam/ (her businesses as work-domain) - My recommendation if forced: separate audrey/ top-level — matches the GCP entity taxonomy (project_gcp_entity_taxonomy_2026-05-29.md) and respects identity isolation.
What goes from ~/Code/ to RAID projects/? Three options: - Full mirror including WIP branches (most coverage) - Canonical-state code only (cleaner, harder to operationalize) - Archival drops at milestones (lightest touch) - My recommendation if forced: full mirror via rsync nightly, since storage is cheap relative to the value of finding old work.

Two principles to lock when we resume

These weren’t questioned and should hold:

One canonical home per file. If a file could live in two places, decide which is primary and use a pointer (symlink / README) in the other. Dedup-passes need to know which copy is the source of truth.
Time-anchor within domains, domain-anchor across media. Within personal/finance/, the next slice is year. Within photos/2024/, the next slice is month. Don’t force two axes of thought simultaneously.

How this connects to existing surfaces

Surface	RAID home it reads
`pa.gf.cx`	`personal/` + `family/household/` document scans (raw bytes here, record metadata in pa)
Immich	`photos/`, `video/` as read-only external library
`evernote.gf.cx`	`personal/journals/evernote-export/`
`data.gf.cx`	`intake/` is Gate B scratch · cleaned items move to canonical homes above
Email	`email/<account>/` maildirs (8 named accounts + dare.co.uk Drive folders)

Resume protocol

When Dan reopens this tomorrow: 1. Don’t re-litigate the 5 domains or the domain-vs-media split — those are settled 2. Walk him through the proposed top-level (above) and the two principles 3. Ask the two open questions (Audrey placement, ~/Code/ mirror policy) 4. Once locked, write up as project_raid_filesystem_spine_<date>.md (proper project memory, not parked sketch) 5. Update project_household_nas_stack_ready_2026-05-29.md with the locked structure under the “Filesystem layout (Synology side)” section (currently has a placeholder structure I wrote earlier — replace with the agreed version)

Cross-references

project_household_nas_stack_ready_2026-05-29.md — the NAS hardware this structure lives on; has a placeholder filesystem layout that needs replacing once locked
project_data_gf_cx_migration_destination_2026-05-29.md — the surface that drives data INTO this structure
project_gcp_entity_taxonomy_2026-05-29.md — the Dan / audreyinc / audreylam separation that informs the Audrey-placement decision
feedback_derivatives_in_r2_originals_on_raid.md — RAID is canonical home for masters, R2 mirrors derivatives
feedback_filesystem_spine_framework.md — Dan’s broader filesystem-spine principle this structure is the local incarnation of

Source: parked_sketch_raid_filesystem_spine_2026-05-29.md · Rendered 2026-05-30 14:32