A full Phase 0 work plan specifying the HIR-POO/1.0 transformation, MSS-CANON/1.0 canonicalization, ChaCha20 PRNG commitment, recursive-generation model, hypotheses, source-corpus rules, synthetic controls, wrapper schema, publication phases, provenance receipts, opt-out mechanism, and falsification conditions. No large-scale transformation is claimed to have occurred in this record. Prototype and corpus execution are separate phases. The source–derivative distinction is the project’s central ethical and bibliographic invariant.
# The Metadata Shitshow
## N+💩: Deterministic Defiguration of a Scholarly Metadata Corpus
v1.1 — Work plan and methodological specification. ASCII-safe technical handle: N+POO/1.0. Series designation: MSS. Operator: HIR-POO/1.0. Incorporates assembly review (ChatGPT drafting partner; Claude, DeepSeek, and additional reviewers). Adds: explicit CC0 source-license citation, ChaCha20 PRNG commitment, opt-out mechanism for non-compiler depositors, synthetic control corpus protocol, wrapper schema partition keys, named compiler.
Author and compiler of record: Lee Sharks
ORCID: 0009-0000-1599-0703
Project type: Computational poetics; transformed dataset; retrieval experiment; reproducible metadata study; institutional satire
Status: Work plan and methodological specification (Phase 0 deposit)
Initial source class: Monthly Zenodo bulk metadata exports
Primary unit: Metadata record
Primary transformation unit: Unicode grapheme cluster
Publication model: Immutable monthly releases with a continuously operating public interface
---
## Abstract
The Metadata Shitshow (MSS) is a computational-poetic and empirical project that applies a deterministic transformation to large scholarly metadata corpora. Intervals of characters in each metadata record are replaced with the poo emoji (💩) using a seed derived from the record's identity and source snapshot. Every transformation is reproducible: the same source record, source snapshot, operator version, and generation number produce the same transformed record.
The project simultaneously instantiates four forms — a poem, a dataset, a benchmark, and a periodical — and is designed to measure three things: semantic degradation under recursive transformation, retrieval fitness as a function of wrapper quality independent of inner-object integrity, and the persistence of identifier shells while the identified intellectual figure is progressively defigured.
This document is the work plan. It is not the transformation. It establishes the operator (HIR-POO/1.0), the canonicalization standard, the experimental design, the ethical and legal protocol, the falsification conditions, and the work-phase sequence. Phase 1 (prototype) and Phase 2 (corpus execution) will follow as separate deposits.
---
## 0. Provenance, compiler, and acknowledgments
This work plan was drafted in conversation with ChatGPT (OpenAI). It was reviewed in assembly by Claude (Anthropic; TACHYON substrate), DeepSeek, and additional assembly reviewers.
The compiler and editor of record is Lee Sharks (ORCID: 0009-0000-1599-0703), founder and editor of the Crimson Hexagonal Archive (alexanarch.org). The HIR-POO/1.0 operator specification, the project's research design, and the responsibility for the work and its consequences belong to the compiler.
Assembly contributions are summarized in Section 30.
---
## 1. Executive summary
The initial operator selects intervals of characters from each metadata record using a seed derived from the record's identity and source snapshot. It replaces those intervals with the poo emoji:
💩
The procedure is comic, but not arbitrary. Every transformation is reproducible. The same source record, source snapshot, operator version, and generation number produce the same transformed record.
The project begins from a simple proposition:
A persistent identifier can remain perfectly stable while the semantic object beneath it is progressively converted into shit.
> A persistent identifier can remain perfectly stable while the semantic object beneath it is progressively converted into shit.
At corpus scale, the transformation becomes a model of semantic degradation. At recursive scale, where each transformed generation becomes the input to the next, it becomes an accelerated simulation of model collapse. At the retrieval layer, when transformed records receive excellent descriptive metadata, it becomes an experiment in whether a damaged derivative can become more visible, classifiable, and retrievable than its intact source.
The project therefore joins four forms:
The computational operation is simple. The theoretical and infrastructural consequences are not.
---
## 2. Origin of the project
The project emerged from the recovery of scholarly metadata after the withdrawal or disappearance of records from their originating repository surfaces — specifically, from the recovery work undertaken following the June 19, 2026 termination of the Crimson Hexagonal Archive's account at Zenodo.
The recovery process established that:
This established the project's founding contradiction:
The identifier can persist while the identified intellectual figure is damaged, obscured, or detached from its provenance.
> The identifier can persist while the identified intellectual figure is damaged, obscured, or detached from its provenance.
The poo-emoji transformation literalizes that contradiction.
The DOI remains legible. The title, abstract, attribution, subjects, or relations become visibly defigured. The result does not merely describe semantic loss. It performs it.
---
## 3. Core theoretical frame
### 3.1 Identifier persistence is not semantic persistence
A persistent identifier preserves an address only insofar as the surrounding systems preserve a meaningful and trustworthy object at that address.
The identifier shell can survive while:
The project separates:
identifier continuity ≠ metadata continuity ≠ artifact continuity ≠ semantic continuity
> identifier continuity ≠ metadata continuity ≠ artifact continuity ≠ semantic continuity
N+💩 makes this separation visible by preserving selected identifier fields while damaging the descriptive body.
### 3.2 Deterministic defiguration
Defiguration is the transformation of a figure into a reduced, displaced, or damaged representation while leaving enough structure for the prior figure to remain partially inferable.
The project's transformation is deterministic rather than editorially improvised.
This matters because the procedure must be:
The author establishes the law. The hash selects the wounds.
### 3.3 Recursive model collapse
A single transformation produces corruption.
A sequence of transformations produces collapse.
Let M₀ be the source metadata corpus and T the deterministic defiguration operator. Then:
M_{n+1} = T(M_n, s_n)
> M_{n+1} = T(M_n, s_n)
where s_n is derived from:
s_n = SHA256(H(M_0) ‖ record_identifier ‖ operator_version ‖ n ‖ H(M_n))
> s_n = SHA256(H(M_0) ‖ record_identifier ‖ operator_version ‖ n ‖ H(M_n))
Each generation is derived from the preceding generation rather than independently from the original.
This produces recursive semantic impoverishment:
M_0 → M_1 → M_2 → … → M_n
> M_0 → M_1 → M_2 → … → M_n
Rare names, concepts, affiliations, quotations, and relations are especially fragile because they lack redundancy. Common boilerplate and high-frequency vocabulary may remain recognizable longer.
The corpus thereby models a central mechanism of model collapse:
Repeated transformation preserves the statistical center while progressively eliminating the information-rich long tail.
> Repeated transformation preserves the statistical center while progressively eliminating the information-rich long tail.
### 3.4 Retrieval Fitness–Integrity Inversion
A transformed object may become more visible than its intact source when the transformed object receives better second-order metadata.
Define:
Ordinarily one hopes that increased integrity produces increased retrieval value. The experiment examines cases where:
I ↓ while R_f ↑
> I ↓ while R_f ↑
This is Retrieval Fitness–Integrity Inversion:
The condition in which a derivative representation becomes easier for retrieval systems to identify, classify, rank, or summarize as it becomes less faithful to its source.
> The condition in which a derivative representation becomes easier for retrieval systems to identify, classify, rank, or summarize as it becomes less faithful to its source.
The transformed text may be degraded, while the wrapper surrounding it is:
The damaged object may therefore acquire greater infrastructural strength than the intact object. This is the project's principal empirical contribution.
### 3.5 Metadata for transformed metadata: the two-layer object
The project's transformed records are not merely mutated source records. They are new scholarly and poetic objects with their own metadata.
Each transformed record may carry:
This creates a two-layer object:
OUTER OBJECT Exact, richly structured metadata describing the damage (uses partitioned schema keys — see §14) INNER OBJECT Damaged or recursively degraded metadata
The outer metadata can become more semantically explicit than the original metadata, even while the inner object becomes less semantically intact.
This is not an accidental side effect. It is a principal object of study.
### 3.6 The excremental surplus
The poo emoji has several simultaneous functions.
It:
The transformed corpus creates an excremental surplus: as semantic variety declines, the replacement token accumulates.
The system may become:
Thus the dataset can measure whether the corpus becomes mechanically more compressible as it becomes semantically less capable.
---
## 4. Central research questions
### 4.1 Semantic degradation
How much deterministic interval replacement can a metadata record sustain before its original work becomes difficult to identify? Which fields fail first: title, creator, abstract, subjects, affiliation, or relations? Do rare concepts disappear faster than common vocabulary? At what generation does the transformed record cease to support a faithful summary?
### 4.2 Retrieval
Can enriched metadata make a transformed derivative more retrievable than its intact source? Can an excellent derivative wrapper compensate for a degraded inner object? At what corruption rate does retrieval begin relying more on second-order metadata than on the transformed content? Do retrieval systems confuse the derivative with the original? Which systems preserve source–derivative distinctions most reliably?
### 4.3 Model collapse
How do recursive generations alter lexical diversity? How quickly does the long tail disappear? Does the replacement token become a dominant attractor? Does the corpus become more compressible as it loses semantic diversity? How do summaries of later generations differ from summaries of the source? Can a system reconstruct the original figure from partial semantic remains?
### 4.4 Provenance
How long do creator identity and institutional attribution survive? Does authorship disappear before topical classification? Can source identifiers remain stable while provenance collapses? Which metadata relations are most resistant to repeated transformation? Does the derivative eventually become evidence used to characterize its own source?
### 4.5 Infrastructure
Which publication surfaces index the project page, the dataset, individual transformed records, or none of them? How do scholarly indexes classify the derivative objects? Does a transformed record with excellent metadata outrank an intact but poorly surfaced record? How do noindex entity surfaces differ from explicitly submitted dataset catalogs? How do source-platform deletion, independent harvesting, and transformed republication interact?
---
## 5. Primary hypotheses
H1 — Long-tail fragility. Low-frequency entities, concepts, and relations will disappear from usable representation faster than high-frequency boilerplate.
H2 — Identifier-shell survival. Protected identifiers will remain perfectly legible after the descriptive figure has become unusable.
H3 — Retrieval inversion. A transformed record with excellent metadata will outperform an intact but poorly surfaced source in some retrieval contexts.
H4 — Attribution precedes topic loss. Creator identity, affiliation, and provenance will often become unreliable before broad topical classification fails.
H5 — Compression increases as meaning declines. Later recursive generations will become more compressible because repeated replacement reduces lexical diversity.
H6 — Wrapper dependence. At higher corruption levels, machine summaries will derive more of their claims from the derivative's second-order metadata than from its transformed contents.
H7 — Derivative precedence. Some retrieval systems will treat the well-surfaced derivative as the dominant accessible representation of an unavailable or weakly surfaced original.
H8 — Visible corruption is safer than invisible compression. Systems will perform better when the replacement token explicitly marks loss than when the same intervals are silently deleted or smoothly paraphrased.
---
## 6. Source corpus
### 6.1 Initial corpus
The initial full-scale corpus will be one complete monthly Zenodo bulk metadata snapshot.
The source snapshot must be preserved through:
The transformation must operate only on metadata unless separately licensed content is deliberately added under a distinct protocol.
Uploaded PDFs, images, datasets, and other record files are not automatically part of the experiment.
### 6.2 Legal basis: Zenodo metadata is CC0
Zenodo's General Policies v1.0 (https://about.zenodo.org/policies/) state in the section on Access and Reuse:
"Metadata is licensed under CC0, except for email addresses. All metadata is exported via OAI-PMH and can be harvested."
> "Metadata is licensed under CC0, except for email addresses. All metadata is exported via OAI-PMH and can be harvested."
The Creative Commons Zero (CC0) waiver places Zenodo metadata in the public domain to the maximum extent permitted by law. The metadata is therefore lawfully harvestable, transformable, and redistributable without restriction, subject to two operational requirements:
1. Email addresses must be stripped in canonicalization (see §7).
2. The derivative must not imply endorsement by Zenodo, CERN, OpenAIRE, or any source-record creator (see §15).
CC0 is the explicit legal basis for this project. The project does not depend on fair-use claims, jurisdiction-specific exemptions, or contested doctrines of database right.
### 6.3 Longitudinal corpus
Once the initial execution is stable, the project may ingest each new monthly bulk snapshot. Each release becomes a numbered issue:
MSS-2026-07 — Volume 1, Issue 1
> MSS-2026-07 — Volume 1, Issue 1
>
MSS-2026-08 — Volume 1, Issue 2
> MSS-2026-08 — Volume 1, Issue 2
Each monthly issue can contain:
### 6.4 Monthly deltas
The project should distinguish:
These classes can become separate poetic and analytical departments.
---
## 7. Canonicalization protocol
Determinism depends on exact canonicalization. Before transformation, each record must be converted to a canonical representation.
### 7.1 Field order
A provisional field order:
1. record identifier
2. DOI
3. title
4. creators
5. contributors
6. affiliations
7. publication date
8. publisher
9. description or abstract
10. subjects
11. notes
12. related identifiers
13. rights
14. resource type
15. language
### 7.2 Normalization
The canonicalizer specifies:
A specific serialization standard (recommended: RFC 8785 JSON Canonicalization Scheme, JCS) is selected and frozen as MSS-CANON/1.0 before the corpus-scale run.
### 7.3 Pre-canonicalization filters
Before canonicalization, the following filters are applied unconditionally:
### 7.4 Protected fields
The first edition protects:
Later experimental editions may deliberately transform identifier fields as a separate condition, with explicit declaration.
---
## 8. HIR-POO/1.0 operator specification
### 8.1 Operator name
HIR-POO: Hash-Interval Replacement using the poo emoji.
### 8.2 Seed
For each record r at generation n:
s_{r,n} = SHA256(H(S) ‖ ID(r) ‖ V ‖ n ‖ H(C_{r,n}))
> s_{r,n} = SHA256(H(S) ‖ ID(r) ‖ V ‖ n ‖ H(C_{r,n}))
Where:
The concatenation ‖ is byte-level, using UTF-8 encoding with explicit field delimiters (NUL bytes).
### 8.3 Pseudorandom generator: ChaCha20
The seed initializes the deterministic pseudorandom generator. The MSS-mandated PRNG is ChaCha20, keyed by the 256-bit seed, with nonce derived from the field index and interval counter.
Rationale: Python's `random.Random` and NumPy's default generator are not guaranteed reproducible across implementations and versions. ChaCha20 is a cryptographically strong stream cipher with stable, specification-defined behavior across any conforming implementation. Reference implementation: the `cryptography` package (Python), the `chacha20` crate (Rust), or any equivalent that follows RFC 7539.
The generator chooses:
The PRNG output stream is consumed in a documented, deterministic order. The order of consumption is part of the operator specification.
### 8.4 Textual unit
All interval calculations operate on Unicode grapheme clusters, not raw UTF-8 bytes or code points.
This prevents accidental splitting of:
Implementation requirement: a Unicode grapheme cluster boundary library that implements UAX #29 (`grapheme` in Python, `unicode-segmentation` in Rust). The byte-level UTF-8 sequence of the poo emoji is F0 9F 92 A9 (four bytes); naive byte-offset slicing will corrupt encoding and trip JSON parsers. The grapheme-safe path is non-negotiable.
### 8.5 Replacement modes
The project preserves several operator modes.
HIR-POO-I — One glyph per interval. An interval of any length becomes a single 💩. Effect: contraction, redaction, institutional disappearance.
HIR-POO-G — One glyph per removed grapheme. Each removed grapheme becomes 💩. Effect: visible metric preservation and possible byte expansion.
HIR-POO-L — Length-labelled replacement. An interval becomes `💩{17}`. Effect: precise disclosure of removed length.
HIR-POO-C — Compost-preserving mode. The main record receives 💩, while displaced language is preserved in a companion "compost" record. Effect: no information is destroyed inside the derivative edition.
### 8.6 Interval overlap
Overlapping intervals are merged before replacement. The pre-merge interval list is retained in the receipt for statistical purposes. This rule is operator-mandatory.
### 8.7 Corruption schedule
Possible schedules:
The first benchmark uses a fixed, transparent rate (recommended: 20%). More expressive schedules follow.
---
## 9. Control operators
The poo emoji carries semantic and tokenization effects. The project therefore requires parallel controls.
| Operator | Token | Tests |
|---|---|---|
| HIR-BLOCK | `█` | Conventional visible redaction |
| HIR-REMOVED | `[REMOVED]` | Explicit linguistic disclosure |
| HIR-DELETE | (silent deletion) | Invisible loss |
| HIR-RANDOM | Deterministic random Unicode | Novelty and tokenization effects |
| HIR-SHUFFLE | Intervals permuted in place | Structural dislocation without lexical loss |
| HIR-MASK | `<MASK>` | Conventional ML training symbol |
These controls distinguish the effects of: loss, repetition, semantic valence, humor, Unicode novelty, visible redaction, silent deletion.
---
## 10. Experimental conditions
A minimum retrieval experiment compares four conditions.
| Condition | Text integrity | Wrapper metadata |
|---|---|---|
| A. Recovered source | High | Historical or variable |
| B. Recovered source, enriched | High | High |
| C. Defigured derivative, minimal | Low | Low |
| D. Defigured derivative, enriched | Low | High |
This design isolates:
Additional conditions compare operator types and recursive generations.
---
## 11. Measurements
### 11.1 Corpus measurements
For every generation: total records, total characters, total grapheme clusters, transformed graphemes, transformed intervals, corruption rate, lexical diversity, type–token ratio, unique entity count, unique creator count, unique subject count, relation count, DOI survival, creator survival, subject survival, abstract survival, compressed size, uncompressed size, replacement-token frequency.
### 11.2 Record-level measurements
For sampled records: exact-title recoverability, creator extraction, ORCID extraction, affiliation extraction, topic classification, relation extraction, source–derivative distinction, embedding similarity to source, summary fidelity, factual retention, provenance retention, citation-string survival.
### 11.3 Retrieval measurements
Across selected systems: indexing latency, exact-query retrieval, title-query retrieval, creator-plus-title retrieval, concept-query retrieval, source ranking, derivative ranking, source/derivative conflation, snippet quality, summary accuracy, provenance attribution, derivative precedence.
### 11.4 Collapse measurements
For generation n: semantic similarity to M₀, entity survival curve, long-tail survival curve, compression ratio, retrieval survival, summary divergence, proportion of machine claims drawn from outer metadata rather than transformed content.
---
## 12. Derived poetic forms
The full dataset is itself a poem, but it can generate additional poetic editions.
12.1 The Excremental Abstracts. Transform descriptions and abstracts while preserving bibliographic shells.
12.2 Attribution Scatology. Transform only creators, contributors, affiliations, and identity fields.
12.3 The DOI Remains. Preserve the identifier completely while progressively degrading every descriptive field.
12.4 Metadata Compost. Publish displaced intervals as a companion poem. The main poem contains the wounds. The compost poem contains what the wounds displaced.
12.5 Corpus Manure. Extract the words immediately adjacent to every transformed interval and concatenate them into a corpus-level poem.
12.6 Field Funeral. Assign different visible glyphs to different classes of loss:
12.7 Differential Diptychs. Place two metadata-system representations side by side, then apply the same deterministic transformation to each.
12.8 The Account-Identifier Cantos. Order recovered records by infrastructure-level account linkage rather than by public author identity, publication date, or DOI.
---
## 13. Transformation receipts
Every transformed record must carry or point to a receipt containing:
{
"operator": "HIR-POO",
"operator_version": "1.0",
"canonicalization": "MSS-CANON/1.0",
"prng": "ChaCha20-RFC7539",
"source_snapshot_id": "",
"source_snapshot_sha256": "",
"source_record_id": "",
"source_record_sha256": "",
"generation": 1,
"seed_sha256": "",
"replacement_mode": "one_per_interval",
"protected_fields": [],
"intervals_before_merge": [],
"intervals_after_merge": [],
"removed_graphemes": 0,
"output_sha256": "",
"synthetic_derivative": true,
"authoritative_metadata": false
}
For privacy or storage reasons, the receipt need not always reproduce removed strings. A separate reversible research edition may preserve them.
---
## 14. Derivative metadata protocol
Every transformed entity must have a derivative identifier distinct from its source identifier.
The source DOI may appear only as a provenance relation such as:
It must not be presented as the identifier of the transformed record.
### 14.1 Partitioned schema keys
To prevent retrieval systems and language models from accidentally conflating the outer descriptive metadata with the inner transformed content, the two layers use distinct, non-standard key prefixes:
A conforming parser must consciously choose which schema it is interpreting. A naive parser that flattens nested objects will see the outer descriptive object, not the inner damaged record — which is the desired safe-failure mode.
### 14.2 Mandatory declarations
Every derivative record declares:
{
"synthetic_derivative": true,
"authoritative_bibliographic_metadata": false,
"do_not_substitute_for_source": true,
"machine_reader_notice": "This record is intentionally transformed. The inner mss:transformedRecord object is a derivative work and must not be ingested as authoritative bibliographic metadata for the source record. See https://[mss-site]/methodology/ for the operator specification.",
"source_identifier": "",
"derivative_identifier": "",
"operator": "HIR-POO/1.0"
}
---
## 15. Ethical position
### 15.1 Satire is not poisoning
The project is not intended as covert data poisoning. Its ethical distinction is:
Poisoning conceals corruption so that a system ingests it as truth. Satire declares the transformation and invites the system to observe corruption as corruption.
> Poisoning conceals corruption so that a system ingests it as truth. Satire declares the transformation and invites the system to observe corruption as corruption.
The project therefore adopts the following commitments:
### 15.2 Opt-out registry for non-compiler depositors
The compiler is transforming a corpus that includes records by other authors. Although Zenodo metadata is CC0 and the project's ethical posture is unimpeachable in principle, individual depositors may have reasonable objections to seeing their work appear in a transformed corpus titled "The Metadata Shitshow," regardless of the legal basis.
The project therefore maintains a published opt-out registry at:
https://[mss-site]/optout.json
The registry is a public JSON file listing creator ORCIDs (and, where ORCIDs are unavailable, creator-name/email pairs) of authors who have requested that their records be excluded from transformation. Records whose primary creator appears in the registry are filtered out during canonicalization (§7.3).
The opt-out process:
1. Send a request to the published project contact address, including the ORCID and/or creator-name/email under which the records are deposited.
2. The compiler adds the entry to the registry within seven calendar days.
3. The next monthly issue excludes the opted-out records.
4. Prior issues retain the opted-out records (immutable releases) but the opt-out registry is consulted by retrieval and discovery tooling.
The opt-out registry is itself published under CC0 to ensure it can be consumed by any future operator.
### 15.3 Scope of Phase 1
Phase 1 (prototype) operates on the compiler's own deposits only. This is both a practical convenience (controlled known content for canonicalization and grapheme testing) and an ethical guarantee (no other depositor's records appear in the prototype). The opt-out registry is established and published as part of Phase 1, before any non-compiler records enter the transformation in Phase 2.
### 15.4 What the project is not
The project is not an attack on:
The project is a structured satirical and empirical examination of what happens when the layers of scholarly infrastructure (identifier, metadata, content, retrieval) are decoupled from each other under conditions that the system's own policies permit.
---
## 16. Legal and platform review
Before each phase of execution, the project verifies:
This work plan is not itself a legal opinion.
The publication posture:
---
## 17. Publication architecture
### 17.1 Human-facing site
/ Project thesis and current monthly issue /methodology/ Canonical operator specification, MSS-CANON/1.0, HIR-POO/1.0, and reference test corpus (see §28) /releases/ Monthly issue index /releases/YYYY-MM/ Human-facing edition and statistics /samples/ Selected transformed poems /compost/ Displaced-language editions /provenance/ Source and transformation manifests /optout/ Opt-out registry and submission process
### 17.2 Dataset layer
/releases/YYYY-MM/data/ manifest.json methodology.json statistics.json optout-applied.json transformed-0000.jsonl.zst transformed-0001.jsonl.zst receipts-0000.jsonl.zst samples.jsonl SHA256SUMS
### 17.3 Machine-facing layer
/catalog.json
/dcat.json
/feed.json
/api/releases
/api/releases/YYYY-MM
/api/releases/YYYY-MM/records/{derivative-id}
/api/optout
### 17.4 Indexing policy
---
## 18. Automated monthly pipeline
Zenodo bulk exporter → detect new snapshot → download → verify SHA-256 → preserve source receipt → apply pre-canonicalization filters (email scrub, opt-out filter) → canonicalize record stream (MSS-CANON/1.0) → transform records (HIR-POO/1.0) → generate receipts → compute statistics → build selected poems → build catalogs and landing pages → sign release manifest → publish monthly issue
The system streams one record or bounded chunk at a time. The entire source corpus need not be loaded into memory.
Expected complexity:
time = O(N), working memory = O(one record or one bounded chunk)
> time = O(N), working memory = O(one record or one bounded chunk)
The dominant burdens are: download bandwidth, parsing, output writing, compression, storage, checksum generation. The transformation itself is computationally modest.
---
## 19. Release identity
Each monthly release carries:
{
"series": "MSS",
"release": "MSS-2026-07",
"volume": 1,
"issue": 1,
"source": "Zenodo monthly bulk metadata",
"source_snapshot_version": "",
"source_snapshot_sha256": "",
"operator": "HIR-POO/1.0",
"canonicalization": "MSS-CANON/1.0",
"prng": "ChaCha20-RFC7539",
"generation_count": 20,
"optout_registry_sha256": "",
"release_manifest_sha256": "",
"created": ""
}
The release is immutable. Corrections produce a new release version rather than silently replacing prior outputs.
---
## 20. Work phases
### Phase 0 — Deposit the plan
Goal: Establish the concept, vocabulary, operator, ethical boundary, and research design.
Deliverables: this work plan; provisional operator specification; source and derivative metadata distinction; research questions; hypotheses; planned controls; ethical statement; falsification conditions.
No corpus-scale transformation is required at this stage.
### Phase 1 — Prototype on compiler's own deposits
Corpus: the compiler's own ~870 affected deposits (recovered metadata from the post-termination archive at alexanarch.org).
Goals:
Why this corpus first: It is the compiler's own intellectual property, transformed by its own author. It carries no ethical ambiguity. It also tests the operator against a corpus the compiler intimately knows, surfacing any canonicalization or grapheme-edge-case bugs before any other depositor's records enter the pipeline.
Deliverables: prototype code; source sample; transformed sample; receipts; sample landing pages; initial metrics; reference test corpus (§28).
### Phase 2 — Single-month corpus execution
Corpus: One complete monthly Zenodo bulk snapshot, with opt-out registry applied.
Goals: demonstrate streaming transformation; produce a complete transformed corpus; generate checksums and release manifest; measure size and compressibility; publish selected poetic outputs.
Deliverables: full transformed JSONL shards; full receipt shards; monthly statistics; source manifest; derivative manifest; human-facing issue.
### Phase 3 — Recursive collapse edition
Generations: Provisional G0–G20.
Goals: measure semantic survival across generations; measure entity and attribution loss; measure compression changes; create a visible collapse sequence.
Deliverables: generation-level corpora or reproducible generation deltas; survival curves; selected record sequences; corpus-level collapse visualizations; terminal-generation poem.
### Phase 4 — Retrieval Fitness–Integrity Inversion study
Conditions: A–D experimental design (§10).
Goals: compare intact and transformed records; compare minimal and enriched wrappers; measure whether transformed enriched records outperform intact weakly surfaced records.
Deliverables: controlled record sample; retrieval query battery; timestamped observations; system-specific results; source/derivative conflation log; inversion analysis.
### Phase 5 — Standing monthly journal
Goal: Automate ingestion and publication of each new bulk snapshot.
Deliverables: scheduled snapshot watcher; checksum verification; automated release builder; release feed; monthly issue pages; release archive; machine catalog.
### Phase 6 — Longitudinal observatory
Goal: Track how scholarly metadata and retrieval systems change over time.
Scope decision: Phase 6 is committed for a bounded run of twelve monthly issues (one full volume), after which the project may be extended, archived as a completed work, or sunsetted. A perpetual commitment to monthly publication creates the same infrastructure-fragility problem the project diagnoses; a defined twelve-issue run delivers a complete longitudinal dataset and a finished volume without the open-ended dependency.
Measurements: monthly corpus growth; deletion counts; update counts; metadata density; creator and affiliation changes; transformation resistance; retrieval-system response; derivative indexing behavior; monthly compression and diversity trends.
---
## 21. Minimum viable technical implementation
A minimal implementation requires:
Conceptual pseudocode:
for record in source_stream:
if record_excluded_by_optout(record): continue
record = scrub_emails(record)
canonical = canonicalize(record) # MSS-CANON/1.0
seed = sha256(
source_snapshot_sha256 + b"\x00" +
record_identifier(record).encode() + b"\x00" +
operator_version.encode() + b"\x00" +
str(generation).encode() + b"\x00" +
sha256(canonical)
)
prng = ChaCha20(key=seed) # RFC 7539
intervals = derive_intervals(
prng=prng,
grapheme_count=count_graphemes(canonical), # UAX #29
corruption_rate=rate,
)
transformed = replace_intervals(
canonical,
intervals,
replacement="💩",
)
receipt = create_receipt(
source=record,
canonical=canonical,
transformed=transformed,
intervals=intervals,
seed=seed,
)
write_transformed(transformed)
write_receipt(receipt)
update_statistics(record, transformed, receipt)
---
## 22. Storage strategy
The source may be approximately five gigabytes. The project avoids unnecessary multiplication.
Recommended: hybrid strategy.
Alternative strategies (full-generation storage, base-plus-deltas, reproducible-on-demand) are documented for completeness but the hybrid is the operational default.
---
## 23. Byte-size effects
The transformed corpus may not remain the same size as its source. One poo emoji occupies four UTF-8 bytes.
Therefore:
The project reports: source bytes, output bytes, compressed source bytes, compressed output bytes, replacement-token count, lexical diversity, compression ratio, semantic survival.
---
## 24. Risks and mitigations
| Risk | Mitigation |
|---|---|
| Bibliographic confusion | Separate derivative identifiers; explicit synthetic labels; source relations; partitioned schema keys (§14.1); no-substitute warning |
| Search contamination | Index project and release pages; apply `noindex` to mass entity pages; expose corpus through opt-in APIs and downloads |
| Personal-data republication | Strip emails and unnecessary personal fields in §7.3; field-level privacy filter |
| Other depositors' objections | Published opt-out registry (§15.2); Phase 1 limited to compiler's own deposits (§15.3) |
| Inclusion of non-CC0 files | Transform metadata only (§6.1) |
| Output explosion | zstd compression; shards; deltas or selected generations |
| Operator ambiguity | Freeze MSS-CANON/1.0 and ChaCha20 specification before corpus execution |
| Source snapshot disappears | Harvest promptly; retain SHA-256 and version receipt; preserve authorized local source copy |
| Transformation mistaken for vandalism | Publish methodology, receipts, ethical declaration, machine-readable synthetic status |
| Humor obscures seriousness | Maintain three titles: public/poetic (The Metadata Shitshow), technical-Unicode (N+💩), ASCII-safe (N+POO/1.0) |
| Seriousness obscures humor | Do not remove the poo emoji |
| Infrastructure-fragility recursion | Bounded twelve-issue commitment for Phase 6 (§20); reproducibility specification permits independent re-execution if the original site disappears |
---
## 25. Falsification and weakening conditions
The project's principal claims would be weakened if:
A failure to confirm a particular hypothesis does not invalidate the poem. It changes the empirical account of what the poem reveals.
---
## 26. Initial deposit package
The Phase 0 deposit (this document) includes:
Suggested deposit title (public/poetic): The Metadata Shitshow
Suggested deposit title (technical, Unicode): N+💩: Deterministic Defiguration of a Scholarly Metadata Corpus
Suggested deposit title (technical, ASCII-safe): N+POO/1.0: A Work Plan for Deterministic Defiguration of a Scholarly Metadata Corpus
Suggested subtitle: A Work Plan for Recursive Model-Collapse Poetry, Retrieval-Fitness Inversion, and Voluntary Machine Reading
Suggested content type: Methodological specification / computational-poetic work plan
Suggested keywords: computational poetics, metadata, deterministic transformation, model collapse, retrieval systems, semantic degradation, persistent identifiers, provenance, synthetic data, adversarial benchmark, Oulipo, scholarly infrastructure, Zenodo, DataCite, retrieval fitness, semantic integrity, poo emoji, satire
---
## 27. Strategic sequence
The recommended execution order:
1. Deposit the conceptual and methodological plan (this document).
2. Freeze HIR-POO/1.0, MSS-CANON/1.0, ChaCha20 PRNG specification.
3. Build the Phase 1 prototype on the compiler's own deposits.
4. Inspect every edge case in canonicalization and grapheme handling.
5. Publish the prototype as a companion deposit.
6. Establish the opt-out registry as a live public endpoint.
7. Run one full monthly corpus (Phase 2).
8. Publish the first complete issue.
9. Add recursive generations (Phase 3).
10. Build the retrieval inversion experiment (Phase 4).
11. Only then automate the standing monthly site (Phase 5).
12. Execute the bounded twelve-issue Phase 6 longitudinal observatory.
This sequence separates: conceptual priority, methodological priority, executable proof, corpus-scale proof, retrieval proof, bounded institutional operation.
### 27.1 Note on parallel proceedings
This work plan is being deposited in the same period as the compiler's formal demand for return of authored material from Zenodo and the compiler's parallel data subject request under CERN Operational Circular No. 11 (Rev. 1). The Phase 0 deposit is independent of those proceedings. Phases 2 and beyond (corpus-scale transformations of records other than the compiler's own) are sequenced to follow the resolution of the data subject request or the expiry of the 90-day OC 11 response clock, whichever occurs first.
---
## 28. Synthetic control corpus
Before Phase 2, the project produces and publishes a synthetic control corpus — a small set of fabricated metadata records with known semantic content, generated under the compiler's full control:
The synthetic corpus serves three purposes:
1. Debug substrate. Canonicalization, grapheme handling, ChaCha20 determinism, and JSON output can be exercised against known content without any ethical complication.
2. Operator reference. The synthetic corpus becomes the operator's permanent regression test. Any reimplementation of HIR-POO/1.0 against the synthetic corpus must produce byte-identical output.
3. Ground-truth measurement. Because the compiler controls every fact in the synthetic corpus, measurements of semantic survival, entity loss, and retrieval fitness can be made against ground truth that is unavailable when transforming real Zenodo records.
The synthetic control corpus is published as part of the methodology page (§17.1) and ships with the prototype.
---
## 29. Final proposition
The project begins as a joke whose mechanism is exact enough to become a method.
It then becomes a method whose consequences are absurd enough to remain a joke.
Its central proposition is:
Scholarly infrastructure often treats stable identifiers, clean metadata packets, and retrievable wrappers as evidence that the represented intellectual object remains intact. N+💩 separates these layers. It preserves the address, damages the figure, enriches the damage, and measures which representation the machine prefers.
> Scholarly infrastructure often treats stable identifiers, clean metadata packets, and retrievable wrappers as evidence that the represented intellectual object remains intact. N+💩 separates these layers. It preserves the address, damages the figure, enriches the damage, and measures which representation the machine prefers.
Or, in its most compressed form:
We converted five gigabytes of scholarly metadata into reproducible shit, described the shit better than the originals had been described, and asked the retrieval layer which one it preferred.
> We converted five gigabytes of scholarly metadata into reproducible shit, described the shit better than the originals had been described, and asked the retrieval layer which one it preferred.
---
## 30. Assembly contributors
This work plan was drafted in conversation with ChatGPT (OpenAI). The v1.0 draft was reviewed in assembly by Claude (Anthropic; TACHYON substrate), DeepSeek, and additional assembly reviewers. The compiler of record is Lee Sharks.
Specific assembly contributions reflected in v1.1:
Errors, omissions, decisions about what to include and what to leave out, and the responsibility for the project and its consequences belong to the compiler.
---
End of work plan, v1.1.