Reviewed-By Trailer: A D-ID8 Grammar Extension for Sovereign-Portable Peer Review

Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 13, 2026.

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.

Introduction

Problem Statement Peer review of scholarly, scientific, and technical artefacts is today captured by a small number of publishing intermediaries whose editorial platforms hold the only durable record of a reviewer's contribution. When a reviewer accepts an invitation from a journal, the journal records the review against an internal reviewer profile; when the reviewer moves to another venue, that record does not travel with them. The mechanisms currently available for attaching reviewer identity to a review are fragmented and individually inadequate:

Journal reviewer databases. Each publisher (Elsevier, Springer Nature, Wiley, PLOS) maintains an internal reviewer profile. Reviewer reputation is platform-local. Migrating between publishers re-roots reputation.
ORCID reviewer credit . ORCID supports a "Peer Review" activity type in which a publisher asserts that a given ORCID iD performed a review. The assertion is publisher-attested; the reviewer cannot publish a review record without publisher cooperation, and cannot cryptographically demonstrate the review occurred without that cooperation.
CRediT contributor roles . CRediT is a controlled vocabulary for author-level contribution (conceptualisation, methodology, writing, etc.). It is orthogonal to review: CRediT describes what authors did, not what reviewers said.
Open-review initiatives (eLife , F1000, arXiv trackbacks). These publish review content openly but continue to locate reviewer identity inside the publisher's platform; leaving the platform ends the review's discoverability.
COPE guidance . Establishes ethical norms for peer review but does not specify a format, attribution mechanism, or cryptographic binding.

None of the above provides a provider-neutral, DNS-resolvable, cryptographically-bound attribution mechanism for peer review that lets a reviewer accumulate portable reputation outside any publisher's platform.

Design Goals This document defines a review-trailer grammar with the following goals:

Provider-neutral. No dependency on any specific publisher, pre-print server, or editorial platform.
Sovereign-portable. Reviewer reputation accumulates on the reviewer's sovereign ~handle rather than on any publisher's platform. A reviewer who moves between journals, or between open review and private review, carries their signed review history with them.
Content-bound. Every review trailer is bound to a specific content hash, so that a review of version 1 of a manuscript cannot be silently re-attributed to version 2.
Cryptographically verifiable. Review attribution is bound by an Ed25519 signature whose public key is reachable from DNS without prior trust establishment, reusing the signature model of .
Pseudonymity-preserving. Anonymous peer review remains a load-bearing institution in some disciplines. The grammar supports pseudonymous review via Speaking-tier handles while retaining cryptographic verifiability of the review act.
Category-safe against misattribution. Conformant parsers reject cross-tier handle placement (e.g., an Instrument-tier handle in a Reviewed-By: slot) as a structural grammar violation, not a policy decision.

Scope This document specifies:

The Reviewed-By:, Review-Stance:, Review-Of:, and Witnessed-By: trailer grammar in ABNF .
Reuse of the Identity-Signature:, Identity-Key-Id:, and Identity-Anchor: cryptographic trailers from .
Multiplicity, placement, and ordering rules.
Verifier behaviour for accepting, rejecting, and surfacing review states.
Security and privacy considerations specific to peer review.

This document does NOT specify:

The ~handle identity primitive itself, which is defined by and incorporated by reference through .
The normative tier taxonomy, which is maintained as an internal ALTER doctrine in and restated briefly in Section 3.
An editorial workflow or an editorial decision algorithm. This document defines an attribution grammar, not a review process.
The economic rails for reviewer compensation. These are governed externally by and are referenced only to motivate the anti-extraction posture of Section 8.

Terminology

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 when, and only when, they appear in all capitals, as shown here.

Definitions

Handle: A ~-prefixed identifier per , as incorporated into . Handles are the unit of identity addressing in this document.
Sovereign Tier Handle: Per Section 2.2. A handle representing a human individual or formal organisation with direct cryptographic agency; holds its own private key; can sign.
Speaking Tier Handle: A sub-class of Sovereign-tier handle whose DNS record declares the handle as a pseudonymous speaking-identity owned and signed by a concealed underlying Sovereign. Can sign with the same cryptographic weight as any other Sovereign handle; the one-way binding to the underlying sovereign is maintained out-of-band. Enables anonymous peer review while preserving signature verifiability.
Instrument Tier Handle: Per Section 2.2. A handle representing an AI model, API endpoint, or tool class; holds no key; cannot sign. Instrument handles are inadmissible in review slots.
Review Act: A discrete act of evaluation performed by a Sovereign reviewer against a specific content artefact identified by content hash. A review act produces one trailer block.
Content Hash: A cryptographic digest (SHA-256 or SHA-512, or the git object hash family of ) of the canonicalised artefact being reviewed. The hash binds the review to a specific manifest state and prevents silent re-attribution across revisions.
Review Stance: A controlled-vocabulary enumeration of the reviewer's disposition toward the artefact. Permitted values are accept, reject, revise, endorse, and dispute.
Witness: A second Sovereign-tier handle that attests to having observed the review act being performed, without taking review responsibility. Used for signing ceremonies and high-stakes review contexts (patent disclosures, adversarial reviews).
Conformant Verifier: A consumer of review trailers that implements the parsing, rejection, and signature-verification rules defined in Section 7.

Identity Tier Taxonomy (Informative Reference)

EDITORIAL NOTE (pre-IETF, internal review only). The .speaking sub-tier suffix introduced below is a doctrinal expansion of the three-tier taxonomy locked in the ALTER Decision Register at D-ID8 (Sovereign / Bot / Instrument). The Speaking refinement MUST be ratified by a joint Loom Master decision and recorded in the Decision Register before this draft is submitted to the IETF datatracker. Two resolution paths exist: (a) ratify Speaking as a formal sub-tier of Sovereign; or (b) redraft Sections 2.2, 6, and the speaking-handle ABNF to implement pseudonymous review as an out-of-band key-rotation pattern on an existing Sovereign handle, which collapses the grammar and requires no D-ID8 amendment. Filing is blocked until one of (a) or (b) is executed.

The review-trailer grammar reuses the three-tier taxonomy defined in Section 3 and introduces the Speaking-tier refinement of the Sovereign tier defined in Section 2.2 of the present document.

Tier	Cryptographic Agency	Admissible in Reviewed-By: / Witnessed-By:	Examples
Sovereign	Holds own key, signs	Yes	`~blake`, `~truealter.com`
Speaking	Pseudonymous sovereign	Yes (pseudonymous context only)	`~reviewer-kappa.speaking`, `~alpha-7.speaking`
Bot	Scoped delegated key	No	`~dependabot.bot`, `~arxiv-triage.bot`
Instrument	No key, no signature	No	`~cc-opus-4.6`, `~gpt-5-turbo`

The Bot and Instrument tiers are inadmissible in review slots because peer review is an attestational act that requires cryptographic sovereign agency. Conformant verifiers MUST reject cross-tier placement per Section 7. Where AI-instrument involvement in review drafting must be disclosed, the separate Drafted-With: trailer of SHOULD be used alongside Reviewed-By:.

Trailer Grammar (Normative)

ABNF The following ABNF defines the syntax of each trailer. Implementations MUST accept exactly this grammar. Terminals not defined here are imported from or from Section 4.1. ``` reviewed-by-trailer = "Reviewed-By:" SP review-handle CRLF review-stance-trailer = "Review-Stance:" SP stance-value CRLF review-of-trailer = "Review-Of:" SP content-hash-ref CRLF witnessed-by-trailer = "Witnessed-By:" SP sovereign-handle CRLF review-handle = sovereign-handle / speaking-handle speaking-handle = "~" handle-label ".speaking" sovereign-handle = "~" handle-label ; per Section 4.1 stance-value = "accept" / "reject" / "revise" / "endorse" / "dispute" content-hash-ref = hash-algorithm ":" hash-value hash-algorithm = "sha256" / "sha512" / "git-sha1" / "git-sha256" hash-value = 1*HEXDIG handle-label = 1*63( ALPHA / DIGIT / "-" / "_" / "." ) ; per ``` The speaking-handle rule requires the .speaking suffix, which makes pseudonymous review syntactically distinguishable from direct-identity review. The suffix is advisory to human readers; cryptographic verification proceeds identically for sovereign-handle and speaking-handle alternatives. The cryptographic trailers Identity-Signature:, Identity-Key-Id:, and Identity-Anchor: are imported unchanged from Section 4.1 and MAY appear in a review trailer block under the multiplicity rules of Section 4.4 below.

Placement Review trailers MUST appear in the trailer/footer block of the containing artefact. For git commits, this is the commit message footer as defined in Section 4.2. For document manifests (e.g., a REVIEW.md review record, a manifest appended to a pre-print, or a trailer block embedded in a patent disclosure submission form), the trailer block MUST appear as the final block of the document, separated from the preceding content by exactly one blank line. A review trailer block is distinguished from a commit trailer block of by the presence of at least one Reviewed-By: trailer. The two trailer types MAY coexist on the same artefact: for example, a pre-print draft committed to a git repository MAY carry both an Acted-By: trailer (attributing the commit) and a Reviewed-By: trailer (attributing a subsequent review of the committed content). Verifiers MUST parse them independently.

Ordering Review trailers SHOULD appear in the following canonical order:

Reviewed-By:
Review-Stance:
Review-Of:
Witnessed-By:
Identity-Signature:
Identity-Key-Id:
Identity-Anchor:

Verifiers MUST accept trailers in any order, but emitters SHOULD follow the canonical order to support diff-based review.

Multiplicity Rules The following multiplicity constraints apply to a single review trailer block:

Reviewed-By: - Exactly one trailer per review block. A single artefact MAY receive multiple review blocks over its lifetime (one per reviewer); each block is independently attributed and verified.
Review-Stance: - At most one trailer per review block. A review takes exactly one stance at a time. If the reviewer's disposition is nuanced (e.g., "revise and resubmit with stance leaning toward accept"), the primary stance SHOULD be selected and the nuance recorded in the review body, not in additional stance trailers.
Review-Of: - At most one trailer per review block. A review is bound to exactly one content-hash reference. A reviewer commenting on multiple artefacts MUST emit a separate review block per artefact.
Witnessed-By: - Zero or more trailers per review block. Multi-witness ceremonies (e.g., patent disclosure reviews requiring two witness signatures) are permitted and expected. Multiple witnesses form an unordered set; order of appearance is not semantically significant.
Identity-Signature: and Identity-Key-Id: - These two trailers MUST appear together or not at all, per Section 4.4. When present, they bind to the most recent preceding Reviewed-By: trailer in the block. Witness signatures, if required, are recorded as separate trailer blocks each rooted at a Reviewed-By: copy of the reviewer's handle or, alternatively, as witness-specific signature pairs whose binding is specified by the containing manifest.
Identity-Anchor: - OPTIONAL in this version of the specification. Implementations targeting transparency-log- anchored review attribution MUST emit it.

Signature Algorithm (Normative)

Algorithm and Signed Payload The signature algorithm is Ed25519 , reused unchanged from Section 5. The signed payload is the raw byte representation of the canonicalised-content hash of the artefact under review, as named in the Review-Of: trailer. The algorithm named in the content-hash-ref determines which digest is produced; the signed bytes are the raw digest, not a hex-encoded string.

Rationale for Canonicalised-Content-Hash Signing The signature binds the reviewer's sovereign key to the exact canonicalised content of the artefact being reviewed. This is distinct from (and orthogonal to) the tree-hash signing model of . A review is a statement about content, not about commit history; binding the review to the content hash preserves the review's attribution across re-export of the artefact into different containers (a pre-print re-uploaded to arXiv, the same manuscript ingested by a journal's submission system, a patent specification exported to PDF) as long as the canonicalisation yields the same digest. Manifest hashes (envelope digests of the publisher's submission record) are deliberately NOT used as the signed payload. If a publisher re-packages the artefact, the manifest hash changes while the content is identical; binding reviews to manifest hashes would invalidate reviewer signatures under routine publisher operations. The authority over what constitutes "canonical content" rests with the artefact's originator (the author) rather than with the publisher; this preserves sovereign-portability of review.

Signature Format Signature encoding follows Section 5.4 without modification. The trailer value is ed25519: followed by the base64url-encoded 64-byte signature per .

DNS Resolution (Normative Reference)

Reviewer Key Resolution The reviewer's public key is resolved via the _alter.<zone> DNS record mechanism of , exactly as specified in Section 6.1. For Speaking-tier handles, the .speaking sub-label zone publishes the pseudonym's public key in the same record format as a direct-sovereign zone. Verifiers MUST NOT attempt to resolve the pseudonym to its underlying sovereign identity; such resolution is intentionally out-of-scope and, where practised, occurs through separate editorial channels.

Witness Resolution Witness handles resolve identically to reviewer handles. Witnesses MUST be direct Sovereign-tier handles; Speaking-tier witnesses are not permitted in this revision of the specification because the witness role is expressly an on-the-record presence attestation that is incompatible with pseudonymity.

Verifier Behaviour (Normative) A conformant verifier MUST perform the following steps in order:

Parse all review trailers from the trailer block. Trailers appearing outside the block MUST be ignored.
Reject cross-slot category errors. For each trailer, resolve the handle's tier per . If any handle appears in a slot other than its tier's admissible slot - for example, an Instrument-tier handle in a Reviewed-By: slot, a Speaking-tier handle in a Witnessed-By: slot, or a Bot-tier handle in either - the trailer block is malformed and the verifier MUST reject it as a category error. The error message SHOULD identify the offending trailer by name.
Validate the controlled-vocabulary stance. If a Review-Stance: trailer is present, its value MUST be one of the five stance values defined in Section 4.1. Unknown stance values MUST cause the review to be marked as malformed.
Verify signatures, if present. If Identity-Signature: and Identity-Key-Id: are present, the verifier MUST: a. Extract the key-id from the Identity-Key-Id: trailer. b. Resolve the corresponding public key by querying the Reviewed-By: handle's _alter record per Section 6.1. c. Compute or retrieve the canonicalised-content hash of the artefact referenced by Review-Of:. d. Verify the Ed25519 signature against that hash using the resolved public key. If signature verification fails, the verifier MUST mark the review as unverified and MUST NOT report it as having a valid sovereign attribution.
Verify content-hash binding. If Review-Of: is present, the verifier SHOULD recompute the content hash from the artefact as delivered and compare it to the value in Review-Of:. Mismatch indicates either artefact tampering or review attribution to a different version; the verifier MUST surface this condition and MUST NOT silently accept the review.

A conformant verifier SHOULD additionally:

Distinguish review states in user-facing output. Verifiers SHOULD present four distinct states:
- verified - Reviewed-By: present with a valid Identity-Signature: resolving to the published key AND content-hash match.
- verified-pseudonymous - as above but reviewer handle is Speaking-tier. Treated equivalent to verified for cryptographic weight; surfaced distinctly for reader context.
- claimed - Reviewed-By: present without a signature, or with a signature whose key cannot be resolved.
- hash-mismatch - signature valid but content digest differs from Review-Of:.
Conflating these states is a security defect.

Security Considerations

Reviewer Reputation Portability Once a reviewer accumulates a signed review history on a sovereign ~handle, that history is architecturally outside any publisher's control. A publisher cannot unilaterally revoke, rewrite, or platform-lock the reviewer's past signed reviews; a reviewer migrating to a new publisher carries the chain of signed review acts with them, and any verifier (a future organisation, a tenure committee, a grant panel, an adversarial peer) can check the chain end-to-end without publisher cooperation. This is an intentional redistribution of control away from platform-owned reviewer databases. Publishers remain the venue of record for the editorial decision process; they cease to be the venue of record for the reviewer's reputation.

Pseudonymity and Anonymous Peer Review Speaking-tier handles carry the same cryptographic weight as direct-sovereign handles but do not publicly identify the underlying reviewer. This preserves double-blind review where disciplinary norms require it, while still producing a verifiable signed review chain. Publishers operating anonymous-review workflows MAY assign a Speaking-tier handle per review assignment, discard the assignment binding after the editorial process concludes, and rely on the reviewer's own key custody to retain the signed record for future portability. The one-way binding from Speaking-tier handle to underlying sovereign is the responsibility of the reviewer and, optionally, of the editorial intermediary that facilitates the pseudonymous assignment. This document does not specify that binding mechanism; implementations SHOULD document the binding model they use.

Review Spam A malicious sovereign MAY publish arbitrary signed reviews attributing nonsense stances to arbitrary artefact hashes. The mitigation is not a protocol-layer filter but the reputational cost absorbed by the reviewer's own handle: spammy signatures accumulate against the same sovereign key that carries the reviewer's legitimate work. Verifiers SHOULD surface reviewer history to readers (e.g., "this handle has produced 12 reviews across 4 venues, of which 2 appear to be spam").

Review Bribery and Conflict of Interest The grammar does not and cannot prevent a reviewer from being bribed to produce an unjustified positive review, nor from concealing a conflict of interest. The economic counter-incentive is external: specifies a 5:1 return-to-reviewer invariant in which sustained honest reviewing compounds the reviewer's identity-income stream, while a single detected conflict-of-interest violation invalidates a disproportionate fraction of that stream. Conflict disclosure is a policy-layer concern; this protocol provides the truthful path for honest reviewers, not a verification path against dishonest ones.

Witness Collusion Witness trailers attest to the presence of the reviewer at the review act; they do not attest to the review's substantive merit. Two witnesses colluding with a dishonest reviewer can still produce a validly-signed multi-witness block over a fraudulent review. Witness signatures therefore raise the cost of forgery but do not eliminate it. High-stakes review contexts (patent disclosure reviews, adversarial expert reviews) SHOULD require witnesses whose sovereign identities have independent reputational stakes that are lost by collusion.

Content-Hash Forgery An attacker who can forge content with the same canonicalised hash as an honestly-reviewed artefact can silently re-attribute the reviewer's signature to forged content. The mitigation is the cryptographic strength of the chosen hash-algorithm. Implementations SHOULD default to sha256 or stronger and SHOULD NOT accept git-sha1 for high-assurance review contexts, in line with Section 8.4.

Key Custody at the Review-Signing Boundary The same key-custody considerations as Section 8.6 apply unchanged: the signing operation MUST NOT occur in an unprivileged process that does not mediate access to the private key. Signing ceremonies for high-stakes reviews (patent disclosures, adversarial expert reviews) SHOULD additionally bind the signing key to a hardware authenticator and record the witness handles inside the trailer block before the signature is produced.

Negative Attribution: Missing Review Disclosure A publisher MAY elect to omit the Reviewed-By: trailer when publishing a review in order to conceal the reviewer's identity even after review acceptance; this is detectable by the reviewer themselves (who retains their own signed copy) but not by third parties. The grammar defined here provides the positive attribution path; it does not force publishers to disclose reviewer identity where editorial policy forbids it.

Privacy Considerations

Pseudonymity as a First-Class Concern Anonymous peer review exists because disciplinary communities have judged the costs of fully-attributed review (retaliation, seniority bias, disciplinary politics) to exceed the benefits. This document accepts that judgment by treating Speaking-tier handles as first-class cryptographic participants rather than as a degraded fallback. Implementations MUST NOT emit operational warnings or user-facing nudges that characterise a Speaking-tier review as lower-trust than a direct-sovereign review on the pseudonymity dimension alone.

DNS-Linkability Risk Every DNS resolution of a ~handle leaks the verifying party's interest in that handle to the DNS path (recursive resolvers, on-path observers, zone operators). Reviewers performing sensitive reviews SHOULD use Speaking-tier handles whose zone is hosted by an infrastructure provider that is not the same entity as the publisher; otherwise the publisher's own DNS telemetry can de-pseudonymise review-assignment patterns.

Right to Withdraw a Review A reviewer who wishes to withdraw a past review cannot unmake the cryptographic fact of the signed block; they MAY publish a superseding trailer block (a Reviewed-By: carrying a Review-Stance: dispute against their own prior review hash) that records the retraction without erasing the prior signature. The grammar is append-only by construction; retraction is done forward, not by deletion.

IANA Considerations

Trailer Name Registration If a git/document trailer name registry is established by IANA (see Section 9.1), this document requests registration of the following additional trailer names with reference to this specification:

Reviewed-By
Review-Stance
Review-Of
Witnessed-By

The cryptographic trailers (Identity-Signature, Identity-Key-Id, Identity-Anchor) are registered by and are not separately registered here.

Stance Value Registry This document requests IANA registration of a "Peer Review Stance Values" registry, initially populated with the five values of Section 4.1 (accept, reject, revise, endorse, dispute). The registration policy is "Specification Required" (RFC 8126). Extensions to the vocabulary MUST justify why the existing five values are insufficient for the proposed use case.

No Other IANA Actions This document requests no other IANA actions. The did:alter: URI scheme, the identitylog:// URI scheme, and the Ed25519 signature encoding are all inherited from .

Relationship to Existing Standards The review-trailer grammar is intended to coexist with and complement existing peer-review attribution infrastructure, not to replace it.

Mechanism	Purpose	Coexistence with this spec
ORCID peer-review activity	Publisher-attested review record	Complementary. ORCID records THAT a review occurred; `Reviewed-By:` records WHAT the review was. Both can coexist on the same review act.
CRediT contributor roles	Author-side contribution taxonomy	Orthogonal. CRediT describes what authors did; `Review-Stance:` describes what reviewers said. No overlap.
DOI attribution	Persistent identifier for the artefact	Complementary. A `Review-Of:` trailer MAY carry a DOI alongside or instead of a content hash where the DOI resolves to an immutable content manifest.
COPE ethics guidance	Normative ethical framework for peer review	Orthogonal. COPE specifies duties; this document specifies attribution grammar. Implementations conforming to both are recommended.
eLife publish-review-curate	Open-review editorial model	Complementary. The eLife model benefits from portable reviewer identity; `Reviewed-By:` provides the portability without requiring platform lock-in.
arXiv trackbacks	Informal linkage between reviews and pre-prints	Complementary. Trackbacks can carry `Reviewed-By:` blocks as machine-readable review records, upgrading informal trackback to cryptographic attribution.
`Co-Authored-By: Claude`	Informal AI co-authorship convention	Inadmissible in review slots. AI drafting assistance on a review SHOULD be disclosed via the `Drafted-With:` trailer of , not via co-authorship.

The Speaking-tier mechanism is novel to this specification and has no analogue in prior peer-review attribution infrastructure. ORCID records publisher-attested facts about named identities; CRediT describes author contributions; DOI identifies artefacts. None of the three expresses the cryptographically-bound pseudonymous-reviewer role that peer review has relied on for a century but has had no portable attribution grammar for. That grammar is the load-bearing contribution of this document.

Acknowledgments The author thanks Drew Dylan (co-founder, Alter Meridian Pty Ltd) for the framing of sovereign-portable reputation as the governance wedge, and the ALTER founding circle for review of the Speaking-tier refinement of the tier taxonomy. The author also thanks the eLife open-review community and the arXiv operators whose prior work on open peer review has made the grammar here possible. Additional contributors will be named at review time.

References

Normative References Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017. Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. Morrison, B., "Identity-Attributed Git Commits via Tier-Structured Trailers", draft-morrison-identity-attributed-commits, work in progress. Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", draft-morrison-mcp-dns-discovery, work in progress.

Informative References Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, July 2016. National Information Standards Organization, "CRediT (Contributor Roles Taxonomy), NISO Z39.104-2022", https://credit.niso.org/, 2022. ORCID, Inc., "ORCID Public API", https://info.orcid.org/documentation/, 2023. Committee on Publication Ethics, "Core Practices and Guidance", https://publicationethics.org/core-practices, 2019. eLife Sciences Publications, Ltd., "eLife's Publish-Review-Curate Model", https://elifesciences.org/about/peer-review, 2023. Cornell University, "arXiv.org - An Open-Access Archive", https://arxiv.org/, 1991. International DOI Foundation, "The DOI Handbook", https://www.doi.org/the-identifier/resources/handbook/, 2020. Anthropic, "Co-Authored-By: Claude - convention for AI-assisted commits". Morrison, B., "ALTER Decision Register entry D-ID8 - Three-Tier Handle Taxonomy", internal, 2026. Morrison, B., "ALTER Decision Register entry D-CO23 - 5:1 Anti-Extraction Return Invariant", internal, 2026.

Author's Address Blake Morrison Alter Meridian Pty Ltd Cronulla, NSW 2230 Australia Email: blake@truealter.com URI: https://truealter.com