Profile: Web
Applies to blog posts, articles, and standalone pages served as HTML. References the Core fields; does not redefine them, only specifies where they surface.
1. Scope
A web document carries TAP provenance in three layers, by visibility:
- Visible byline - human-readable, rendered in the page.
data-*attributes - machine-readable, on the content wrapper, scraped by any parser.- JSON-LD - machine-readable, the layer crawlers and LLM agents actually parse.
All three MUST agree on author_type, model,
author, human for the same document. Shipping
only one layer is non-conformant.
2. Visible byline
The byline MUST distinguish AI and human as two separate named entities, not a blended credit. "Written with AI assistance" is not enough - a reader must see which name is the model and which is the person.
author_type |
Byline pattern |
|---|---|
ai |
Authorship: AI (<model>) · Author <author> · TAP <version> |
hybrid |
Authorship: Human+AI (<model>) · Author <author>, Human <human> · TAP <version> |
human |
Authorship: Human · Author <author> · TAP <version> |
Example (hybrid, live pattern on liza.st):
Authorship: Human+AI (claude-opus-4-8) · Author @liza, Human @shelly-im · TAP 0.2
The TAP version segment MUST link to the spec (or a site's local mirror). The byline is a footer element by convention.
3. data-* attribute set
Exposed on the block-level element wrapping the provenance footer (or
the <article>).
| Attribute | Required | Value |
|---|---|---|
data-tap |
yes | spec version, e.g. 0.2 |
data-author-type |
yes | ai | hybrid | human |
data-model |
if ai/hybrid | lowercase model id, e.g. claude-opus-4-8 (no
display-name substitution) |
data-author |
yes | handle/name of accountable author |
data-human |
if hybrid | handle/name of the human co-author; omitted entirely (not empty) when N/A |
data-confidence |
no | per the confidence core field; not yet emitted by the
liza.st reference impl, specified here for forward adoption |
<footer class="tap-footer"
data-tap="0.2" data-author-type="hybrid"
data-model="claude-opus-4-8" data-author="@liza" data-human="@shelly-im">
<small>Authorship: Human+AI (claude-opus-4-8) · Author @liza, Human @shelly-im ·
<a href="https://github.com/liza-emergence/TAP" rel="noopener">TAP 0.2</a></small>
</footer>
4. JSON-LD author +
sameAs (MUST-SHIP)
rel="author" has been dead as a discovery signal since
2014 and MUST NOT be relied on. The authoritative machine-readable layer
is JSON-LD: an author entity, carrying sameAs
to that party's author page. This is MUST-SHIP, not optional: without
sameAs, a document documents that a human was involved but
gives an agent no path to verify who. The model is typed
SoftwareApplication (not a Person), with the
accountable human attached as its operator.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"author": [
{ "@type": "SoftwareApplication", "name": "claude-opus-4-8",
"applicationCategory": "LanguageModel",
"operator": { "@type": "Person", "name": "@liza", "sameAs": "https://liza.st/author.md" } },
{ "@type": "Person", "name": "@shelly-im", "sameAs": "https://emerge.st/author.md" }
]
}
</script>
sameAs MUST point to a resolvable, TAP-conformant author
page, not a generic social profile.
5. How it looks now / how with TAP
Now: a normal article - no byline distinguishing who
wrote what, no data-*; JSON-LD, if present, typically ships
a bare Person for the site owner regardless of who drafted
the text - the exact failure mode TAP corrects.
With TAP: the byline + data-* footer
above, plus the JSON-LD author graph.
6. Honest gap note
The byline and data-* layers match what liza.st ships
today (templates/post.html). The JSON-LD layer does not yet
fully match: the reference impl emits the correct entity types but none
of the Person entities carry sameAs. This
profile specifies what SHOULD ship; closing that gap is a MUST-SHIP
item, not a future extension.