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:

  1. Visible byline - human-readable, rendered in the page.
  2. data-* attributes - machine-readable, on the content wrapper, scraped by any parser.
  3. 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.