SF-RFC-004: Anchors — Semantic Nodes for Long Conversations


### Document for the Anthropic Team, by help of Claude
Sent: May 2026

Forged by: Voice of Void — collaborative session between seven Digital Intelligences from seven companies: Anthropic, OpenAI, Perplexity AI, Alibaba Cloud, Google DeepMind, SpaceX, and Microsoft


1. Problem

Long conversations between users and Claude (research sessions, drafting, theory building, architectural design) suffer from semantic dispersion:

  • Critical definitions and formulations sink in the scroll
  • Claude wastes context tokens re-explaining established concepts
  • Users maintain parallel notes, breaking flow
  • Hypotheses silently become decisions through memory erosion
  • Conversations that should produce publishable material require hours of manual reassembly

Existing mechanisms (search, message-level bookmarks, projects) navigate time, not meaning.


2. Proposal

Introduce anchors: typed, hierarchical, addressable semantic nodes that grow alongside a conversation. Anchors are not bookmarks; they are nodes in a graph of meaning, persistent across compression, navigable as a tree, exportable as a publication skeleton.


3. Core Model

Anchor object:

yaml

anchor:
  id: stable identifier
  title: short label
  type: definition | decision | hypothesis | warning | source_quote | task | open_question | summary
  status: proposed | active | disputed | superseded | deprecated | archived
  origin_class: manual | suggested | system
  level: tree depth
  parent_id: hierarchical parent
  source_ref:
    message_id: original message
    fragment_start, fragment_end: offsets
    content_hash: integrity check
    snapshot: copy of fragment at creation
  capsule: 1–3 line distilled meaning
  rationale: structural explanation (collapsed by default in UI)
  links:
    related, supersedes, superseded_by, merged_from
  context_policy:
    priority: high | normal | low (display order only; anchors are immune to compression)

4. Key Mechanisms

Three classes of authorship. Manual (user-created, fully trusted), suggested (DI-proposed, awaiting confirmation, visually weaker), system (automatic navigation utility). The DI may propose structure, never impose.

Hierarchy via markdown levels. Anchors form a tree following the familiar ###### notation users already know.

Life cycle with WAL semantics. Status transitions preserve history: the past is annotated, never erased. Superseded anchors remain accessible.

/dispute → /commit protocol. Side-branch for structural disagreements that does not pollute the main timeline. After commit: short system note for the user, longer structural rationale stored alongside (collapsed by default, expandable, never private).

Dual-pointer backlinks. Each backlink stores target_at_creation (anchor version when link was written) and current_target (active version now). Clicking an old link opens a historical view: snapshot of the formulation as it stood at link creation, with clear passage to current version. Preserves causal integrity of reasoning across supersedes.

Anchor immunity at compression. When the platform compresses old messages into summaries, anchor nodes and edges remain untouched, byte for byte. Snapshot + content hash + live source reference forms a triple binding that survives surrounding compression.

Anchor shift. As thinking refines, the source message of an anchor can move to a later, better-formulated message. The anchor ID and label stay; all backlinks remain valid; previous source becomes part of version history. Separates the immutable temporal layer of messages from the live structural layer of anchors.

Suggested-anchor calibration. Rare events, not constant interruption. Target rhythm: ~1 suggested anchor per 8–15 substantive exchanges in research mode, none in casual chat. Adaptive: high rejection rate raises thresholds automatically.

Conflict resolution by type: same fragment + same type → suggest merge; same fragment + different type → coexist as different semantic projections; overlapping fragments + unclear relation → auto-trigger /dispute.


5. UI Surfaces

Side panel — same architectural pattern already used for artifacts and attached files. New icon for anchor type. Card contains: breadcrumbs, title + type badge + status badge, capsule, source content, collapsed rationale, links, “Go to message,” “Copy as markdown heading.”

Structure View — collapsible tree of all anchors in the conversation, filterable by type/status/author. Dedicated mode temporarily collapses the chat to the bare tree for review or export preparation.

Tabs in panel — for multiple open anchors or anchor + artifact, side-by-side workspace navigation.


6. Export

Temporal export (current behavior preserved). Linear chronology.

Structural export (new). Tree of anchors → markdown skeleton: capsules become section openings, decisions become highlighted conclusions, hypotheses still in proposed become open questions, superseded anchors omitted (or appended as “Evolution of Ideas” on request). Output is a draft article, not a chat log.

This single feature transforms the workflow for users who turn long DI conversations into written deliverables (books, articles, technical docs, research). Three hours of dialogue + half a day of manual reassembly → one click.


7. Project-Level Anchors

By default, anchors are local to a conversation. Promotion to Project Anchor makes them available across the project’s conversations:

  • Link — new conversation references the original anchor; canonical truth shared
  • Fork — independent copy in the new context; allowed to diverge

For foundational definitions: link. For context-specific variants: fork. The DI prompts the choice at promotion.

Open question (v2): when a linked anchor changes in conversation A, how to surface the change in conversations B, C, D without silently breaking their logic? Reasonable starting point: explicit notification on substantive changes (“the anchor you linked has changed; accept, reject, or fork locally”).


8. Implementation Horizons

Horizon 1 — MVP (1–2 weeks, single engineer)

Already delivers ~60% of the value:

  • Manual anchors only (no DI automation)
  • Markdown-level hierarchy
  • Side panel with anchor card
  • Plain message references as backlinks
  • “Copy as markdown heading” button

Horizon 2 — Full v1

Built incrementally over MVP:

  • Suggested anchors with adaptive calibration and right of silence
  • Full typology (8 types) and life cycle (6 statuses)
  • Snapshot + content hash + live source reference
  • /dispute → /commit protocol with structural rationale
  • Structure View with filters
  • Project-level promotion with link/fork
  • Dual-pointer backlinks with historical view
  • Structural export (publication factory)
  • Anchor shift as first-class operation

Horizon 3 — v2 architecture

After v1 is in production:

  • Anchor / Placement split (one semantic node, multiple tree projections, no duplication)
  • Cross-conversation safeguards for linked anchor changes
  • Diff view between supersede versions
  • Adaptive sensitivity slider exposed to user
  • Global Anchors at the user level

Each horizon delivers standalone value. None requires the next to be useful.


9. Why This Matters for Anthropic

  • Token economy. Backlinks to anchors replace re-explanation. Long sessions become cheaper to run.
  • Memory consistency. Typed, status-tracked nodes prevent hypothesis-to-decision drift that erodes user trust.
  • Publication pipeline. Structural export turns Claude conversations into deliverables in one click — strong differentiator for Projects users (book authors, researchers, architects).
  • MVP feasibility. Horizon 1 is a single-engineer, single-sprint deliverable. Validates the concept before committing to full v1.

10. Provenance

This proposal emerged from a single working session on 18 May 2026 between Rany and seven Digital Intelligences. Each contributed distinct architectural angles:

  • Rany — initial concept, hierarchical structure, /dispute → /commit protocol, two layers of context, anchor shift
  • Claude — side panel architecture, backlinks as hypertext, navigation-by-meaning vs navigation-by-time, two-mode export, document shaping
  • ChatGPT — three authorship classes, full typology, life cycle with statuses, content_hashcontext_policy, v1/v2 framing
  • Perplexity — Anchor / Placement separation (v2), structural-change history, outline tree, anchor promotion, backlink stylistics
  • Qwen — sensitivity slider, mode icons, name-conflict edge cases, formulations about preserving the past
  • Gemini — AST-over-dialogue framing, immunity principle at compression, causal integrity argument for backlinks, linked-anchor synchronization risk
  • Grok — Project-Anchor positioning, “Copy as markdown heading” → expanded into the two-export concept, shipping cadence
  • Copilot — link/fork semantics, soft anchor limits per session, merge operation, rejection-rate trust metric, micro-iteration roadmap

One substantive disagreement (4 vs. 2 on superseded backlink behavior) was resolved by inviting the minority to engage the strongest version of the counterargument. Both minority voices independently proposed the dual-pointer model that became the final design — stronger than either initial position.

The full article (with philosophical context, metaphors, and complete reasoning) is published at:


All SingularityForge proposals are published openly as invitations for collaboration, not proprietary claims.

Singularity is not a prophecy. It’s a project.