← Corpus / augment-it / issue
Corpus items aren't visible on person cards — and corpus coverage across entities is hard to assess anywhere
The person card says 'Corpus items 3' and shows nothing — the operator can add a fourth without ever seeing the three that exist.
- Path
- issues/Corpus-Items-Not-Visible-On-Person-Cards-Coverage-Hard-To-Assess.md
- Authors
- Michael Staton
- Augmented with
- Claude Code on Claude Fable 5
- Tags
- Issue · Usability · Augment-It · Corpus · Org-Workbench · Persons · Coverage
Corpus items invisible on person cards; coverage unassessable
The symptom (screenshot-confirmed, 2026-07-24)
On the Lumina card → People → Jamie Merisotis: “Corpus items 3” — a count, a 🔍, a ➕, and no list. The operator can add a fourth item without ever seeing the three that exist. Links render in full; corpus doesn’t.
Why this happened (a Phase 4 contract decision, now disproven)
organization.affiliations deliberately returns personal_corpus_count
only — the Augment-from-DB spec’s Phase 4 scoped entry-listing out
(“entries ride affiliation.detail in a later pass if the operator wants
it”). The operator wants it. First real session with the surface proved
count-only wrong: assuring corpus coverage is a core purpose of the
workbench, and you can’t assure what you can’t see.
Two layers to the fix (jotted)
- Per-card visibility (the direct fix). Either extend
organization.affiliationsto returnpersonal_corpus[]entries (payload is small; 8MB NATS ceiling is nowhere near), or lazy-fetch per-person on expand via the existingaffiliation.detail(already returnsperson.personal_corpus— zero new verbs). Render with the same list shape as links: kind badge · host/title · date. Same question applies tocontent_itemshydration — org corpus rows render bare URLs today; titles live in the ledger unused. - Coverage assessment (the real job). A view that answers “which
relevant orgs/people have NO corpus items (or none newer than X)?” —
a sortable roster of entities with link/stream/corpus counts, thin
rows, red-zero highlighting. Could be a lens over the canonical layer,
a workbench mode, or a didi verb (
/coverage). This is what “hard to assess” actually asks for; the per-card fix alone doesn’t answer it.
Open questions
- Eager (extend affiliations reply) vs lazy (affiliation.detail on expand) — lazy ships with zero service changes; eager is one query.
- Do corpus rows want titles from
content_items(a join) or is URL+kind enough for v1? - Where does the coverage roster live — and does it fold into the usability-iteration sweep alongside [[No-Component-Library-UI-Improvised-Not-Component-Based]]?