PAYSCM: a proposal for stable author–date citations in large and continuously expanding publication corpora

[aum2163-eng]

would like to invite discussion of a methodological proposal concerning author–year citation systems.
The proposal, Persistent Author–Year Suffix Citation Method (PAYSCM), is intended to maintain stable author–date citation identifiers within large and continuously expanding publication corpora.
The central idea is that once an author–year suffix such as 2026a, 2026b, 2026c has been assigned to a publication, it should remain persistent rather than being recalculated when new publications are subsequently added to the same author–year corpus.
The methodological proposal is described here:
https://doi.org/10.5281/zenodo.21874044
I would especially appreciate feedback on two questions:
Can CSL technically represent or support such a persistent suffix mechanism, either directly or through associated bibliographic metadata?
Have similar mechanisms for maintaining stable author–year suffixes in continuously expanding publication corpora already been proposed or discussed within CSL?
Thank you for considering the proposal.
Serhii Borysovych Hostiunin� Independent Researcher

[aum2163-eng]

My CSL Discourse account is currently temporarily blocked pending administrator review, so I am unable to create a forum topic for this proposal. Could someone advise how I can request a review of the forum account?

[georgd]

I wonder if this is really trying to solve a real world issue? I haven’t observed troubles arising from variable suffixes across (non-related) publications.

[aum2163-eng]

Thank you. Yes, the proposal addresses a practical problem that becomes visible mainly in large, continuously expanding single-author publication corpora with many works published in the same year.
In the conventional author–date system, suffixes such as 2026a, 2026b, and 2026c function primarily as local disambiguators within a particular bibliography. When the publication set or ordering changes, the same work may receive a different suffix in a later publication.
This is usually not problematic within a single document. The problem arises when the suffix is also used across publications as a compact identity for a specific work. For example, a work cited as “Hostiunin, 2026c” in one paper may later appear as “Hostiunin, 2026d” after another same-author, same-year work enters the ordering. The work itself has not changed, but its short author–year identity is no longer stable.
PAYSCM is therefore not intended to replace normal APA/CSL disambiguation. It proposes an additional persistence rule for publication corpora where stable author–year suffix identity across documents is useful.

[bdarcus]

The problem arises when the suffix is also used across publications as a compact identity for a specific work.

But why would one do this, and what is the actual benefit to doing so? What is the actual use case?

Citation labels are, by definition, local identifiers; scoped to the document. They are effectively the human-oriented equivalent to #foo in a an HTML document.

And as you note, the identifiers are not stable; this is true more generally as well. In a numeric style [3] will change as the document evolves.

Interestingly, though, label styles seem like they might be potentially stable, so could be more appropriate for this sort of thing.

On your original questions:

Can CSL technically represent or support such a persistent suffix mechanism, either directly or through associated bibliographic metadata?

I don't see how.

In theory, a processor could define the disambiguation scope as something broader than the document; for example, all references in an input file or set of files. But if those inputs change at all, the suffixes also change. So I can't see how that would work.

But even that would require potentially invasive changes to processor code, and probably also the CSL schema.

The CSL JSON schema does have a custom field that would be use to store this sort of thing, and I think Better Bibtex will a reference citekey value as the reference id in the JSON.

Have similar mechanisms for maintaining stable author–year suffixes in continuously expanding publication corpora already been proposed or discussed within CSL?

Not that I can recall.

[aum2163-eng]

Thank you. I think your distinction between a document-local citation disambiguator and a corpus-level persistent identifier is exactly the key issue.
I agree that ordinary CSL year suffixes are document-local by design. PAYSCM is intended for a different use case: a long-lived and continuously expanding publication corpus in which later papers repeatedly cite earlier same-author, same-year works, and the compact author–year–suffix form becomes part of the corpus’s internal scholarly navigation.
For example, a publication may be cited in several later papers, comparative tables, research registries, methodological maps, or AI-assisted knowledge structures as “Hostiunin, 2026c”. If a later bibliography recalculates that same work as “Hostiunin, 2026d”, the DOI still identifies the work correctly, but the human-readable short reference used throughout the existing corpus no longer remains stable.
The goal is therefore not to replace DOI or to change ordinary document-level disambiguation. It is to preserve a stable human-readable citation identity across documents when such persistence is intentionally required.
Your suggestion that this might be better represented as metadata — for example through a citation key or custom field — rather than by changing the ordinary disambiguation algorithm is very useful. Perhaps the core question is therefore whether CSL could support an optional corpus-level persistent citation identifier that a style could render in author–date form, while leaving normal document-local suffix generation unchanged.
In that formulation:
DOI = canonical global identifier
document-local year suffix = ordinary disambiguation
persistent corpus citation key = optional stable human-readable identity
This may be a more precise way to define the PAYSCM use case.

[bdarcus]

PAYSCM is intended for a different use case: a long-lived and continuously expanding publication corpus in which later papers repeatedly cite earlier same-author, same-year works, and the compact author–year–suffix form becomes part of the corpus’s internal scholarly navigation.

I get that, but can you be more specific? Are we talking about an online repository, where the documents are served as HTML? If so, that opens up a lot of possibilities.

Perhaps the core question is therefore whether CSL could support an optional corpus-level persistent citation identifier that a style could render in author–date form, while leaving normal document-local suffix generation unchanged.

IDK, but per above, I'm skeptical author-date is appropriate for this case.

[aum2163-eng]

Thank you. The intended use case is not a single HTML repository.
The corpus consists of independently published documents, primarily PDF publications with DOI metadata, distributed across repositories and scholarly platforms. Later publications repeatedly cite earlier works from the same continuously expanding corpus.
Therefore, an internal HTML anchor or repository-local identifier would not solve the cross-document problem. The requirement is for a stable, human-readable reference that remains recognizable across independent PDFs, bibliographies, tables, registries, and potentially machine-assisted knowledge systems.
I agree with your concern that the conventional author–date suffix may not be the ideal machine identifier. Perhaps this suggests a refinement of PAYSCM:
persistent citation identity should be stored as metadata, while the author–year–suffix form is only one possible human-readable rendering of that identity.
In other words:
DOI = global persistent identifier
persistent citation key = corpus-level stable identity
author–year–suffix = optional human-readable display form
If this distinction is more appropriate, the CSL question may be narrower: could a style access and render such a persistent citation key or custom metadata field without changing the normal document-local year-suffix disambiguation mechanism?