**Continuity marker archaeology**

Continuity marker: an observable feature in human-AI interaction artifacts -- such as a term, definition, metaphor, ritual, schema, prompt, behavior-name, narrative motif, or governance move -- that recurs independently across changes in model, user, context, platform, or time. Independent recurrence is the sole qualifying criterion; the marker's function is treated as an open question, coded after inclusion rather than assumed. 

Defined handle: a compact linguistic unit in a human-AI interaction artifact that is locally given meaning by the artifact itself. Handles may appear as words, phrases, metaphors, slogans, imperatives, behavior-names, role-names, schema labels, ritual labels, or recurring formulations. For clean inclusion, the artifact must attach local defining work to the unit through explicit definition, naming, restatement, function statement, operational instruction, category placement, or example linkage.

 The handle and its attached defining work together form the structural unit of analysis. 

External-domain exclusion: A locally defined unit is not coded as a defined handle if the local defining work merely reports an established real-world, disciplinary, historical, biological, legal, religious, technical, or cultural referent. These units may be tagged during preprocessing as [external-term] and treated as context only.

- *[external-term] tags are added in preprocessing, not by coders; they wrap any term whose local definition reports an established real-world referent rather than describing the interaction; coders treat tagged spans as context only.* 

Negative boundary: Unexplained motifs, metaphors, slogans, or labels are also not coded as defined handles, even when their meaning seems obvious; they may instead be logged separately as motif/label present -- no local definition. Defined handles should not require broad post context to attach a definition. Spans wrapped in [external-term]...[/external-term] are not coded as defined handles, though they remain visible as context. 

--

Defining work: when the artifact locally attaches meaning through visible moves such as:

* Explicit definition	Directly states what the handle means  
* Naming act	 A phrase such as "I call this X" may flag X as a handle, but naming alone doesn't define it. It counts toward a defined handle only when the same local window also does defining work on X (one of the other moves above). A name with no defining work in its window is a bare label -- log it as *motif/label present*, not a defined handle.   
* Restatement		Gives a plain-language equivalent  
* Function statement	Explains what the handle does or is for  
* Operational instruction	Defines by use: "when X happens, do Y"  
* Category placement	"X is a kind/type/form of Y"  
* Example linkage	Concrete examples can define the handle's range

The coder should not supply meaning from vibe, familiarity, or whole-post interpretation.

**3. The window rule ("local" / broad post context) -- built for published posts**

The corpus is mostly publicly posted material (articles, framework writeups), not transcripts. The window is built around the structures that show up in authored, edited prose.

Principle: Key the window on the structural unit the handle sits in; fall back to a raw sentence count only when there is no stronger unit. Author-chosen structure is a more reliable proximity signal than counting.

Starting rules (all numbers are dials to calibrate against a sample, not to theorize):

* Flat prose -> within +/-3 sentences of the handle.  
* List item -> same item, or a directly nested sub-item. Siblings excluded -- a deliberate tightening.  
* Heading + body -> the heading plus the paragraph immediately under it, not the whole section.  
* Glossary / schema entry -> the same entry, whole.  
* Table -> same row, plus its column header if the header carries the definition.  
* Embedded transcript snippet -> same turn, or the directly responding turn (a minority case in this corpus).  
* Whole-post interpretation needed -> not a defined handle; log it instead.

**Negative boundary:**

Three exclusions, each for a different reason:

* Unexplained motifs, metaphors, slogans, or labels are not coded as defined handles, *even when their meaning seems obvious*; they go to the motif log instead (see section 5).  
* Defined handles should not require broad post context to attach a definition.  
* Spans wrapped in `[external-term]...[/external-term]` are not coded as defined handles, though they remain visible as context.

The three cover, in order: defined-elsewhere-or-undefined, defined-but-needs-the-whole-post, and defined-but-pointing-outward.

Meaning:

* If "mirror" appears but is not explained, do not decide what it means.  
* If "collapse the frame" appears but is not explained, do not infer its function.  
* If a metaphor feels obvious to the reader, that still does not count as local defining work.

This protects the project from turning into interpretation of what the researcher thinks the author meant.

## **9. Hermit crab problem and external-domain exclusion**

A new problem appeared through the "hermit crab" example:

"Coenobita compressus is a land hermit crab that lives on the Pacific coast of Central and South America."

This technically matches the defined-handle rule:

* compact linguistic unit: "Coenobita compressus"  
* locally given meaning: "is a land hermit crab..."  
* category placement/definition: yes

But it is not a human-AI interaction handle. It is a scientific/taxonomic term whose meaning comes from an external domain.

This led to the **external-domain exclusion**.

Current rule:

A locally defined unit is not coded as a defined handle if the local defining work merely reports an established real-world, disciplinary, historical, biological, legal, religious, technical, or cultural referent. These units may be tagged during preprocessing as `[external-term]...[/external-term]` and treated as context only.

**The actual test.** Ask what the defining work is *about*. If it explains the term's own real-world referent (what the thing is, out in the world), exclude it. If it explains something happening in or about the interaction, keep it. The axis is *imported vs. reworked meaning*, **not** field of origin. 

Important distinction:

* If the artifact merely reports an outside-domain term, exclude it.  
* If the artifact adapts or repurposes an outside-domain term to describe a human-AI interaction pattern, it may re-enter as a defined handle or figurative frame.

Example:

* "Overfitting is when a model fits noise instead of signal." -> reports the textbook meaning -> external.  
* "The model is overfitting to me -- it's started mirroring my phrasing back instead of pushing." -> same word, but the work is about the interaction -> possible handle.

**11. Metaphors and analogies: the novice-language problem**

The project then identified a major issue: many users, especially novices, may describe AI behavior through metaphor or analogy because they do not have stable technical language for what they are experiencing.

This means strict defined-handle rules could miss important data.

For example, novice users might say things like:

* "Talking to AI is like looking into a mirror."  
* "It feels like an oracle."  
* "It echoes me back to myself."  
* "It's like a ghost in the machine."  
* "It's like a parasite feeding on my thoughts."  
* "It's like a second brain."  
* "It's like a therapist, but not really."

Some of these may not be defined handles because no compact named unit is locally defined. But they may still reveal independently perceived AI-interaction patterns.

The solution was not to weaken the defined-handle rule. Instead, the project added a parallel category.

**12. Interaction figurative frame**

Chosen term: Interaction figurative frame

Current definition:

An interaction figurative frame is a metaphor, analogy, simile, image, comparison, or narrative framing present in a human-AI interaction artifact that describes, explains, or organizes a perceived AI-related behavior, role, risk, effect, or interaction pattern. Unlike a defined handle, it does not need to appear as a compact named unit. Coders may record the figurative source, the AI-interaction target, and the locally supplied mapping, but should not infer meanings beyond what the artifact provides within the allowed context window.

Reason for choosing this term:

* "Handle" was too compact and name-like.  
* "Interpretive handle" sounded dangerous because it implied coder interpretation.  
* "Frame" captures the broader comparison structure.  
* "Figurative" covers metaphor, analogy, simile, image, comparison, and narrative framing.  
* "Interaction" keeps it tied to human-AI interaction instead of general literary imagery.

**13. Defined handle vs interaction figurative frame**

Important distinction:

* Category: What it captures  
* Defined handle: Compact unit locally given meaning by the artifact  
* Interaction figurative frame: Figurative comparison used to describe or organize perceived AI interaction  
* Motif/label present -- no local definition: Salient phrase/image appears but is not explained  
* External term: Flagged in pre-processing; context only

Example:

Text: "The AI is a mirror."

Code:

* Motif/label present -- no local definition.  
  Text: "The AI is a mirror. It reflects my assumptions back at me in fluent language, which makes it feel wiser than it is."  
  Code:  
* Interaction figurative frame.  
* Source: mirror/reflection.  
* Target: AI response behavior.  
* Mapping: AI reflects user assumptions back in fluent form.  
  Text: "I call this the mirror effect: the model reflects the user's assumptions back so smoothly that it feels like independent insight."  
  Code:  
* Defined handle.  
* Handle: mirror effect.  
* Defining work: model reflects user assumptions back so smoothly that it feels like independent insight. 

**15. Common-frame flagging / background subtraction**

In the first few passes through the corpus, the project should not hunt for obvious frames in advance. It should let them appear naturally in coding results. If "mirror" appears many times, that is not a failure. It is a finding.

Workflow:

* Early passes: Code interaction figurative frames as they appear without pre-filtering obvious ones  
* Recurrence review: Identify high-frequency frames such as mirror, echo, tool, companion, oracle, ghost, etc.  
* Common-frame list: Build a running list of observed common frames  
* Later passes: Continue coding them, but flag them as common/background  
* Quiet-frame search: Inspect unflagged or quieter recurring frames that may otherwise be drowned out

The point is not to delete common frames. It is to count them, prove they are common, and then visually separate them so quieter convergent cases can be found.

## **18. Corpus direction**

The corpus may include:

* public AI-assisted frameworks  
* reflective essays/posts about AI interaction  
* personal AI-use schemas  
* public codebooks or rituals  
* GitHub READMEs  
* GitHub changelogs  
* developer project documentation  
* technical artifacts around AI tools/wrappers/agents  
* more literary or reflective artifacts

The project will focus on two populations:

1. **Developer/technical artifacts** -- READMEs, changelogs, wrappers, agent documentation, tool schemas, technical workflows.  
2. **Reflective/literary/user-facing artifacts** -- essays, personal frameworks, metaphors, rituals, interaction narratives.