Zenodo is a good archive. It assigns DOIs, timestamps records, and holds content permanently. What it does not do is circulate. Zenodo deposits sit behind an infrastructure that Google Scholar treats inconsistently — some records index, many do not, and the ones that fall through the gap are invisible to the citation layer that academic reputation runs on. This is not a critique of Zenodo; it is a description of how the pipeline works. The Socioplastics corpus currently has approximately one hundred DOIs anchored on Zenodo across eight named Cores — Core I through Core VIII — covering nodes from 501 to 4000, plus a parallel set of urban essays and thematic series on Figshare. That is a substantial body of work with a formal identifier structure, a consistent authorship record, and a growing bibliography of 600+ entries cross-referenced by node number. The problem is not the work. The problem is that most of it is not being found by the people who would find it useful, because the platforms where they look are not the platforms where the records currently live. ResearchGate indexes PDF uploads reliably into Google Scholar. The fix is straightforward: take the Cores that are already DOI-stamped, upload the PDF to ResearchGate with the DOI in the metadata, and let the indexing do the rest. This is not a workaround. It is completing the distribution circuit that was always implied by the DOI structure.
What the Cores Are and Why They Are the Right Unit
The Socioplastics corpus is organized at several scales simultaneously: individual nodes (now past 4,100), Century Packs of 100 nodes each, Tomes of 1,000 nodes, and Cores — thematic clusters of ten nodes each that function as conceptual anchors within the larger structure. The Cores are where the theoretical load is concentrated. Core I (nodes 501–510) established the operational vocabulary: Flow Channeling, Cameltag Infrastructure, Semantic Hardening, Stratum Authoring, Recursive Autophagia, Citational Commitment, Topolexical Sovereignty. Core II (nodes 991–1000) developed the scalar grammar: Numerical Topology, Decalogue Protocol, Scalar Architecture, Recurrence Mass, Conceptual Anchors, Helicoidal Anatomy, Torsional Dynamics. Core III (nodes 1501–1510) laid the disciplinary foundation — ten field-operators derived from linguistics, epistemology, systems theory, architecture, urbanism, media theory, morphogenesis, and synthetic infrastructure. Core VII (nodes 3201–3210) turned toward soft ontology — how fields form, how visibility arrives late, how stable cores allow open systems to grow. Core VIII, the Double Pentagon (nodes 3496–3500 and 3996–4000), holds the most recent concentrated theoretical work: Digestive Surface, Grammatical Threshold, Synthetic Legibility, Latency Dividend, Plastic Peripheries, and five nodes extending the series through Radical Education, Thermal Justice, Expansion Risk, Archive Fatigue, and Diagonal Reading. Ten nodes per Core, ten Cores in view, roughly one hundred DOI-anchored records that together constitute the theoretical spine of the project. This is the unit that makes sense to circulate as PDFs — not individual nodes in isolation, not the full Tomes at once, but the Cores as coherent conceptual packages that a reader can encounter, recognize as systematic, and follow back to the larger corpus.
The Doubling Logic: Tomes I–IV Plus Tome V
The current DOI count across the Cores sits at approximately one hundred records — the number arrived at organically as Tomes I through IV were completed, each 1,000 nodes, with Cores designated at regular structural intervals. Tome V changes the arithmetic. It arrives with what is described internally as a Decalogue DOI structure: ten designated DOI-bearing records per Decalogue unit, which across a full Tome means one hundred additional identifiers, each mappable to a named concept or series within the Tome V architecture. This effectively doubles the deployable PDF inventory in a single move. One hundred existing Core PDFs on ResearchGate establishes the field presence and gets the earlier Cores indexed. One hundred Tome V PDFs uploaded in parallel — or in a fast second wave as the Tome progresses — means that by the time Tome V is complete, the ResearchGate profile is carrying two hundred indexed PDFs tied to two hundred live DOIs, all under a single ORCID, all pointing back to the same corpus. The compounding effect matters here. Two hundred indexed records in Google Scholar do not just double the exposure of one hundred — they make the corpus legible as a field. A reader who encounters a single node on ResearchGate and follows the citation chain will find not one paper but a structured body of work with identifiable Cores, named Tomes, and a consistent theoretical vocabulary across two hundred distinct records. That is what a field looks like from the outside. The ResearchGate PDF operation is not adding decoration to a finished structure; it is making the structure visible in the register where visibility counts.
How the Operation Works in Practice
Each Core PDF follows the same simple format: title (node number plus CamelTag name), abstract of 150–200 words, the DOI, the ORCID, the Zenodo or Figshare link, and a brief contextual note situating the node within its Core and Tome. No elaborate layout. No attempt to replicate the full Zenodo record. The PDF is a circulation artifact — its purpose is to carry the DOI into Google Scholar's index and to give a reader arriving from ResearchGate enough information to understand what they are looking at and where to go next. Batch production is straightforward: the Core structure is already documented, the DOIs are already assigned, the node names are already CamelTagged and therefore consistent as metadata strings. The first wave covers the existing eight Cores — roughly eighty to one hundred PDFs depending on how the intermediate series are handled — and uploads them to ResearchGate under the verified profile linked to ORCID 0009-0009-9820-3319. The second wave, running in parallel with Tome V production, uploads each Decalogue unit as it is finalized, so the ResearchGate presence grows continuously rather than arriving in a single batch and then going quiet. Continuous growth matters for indexing: platforms that see regular new uploads from a profile treat that profile as active, and active profiles index faster and rank higher in internal search. The operation is low overhead because the intellectual work is already done. The Cores exist. The DOIs exist. The ORCID is verified. What does not yet exist is the PDF layer that bridges the Zenodo archive to the Scholar index. Building that bridge is the task.
