Untitled 2
Bringing Project Shepherd Into the Fold — Structural Analysis & Vault
Alignment
Context
Tony owns an Airtable base, Project Shepherd (🏗PROJECT SHEPHERD,
appHPUyBklcer3wA0;
a dated version-snapshot SHEPHERD | AIRv0414 | 10.03, appiazgCjnFgrNyOU, is
structurally
identical — same table IDs). He loves its structure and wants (a) an honest
read on what it gets
right and wrong, and (b) concrete ways his vaults (TAC-GKOS Knowledge +
second-brain Action) can
better reflect that structure.
This is a diagnosis + recommendation deliverable — NOT a rebuild of the
Airtable base and NOT a
mass vault migration. Output is a vault artifact (topic/decision note) Tony
can act on.
—
What Project Shepherd Actually Is (verified via Airtable MCP)
A company knowledge-operations base (origin ~2019, real-estate/construction
firm, bilingual
EN/ES). Architecture:
- One hub table — Repository — 13 rows, one per knowledge-element type. Each
row carries a
live rollup — Total (count of records in that category) + lookup — Updates
(recently
modified records) + an Update's Concatenation formula. It is a
registry-of-registries with
auto-counts. (e.g. row "Processes" # 1, row "Templates" # 2, "How-to's —
Total" = 7.)
- ~15 typed satellite tables, each a closed knowledge-element type with a
crisp one-sentence
definition in its table description:
- Processes — "the backbone of all know-how; connects a series of actions
and decisions to
develop a task" (explicitly #1; everything else orbits it)
- Templates · Tools · Standards · Procedures · Policies · Forms · Tutorials
· Reports ·
How-To · Reference · Organizational Structures · Software · Bases (DB access)
- plus company-ops tables: Job Descriptions · Loaners (barcode asset
tracking)
- Freshness engine — every satellite table has Last Update (lastModifiedTime)
+ an
Update? formula that flags whether the record changed within a defined window.
Stale-vs-fresh
is computed, not hand-tracked.
- Audience routing — every table has a Who's interested? select (Everyone /
Digital
Manufacturing / Project Management / Operation / …).
- Everything links back to a Process via multipleRecordLinks. Knowledge is
anchored to how
work gets done, not just filed by topic.
What it gets RIGHT (worth stealing)
1. A live index, not a hand-maintained one. Repository rollups auto-count each
family. This is
exactly what Registry v2's "disk-truth counters, no drifted counts" is
reaching for — Shepherd
proves it as a working pattern.
2. A crisp, closed typology of doctrine/knowledge-element types****, each with a
one-line
definition. Process / Template / Standard / Procedure / Policy / Tool / How-To
/ Tutorial /
Reference / Org-Structure. This is the crown jewel and maps almost 1:1 onto
the vault's
type-sprawl problem (DD-009 / PLAN-024 classification consolidation).
3. A built-in maintenance/freshness engine (Update? + Last Update) — a working
proof-of-concept of Tony's parked Entity Maintenance Ledger (EML) +
maintenance-engine idea.
4. Process-centric anchoring — knowledge hangs off processes/SOPs, not just
topics.
5. Audience routing — each element declares who it's for.
What it gets WRONG (do NOT copy)
6. Bilingual field-name drift — the Repository hub names the same categories
twice
(Templates link + Procesos/Herramientas/Estándares links; EN table names, ES
field names).
Exactly the naming drift Tony fights. One concept, two names = rot.
7. Hub bloat / brittleness — Repository carries ~45 fields (link + Total +
Updates ×15). The
triple-per-category is heavy and fragile; add a type → touch the hub in 3
places.
8. No stable IDs, no ledger. Records are keyed by Name only. No append-only
history, no
correction trail. Here the vault is AHEAD of Shepherd (PRJ-NNN, TN-NNN,
PLAN-000-LEDGER,
VAULT-000-HISTORY-LEDGER). Don't regress.
9. Freshness ≠ audit trail. Update? flags that a record is stale but not what
changed —
the vault's ledger concept is richer; keep it.
10. Company-ops cruft — Reports / Loaners / Job Descriptions / Barcode are
irrelevant to a
personal PKM. Take the pattern, not the tables.
—
Vault Mapping (verified against Registry v2 / DD-009 / GL-005 / EML)
Shepherd's satellite tables are node_type: document subtypes. The vault
already governs most of
them — but as registry families, not as a type: subtype vocabulary, which is
precisely the
axis-confusion DD-009 exists to fix. Crosswalk:
┌─────────────────────┬───────────────────────────────┬──────────────────┐
│ Shepherd element │ Vault equivalent │ Status │
│ type │ │ │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ Process (declared │ NONE — closest is SOP, but │ │
│ #1 backbone) │ SOP governs registry │ GAP │
│ │ mechanics │ │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ Procedure │ SOP-NNN (node_type: document) │ covered │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ Standard │ GL-NNN guideline │ covered │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ Policy │ GOV-NNN / ADR-NNN / DD-NNN │ covered │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ Template │ type: template │ covered │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ Tool / Software │ AUTO-NNN / node_type: engine │ partial │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ Reference │ type: reference │ covered │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ How-To / Tutorial │ type: reference / TN-NNN │ covered │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ Report │ dashboards / Bases │ partial (n/a │
│ │ │ personal) │
├─────────────────────┼───────────────────────────────┼──────────────────┤
│ Org Structure / Job │ │ skip │
│ Desc / Loaners │ — │ (company-ops │
│ │ │ cruft) │
└─────────────────────┴───────────────────────────────┴──────────────────┘
- Repository hub (live rollup) ↔ 05.00 Index for Registries v2 — but the
vault's is a
hand-bumped counter (SOP-001 step). Shepherd auto-counts. Gap = automation.
- Update? + Last Update freshness engine ↔ parked EML
(~/.claude/plans/PARKED-entity-maintenance-ledger-2026-07-07.md) — EML already
specs a Dataview
staleness query from updated: + review_cadence. Shepherd is a working proof of
that exact idea.
- Where the vault is AHEAD: stable IDs + append-only ledgers (PRJ/TN/PLAN +
PLAN-000-LEDGER,
VAULT-000-HISTORY-LEDGER, registry-v2-exceptions). Shepherd has none. Do not
regress.
- GL-005's seven node_type values are immutable — so "Process as first-class"
must land as a
type: subtype under document, NOT a new node_type.
—
Recommended Approach — Two light artifacts, no initiative scaffolding
Deliverable is one analysis atomic + one catalog reference note. Both are
knowledge promotion /
asset registration, not a new Active-5 initiative — WIP gate does not fire. No
edits to
PLAN-024 / DD-009 / GL-005 / EML — the note produces inputs those initiatives
can lift when Tony
chooses. IDs allocated via SOP-001 Registry Controller — never hand-picked.
Artifact 1 — TN-NNN-project-shepherd-structural-analysis.md (the mine)
- Home: 40-49 Knowledge & Concepts/40 Topics/. Allocate the next TN id via
SOP-001 (index
reports next = TN-132; confirm at write time, write file + 05.14 index row +
TN ledger row +
bump, same session). Frontmatter per GL-002 (tn_id, type: topic, node_type:
document,
domain: meta, typed tac7code starting d, aliases, ai_assisted: true).
- Follow tAC7CODE doc structure (H1 + code, TOC, numbered H2/H3) and use
colored callouts
aggressively ([!abstract] for Shepherd quotes, [!important] for the Process
gap, [!tip] for
each recommendation, [!caution] for the do-not-copy list, [!tldr] recap).
- Sections: (1) Shepherd Base Passport callout · (2) What it is · (3) What it
gets right ·
(4) What it gets wrong / do-not-copy · (5) Vault crosswalk table · (6)
Recommendations R1–R4 ·
(7) prose Provenance.
- ≥2 real backlinks (vault rule): link
PLAN-024-vault-classification-consolidation,
DD-009-vault-classification-doctrine, GL-005-node-type-standard — all
verified to exist.
The four recommendations (content of §6):
- R1 — Typology → subtype seed (feeds PLAN-024 Phase-1). Deliver the crosswalk
above as a
candidate ~12-value document subtype list: process · procedure · standard ·
policy · template · tool · reference · how-to · tutorial · report · concept ·
note. Flag it "ready to lift into
PLAN-024 Phase-1 once DD-009 is countersigned" — Phase-1's subtype list is
currently undesigned.
- R2 — Process as first-class type subtype (feeds DD-009 / GL-005). Recommend
adding process
under node_type: document, defined as a durable description of how a recurring
piece of work
flows — distinct from SOP (governs vault/registry mechanics) and PLAN
(one-time outcome).
Anchor knowledge notes to processes via edges: {rel: implements |
contributes-to}. Note only
proposes; the GL-005/DD-009 amendment stays Tony's call.
- R3 — Live-rollup index Base (buildable follow-on). Recommend an Obsidian
.base over the
registry families that live-counts each from disk (reimplements Shepherd's
Repository rollup atop
the hand-bumped 05.00 index). Sketch the spec in the note (source = family
folders, group by
prefix, count + max updated:); build only on greenlight (obsidian-bases skill;
likely an
AUTO-NNN or a Base in 00-09 SYS).
- R4 — EML reference design (feeds parked EML). Record that Shepherd's
Update?/Last Update
is the working reference for EML's staleness view; when EML resumes, model the
overdue flag on it.
Cross-link the PARKED pre-plan. No EML execution now.
Artifact 2 — Project Shepherd (Reference).md (the catalog — "into the fold"
made literal)
- On-convention reference note (Topic Name (Reference).md). Confirm
reference-note home at write
time (40-49 Knowledge & Concepts/ Reference area vs 40 Topics/); place
accordingly.
- Content = Base Passport: name 🏗PROJECT SHEPHERD, appId appHPUyBklcer3wA0;
version-snapshot
SHEPHERD | AIRv0414 | 10.03 / appiazgCjnFgrNyOU; owner Tony; origin ~2019
construction firm;
purpose (company knowledge-ops base); access (Airtable MCP, permission
create); one-line "why it's
in the fold" + backlink to the TN analysis. References aren't an SOP-001
family → no registry ID.
- Add a memory pointer (reference type) so the base is recall-findable next
session.
—
Verification
1. Files exist & are on-convention: ls both new files; confirm TN filename
TN-132-*.md and
reference filename Project Shepherd (Reference).md.
2. Registry integrity (SOP-001): confirm 05.14 Topic Notes index shows the new
TN row, the TN
ledger has an append row, and 05.00 Index for Registries v2 TN next-id bumped
132 → 133. No
hand-picked id, no gap.
3. Backlinks resolve: open the TN in Obsidian (or grep) and confirm the three
wikilinks
(PLAN-024, DD-009, GL-005) resolve to existing files — ≥2 real backlinks
satisfied.
4. Callouts render colored, not gray (spot-check in Obsidian) and tAC7CODE
structure present
(code below H1, TOC, numbered sections).
5. Recommendations are lift-ready: R1's subtype table is copy-pasteable into
PLAN-024 Phase-1;
R2's process definition slots into DD-009's subtype axis; each rec names its
target file.
6. Provenance prose present at the foot of the TN (this session; Airtable MCP
inspection of
appHPUyBklcer3wA0 + two vault Explore agents; solo Claude — no Parker Sol
passport, so state that).
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
