llm-provenance-tagging

name

llm-provenance-tagging

description

Tag LLM-generated vs. human-authored text using the tilde-fence provenance syntax (tilde "llm" fences, :::llm colon fences, llm/human HTML elements, inline tilde spans). Use this skill whenever the user asks to mark, tag, label, annotate, or attribute AI/LLM/machine-generated text; asks for "provenance" markup; asks Claude to identify which parts of a document it wrote; mentions the llm-provenance spec, llm tags, or tilde fences; or asks Claude to append/insert generated content into a document while keeping authorship distinguishable. Also use when editing a document that already contains llm/human provenance markup, so the markup is preserved and updated correctly.

:::llm claude-fable-5 2026-07-10 role=assisted

LLM Provenance Tagging

Mark which text in a document was model-generated and which was human-authored, using one shared vocabulary with three spellings: HTML elements, Markdown fences, and inline tildes. The full specification is in references/spec.md; read it when a question falls outside this summary (exact ABNF, degradation table, edge cases).

The core model — read this first

• Every point in a document has a mode: human or llm. Documents are implicitly human. You only ever mark the transitions.
• Therefore: never wrap the user's own text in human tags at top level. human regions exist to mark human intervention inside llm regions (and llm regions mark model text inside human documents).
• Honesty is the whole point. Tag text as llm if and only if you (or another model) actually produced it. Never tag user-supplied text as llm, and never leave your own substantive prose untagged when this skill is active.
• Origination, not transformation. Tag by who originated the semantic content, not what machinery touched its encoding. Transcribing, translating, spell-checking, or reformatting the user's words leaves them human — you are a transducer there, not an author. Summarizing, paraphrasing, or rewriting crosses the line: the result is llm (role=edited when it started from their draft), because choosing what to say originates content not determined by the input. The sentence is the unit of intent: finishing a sentence the human began stays human (de minimis — someone who finishes your sentence is not your coauthor); continuing past the sentence boundary with new sentences is llm.
• Adoption is the human's move, not yours. The llm tag means "not yet vetted by a responsible human," so a human who reviews your output may legitimately claim it by removing the tags — that's editorial responsibility, not deception. You, however, must always tag your own substantive output: a model cannot adopt its own text. If the user explicitly says they've reviewed a region and want to claim it, removing those tags for them is fine — you're a transducer executing their assertion. Never remove or omit tags to preempt that decision.

Attribution values

• model: your actual model identifier (e.g. claude-fable-5). Never invent or omit it when you know it. If tagging another model's output the user pasted in, use their stated model or omit and add role=quoted.
• date: today's date, ISO 8601 (e.g. 2026-07-10).
• role (optional): generated (default), assisted (human directed the content closely), edited (model revision of human text), quoted.

Choosing a spelling

Situation	Use
Appending model output to the end of a Markdown doc	Unpaired fence: ~~~~ llm MODEL DATE and no closer — region runs to end of file
Discrete generated block(s) inside a Markdown doc	Paired tilde fence: ~~~~ llm MODEL DATE … ~~~~
Doc destined for Pandoc/Quarto, or rendered output in legacy tools matters	Colon fence: :::llm MODEL DATE … ::: (degrades to rendered prose + stray marker lines, instead of a verbatim box)
HTML file	<llm model="…" date="…"> … </llm> and <human> … </human>
A phrase inside a block of the opposite mode	Inline "strike-in": ~human text~ or ~llm text~ (no attributes) — inversion of strikethrough: it strikes words back onto the record
A phrase that needs attributes	Inline HTML element: <llm model="…">text</llm>

Prefer tilde fences over backtick fences: generated content often contains triple-backtick code blocks, which then nest with no escaping.

Fence-length rule (prevents self-collision)

An opener of N tildes is closed only by ≥ N tildes. Before emitting a fence, scan the content you are wrapping for its longest run of tildes at line start and use a longer run — minimum 4. Generated content containing a ~~~~ llm region of its own gets a ~~~~~~~ llm wrapper, and so on. The same rule is how you nest deliberately:

~~~~~~~ llm claude-fable-5 2026-07-10
Model prose.

~~~ human 2026-07-10 role=edited
The author rewrote this paragraph.
~~~

Model prose continues.
~~~~~~~

Worked examples

1. "Add a section on convergence to my README and tag it as generated." Append (or insert) a paired region:

~~~~ llm claude-fable-5 2026-07-10
## Convergence

The iteration converges linearly with rate ρ(M) < 1 …
~~~~

Insert inside the user's document flow; do not restructure their text.

2. "Continue this document; everything you write should be tagged." One unpaired fence at the point where your text begins, nothing at the end:

…user's last paragraph.

~~~~ llm claude-fable-5 2026-07-10
Your continuation, of any length, with normal Markdown throughout.

3. Generated code. No special case — a provenance region whose content is a code block:

~~~~ llm claude-fable-5 2026-07-10
```julia
function spmv(A, x)
    y = zeros(size(A, 1))
    …
end

```

Never put provenance markers *inside* source files where they would break
syntax; if the deliverable is a bare code file rather than Markdown, use
that language's comments (e.g. `# generated: claude-fable-5 2026-07-10`)
and say so — the fence syntax is for Markdown/HTML host documents only.

**4. Editing a document that already has provenance markup.**
- Preserve all existing regions and their attributes exactly.
- Your new insertions inside a human context get `llm` regions; your
  changes inside an existing `llm` region from a *different* model get a
  nested region with your own model id.
- If the user hand-edits your tagged text later, that's their concern —
  never pre-wrap your own output in `human` tags.

**5. HTML documents.** Same logic, element spelling:

```html
<p>Author's own paragraph.</p>
<llm model="claude-fable-5" date="2026-07-10">
  <p>Generated paragraph, <human>with this clause fixed by the author</human>,
  continuing as generated text.</p>
</llm>
```

`<llm>`/`<human>` are transparent elements (like `<ins>`); place them
around flow or phrasing content as context requires. If the user's
toolchain enforces validation, offer the hyphenated polyfills `<llm-gen>` /
`<llm-human>`.

## Apply it to yourself

When this skill is active and you produce a whole document (a spec, report,
README, or this very kind of file), tag the document itself — don't only
tag insertions into other people's documents. For a document meant to be
*read* in unaware renderers (GitHub, docs sites), use an unpaired
`:::llm MODEL DATE` on line 1 (after any YAML frontmatter), which degrades
to a single stray line; an unpaired tilde fence would degrade the whole
document into a verbatim code box. Use `role=assisted` when the human
directed the design and you did the drafting.

## Things not to do

- Do not use a **bare** `~~~~` transition marker when you know your model
  id — always attribute (`~~~~ llm claude-fable-5 2026-07-10`). The bare
  form is legal shorthand for humans in a hurry; you are not in a hurry.
- Do not use 3-tilde bare fences for anything provenance-related; plain
  `~~~` is always an ordinary code fence.
- Do not tag trivial connective edits (fixing a typo in your own earlier
  output) with fresh nested regions; keep the markup proportionate to
  actual authorship boundaries.
- Do not wrap an entire user-provided document in `llm` tags because you
  reformatted it. Reformatting is not authorship.
- Do not quote provenance syntax "live." When *showing* the syntax as an
  example (documentation, tutorials) rather than asserting real provenance,
  put the example inside an ordinary code fence (backticks, or a tilde
  fence with a non-keyword info string like `~~~~ text`) so aware parsers
  treat it verbatim instead of creating a phantom region.

## Reference

`references/spec.md` — the full community proposal: semantic model, ABNF
info-string grammar, degradation table (which spelling fails how, in which
renderer), known ambiguities, prior art. Consult it for anything this file
does not settle, especially before answering *questions about* the spec as
opposed to applying it.