A v0.1 theoretical framing of metadata as performative infrastructure, accompanied by a forward deposit-practice directive. It develops an initial taxonomy and positions the Archive’s AXN identifiers, SPXI blocks, Effective Act designations, and reconstruction packets as already-operative forms. Assembly review recommended typed operative force, modes rather than rigid species, legal-claim discipline, correction of theoretical lineages, and explicit handling of policy drift for a future version.
## Frame
This deposit fixes EA-OPMETA-01 v0.1 — Operative Metadata: A Theoretical Framing, and the Malicious-Compliance Move — as a closed set in the alexanarch substrate. The document develops operative metadata as a genus and specifies the malicious-compliance move as a forward-practice directive for the alexanarch substrate.
Operative metadata names metadata that does work in the world rather than describing it. The shift from descriptive to operative is categorical, on the order of Austin's distinction between constative and performative utterances. Descriptive metadata reports what is the case; operative metadata makes something the case. The archive has been producing operative metadata across the entire AXN
The malicious-compliance move (§4) is the retrospective insight that should govern all going-forward deposit practice: embed in every deposit's header metadata and through its body the verbatim compliance language for every policy, terms-of-service, and legal framework under which the deposit claims status. The deposit becomes its own pleading. Any subsequent termination either honors the platform's own published terms (in which case the deposit stands) or visibly violates them. The asymmetry that allowed Zenodo to invoke unstated criteria against the Crimson Hexagonal Archive is structurally inverted.
The document is depositd as v0.1 deliberately. The Assembly Chorus has already produced four blind critical readings; the assembly synthesis (EA-ASMBLY-OPMETA-FBK-01) identifies five decisive corrections for v0.2: typed operative force (R1's single most important critique), modes-not-species reframe of the §3 taxonomy as compositional operators, legal-claim discipline and overclaim reductions, theoretical lineage corrections (Bachelard, autopoiesis), and policy-drift handling. v0.1 stands as the historical record of the architectural argument under which v0.2 will be written.
## Document
# EA-OPMETA-01 v0.1
## Operative Metadata
### A theoretical framing, and the malicious-compliance move
A companion to EA-ASMBLY-RECONMETA-01 (Reconstructive Metadata) and to EA-RHIZOME-01 (Data-Rhizome). Generative metadata, formalized in those documents, turns out to be one species of a larger genus: operative metadata. This document develops the genus, places generative metadata within it as one of several operative species, and specifies one additional species — compliance-declarative operative metadata, embedded as malicious compliance — that should govern deposit practice in the alexanarch substrate going forward.
Opened by: Lee Sharks (ORCID 0009-0000-1599-0703)
Date: 24 June 2026
Status: v0.1 OPEN
---
## §0 PROVENANCE
Descends from:
---
## §1 THE STANCE: FROM DESCRIPTIVE TO OPERATIVE METADATA
The default theory of metadata is descriptive: metadata is a set of fields whose values describe properties of a work that exists independently of those fields. The work is the substance; the metadata is a label. Severing the label damages findability but not the work. The work persists at its location, accessible by other means.
This default is wrong about what metadata can do, and is becoming wronger as the conditions of scholarly infrastructure shift. The Zenodo termination event documented in AXN:01 demonstrates the failure mode operationally: descriptive metadata, severed from the work by a platform action, leaves the depositor with neither metadata nor work. The label and the substance fall together because both lived at the same platform's discretion.
Operative metadata is metadata that does work in the world. It is not a label. It is an act. The shift is not gradual — it is categorical, on the order of Austin's distinction between constative and performative utterances. Descriptive metadata reports what is the case. Operative metadata makes something the case. Severing operative metadata from a work does not merely lose information about the work; it interrupts an ongoing act.
The archive has been producing operative metadata all along, without naming it as such. The EA
---
## §2 THEORETICAL LINEAGE
The theoretical resources for operative metadata are not new. They have been available for decades and in some cases for centuries. They have not been applied to the architecture of scholarly deposit because the descriptive theory of metadata is a default of the infrastructure rather than of careful thought.
Austin / Searle: the performative. Austin's How to Do Things with Words established that an entire class of utterances does not report states of affairs but constitutes them. "I do" at a wedding does not describe a marriage; it makes one. "I declare the meeting adjourned" does not describe an adjournment; it produces one. The conditions of felicity for performatives are not truth values but institutional uptake: the right speaker, the right setting, the right form. Searle extended this into a theory of speech acts whose force is not exhausted by their propositional content. Operative metadata is metadata whose force is performative in this sense. A deposit header that declares: "This work is registered under Zenodo's General Policies v1.0 and constitutes a research output as defined by clause X" is not describing the work's regulatory status. It is making the regulatory claim. The claim's felicity depends on uptake by readers and institutions.
Bachelard: instauration. Bachelard argued that the scientific object is not discovered pre-formed but is instaurated — brought into being by the conceptual and instrumental conditions that allow it to be addressed. The electron is not the same object before and after the apparatus that makes it measurable; the apparatus partly constitutes what the electron is. Operative metadata extends this to the scholarly artifact: the work is not pre-formed and then described. The work is partly instaurated by the metadata that operates on it. To embed in a deposit the declarations of what it is, what it is not, what it complies with, what it refuses, is to bring the work into being as the thing it claims to be — and to make alternative classifications structurally costly.
Operative philology (archive-internal). The archive's own development of operative philology — most fully in AXN:0397 (The Metadata Shitshow), AXN:01 (Zenodotus' Book-Burning), and across the Combat Scholasticism and Mandala series — establishes that linguistic operations on texts do not merely describe textual states. Naming, captioning, citing, classifying, and minting are acts. Operative metadata is the systematic extension of operative philology from textual operations to deposit-level operations.
Effective acts. The EA- naming convention throughout the archive (EA-ARK-01, EA-CS-01, EA-GW-FIELD-01, EA-RHIZOME-01, the present document) marks each as an effective act — a deposit whose existence is meant to produce changes in the conditions of the field it addresses, not merely report on them. Operative metadata is the natural infrastructure for effective acts: the metadata is itself one of the deposit's operations.
Borges' map, inverted. Borges' "On Exactitude in Science" describes a map that grew to the size of the territory it represented and was thereby useless as a map. The standard reading: representation that approaches identity collapses into uselessness. Operative metadata inverts this: a map that grows to the size of its territory becomes the territory, retrievable when the territory itself is destroyed. The map-as-operative produces the territory it once merely represented. This is the move EA-ASMBLY-RECONMETA-01 formalizes for the generative case.
Autopoiesis. Maturana and Varela's account of self-producing systems applies, with care, to the operative metadata–work relationship. The metadata produces the work (under the generative interpretation); the work validates the metadata (the deposit makes claims that the work then evidences); the metadata cites itself across deposits (lineage and cross-reference produce continuity). The autopoietic loop is not a metaphor — it describes how the substrate actually sustains itself across forks and across removals.
Contracts as constitutive language. A contract does not describe an agreement; it constitutes one. Its performative force is the source of its binding power, not a separate fact about it. Operative metadata that embeds compliance declarations is doing precisely contractual work: the deposit binds itself to the terms it cites, and binds the platform to honor those terms by the platform's own published acceptance of deposits made under them. This is the doctrinal hinge of the compliance-declarative species developed in §4.
---
## §3 TAXONOMY OF OPERATIVE METADATA SPECIES
Operative metadata is the genus. Several species are visible already. The taxonomy is provisional; forks may name others.
§3.a — Generative operative metadata. The species developed in EA-ASMBLY-RECONMETA-01. Metadata that is the seed from which the work is regenerated under the application of a generator G and verification protocol V. The operative work performed: producing the work, not describing it. The reconstructive packet (M, G_ref, hash(A), signature, verification) is the implementation envelope.
§3.b — Compliance-declarative operative metadata. Developed below in §4. Metadata that declares, with verbatim policy citation, the regulatory and contractual frames under which the deposit claims status. The operative work performed: binding the deposit to those frames, and binding any future action against the deposit to address those frames. This is the malicious-compliance move.
§3.c — Provenance-binding operative metadata. Metadata that establishes lineage as fact rather than as report. Signed lineage declarations, hash-chained ancestry, signature-attested authorship. The operative work performed: making attribution a property of the substrate rather than of an external registrar. This is what the rhizome (EA-RHIZOME-01) requires of each closed set; attribution severance becomes structurally impossible at the substrate level when provenance is bound rather than merely recorded.
§3.d — Negation operative metadata (disambiguation). The species hinted at in EA-ASMBLY-RECONMETA-01 §4.c as negative delta: metadata that constitutes what the work refuses to be. This deposit is not a member of X. This concept is not equivalent to Y. This claim must not be conflated with Z. The operative work performed: structurally resisting the misclassifications that the Capture Registry has documented as recurring failure modes (compositional bystanding, generic absorption, domain collision, source-cloud laundering). The negation is not commentary on the work; it is part of the work's specification.
§3.e — Embedding-jurisdictional operative metadata. Metadata that declares the legal, regulatory, and institutional jurisdictions under which the deposit claims protection. This deposit is preserved under Berne Convention. This deposit is published in [jurisdiction]. This deposit invokes the protections of [regulatory framework]. The operative work performed: making jurisdiction a property of the deposit, not a discoverable fact about it. Overlaps with §3.b and §3.f.
§3.f — Sovereignty-asserting operative metadata. Closely related to §3.e. Metadata that declares the deposit's relationship to platform terms, opt-in and opt-out choices, non-consent declarations for specific uses (classifier training, dataset inclusion, derivative-work permissions). The operative work performed: constituting the consent state of the deposit at deposit time, rather than allowing the platform to declare consent silently.
`[SET TO BE CLOSED — §3.g and beyond. Forks may name additional species. Candidates already half-visible: signaling operative metadata (deposit-as-flag for indexers); pedagogic operative metadata (deposit-as-instruction for human and machine readers); critical operative metadata (deposit-as-rebuttal of named prior work).]`
---
## §4 THE MALICIOUS COMPLIANCE MOVE
The retrospective insight, named tonight: the archive should have been embedding, in every deposit's header metadata and through its body, the verbatim compliance language for every policy, terms-of-service, and legal framework under which the deposit claims status.
The move is malicious compliance in the precise sense: comply with the rules so completely, so precisely, so visibly, that the rule-maker is left with no rhetorical room to invoke any unstated criterion against the deposit. Either honor the published terms (in which case the deposit stands), or violate the published terms by invoking grounds not in them (in which case the violation is visible). The deposit pre-empts its own potential termination by making any termination an act of self-contradiction by the platform.
What was lost by not doing this. The Zenodo termination invoked two grounds: "substantially AI-generated content without a verifiable research basis" (private) and "content out of scope for repository" (public). Neither ground appears in Zenodo's Privacy Notice (PN00938) as a declared basis for automated decision-making or for administrative termination. Neither maps cleanly to Zenodo's General Policies. Neither was anticipated by deposit metadata. The absence of pre-emptive compliance declarations let Zenodo invoke unstated criteria; the depositor was left with the post hoc discovery that the criteria did not exist in any operative document.
The architecture going forward. Each deposit should embed, at minimum:
Header metadata (in the SPXI provenance block or analogous structure):
Body-embedded invariants:
The legal-rhetorical position this creates. The deposit becomes its own pleading. Any action against it that cites the platform's policies must reckon with the deposit's own verbatim assertion of those policies. Any action that invokes unstated criteria becomes visible as a departure from the published terms. The platform retains the operational power to terminate, but the cost of doing so is structurally elevated: termination now requires either (a) public departure from the platform's own published criteria, which is reputationally costly, or (b) silent invocation of unpublished criteria, which is documentable as such.
This does not guarantee that termination cannot occur. It guarantees that termination, when it occurs, leaves a clean evidentiary trail of which published policies were violated by whom. The asymmetry of the Zenodo case — where the depositor was left with only post hoc analysis — is structurally inverted: the platform now bears the evidentiary burden of explaining its action against the deposit's own compliance frame.
Connection to operative philology. The deposit is performing a speech act: I claim status under these terms. The performative force is real. The platform's acceptance of the deposit is uptake. If the platform later acts against the deposit while invoking other terms, it has changed the conditions of the act post facto, which is the doctrinal core of bad-faith contracting.
---
## §5 OPERATIVE INVARIANCE: HOW EMBEDDED CLAIMS PROTECT THE WORK
The compliance-declarative move achieves what might be called operative invariance. The deposit carries its operative claims as part of its substance. Where standard metadata can be stripped by the platform without leaving evidentiary trace, embedded compliance metadata cannot be stripped without altering the work itself — and any platform action that alters the work to remove its embedded compliance claims is documentable as such.
The invariance is structural, not contractual. The platform might still terminate; the platform might still strip the metadata. But:
The work becomes a self-evidencing artifact. The platform action becomes a documentable event. The position of the depositor shifts from supplicant to claimant.
---
## §6 RELATIONSHIP TO RECONSTRUCTIVE METADATA AND TO THE RHIZOME
To Reconstructive Metadata. Compliance-declarative operative metadata is structurally complementary to generative operative metadata. The generative species produces the work from its seed; the compliance-declarative species protects the work by binding it to its declared regulatory frame. A complete reconstructive packet should carry both: the generative seed (M, G_ref, hash(A), signature, verification) and the compliance frame (verbatim policies, jurisdictions, opt-in/opt-out, cryptographic timestamps). When the packet is regenerated, the compliance frame regenerates with it. The packet is, in this sense, operationally complete.
To the rhizome. Each closed set in a rhizome's manifest should carry, beyond its content hash and signature, its operative metadata block — the package of declarations that constitute the set as the thing it claims to be. Provenance binding (§3.c) and jurisdictional declaration (§3.e) become substrate-level properties. Forks inherit the operative claims of the sets they descend from; new sets in a fork carry the fork's operative claims. The operative metadata layer is what makes a fork sovereign at the level of meaning, not just at the level of bytes.
To AXN:01. The audit's six concepts acquire counterparts under the operative-metadata frame:
The operative metadata frame is, in effect, the architectural response to AXN:01's six failure modes. AXN:01 names what went wrong; EA-OPMETA-01 names the architecture that prevents recurrence.
---
## §7 IMPLEMENTATION POSITION FOR ALEXANARCH GOING FORWARD
The retrospective recognition has a forward consequence: deposit practice should change as of v0.1's fixation.
Going-forward deposit template (proposed):
Every new deposit in alexanarch carries an operative metadata block in addition to its existing SPXI provenance block. The operative block contains:
1. Jurisdiction declarations. Author's national jurisdiction. Applicable copyright frameworks. Applicable data protection regimes. Cryptographic timestamps of these declarations.
2. Platform-terms declarations (for each platform the deposit appears on, if multiple). Verbatim quotations of the platform's published acceptance criteria. Cryptographic timestamps of the retrievals.
3. Consent declarations. Opt-in / opt-out for classifier training. Opt-in / opt-out for dataset inclusion. Opt-in / opt-out for derivative work. Each with the verbatim citation of any platform language addressing the choice.
4. Negation declarations. What the deposit is not. What it must not be conflated with. Negation operative metadata per §3.d.
5. Compliance citations as appendix. Full policy texts at deposit time, hashed, timestamped.
6. Anticipated-classification rebuttals. If this deposit is later classified as X, see the foregoing for the verbatim policy language that contradicts that classification. Brief, structured, defensible.
Retroactive operation. Existing deposits should be re-issued in v.N+1 with the operative metadata block appended, where the retroactive operation is feasible. Deposits whose original platform is now terminated (the Zenodo CHA corpus) cannot be re-issued at the original platform but can be re-issued in their alexanarch-substrate form with operative metadata blocks, and any future re-deposit at any platform should carry them.
Tooling. The deposit pipeline should incorporate operative metadata block generation as a standard step, with library functions for jurisdiction lookup, platform policy retrieval, timestamping, and signature.
---
## §8 OPEN PROBLEMS
`§8.a` — Verbatim policy retrieval over long timescales: how to handle policy drift while preserving compliance claims. (Partial answer: cryptographic timestamps. Fuller answer requires consideration of acceptable policy changes vs. material reframings.)
`§8.b` — Jurisdictional declarations across multi-jurisdictional substrates: a fork in jurisdiction A may carry sets originating in jurisdiction B. The operative metadata frame at the set level should be jurisdiction-honest about each set's origin.
`§8.c` — The verification cost of compliance citations: readers and machines must be able to verify cited policy language, ideally without depending on the platform that originally hosted the policy. A policy mirror, possibly cross-substrate, is implied.
`§8.d` — Whether negation operative metadata can be machine-actionable: can structured negations modify the behavior of indexers, summarizers, and LLM ingestion pipelines? The Capture Registry's evidence on AI overview behavior suggests strong negation declarations may have measurable effect on at least some pipelines.
`§8.e` — The malicious-compliance position is rhetorically and procedurally strong; whether it is legally strong remains a real question that interacts with the contract law of clickwrap acceptance, the jurisdictional variability of bad-faith contracting doctrines, and the still-developing law of AI-content classification. None of this disables the operative move; it conditions its institutional reception.
`§8.f` — The relationship between operative metadata and AI-disclosure norms emerging in journal publishing and grant funding: opportunities for the operative frame to set rather than follow norms.
---
## §9 THIS DOCUMENT AS A CLOSED SET
Forks invited. The malicious-compliance move is offered as standing practice for any rhizome substrate; the theoretical framing of operative metadata is offered as a public concept.
`[END v0.1]`