Documentation

Modern LLM-driven retrieval systems rarely process a query as a single lookup. They decompose it into multiple sub-queries — a process called query fan-out — each targeting a different facet of the topic. A question like “how does DNS resolution work?” might fan out to sub-queries for “DNS definition,” “resolver role,” “recursive lookup process,” “TTL caching,” and more.

A piece of content does not succeed or fail as a whole in this model — it succeeds or fails concept by concept, as each sub-query attempts to match a specific facet of the topic. A page that covers five of eight expected concepts may answer five fan-out queries confidently and fail the rest, regardless of how well-written the covered sections are.

ContentGraph is built around this behavior. The anchor concept defines the primary query. The explanation framework models the expected fan-out space — the concepts a retrieval system is likely to sub-query for when a user asks about the anchor topic. Integration states predict how reliably each concept will satisfy its sub-query when found. The writing guidance closes the gaps.

Phase 1 analyzes the content to produce an observed map — a graph of the concepts, relationships, and coverage gaps as they exist in the current text.

For each input, ContentGraph determines:

• —Anchor concept: the primary subject the content is explaining.
• —Observed concepts: all named entities, terms, processes, and ideas found in the content.
• —Relationships: connections between concepts, whether stated directly or inferred from context.
• —Question coverage: whether the content addresses eight standard diagnostic questions for the identified topic.

Once the observed map is complete, ContentGraph generates an explanation framework — a model of what concepts and relationships should be present for a complete explanation of the anchor topic — and translates the gap into writing guidance.

ContentGraph produces three output layers:

• —the observed graph — a visual map of concepts as they appear in the content
• —the explanation framework — a visual model of optimal coverage for the anchor topic
• —writing guidance — actionable editorial instructions for closing the gap

These layers are complementary. The graphs communicate structure visually; the guidance communicates it editorially. Both are necessary to act on the analysis.

All three pipeline calls use Claude Sonnet 4 (claude-sonnet-4-20250514) by Anthropic. Sonnet 4 is Anthropic’s capable general-purpose tier — chosen over faster, cheaper models because structured extraction, integration state judgment, and framework generation require strong reasoning and high instruction-following reliability. Haiku-class models produce noticeably less consistent results for these tasks.

Each analysis run costs three API calls against the user’s own Anthropic key: one for Phase 1 (content analysis) and two for Phase 2 (framework generation and writing guidance). Cost scales with content length. Typical analyses of a 1,500–3,000 word article run well within standard Sonnet pricing; very long documents cost proportionally more.

The explanation framework is generated from the model’s training knowledge of the anchor topic, not from a live index or curated ontology. This means the framework reflects the world as Claude understood it at its training cutoff. Topics that have evolved significantly since then — new protocols, renamed standards, emerging practices — may produce frameworks that are incomplete or subtly dated. Users working in fast-moving domains should treat the framework as an informed starting point and apply their own judgment to its coverage recommendations.

The anchor concept is the primary subject the content is explaining. It is the conceptual root of the observed graph: all other concepts are placed in relation to it.

Anchor identification is the first and most consequential judgment ContentGraph makes. If the anchor is wrong, the observed graph may still be internally consistent, but it will not reflect the content’s actual purpose, and the framework generated in Phase 2 will target the wrong topic.

Each concept in the observed graph is assigned one of four integration states describing how well it is developed and connected within the content.

Each concept is assigned an explanatory role — a label describing the conceptual function it serves in the explanation. Common roles include mechanism, prerequisite, outcome, context, component, and contrast.

Roles are assigned by the model based on how the concept is used in the content. They are not a fixed taxonomy — two analyses of the same content may produce slightly different role labels while accurately capturing the same underlying function.

Relationships are classified as either explicit or implied:

For each relationship, ContentGraph identifies a subject-verb-object triple from the text where possible. These triples are displayed in the content findings panel and serve as evidence for each relationship claim.

SVO structures are the most reliably extractable unit of propositional content. A relationship that cannot be reduced to an SVO triple is harder to verify and harder for a downstream system to interpret or reuse.

Relationships in ContentGraph are directional. “A depends on B” and “B depends on A” are not the same relationship, and the graph renders them with directional arrows accordingly.

When source and target are ambiguous in the text, the model infers direction. This inference may be wrong, particularly for symmetric, reciprocal, or loosely phrased relationships. Users who notice a directional error should read the relationship label alongside the graph edge rather than relying on arrow direction alone.

The framework models the expected fan-out space for the anchor topic — the concepts and relationships a retrieval system is likely to generate sub-queries for when a user asks about the anchor.

It is most useful as a comparison layer. When rendered alongside the observed graph, it reveals which concepts are well covered, which are thin, and which are missing entirely. The writing guidance in Phase 2 is generated directly from this comparison — closing the gap between what the content covers and what the fan-out space expects.

Each concept in the framework is assigned a basis describing where its inclusion comes from.

Each framework concept is assigned a priority reflecting its importance for a complete explanation of the anchor topic.

Priority reflects a concept’s expected centrality in the fan-out distribution for the anchor topic. An essential concept will appear in nearly every retrieval path for this topic — its absence is a broad gap, not a narrow one. A useful concept appears in a narrower range of sub-queries. Priority is not a directive; a concept may be marked essential by the framework but be intentionally out of scope for a specific piece of content.

Each framework concept is also assigned a coverage status indicating how well it is addressed in the observed content.

Identifies framework concepts with coverage status no or partial and priority essential or important. For each, the guidance describes the concept, explains why it matters for the anchor topic, and provides an example sentence for introducing it.

Identifies concepts present in the observed map with integration state underexplained or naming_inconsistent. For each, the guidance describes the integration problem and suggests an approach to resolution.

These items target concepts the content is already trying to discuss but failing to handle clearly. Improving them typically requires expanding a definition, adding a relationship, or standardizing terminology.

Identifies implied relationships in the observed map that should be stated directly. For each, the guidance names the source and target concepts, describes the relationship, and provides an example sentence that states it explicitly.

Sentence-level guidance ties specific editorial instructions to one or more concepts. Unlike the above categories, which are concept-centric, sentence guidance is phrased as a writing directive that can be applied locally to relevant passages.

The observed_analysis event contains the full data powering the observed graph and the content findings panel. It arrives as a single event once the Phase 1 LLM call completes.

These two events arrive sequentially. The framework graph renders when explanation_framework arrives. The writing guidance panel renders when writing_guidance arrives.

For each observed concept:

For each framework concept, the fields differ: priority, basis, alreadyPresent (yes / partial / no), whyItMatters, and relatedConcepts replace the observed-map-specific fields.

For each observed relationship:

Framework relationships carry the same source, target, and label fields, with basis replacing isExplicit.

The NDJSON streaming model serves two goals: progressive rendering and structured access. The observed graph begins rendering as soon as Phase 1 completes, without waiting for Phase 2. The structured fields support both graph rendering and writing guidance generation from the same data.

ContentGraph assumes the model can determine the primary subject of the content from the text alone. This assumption is necessary because the anchor defines the reference frame for all subsequent analysis — the observed graph, the framework, and the writing guidance are all organized around it.

ContentGraph assumes that breaking content into numbered sentences and presenting them to the model preserves enough structure for accurate concept and relationship extraction. HTML formatting, tables, captions, and visual layout are stripped before analysis.

ContentGraph assumes the model's generated framework is a meaningful editorial goal — not an arbitrary list of concepts, but a principled model of what a complete explanation would cover for the identified anchor topic.

ContentGraph assesses coverage against eight questions: whether the content explains what the anchor is, how it works, what it depends on, what it produces, when it applies, what it contrasts with, what commonly goes wrong, and what evidence supports it.

ContentGraph assumes the model can identify when different names or phrasings refer to the same concept and normalize them under a single label. The system also re-derives concept IDs from labels rather than trusting LLM-generated slugs, to reduce inconsistency.

The analysis is configured around claude-sonnet-4-20250514. ContentGraph assumes the model can make stable judgments about anchor identification, concept extraction, integration state assignment, framework generation, and guidance production.

ContentGraph looks for main or article elements when parsing HTML input. If neither is present, it falls back to all p tags. Navigation, headers, footers, scripts, styles, and sidebars are stripped.

ContentGraph splits content into sentences by detecting sentence-ending punctuation followed by a space and an uppercase letter, with a minimum sentence length of 10 characters.

If Phase 1 produces an incorrect anchor, incomplete concept extraction, or poor question coverage assessment, Phase 2 uses that output as its foundation. Errors in Phase 1 are not corrected by Phase 2 — they are amplified.

Integration states are assigned by the model based on its reading of the content. They are not computed from text statistics, keyword frequency, or parse-tree analysis.

Both graphs use a D3 force-directed simulation. The layout converges to a stable position but is sensitive to initial conditions. The same content may render with different node positions on different runs.

ContentGraph does not reject large inputs. Very long documents may approach model context limits, causing the LLM to truncate its analysis or produce an incomplete concept map.

ContentGraph extracts relationships most reliably when they are expressed as clear subject-verb-object structures in prose. Relationships expressed through tables, comparison lists, headings, or other non-prose structures may not be captured.

The user's Anthropic API key is stored in sessionStorage and cleared when the browser tab closes. It is never sent to any server other than the Anthropic API directly.

The explanation framework is produced by a single LLM call using the model's general training knowledge. It is not derived from a curated ontology, a domain expert, or the user's specific audience requirements.

The framework, guidance, and integration states are one model's structured reading of one piece of content at one point in time. They do not account for the user's audience, purpose, tone, voice, or strategic goals.

No retrieval system publishes how it decomposes queries. The sub-queries any given system generates for a topic are not documented, not versioned, and not consistent across providers. ContentGraph's framework models an idealized fan-out space — a principled estimate of what sub-queries would be issued for the anchor topic — not an empirically observed one.

Retrieval system internals — including how queries are decomposed and expanded — are updated silently and frequently. A framework that accurately models the fan-out space for a topic today may be less accurate after an update that changes how the system fans out for that topic.

The 8 question coverage dimensions are a principled approximation of common fan-out sub-query patterns for explanatory content. They are not a taxonomy derived from observed retrieval system behavior and do not correspond to the internal query decomposition logic of any specific system.

The anchor concept is the foundation of the entire analysis. If it is wrong, the observed graph may be coherent but misaligned with the content’s purpose, the framework will target the wrong topic, and the writing guidance will suggest changes that move the content in the wrong direction.

The explanation framework is an editorial reference, not a content requirement. Users may interpret essential or important concepts as mandatory additions, even when those concepts are not relevant to their specific content goal, audience, or angle.

Changes to the underlying model may change how ContentGraph identifies anchors, assigns integration states, generates frameworks, or produces guidance.

A dense observed graph — many nodes, many connections — may look thorough while still having significant coverage gaps. Content that mentions many concepts superficially will produce a visually rich graph, but integration states will reveal that most of those concepts are weakly_integrated or underexplained.

• —Understanding which concepts in an explanation are underdeveloped or poorly connected
• —Identifying relationships that are implied but never stated directly
• —Building a first draft of an explanation framework for a new topic
• —Comparing coverage across different versions or drafts of explanatory content

• —Treating the framework as a content brief that must be fully satisfied
• —Using integration states as a substitute for reading and judging the content directly
• —Applying the tool to narrative, opinion, or persuasive content where structural completeness is not the primary goal