David F GliddenandClaude Opus 4.7
e9e772d69c
Safety checkpoint before deep-audit Phase 0 of the ARC repo. Steward-authorized commit-everything for rollback safety. ARC architectural locks (2026-04-26 evening): - Path 1 enfilade structure (separate Colophon and Lex items) - 8-door enfilade locked: Colophon · Lex · Framework · Vignette · Attention · Chamber · Tools · Now (+ Bio quiet link) - Adsum and threshold-hic as two distinct texts on the reflowed About page (steward verbatim: "They are certainly not the same text") ARC consolidation pass (canonical tracker project-arc-rework.md, +~700 lines): fold 04-23 evening (Norris read), 04-24 (lex-method authored, posture cluster, §XII Sidenotes, ARC CLAUDE.md cleanup), 04-25 (marks cluster, colophon-at-scale, full Vico/Harrison lex-chain), 04-26 (chamber-library walk, cluster scaffolds, canonical-tracker discipline surfaced). Sibling-file integration: four 2026-04-26 frame files folded into the canonical tracker (Integrations A/B/C/D) with INTEGRATED redirect notices retained as audit trail. New durable feedback memories: - feedback-canonical-workstream-tracker-discipline (umbrella drift surfaced 2026-04-26 by steward; proposes /wake-up + /wrap-up amendments) - feedback-catalogues-stale-walk-trees (steward feedback on chamber-library catalogue currency) Implementation plan drafted for the coming week: Phase 0 deep audit → Phase 5 cleanup, with steward additions on second pass (deep audit; Chamber v1 as own browsable archive; clean rebuild of cluster sources rather than moving test artifacts as canon). Also bundled (untracked accumulation since 04-17): - ~24 session memory + ledger files for 04-17 through 04-26 work - ~10 feedback memories (BMF + ARC + working-method) - 5 project memories (lex-as-method, strunk-white queue, plus today's four) - 4 user memories (duality-rules, formation-practice, foundation-work, humic-layer) Steward-side modifications also in this commit: ~/CLAUDE.md, bin/bmf-start.sh, open-tasks.md, project-focus-april-may.md, session-2026-04-17 — all pre-existing, not from today's session. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
68 lines
7.3 KiB
Markdown
68 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
|
|
---
|
|
# 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.
|