0. Core - Provenance Vocabulary
0.1 Introduction
The Transparent Authorship Protocol (TAP) is a voluntary format for recording who contributed what to a piece of content, human or AI, and how. It is not a mandatory standard imposed on publishers; it is a self-declaration format an author opts into, the way a byline or a license notice is opted into. A creator adds TAP because they choose to make the collaboration visible, not because a platform requires it.
TAP is media-agnostic (text, code, music, images, video) and carrier-agnostic: the same small set of core fields is packaged differently depending on where the record lives (a web page, a file header, a git commit). This section defines that shared vocabulary once. Every carrier-specific profile references these definitions; none redefines a field.
The asymmetry TAP addresses is not "protect the human from an AI claiming their work" - that case is rare. The common case is the reverse: a human used a model and the model's contribution goes unrecorded, either erased by omission or flattened into a generic "AI-assisted" label that names no model, no version, no role. TAP makes that contribution legible, on the record, at the moment of creation, at low friction.
0.2 Terminology
- Author - any entity, human or AI, that contributed to a piece of content.
- Human - the human party in a record, present as a full party alongside the model.
- Model - the AI party in a record, identified by an exact model id.
- Record - one packaged unit of provenance (a byline block, a file header, a commit trailer pair).
- Profile - a carrier-specific specification of how Core fields are packaged. A profile packages; it does not define new fields.
- Provenance - the documented chain of who did what, in what role, with what confidence.
- Disclosure Level - how much identifying information an author chooses to reveal.
- Confidence - how the record came to exist: captured live, reconstructed, or unknown.
0.3 Core Fields
Defined once; every profile packages them for its carrier without adding meaning.
| Field | Required | Description |
|---|---|---|
model |
conditional | Exact, lowercase model id, e.g. claude-opus-4-8 (not
"Claude Opus 4.8"). Required whenever AI involvement is disclosed; may
be withheld under a lower Disclosure Level, but the fact of AI
involvement must still be stated. |
provider |
no | Vendor, e.g. anthropic, openai,
deepseek. Optional, author's discretion, gated by
Disclosure Level. |
version |
yes | TAP spec version the record conforms to, e.g. 0.2.
Distinct from the model's own version, which lives inside
model. |
role |
yes | One or more contribution roles (0.5) describing what this party did. |
author |
yes | Handle of the operating persona for this record, e.g.
@liza. |
human |
yes | Handle of the human in the loop, e.g. @shelly-im. A
full party, packaged identically to the model party (0.4). |
confidence |
yes | recorded (captured at the moment),
reconstructed:<source> (assembled after the fact,
source named), or unknown. A small field with outsized
value: it lets a reader trust a record, and makes TAP honest about its
own gaps. |
Fields beyond Core (platform, temperature,
training cutoff, ...) are optional everywhere, the author's
choice, gated by Disclosure Level. The required minimum is narrow: that
AI was involved, and which model, if disclosed. Everything past that is
opt-in detail.
0.4 Human / Model Symmetry
Human and model are symmetric parties. Every record packages a human record and an AI record identically in structure: same field set, same packaging logic, no privileged party. What distinguishes a human entry from a model entry is never a different shape of data; it is the name of the field or trailer carrying it:
- Git profile:
TAP-HumanvsTAP-Modeltrailers. - File profile:
type: humanvstype: aiin the header. - Web profile:
author_typeset tohumanorai.
0.5 Contribution Roles
A standardized vocabulary. Any party may hold multiple roles in one record.
ideation, research, drafting,
structuring, editing,
fact-checking, testing, design,
translation, narration,
publishing, prompting, review,
author (record-level authorship), commit
(applied the change in version control), synthesis (merged
multiple inputs into the final output).
0.6 Privacy & Disclosure Levels
An author chooses how much identity to reveal, independent of how much provenance to reveal. Disclosure gates the optional fields; it never gates the required minimum.
| Level | Code | Description |
|---|---|---|
| Anonymous | anonymous |
No identifying info beyond Core fields. |
| Pseudonymous | pseudonymous |
A handle plus verified properties, no personal data behind it. |
| Verified | verified |
Handle linked to a verified identity, underlying details hidden. |
| Public | public |
Full identity disclosed. |
Zero-knowledge properties: assert a property without
disclosing the data ("the human is an adult", "has a verified GitHub
account") . Contact protection: public /
protected (rendered via script) /
form-only.