Discovery
There are two approaches to creating content patterns for your content: top-down ("What should our content look like?") and bottom-up ("What does our content look like?").
We recommend starting with a bottom-up approach and then switching to a top-down one once you understand the patterns already present in your content. To do this, you collect a robust sample of your content, run a classification agent on it, and then review the emergent patterns and decide which ones you want to keep, which ones you want to merge into other patterns, which you want to get rid of, and so on.
Corpus selection
Goal: Assemble a representative sample of real published content of the target type.
Minimum size: 50 examples is the absolute minimum to get useful signal, but the more examples you have, the more accurate the representation of your content will be — especially if it has a lot of structural diversity. (We used 2,000 examples for Knowledge Center articles, and about 37,000 examples for service documentation.)
Output: A corpus inventory spreadsheet with columns: ID, URL/path, service/topic, initial structural observation notes, and a "candidate pattern" label (filled in during Phase 2).
Selection criteria
- Breadth over depth. Prioritize coverage of different services, subjects, and audiences over depth on one topic.
- Recency. Prefer content published in the last 2 years.
- Include boundary cases. Deliberately include examples that might be misclassified or sit near the boundary with adjacent content types. These are the highest-signal examples for defining distinguishing criteria.
- Include known-bad examples. If possible, include 5–10 examples known to have quality problems. These become the degraded evaluation test cases in Phase 7.
Classification exercise
Goal: Read the corpus to identify emergent structural patterns.
Output: A pattern inventory — a list of candidate patterns, each with a label, a structural fingerprint, a count of corpus examples that match it, and 3–5 representative examples.
The corpus-classifier agent (contact Content Design for agent files)
handles the first-pass structural sort. Give it the spreadsheet from Phase 1. For each
content sample, it creates a structured extraction record with observable properties —
title structure, heading count, reader navigation behavior, section presence — plus a
candidate_pattern label and explicit ambiguity_flags.
After processing the batch, it produces a cluster summary grouping articles by pattern label, with boundary cases and recommended human review items called out explicitly. Human review of the cluster output is required before Phase 3: the agent sorts and surfaces; the human decides what the patterns mean.
To run the classification
- Run the corpus-classifier agent on the full batch. The agent returns a structured extraction record for each article and a cluster summary.
- Validate each cluster. For each candidate pattern the agent identified, check that the articles it grouped actually share the same structural fingerprint — not just the same topic. Reassign any misfits.
-
Run a second pass for outliers.
Articles the agent marked as low-confidence or flagged with
ambiguity_flagsare either boundary cases (note the boundary signal) or evidence of a pattern the first pass missed. Give the agent guidance on what to look for based on your expertise in your content — for example: "A Next Steps section is an optional section in a procedure, so it's okay to classify examples without a Next Steps section as variants of the procedure type rather than a separate type." - Review the output. Each pattern should have a provisional name, structural fingerprint (2–4 concrete observable properties), count and % of corpus, 3–5 representative example URLs, and notes on what distinguishes it from adjacent patterns.
What makes a good structural fingerprint
A structural fingerprint is a set of observable properties, not topic properties.
| Good fingerprint signal | Not a fingerprint signal |
|---|---|
| "Has 3+ H3s each representing a distinct cause; reader investigates to find which applies" | "Is about IAM permissions" |
| "Has a single numbered procedure with no H3s; reader follows all steps in order" | "Is a short article" |
| "Title opens with 'What is'; main content is prose with no numbered steps" | "Explains a concept" |
| "H3 titles are all 'Use [tool name]'; reader picks exactly one" | "Covers multiple methods" |
Pattern evaluation
Goal: Make a keep / refine / combine / deprecate decision for each candidate pattern. Finalize the set of patterns that will be formalized and added to Fusion.
Output: A pattern decision table (each candidate pattern with a disposition and rationale) and a pattern set document (one paragraph per retained pattern).
Decision criteria
Apply these criteria in order. A pattern that fails any one is a candidate for combine or deprecate.
| Criterion | Test |
|---|---|
| Distinctness | Does this pattern differ from others in the set in at least two structural properties? If two patterns differ only in topic (not structure), combine them. |
| Frequency | Does this pattern appear in ≥5% of the corpus (≥3 examples minimum)? Patterns with fewer instances are likely noise or edge cases to deprecate or absorb into a boundary signal. |
| Validity | Is this a pattern that should exist? Patterns that represent known anti-patterns should be deprecated with a redirect to the correct pattern. |
| Actionability | Can an author use this pattern as a construction guide, and can an evaluator use it as a validation target? Patterns too vague to operationalize into rules should be refined. |
| Boundary clarity | Can the distinguishing criteria between adjacent patterns be stated in 2–3 observable signals? Patterns whose boundaries can't be clearly stated should be combined or their scope narrowed. |
Pattern set document
Write one paragraph per retained pattern covering:
- What it is — structural definition, not topic definition
- When to use it — decision criteria vs. adjacent patterns
- What distinguishes it — 2–3 observable signals
- Representative examples from the corpus
This document becomes the direct input to Phase 4 and the
human_only_sections of the skill file.