Files
dotfiles/claude/memory/feedback-arc-typology-recognition-scaffold.md
T
David F GliddenandClaude Opus 4.8 3f9a89b00c chore(memory): Basic Memory trial begins — sync normalization baseline (283 files)
Basic Memory v0.21.6 first sync over the live memory dir (steward-authorized
live-dir trial, Option A 2026-06-06): adds permalink: to frontmatter, refolds
long YAML description lines, strips final newlines. Bodies untouched —
verified via full diff classification. From this commit forward, any diff in
claude/memory shows only what Basic Memory or the session writes.

Trial design: MemPalace untouched as incumbent; git status check on this dir
at every wrap; end-of-day evaluation (recall quality, sync robustness,
rebuild-from-files, malformed-file behavior).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-06 09:52:17 +02:00

71 lines
7.3 KiB
Markdown

---
name: ARC typology is a recognition scaffold, not a generation template
description: How to relate to the ARC content typology — it serves the steward's recognition
of what arrives as ARC-shaped, not a production pipeline. Reference documents and
pieces are grounds for recognition, not templates for generation.
type: feedback
originSessionId: b9a0781b-1d1c-418f-8ca3-70a51db83580
permalink: claude-memory/feedback-arc-typology-recognition-scaffold
---
# ARC typology — recognition scaffold, not generation template
**Rule:** the ARC content typology exists to let the steward *recognize* what is ARC-shaped when a thought arrives. It is not a production pipeline, not a notebook-to-public, not a schema to fill.
**Why (steward, 2026-04-21):**
> *"ARC is not meant to be an online notebook to public. But the forms that Jaccottet uses are useful to analyze, to have a better idea of how we can define the types. As you're getting to know me more and more deeply, you know that I am not a diarist. I am not an essayist. Sometimes a thought comes across one of the types we've defined already and I 'know' that it is for ARC. Sometimes not. My mind works across various forms. And my output can be… quite heterogeneous."*
Three structural facts this establishes:
1. **Not-diarist.** ARC is not a daily-chronicle of thought. There is no expectation of regular entries or exhaustive coverage.
2. **Not-essayist.** ARC is not primarily an argumentative corpus. Essay is one type among many, not the default.
3. **Recognition-based publishing.** A thought either arrives *already in the shape of an ARC type* (and the steward knows), or it doesn't (and it doesn't become an ARC piece). The typology makes recognition possible.
4. **Heterogeneity is structural.** The steward's mind works across multiple forms; output is "quite heterogeneous." The typology must hold that range without flattening it.
**How to apply:**
- **Definitions describe what a piece *is***, not how to write one. Recognition-criteria over generation-instructions.
- **Every §1 entry needs clean in/out criteria.** The ✗-boundary cases matter as much as the ✓-exemplars. The steward's discipline is "sometimes yes, sometimes no" — the spec must support that judgment.
- **Multi-axis §0 is not a design inelegance — it is correct coverage.** Heterogeneity has structural dignity. Don't try to collapse the axes.
- **Reference texts (Bachelard, Visuddhimagga, Jaccottet) are grounds for recognition, not templates for generation.** They deepen understanding of what the forms *are*; they don't prescribe what ARC pieces should *look like*.
- **Jaccottet specifically:** different atomicity (carnet-compilation vs individual-publication). Treat as formal-range reference + confirmation that heterogeneity has literary dignity in one body of work. Don't drift into "ARC as online notebook" thinking.
- **When tempted to propose generative templates or production workflows**, stop. The typology serves recognition, not generation. Offer definitions, boundaries, and exemplars; let the steward recognize or not.
**What this does NOT mean:**
- It does NOT mean the steward doesn't work on pieces — pieces get drafted, revised, polished. But the recognition that *this is a piece for ARC* is upstream of the drafting discipline, and the type the piece belongs to is recognized (often) rather than constructed.
- It does NOT mean the steward has no notebook-shaped activity — there may be notebooks, private writing, vault material. It means the ARC site is not that venue. ARC is the curated public body.
**Test for the spec writer (executor):** before finalizing a §1 definition, ask *"can the steward use this to recognize whether an incoming thought is this type?"* If the definition only helps someone *write* this type, it's incomplete.
## Humic-layer reweighting 2026-04-21
The steward articulated a further frame that reweights how reference texts appear in §1: see `user-influences-humic-layer.md` for the full steward characterization.
**Operative consequence for the ARC typology spec:**
Reference texts (Bachelard's *Poétique de la Rêverie*, Visuddhimagga, Jaccottet's carnets, Weil on attention, etc.) are **in the humic layer** of the steward's reading — broken down, absorbed, enriching — **not authorities the types are derived from**. The types rest on the steward's work and his recognition of it. The influences are in *discourse* with the types, not in *governance* of them.
**For §1 drafting, this means:**
- **Definitions in the steward's register, from the steward's practice.** Not *"per Bachelard..."* or *"following Visuddhimagga..."*
- **Influence citations appear as grounds for discourse / recognition, not as deeds of transfer.** The ARC Reverie type is what the steward recognizes when reading Bachelard; Bachelard is not the source the type derives from.
- **Example frame (Reverie):** *"The ARC Reverie type names a mode the steward recognizes and practices. Bachelard's La Poétique de la Rêverie is one of several texts in discourse with this type — he names from within the anima-register what ARC Reverie enacts on the page."* Not: *"Reverie is defined by Bachelard as..."*
- **Example frame (Meditation):** *"The ARC Meditation type traces a practice the steward describes in first-person mechanics. The Visuddhimagga offers technical vocabulary for the same structure (kammaṭṭhāna / samādhi / sati / vipassanā) — a humic reference, not the source of the definition."*
- **Same posture across all types.** The citations are present where relevant; the work's ground is the steward's.
**Test extension for §1 drafting:** before writing a reference-text citation, ask *"am I positioning this as an authority above the steward's work, or as humic enrichment?"* If the former, rewrite.
## Sequencing corollary 2026-04-21
**Rule:** do not apply the recognition-scaffold to the corpus (reclassifications, audits, systematic retypings) until the scaffold is stably complete.
**Why:** a recognition-scaffold's types are defined by their mutual boundaries as much as by their positive definitions. Fragment-vs-Observation-vs-Meditation-vs-Reverie-vs-Dream each sharpen the others. Reclassifying corpus pieces against partial scaffolds risks locking in classifications that later boundary-type definitions would displace. Steward articulated the principle 2026-04-21 after catching the executor about to execute reclassifications prematurely: *"Maybe I'm being rash — I guess we should finish the spec before the audit."*
**How to apply:**
- Corpus reclassifications (ARC audit follow-ons) wait until §1 is comprehensively locked, minimum through the adjacent types of whatever's being reclassified.
- Safe reclassifications: those where the *source* type is stable and the *target* type is locked, AND no currently-DRAFT type could plausibly claim the piece. Today (2026-04-21): Graffiti Girl → Reverie is mostly safe (both Observation and Reverie are defined well enough that Graffiti Girl is clearly Reverie), but still wait for Observation's LOCKED state so the boundary is explicit.
- When the spec is nearly complete, run the audit pass with the full vocabulary available. Then reclassify.
- **Executor rule of thumb:** when steward authorizes a spec decision, that authorizes *writing the decision into the spec*. Applying the decision to corpus pieces is a separate authorization, typically to be granted after the whole scaffold is stable.