The 20-Year File: A Zero-Dependency Architecture for Digital Paratypes
T. M. Jones, PhD
TJID3 Technical Note • Published: December 2025
DOI: 10.5281/zenodo.18054789
Abstract
This technical note describes a practical way to publish datasets and visualizations as a single, durable HTML file that runs offline. The implementation uses native browser standards, just Vanilla JavaScript (standard ECMAScript) and CSS3. It vendors all visualization code into the document. The dataset is stored inline, eliminating fetch calls and external dependencies. Borrowing from taxonomy: if the digital holotype is the raw dataset, this describes a "digital paratype," packaging analysis and figures alongside data in a single archival file. The methodology is demonstrated in the Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297), a longitudinal economic dataset (74 months at publication).
Unlike a static PDF, the document rewrites itself at load time, regenerating durations, refreshing labels, and updating summary text from embedded data. This keeps the narrative aligned as the dataset grows. The "evergreen" workflow means replacing the monthly JSON payload triggers automatic regeneration without rebuilds. The same approach supports multilingual publication; six languages were added without an API. Performance validation using PageSpeed Insights shows strong interactivity and accessibility on typical devices. Standard growth models suggest multi-century operability is mathematically possible.
Unlike physical specimens that require protection from damage, these digital artifacts survive through distribution. The preservation strategy shifts from custody to replication. At 325KB for seven years of data, the artifact functions as "viral data"; distributable via email, thumb drives, or web hosting while remaining completely self-contained.
This methodology paper describes a self-modifying HTML architecture demonstrated in the Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297), a longitudinal economic dataset tracking 74 months of regulatory data. The artifact executes its own code to regenerate narrative sections each time new data is added, maintaining alignment between analysis and evidence without external build processes.
This is neither a static webpage, a web application, nor self-modifying code in the traditional sense. It's a single HTML file that, when opened, executes code to rewrite its own narrative sections from embedded data - generating current summaries, conclusions, and analytical text based on the dataset's current state. This is a category that doesn't yet have a name. Borrowing from taxonomic nomenclature, these are termed digital paratypes.
Longitudinal datasets often retain scientific value for decades. Interactive visualizations and their data payloads that accompany them often do not. Many modern web deployments depend on layered toolchains, build pipelines, CDNs, and versioned packages that can disappear or become difficult to reproduce over time. When a visualization is tightly coupled to that tooling stack, the research may remain intact while the interface becomes unusable. This is an archival risk: the record still exists, but the instrument for exploring it cannot be reliably executed in the future.
Physical archives can be lost to fire. Water damage can erase them. War can destroy them. Simple attrition can remove them, quietly. Digital artifacts fail in a different way. They depend on infrastructure that degrades over time. Frameworks churn. CDNs break. APIs are deprecated. Package managers become inaccessible.
This pattern might be termed "complexity theater", sophisticated architectural choices designed for enterprise-scale challenges applied to research artifacts that require longevity over scalability. The infrastructure is impressive. The tooling is elaborate. But for archival purposes, the complexity becomes the vulnerability.
The digital preservation community has long recognized that replication protects against institutional failure. Stanford's LOCKSS program ("Lots of Copies Keep Stuff Safe") pioneered distributed preservation networks for academic journals, demonstrating that geographically dispersed copies under independent administration provide robust defense against content loss. However, these systems require coordinated institutional infrastructure: networked repositories, automated auditing protocols, and persistent organizational commitment.
A zero-dependency architecture inverts this model. Instead of institutions maintaining copies through active curation, the artifact's self-contained portability enables friction-free distribution. The preservation strategy shifts from custody to replication. A single HTML file can be copied indefinitely. Redundant storage is easy. Opening the file requires no installation. A network connection is optional. Physical type specimens are fragile because they cannot be duplicated. Framework-dependent visualizations are fragile because they cannot be duplicated as working objects. Zero-dependency artifacts survive through distribution itself.
There is no single specimen to protect. The file functions as the reference artifact. Every copy remains complete. Distribution is the defense.
This approach applies Fernand Braudel's la longue durée to digital preservation, framing the work in centuries rather than quarterly cycles. By looking past transient frameworks and architectural trends, the focus remains on enduring web standards—the infrastructural layer that survives technological shifts.
For the Michigan Cannabis market dataset, the design constraint was explicit: the complete interactive paper must run as a single HTML file opened locally in a standard browser. The artifact must function offline, without installation steps, and without external requests.
The dataset is structured using a domain-specific ontology optimized for compactness - multiple years of regulatory data totaling 34KB through consistent schema design. Each monthly update triggers the document to rewrite its own narrative sections, regenerating summaries and updating visualizations from the embedded data payload.
The "Evergreen" Architecture
The solution utilizes a pattern I call "Gojira & Gamera." It separates the data payload from the visualization engine, keeping both within the DOM but logically distinct.
1. Gojira (The Data Engine)
Instead of fetching data from an external database or a CSV file, the full dataset is embedded directly into the HTML as a pre-hydrated JSON object. This avoids asynchronous loading states and network latency entirely.
// Example of the "Gojira" embedded data structure
const rawData = [
["10/1/2019", "Oct", 2019, "$28,594,402", ...],
["11/1/2019", "Nov", 2019, "$26,628,235", ...],
// ... 60+ months of data
];
Listing 1: Data embedding strategy. The raw array structure injects the complete dataset into the DOM, eliminating fetch requests.
2. Gamera (The Visualization Logic)
The application logic uses an IIFE (Immediately Invoked Function Expression) to encapsulate state, preventing pollution of the global namespace. It utilizes Vanilla JavaScript to manipulate the DOM directly, bypassing the Virtual DOM overhead inherent in complex frameworks.
Listing 2: Scope encapsulation. This design creates a secure, encapsulated execution context for the logic.
For the visualization layer, the project relies on Chart.js. To strictly adhere to the zero-dependency constraint, the library was treated not as a remote dependency to be fetched, but as a brick cemented into the wall of the application. Technically known as "vendoring," the source code was minified and embedded directly into the document, ensuring the visualization engine functions as immutable infrastructure that is intended to outlast any package manager or CDN.
3. Zero-Dependency Styling
The architecture uses CSS Custom Properties for theming. This allows for instant Dark/Light mode switching through a single attribute change, eliminating the need to parse or load external CSS libraries.
Performance & "Living" Behavior
The architecture is consistent with Native ECMAScript. When architected correctly, native ECMAScript can outperform complex frameworks for evergreen artifacts; where the narrative evolves dynamically as the dataset grows.
Unlike a static report, this document functions as a state engine. Upon loading the JSON payload, the document performs a "self-audit," recalculating the temporal duration (e.g., updating "6-Year Trends" to "7-Year Trends"), refreshing the citation year, and revising summary statistics in the DOM text. Because this logic executes linearly without the overhead of framework hydration or Virtual DOM diffing, the document achieves near-immediate First Contentful Paint (FCP) and near-instant interactivity, regardless of the dataset's growing size.
Catchpoint Synthetic Monitoring reports provide controlled, repeatable performance measurements from their global test nodes under standardized conditions (100ms latency, 5Mbps throughput). These lab-grade metrics, including start render, first contentful paint, and total blocking time, validate the artifact’s sub-second rendering performance in a consistent testing environment—offering a reproducible benchmark distinct from real-user variability.
Google PageSpeed Insights (PSI) audits were conducted on the production build to evaluate the effectiveness of the optimization strategy. The results confirmed the stability goals while highlighting the trade-offs inherent in a monolithic design.
The artifact is a functional template. To fork it: save the single HTML page, then update the <title> and replace the domain-specific content with your own. This works through direct derivation: each new artifact starts as a copy of this complete and self-contained reference.
Snapshot Date: 2026-01-06 (Production Build)
0.5s
Start Render
0.8s
FCP
0.8s
LCP
0.8s
Speed Index
0.1s
TBT
0.002
CLS
250KB
Page Weight
0.8s
DC Time
250KB
DC Bytes
1.0s
Total Time
Figure 1a: Catchpoint performance metrics for the artifact, captured from the production deployment to provide a repeatable baseline.
100
Performance (PSI)
100
Accessibility
100
Practices
100
SEO
Figure 1b: Google PageSpeed Insights (PSI) snapshot (2026-01-06). The results reflect real-world performance for typical users on average devices and networks. Performance, Accessibility, Best Practices, and SEO each score ~ 100, supporting the efficiency of the zero-dependency architecture.
Limitations: The 5MB Ceiling
This system prioritizes stability and long-term preservation over the scalability required for large transactional or streaming data applications. It is designed for typical scientific publishing, where datasets are modest in size but require reliable longevity.
The architecture is implemented as a zero-dependency, single HTML file. This design introduces a practical performance ceiling of approximately 5MB, beyond which user experience degrades due to download and parsing latency. Within this constraint, performance remains predictable and manageable.
This architecture is designed for single-author research workflows, not collaborative team development. The monolithic structure prevents the division of labor typical in modern web development - where CSS specialists, JavaScript developers, backend engineers, and content writers work in parallel on separate files merged through build processes. Digital paratypes trade collaborative infrastructure for archival independence.
However, this constraint enables a different form of collaboration: derivative reuse. The artifact can be copied, modified, and forked for new work without institutional permission or infrastructure dependencies. The embedded data can be extracted and repurposed. A digital paratype can be forked to create new independent artifacts - each complete and functional, requiring no coordination with the original author. This differs from collaborative platforms, where data access depends on ongoing institutional support and server infrastructure.
Arithmetic Projections
The data structure is lean and purpose‑built. The dataset grows at approximately 5.3 KB per year. With a 34 KB payload representing seven years of production data and a 5 MB ceiling, the architecture can remain performant for centuries, well beyond the stated 20‑year archival target.
Values
Maths
Current payload size
34 KB
Annual growth rate
≈5.3 KB/year
Ceiling (practical limit)
5 MB
Years to ceiling
≈900 years
Size at 20 years
≈140 KB
Derived from Michigan CRA data
Source: Michigan Digital Paratype archive index (74 months, October 2019–November 2025).
Conclusion
This work shows that a zero-dependency, single-file HTML publication can support interactive data storage and multi-series visualization while minimizing long-term operational requirements. By embedding the dataset and vendoring the visualization code, the artifact remains executable offline and avoids failure modes associated with external infrastructure.
This work demonstrates what appears to be a novel document architecture: artifacts that regenerate their own analysis from embedded data. While self-contained HTML documents and executable research compendia exist separately, no examples were found combining zero-dependency execution with self-modifying narrative generation. The Michigan Cannabis analysis contains the complete logic to rewrite its narrative sections when new monthly data is inserted. Each version can produce the next version. This is not traditional reproducible research, where external users verify results by re-running code. This is self-modification by design; where the document maintains its own coherence through execution.
The implications extend beyond technical novelty. If documents can contain the process of their own regeneration, they become digital paratypes in a deeper sense than taxonomic metaphor suggests. They preserve not just content, but the machinery of authorship itself. Each copy distributed is a complete, functional replica capable of producing future iterations.
The approach is intended for modest-to-medium datasets where durability and reproducibility take precedence over large-scale streaming, complex authentication, or rapid feature turnover. Within the practical file-size ceiling described above, a monolithic HTML artifact can function as a stable, citable interface for longitudinal research and archival distribution. At 325KB for several years of data, this approach demonstrates preservation through viral distribution rather than institutional custody. The artifact survives by being copied, not protected.
For data that must persist, distribution remains the defense. This is a working implementation, not a proposal. The methodology is demonstrated at https://tjid3.org/.
Le fichier de 20 ans :
Une Architecture Sans Dépendances pour les Paratypes NumériquesLe fichier de 20 ans | Paratypes Numériques
Résumé
Cette note technique décrit une méthode pratique pour publier des ensembles de données et des visualisations sous forme d'un seul fichier HTML durable qui fonctionne hors ligne. L'implémentation utilise des standards natifs du navigateur, uniquement du Vanilla JavaScript (ECMAScript standard) et CSS3. Elle intègre tout le code de visualisation dans le document. L'ensemble de données est stocké en ligne, éliminant les appels fetch et les dépendances externes. Empruntant à la taxonomie : si l'holotype numérique est l'ensemble de données brutes, ceci décrit un « paratype numérique », regroupant analyses et figures aux côtés des données dans un seul fichier d'archives. La méthodologie est démontrée dans la Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297), un ensemble de données économiques longitudinales de plusieurs années.
Contrairement à un PDF statique, le document se réécrit au moment du chargement, recalculant les durées, actualisant les étiquettes et mettant à jour le texte récapitulatif à partir des données intégrées. Cela maintient le récit aligné au fur et à mesure que l'ensemble de données croît. Le flux de travail « evergreen » signifie que le remplacement de la charge utile JSON mensuelle déclenche un recalcul automatique sans reconstruction. La même approche prend en charge la publication multilingue ; six langues ont été ajoutées sans API. Les validations de performance montrent une forte interactivité et accessibilité sur les appareils typiques. Les modèles de croissance standard suggèrent qu'une opérabilité multi-séculaire est mathématiquement possible.
Contrairement aux spécimens physiques qui nécessitent une protection contre les dommages, ces artefacts numériques survivent par la distribution. La stratégie de préservation passe de la garde à la réplication. À 325 Ko pour sept années de données, l'artefact fonctionne comme des « données virales » ; distribuable par courriel, clés USB ou hébergement web tout en restant complètement autonome.
Cet article méthodologique décrit une architecture HTML auto-modifiante démontrée dans la Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297), un ensemble de données économiques longitudinales couvrant 74 mois de données réglementaires. L'artefact exécute son propre code pour régénérer les sections narratives à chaque ajout de nouvelles données, maintenant l'alignement entre l'analyse et les preuves sans processus de construction externe.
Il ne s'agit ni d'une page web statique, ni d'une application web, ni d'un code auto-modifiant au sens traditionnel. C'est un fichier HTML unique qui, lorsqu'il est ouvert, exécute du code pour réécrire ses propres sections narratives à partir de données intégrées - générant des résumés actuels, des conclusions et du texte analytique basés sur l'état actuel du jeu de données. C'est une catégorie qui n'a pas encore de nom. Empruntant à la nomenclature taxonomique, ceux-ci sont appelés paratypes numériques.
Les jeux de données longitudinales conservent souvent une valeur scientifique pendant des décennies. Les visualisations interactives et leurs charges de données qui les accompagnent, en revanche, rarement. De nombreux déploiements web modernes dépendent de chaînes d'outils stratifiées, de pipelines de construction, de CDN et de paquets versionnés qui peuvent disparaître ou devenir difficiles à reproduire au fil du temps. Lorsqu'une visualisation est étroitement couplée à cette pile d'outils, la recherche peut rester intacte tandis que l'interface devient inutilisable. C'est un risque d'archivage : le dossier existe toujours, mais l'instrument permettant de l'explorer ne peut plus être exécuté de façon fiable dans le futur.
Les archives physiques peuvent être perdues à cause d'un incendie. Les dégâts des eaux peuvent les effacer. La guerre peut les détruire. Une simple attrition peut les faire disparaître, discrètement. Les artefacts numériques échouent d'une autre manière. Ils dépendent d'une infrastructure qui se dégrade au fil du temps. Les frameworks évoluent. Les CDN tombent en panne. Les API sont dépréciées. Les gestionnaires de paquets deviennent inaccessibles.
Ce modèle pourrait être qualifié de « théâtre de la complexité », des choix architecturaux sophistiqués conçus pour des défis à l'échelle de l'entreprise appliqués à des artefacts de recherche qui nécessitent la longévité plutôt que l'évolutivité. L'infrastructure est impressionnante. L'outillage est élaboré. Mais à des fins d'archivage, la complexité devient la vulnérabilité.
La communauté de préservation numérique reconnaît depuis longtemps que la réplication protège contre les défaillances institutionnelles. Le programme LOCKSS de Stanford (« Lots of Copies Keep Stuff Safe ») a été pionnier dans les réseaux de préservation distribués pour les revues académiques, démontrant que des copies géographiquement dispersées sous administration indépendante fournissent une défense robuste contre la perte de contenu. Cependant, ces systèmes nécessitent une infrastructure institutionnelle coordonnée, des dépôts en réseau, des protocoles d'audit automatisés et un engagement organisationnel persistant.
Une architecture zéro dépendance inverse ce modèle. Au lieu que les institutions maintiennent des copies par curation active, la portabilité autonome de l'artefact permet une distribution sans friction. La stratégie de préservation passe de la garde à la réplication. Un seul fichier HTML peut être copié indéfiniment. Le stockage redondant est simple. Ouvrir le fichier ne nécessite aucune installation. Une connexion réseau est optionnelle. Les spécimens types physiques sont fragiles parce qu'ils ne peuvent pas être dupliqués. Les visualisations dépendantes de frameworks sont fragiles parce qu'elles ne peuvent pas être dupliquées en tant qu'objets fonctionnels. Les artefacts zéro dépendance survivent par la distribution elle-même.
Il n'y a pas de spécimen unique à protéger. Le fichier fonctionne comme l'artefact de référence. Chaque copie reste complète. La distribution est la défense.
Cette approche applique la longue durée de Fernand Braudel à la préservation numérique, cadrant le travail en siècles plutôt qu'en cycles trimestriels. En regardant au-delà des frameworks transitoires et des tendances architecturales, l'accent reste sur les standards web durables, la couche infrastructurelle qui survit aux changements technologiques.
Pour le jeu de données du marché du Cannabis du Michigan, la contrainte de conception était explicite : le document interactif complet doit s'exécuter comme un seul fichier HTML ouvert localement dans un navigateur standard. L'artefact doit fonctionner hors ligne, sans étapes d'installation et sans requêtes externes.
Le jeu de données est structuré à l'aide d'une ontologie spécifique au domaine optimisée pour la compacité - plusieurs années de données réglementaires totalisant 34 Ko grâce à une conception de schéma cohérente. Chaque mise à jour mensuelle déclenche la réécriture par le document de ses propres sections narratives, régénérant les résumés et mettant à jour les visualisations à partir de la charge de données intégrée.
L'architecture « evergreen »
La solution s'appuie sur un schéma que j'appelle « Gojira & Gamera ». Il sépare la charge utile des données du moteur de visualisation, en conservant les deux dans le DOM, mais en les distinguant clairement sur le plan logique.
1. Gojira (le moteur de données)
Plutôt que de récupérer les données depuis une base externe ou un fichier CSV, l'ensemble du jeu de données est intégré directement dans le HTML sous la forme d'un objet JSON pré-hydraté. Cela élimine entièrement les états de chargement asynchrones et la latence réseau.
// Example of the "Gojira" embedded data structure
const rawData = [
["10/1/2019", "Oct", 2019, "$28,594,402", ...],
["11/1/2019", "Nov", 2019, "$26,628,235", ...],
// ... 60+ months of data
];
Listing 1 : Stratégie d'intégration des données. La structure en tableau injecte l'ensemble du jeu de données dans le DOM, en supprimant les requêtes fetch.
2. Gamera (la logique de visualisation)
La logique applicative utilise une IIFE (Immediately Invoked Function Expression) pour encapsuler l'état, ce qui évite de polluer l'espace de noms global. Elle s'appuie sur du JavaScript "Vanilla" pour manipuler le DOM directement, en contournant le surcoût du Virtual DOM inhérent à des frameworks complexes.
Listing 2 : Encapsulation de la portée. Cette conception crée un contexte d'exécution sûr et encapsulé pour la logique.
Pour la couche de visualisation, le projet s'appuie sur Chart.js. Pour respecter strictement la contrainte « zéro dépendance », la bibliothèque n'a pas été traitée comme une ressource distante à télécharger, mais comme une brique scellée dans le mur de l'application. Techniquement, cela relève du « vendoring » : le code source a été minifié et intégré directement au document, afin que le moteur de visualisation fonctionne comme une infrastructure immuable, conçue pour survivre à tout gestionnaire de paquets ou CDN.
3. Style zéro dépendance
L'architecture utilise des propriétés personnalisées CSS (CSS Custom Properties) pour le thème. Cela permet un basculement instantané entre mode sombre et mode clair via un simple changement d'attribut, sans charger ni parser de bibliothèque CSS externe.
Performance et comportement « vivant »
Lorsqu'elle est correctement architecturée, une approche fondée sur l'ECMAScript natif peut surpasser des frameworks complexes pour des artefacts « evergreen », où le récit évolue dynamiquement à mesure que le jeu de données s'étend.
Contrairement à un rapport statique, ce document fonctionne comme un moteur d'état. Au chargement de la charge utile JSON, la page effectue un « auto-audit » : elle recalcule des durées (par exemple « tendances sur 6 ans » → « tendances sur 7 ans »), rafraîchit l'année de citation, et met à jour des statistiques de synthèse dans le texte DOM. Comme cette logique s'exécute de façon linéaire, sans surcouches d'hydratation ni diff de Virtual DOM, le document atteint un affichage initial rapide (FCP) et une interactivité quasi immédiate, même lorsque le jeu de données augmente.
Les rapports de surveillance synthétique Catchpoint fournissent des mesures de performance contrôlées et reproductibles à partir de leurs nœuds de test mondiaux, dans des conditions standardisées (latence de 100 ms, débit de 5 Mbps). Ces métriques de laboratoire, incluant le début du rendu, le premier affichage de contenu et le temps de blocage total, valident les performances de rendu en moins d'une seconde de l'artefact dans un environnement de test cohérent — offrant ainsi un référentiel reproductible distinct de la variabilité des utilisateurs réels.
Des analyses de performance ont été réalisées sur le build de production pour évaluer l'efficacité de la stratégie d'optimisation. Les résultats confirment les objectifs de stabilité, tout en mettant en évidence les compromis inhérents à une conception monolithique :
Cet artefact est un modèle fonctionnel. Pour le dupliquer (*fork*) : enregistrez la page HTML unique, puis mettez à jour la balise <title> et remplacez son contenu spécifique au domaine par le vôtre. Contrairement aux *frameworks* qui nécessitent une intégration, cela fonctionne par dérivation directe : chaque nouvel artefact commence comme une copie de cette référence complète et autonome.
Instantané : 2026-01-06
0.496s
Début rendu
0.8s
Premier affichage de contenu
0.761s
Plus grand affichage de contenu
0.761s
Indice de vitesse
0.099s
Temps de blocage total
0.002
Décalage cumulatif de mise en page
250KB
Poids de la page
0.834s
Temps DC
250KB
Octets DC
0.984s
Temps total
Figure 1a : Métriques de performance Catchpoint pour l’artefact, capturées à partir du déploiement en production, mesurant les temps réels sur appareils et réseaux en conditions d'utilisation.
100
Performance (PSI)
100
Accessibilité
100
Bonnes pratiques
100
SEO
Figure 1b : Google PageSpeed Insights (PSI), instantané du 2026-01-06. Ce score reflète les performances en conditions réelles pour la majorité des utilisateurs, sur des appareils et réseaux moyens.
Limites : le plafond des 5 MB
Ce système privilégie la stabilité et la préservation à long terme plutôt que l'évolutivité requise pour des applications transactionnelles volumineuses ou des flux de données en continu. Il est conçu pour les usages typiques de la publication scientifique, où les jeux de données restent modestes, mais exigent une longévité fiable.
L'architecture est implémentée sous la forme d'un seul fichier HTML « zéro dépendance ». Ce choix introduit un plafond pratique d'environ 5 MB, au-delà duquel l'expérience utilisateur se dégrade en raison de la latence de téléchargement et du coût d'analyse/parsing. Dans cette contrainte, les performances restent prévisibles et gérables.
Cette architecture est conçue pour des flux de travail de recherche à auteur unique, et non pour le développement collaboratif en équipe. La structure monolithique empêche la division du travail typique du développement web moderne - où les spécialistes CSS, les développeurs JavaScript, les ingénieurs backend et les rédacteurs de contenu travaillent en parallèle sur des fichiers séparés fusionnés par des processus de construction. Les paratypes numériques échangent l'infrastructure collaborative contre l'indépendance archivistique.
Cependant, cette contrainte permet une forme différente de collaboration : la réutilisation dérivée. L'artefact peut être copié, modifié et dérivé pour de nouveaux travaux sans autorisation institutionnelle ni dépendances d'infrastructure. Les données intégrées peuvent être extraites et réutilisées. Un paratype numérique peut être dérivé pour créer de nouveaux artefacts indépendants - chacun complet et fonctionnel, ne nécessitant aucune coordination avec l'auteur original. Cela diffère des plateformes collaboratives, où l'accès aux données dépend du soutien institutionnel continu et de l'infrastructure serveur.
Projections mathématiques
L'architecture de licence crée des contraintes prévisibles. La structure de données est allégée et spécialement conçue. L'ensemble de données croît d'environ 5,3 Ko par an. Avec une charge utile de 34 Ko représentant sept années de données de production et un plafond de 5 Mo, l'architecture peut rester performante pendant des siècles, bien au-delà de l'objectif d'archivage déclaré de 20 ans.
Valeurs
Mathématiques
Taille actuelle de la charge utile
34 Ko
Taux de croissance annuel
≈5,3 Ko/an
Plafond (limite pratique)
5 Mo
Années jusqu'au plafond
≈900 ans
Taille à 20 ans
≈140 Ko
Dérivé des données CRA du Michigan
Source : Michigan Digital Paratype archive index (74 mois, octobre 2019–novembre 2025).
Conclusion
Ce travail montre qu'une publication HTML à fichier unique et sans dépendances peut prendre en charge le stockage de données interactif et la visualisation multi-séries tout en minimisant les exigences opérationnelles à long terme. En intégrant l'ensemble de données et en vendorisant le code de visualisation, l'artefact reste exécutable hors ligne et évite les modes de défaillance associés à l'infrastructure externe.
Ce travail démontre ce qui semble être une architecture documentaire nouvelle : des artefacts qui régénèrent leur propre analyse à partir de données intégrées. Bien que les documents HTML autonomes et les compendia de recherche exécutables existent séparément, aucun exemple n'a été trouvé combinant l'exécution sans dépendances avec la génération narrative auto-modifiante. L'analyse du Cannabis du Michigan contient la logique complète pour réécrire ses sections narratives lorsque de nouvelles données mensuelles sont insérées. Chaque version peut produire la version suivante. Il ne s'agit pas de recherche reproductible traditionnelle, où des utilisateurs externes vérifient les résultats en réexécutant le code. Il s'agit d'auto-modification par conception ; où le document maintient sa propre cohérence par l'exécution.
Les implications vont au-delà de la nouveauté technique. Si les documents peuvent contenir le processus de leur propre régénération, ils deviennent des paratypes numériques dans un sens plus profond que ne le suggère la métaphore taxonomique. Ils préservent non seulement le contenu, mais la machinerie de l'auteur elle-même. Chaque copie distribuée est une réplique complète et fonctionnelle capable de produire des itérations futures.
L'approche est destinée aux ensembles de données modestes à moyens où la durabilité et la reproductibilité priment sur le streaming à grande échelle, l'authentification complexe ou le renouvellement rapide des fonctionnalités. Dans le plafond pratique de taille de fichier décrit ci-dessus, un artefact HTML monolithique peut fonctionner comme une interface stable et citable pour la recherche longitudinale et la distribution archivistique. À 325 Ko pour 74 mois de données, cette approche démontre la préservation par distribution virale plutôt que par garde institutionnelle. L'artefact survit en étant copié, non protégé.
Pour les données qui doivent persister, la distribution reste la défense. Il s'agit d'une implémentation fonctionnelle, non d'une proposition. La méthodologie est démontrée à https://tjid3.org/.
Die 20‑Jahres‑Datei: Eine Zero-Dependency-Architektur für Digitale ParatypenDie 20‑Jahres‑Datei | Digitale Paratypen
Zusammenfassung
Diese technische Notiz beschreibt eine praktische Methode zur Veröffentlichung von Datensätzen und Visualisierungen als einzelne, dauerhafte HTML-Datei, die offline läuft. Die Implementierung verwendet native Browser-Standards, nur Vanilla JavaScript (Standard-ECMAScript) und CSS3. Sie integriert den gesamten Visualisierungscode in das Dokument. Der Datensatz wird inline gespeichert, wodurch Fetch-Aufrufe und externe Abhängigkeiten entfallen. Aus der Taxonomie entlehnt: Wenn der digitale Holotyp der Rohdatensatz ist, beschreibt dies einen „digitalen Paratyp", der Analysen und Abbildungen zusammen mit Daten in einer einzigen Archivdatei verpackt. Die Methodik wird in der Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297) demonstriert, einem longitudinalen Wirtschaftsdatensatz über 74 Monate.
Im Gegensatz zu einem statischen PDF schreibt sich das Dokument beim Laden selbst neu, berechnet Zeiträume neu, aktualisiert Beschriftungen und aktualisiert Zusammenfassungstexte aus eingebetteten Daten. Dies hält die Erzählung ausgerichtet, während der Datensatz wächst. Der „Evergreen"-Workflow bedeutet, dass das Ersetzen der monatlichen JSON-Nutzlast eine automatische Neuberechnung ohne Rebuilds auslöst. Derselbe Ansatz unterstützt mehrsprachige Veröffentlichungen; sechs Sprachen wurden ohne API hinzugefügt. Leistungsvalidierungen zeigen starke Interaktivität und Zugänglichkeit auf typischen Geräten. Standardwachstumsmodelle legen nahe, dass eine jahrhundertelange Betriebsfähigkeit mathematisch möglich ist.
Im Gegensatz zu physischen Exemplaren, die Schutz vor Beschädigung benötigen, überleben diese digitalen Artefakte durch Verteilung. Die Erhaltungsstrategie verschiebt sich von der Verwahrung zur Replikation. Mit 325 KB für sieben Jahre Daten funktioniert das Artefakt als „virale Daten"; verteilbar per E-Mail, USB-Sticks oder Webhosting, während es vollständig in sich geschlossen bleibt.
Verfügbarkeit: Das Live-Artefakt ist zugänglich unter https://tjid3.org/
Der Kontext: Archivierungsrisiko
Dieses Methodenpapier beschreibt eine selbstmodifizierende HTML-Architektur, demonstriert in der Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297), einem longitudinalen Wirtschaftsdatensatz, der 74 Monate regulatorischer Daten verfolgt. Das Artefakt führt seinen eigenen Code aus, um narrative Abschnitte jedes Mal neu zu generieren, wenn neue Daten hinzugefügt werden, und hält dabei die Ausrichtung zwischen Analyse und Evidenz ohne externe Build-Prozesse aufrecht.
Dies ist weder eine statische Webseite, eine Webanwendung noch selbstmodifizierender Code im traditionellen Sinne. Es ist eine einzelne HTML-Datei, die beim Öffnen Code ausführt, um ihre eigenen narrativen Abschnitte aus eingebetteten Daten neu zu schreiben – aktuelle Zusammenfassungen, Schlussfolgerungen und analytische Texte werden basierend auf dem aktuellen Zustand des Datensatzes generiert. Dies ist eine Kategorie, die noch keinen Namen hat. Aus der taxonomischen Nomenklatur entlehnt werden diese als digitale Paratypen bezeichnet.
Longitudinale Datensätze behalten oft jahrzehntelang wissenschaftlichen Wert. Interaktive Visualisierungen und ihre Datennutzlasten, die sie begleiten, tun dies oft nicht. Viele moderne Web-Deployments hängen von geschichteten Toolchains, Build-Pipelines, CDNs und versionierten Paketen ab, die im Laufe der Zeit verschwinden oder schwer zu reproduzieren werden können. Wenn eine Visualisierung eng an diesen Tooling-Stack gekoppelt ist, kann die Forschung intakt bleiben, während die Schnittstelle unbrauchbar wird. Dies ist ein Archivierungsrisiko: Der Datensatz existiert noch, aber das Instrument zu seiner Erkundung kann in Zukunft nicht zuverlässig ausgeführt werden.
Physische Archive können durch Feuer verloren gehen. Wasserschäden können sie auslöschen. Krieg kann sie zerstören. Einfache Abnutzung kann sie leise entfernen. Digitale Artefakte versagen auf andere Weise. Sie hängen von Infrastruktur ab, die im Laufe der Zeit degradiert. Frameworks ändern sich ständig. CDNs brechen. APIs werden als veraltet markiert. Paketmanager werden unzugänglich.
Dieses Muster könnte als „Komplexitätstheater" bezeichnet werden – ausgefeilte architektonische Entscheidungen, die für Herausforderungen auf Unternehmensebene entwickelt wurden und auf Forschungsartefakte angewendet werden, die Langlebigkeit statt Skalierbarkeit erfordern. Die Infrastruktur ist beeindruckend. Das Tooling ist aufwendig. Aber für Archivierungszwecke wird die Komplexität zur Schwachstelle.
Die digitale Erhaltungsgemeinschaft hat längst erkannt, dass Replikation vor institutionellem Versagen schützt. Stanfords LOCKSS-Programm („Lots of Copies Keep Stuff Safe") war Pionier bei verteilten Erhaltungsnetzwerken für akademische Zeitschriften und demonstrierte, dass geografisch verteilte Kopien unter unabhängiger Verwaltung einen robusten Schutz gegen Inhaltsverlust bieten. Diese Systeme erfordern jedoch koordinierte institutionelle Infrastruktur – vernetzte Repositorien, automatisierte Audit-Protokolle und dauerhaftes organisatorisches Engagement.
Eine Zero-Dependency-Architektur kehrt dieses Modell um. Anstatt dass Institutionen Kopien durch aktive Kuratierung pflegen, ermöglicht die in sich geschlossene Portabilität des Artefakts eine reibungslose Verteilung. Die Erhaltungsstrategie verschiebt sich von der Verwahrung zur Replikation. Eine einzelne HTML-Datei kann unbegrenzt kopiert werden. Redundante Speicherung ist einfach. Das Öffnen der Datei erfordert keine Installation. Eine Netzwerkverbindung ist optional. Physische Typusexemplare sind fragil, weil sie nicht dupliziert werden können. Framework-abhängige Visualisierungen sind fragil, weil sie nicht als funktionierende Objekte dupliziert werden können. Zero-Dependency-Artefakte überleben durch die Verteilung selbst.
Es gibt kein einzelnes Exemplar zu schützen. Die Datei fungiert als Referenzartefakt. Jede Kopie bleibt vollständig. Verteilung ist die Verteidigung.
Dieser Ansatz wendet Fernand Braudels Konzept der langfristigen Dauer (longue durée) auf die digitale Erhaltung an und rahmt die Arbeit in Jahrhunderten statt in Quartalszyklen. Indem man über vergängliche Frameworks und architektonische Trends hinaussieht, bleibt der Fokus auf dauerhaften Web-Standards – der infrastrukturellen Schicht, die technologische Wechsel überlebt.
Für den Michigan-Cannabis-Marktdatensatz war die Designbeschränkung explizit: Das vollständige interaktive Paper muss als einzelne HTML-Datei laufen, die lokal in einem Standardbrowser geöffnet wird. Das Artefakt muss offline funktionieren, ohne Installationsschritte und ohne externe Anfragen.
Der Datensatz ist unter Verwendung einer domänenspezifischen Ontologie strukturiert, die auf Kompaktheit optimiert ist – mehrere Jahre regulatorischer Daten mit insgesamt 34 KB durch konsistentes Schema-Design. Jedes monatliche Update löst aus, dass das Dokument seine eigenen narrativen Abschnitte neu schreibt, Zusammenfassungen regeneriert und Visualisierungen aus der eingebetteten Datennutzlast aktualisiert.
Die „evergreen"-Architektur
Die Lösung basiert auf einem Muster, das ich „Gojira & Gamera" nenne. Es trennt die Daten-Payload vom Visualisierungsmotor, hält beide im DOM, aber unterscheidet sie logisch klar voneinander.
1. Gojira (die Daten-Engine)
Anstatt Daten aus einer externen Quelle oder einer CSV-Datei zu laden, wird der gesamte Datensatz direkt in das HTML eingebettet, als vorhydratisierte JSON-Struktur. Damit entfallen asynchrone Ladezustände und Netzwerklatenz vollständig.
// Example of the "Gojira" embedded data structure
const rawData = [
["10/1/2019", "Oct", 2019, "$28,594,402", ...],
["11/1/2019", "Nov", 2019, "$26,628,235", ...],
// ... 60+ months of data
];
Listing 1: Strategie zur Dateneinbettung. Die Roh-Array-Struktur bindet den vollständigen Datensatz in das DOM ein und eliminiert Fetch-Anfragen.
2. Gamera (die Visualisierungslogik)
Die Anwendungslogik verwendet eine IIFE (Immediately Invoked Function Expression), um den Zustand zu kapseln und den globalen Namensraum nicht zu verschmutzen. Sie setzt auf „Vanilla" JavaScript zur direkten DOM-Manipulation und vermeidet so den Overhead eines Virtual DOM, der bei komplexen Frameworks üblich ist.
Listing 2: Kapselung des Geltungsbereichs. Dieses Design schafft einen sicheren, gekapselten Ausführungskontext für die Logik.
Für die Visualisierungsschicht nutzt das Projekt Chart.js. Um die Vorgabe „zero dependency" strikt einzuhalten, wird die Bibliothek nicht als entfernte Ressource behandelt, die zur Laufzeit geladen wird, sondern als versiegelter Bestandteil des Dokuments. Technisch ist das „vendoring": Der Quellcode wurde minifiziert und direkt eingebettet, sodass der Visualisierungsmotor wie eine unveränderliche Infrastruktur funktioniert, entkoppelt von Paketmanagern oder CDNs.
3. Zero-dependency Styling
Die Architektur verwendet CSS Custom Properties für das Theme. Dadurch kann zwischen Dark- und Light-Mode instantan umgeschaltet werden, indem lediglich ein Attribut geändert wird, ohne externe CSS-Bibliotheken zu laden oder zu parsen.
Leistung und „lebendes" Verhalten
Bei sauberer Architektur kann ein Ansatz auf Basis nativen ECMAScript komplexe Frameworks für „evergreen"-Artefakte übertreffen, in denen sich die Erzählung dynamisch weiterentwickelt, während der Datensatz wächst.
Im Gegensatz zu einem statischen Bericht funktioniert dieses Dokument als Zustandsmaschine. Nach dem Laden der eingebetteten JSON-Payload führt die Seite eine Art „Selbstprüfung" aus: Sie berechnet Zeitdauern neu (z. B. „6-Jahres-Trends" → „7-Jahres-Trends"), aktualisiert das Zitierjahr und passt zusammenfassende Kennzahlen im DOM-Text an. Weil diese Logik linear ausgeführt wird, ohne Hydration-Schichten und ohne Virtual-DOM-Diff, erreicht das Dokument einen schnellen initialen Paint (FCP) und nahezu unmittelbare Interaktivität, selbst wenn der Datensatz größer wird.
Catchpoint Synthetic Monitoring Berichte liefern kontrollierte, wiederholbare Leistungsmessungen von ihren globalen Testknoten unter standardisierten Bedingungen (100 ms Latenz, 5 Mbps Durchsatz). Diese Labor-grad-Metriken – inklusive Start Render, First Contentful Paint und Total Blocking Time – validieren die Sub‑Sekunden‑Rendering‑Leistung des Artefakts in einer konsistenten Testumgebung und bieten so einen reproduzierbaren Maßstab, der sich von der Variabilität echter Nutzerdaten abhebt.
Performanceanalysen wurden auf dem Produktions-Build durchgeführt, um die Optimierungsstrategie zu bewerten. Die Ergebnisse bestätigen die Stabilitätsziele, machen aber auch den inhärenten Trade-off einer monolithischen Bauweise sichtbar:
Dieses Artefakt ist eine funktionale Vorlage. Um es zu forken: Speichern Sie die einzelne HTML-Seite, aktualisieren Sie dann den <title>-Tag und ersetzen Sie die domänenspezifischen Inhalte durch Ihre eigenen. Im Gegensatz zu Frameworks, die Integration erfordern, funktioniert dies durch direkte Ableitung: Jedes neue Artefakt beginnt als Kopie dieser vollständigen, eigenständigen Referenz.
Snapshot:2026-01-06(Produktions-Build)
0.496s
Start Render
0.8s
First Contentful Paint
0.761s
Largest Contentful Paint
0.761s
Speed Index
0.099s
Total Blocking Time
0.002
Cumulative Layout Shift
250KB
Page Weight
0.834s
DC Time
250KB
DC Bytes
0.984s
Total Time
Abbildung 1a: Catchpoint‑Leistungsmetriken für das Artefakt, erfasst vom Produktions‑Deployment mit Zeitmessungen auf realen Geräten und Netzwerken.
100
Leistung (PSI)
100
Barrierefreiheit
100
Bewährte Verfahren
100
SEO
Figure 1b: Google PageSpeed Insights (PSI), Momentaufnahme 2026-01-06. Dieser Wert spiegelt die reale Leistung für die meisten Nutzer auf durchschnittlichen Geräten und in durchschnittlichen Netzwerken wider.
Grenzen: die 5-MB-Obergrenze
Dieses System priorisiert Stabilität und langfristige Bewahrung gegenüber der Skalierung, die für große transaktionale Anwendungen oder kontinuierliche Datenströme erforderlich ist. Es ist für typische wissenschaftliche Publikationen gedacht, bei denen Datensätze überschaubar bleiben, aber zuverlässige Langlebigkeit verlangen.
Die Architektur ist als eine einzelne „zero dependency"-HTML-Datei implementiert. Diese Entscheidung führt zu einer praktischen Obergrenze von ungefähr 5 MB, ab der die Nutzererfahrung durch Download-Latenz sowie Parsing- und Initialisierungskosten leidet. Innerhalb dieser Grenze bleibt die Performance vorhersagbar und gut steuerbar.
Diese Architektur ist für Forschungsworkflows mit einem einzelnen Autor konzipiert, nicht für kollaborative Teamentwicklung. Die monolithische Struktur verhindert die Arbeitsteilung, die typisch für moderne Webentwicklung ist - wo CSS-Spezialisten, JavaScript-Entwickler, Backend-Ingenieure und Content-Autoren parallel an separaten Dateien arbeiten, die durch Build-Prozesse zusammengeführt werden. Digitale Paratypen tauschen kollaborative Infrastruktur gegen archivistische Unabhängigkeit.
Diese Einschränkung ermöglicht jedoch eine andere Form der Zusammenarbeit: abgeleitete Wiederverwendung. Das Artefakt kann kopiert, modifiziert und für neue Arbeiten geforkt werden, ohne institutionelle Genehmigung oder Infrastrukturabhängigkeiten. Die eingebetteten Daten können extrahiert und wiederverwendet werden. Ein digitaler Paratyp kann geforkt werden, um neue unabhängige Artefakte zu erstellen - jedes vollständig und funktional, ohne Koordination mit dem ursprünglichen Autor. Dies unterscheidet sich von kollaborativen Plattformen, wo der Datenzugriff von laufender institutioneller Unterstützung und Server-Infrastruktur abhängt.
Mathematische Projektionen
Die Lizenzarchitektur schafft vorhersehbare Einschränkungen. Die Datenstruktur ist schlank und zweckgebaut. Der Datensatz wächst mit etwa 5,3 KB pro Jahr. Mit einer 34-KB-Nutzlast, die sieben Jahre Produktionsdaten repräsentiert, und einer 5-MB-Obergrenze kann die Architektur jahrhundertelang leistungsfähig bleiben, weit über das angegebene 20-Jahres-Archivierungsziel hinaus.
Werte
Mathematik
Aktuelle Nutzlastgröße
34 KB
Jährliche Wachstumsrate
≈5,3 KB/Jahr
Obergrenze (praktisches Limit)
5 MB
Jahre bis zur Obergrenze
≈900 Jahre
Größe nach 20 Jahren
≈140 KB
Abgeleitet aus Michigan CRA-Daten
Quelle: Michigan Digital Paratype archive index (74 Monate, Oktober 2019–November 2025).
Fazit
Diese Arbeit zeigt, dass eine Zero-Dependency-HTML-Publikation in einer einzigen Datei interaktive Datenspeicherung und Multi-Serien-Visualisierung unterstützen kann, während die langfristigen Betriebsanforderungen minimiert werden. Durch die Einbettung des Datensatzes und das Vendoring des Visualisierungscodes bleibt das Artefakt offline ausführbar und vermeidet Fehlermodi, die mit externer Infrastruktur verbunden sind.
Diese Arbeit demonstriert eine scheinbar neuartige Dokumentarchitektur: Artefakte, die ihre eigene Analyse aus eingebetteten Daten regenerieren. Während eigenständige HTML-Dokumente und ausführbare Forschungskompendia getrennt existieren, wurden keine Beispiele gefunden, die Zero-Dependency-Ausführung mit selbstmodifizierender Narrativgenerierung kombinieren. Die Michigan-Cannabis-Analyse enthält die vollständige Logik, um ihre narrativen Abschnitte neu zu schreiben, wenn neue monatliche Daten eingefügt werden. Jede Version kann die nächste Version produzieren. Dies ist keine traditionelle reproduzierbare Forschung, bei der externe Benutzer Ergebnisse durch erneutes Ausführen von Code überprüfen. Dies ist Selbstmodifikation durch Design; bei der das Dokument seine eigene Kohärenz durch Ausführung aufrechterhält.
Die Implikationen gehen über technische Neuheit hinaus. Wenn Dokumente den Prozess ihrer eigenen Regeneration enthalten können, werden sie zu digitalen Paratypen in einem tieferen Sinn, als die taxonomische Metapher suggeriert. Sie bewahren nicht nur Inhalte, sondern die Maschinerie der Autorenschaft selbst. Jede verteilte Kopie ist eine vollständige, funktionale Replik, die zukünftige Iterationen produzieren kann.
Der Ansatz ist für bescheidene bis mittlere Datensätze gedacht, bei denen Haltbarkeit und Reproduzierbarkeit Vorrang vor großflächigem Streaming, komplexer Authentifizierung oder schnellem Feature-Wechsel haben. Innerhalb der oben beschriebenen praktischen Dateigrößenobergrenze kann ein monolithisches HTML-Artefakt als stabile, zitierbare Schnittstelle für Längsschnittforschung und Archivverteilung fungieren. Mit 325 KB für 74 Monate Daten demonstriert dieser Ansatz Bewahrung durch virale Verteilung statt institutioneller Verwahrung. Das Artefakt überlebt durch Kopieren, nicht durch Schutz.
Für Daten, die persistieren müssen, bleibt Verteilung die Verteidigung. Dies ist eine funktionierende Implementierung, kein Vorschlag. Die Methodologie wird demonstriert unter https://tjid3.org/.
El archivo de 20 años: Una Arquitectura Sin Dependencias para Paratipos DigitalesEl archivo de 20 años | Paratipos Digitales
Resumen
Esta nota técnica describe una forma práctica de publicar conjuntos de datos y visualizaciones como un único archivo HTML duradero que se ejecuta sin conexión. La implementación utiliza estándares nativos del navegador, solo Vanilla JavaScript (ECMAScript estándar) y CSS3. Integra todo el código de visualización en el documento. El conjunto de datos se almacena en línea, eliminando llamadas fetch y dependencias externas. Tomando prestado de la taxonomía: si el holotipo digital es el conjunto de datos sin procesar, esto describe un "paratipo digital", empaquetando análisis y figuras junto con datos en un único archivo de archivo. La metodología se demuestra en la Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297) un conjunto de datos económicos longitudinales de 74 meses.
A diferencia de un PDF estático, el documento se reescribe a sí mismo en tiempo de carga, recalculando duraciones, actualizando etiquetas y actualizando texto resumido a partir de datos embebidos. Esto mantiene la narrativa alineada a medida que el conjunto de datos crece. El flujo de trabajo "evergreen" significa que reemplazar la carga útil JSON mensual activa un recálculo automático sin reconstrucciones. El mismo enfoque admite publicación multilingüe; se agregaron seis idiomas sin API. Las validaciones de rendimiento muestran fuerte interactividad y accesibilidad en dispositivos típicos. Los modelos de crecimiento estándar sugieren que la operabilidad multisecular es matemáticamente posible.
A diferencia de los especímenes físicos que requieren protección contra daños, estos artefactos digitales sobreviven a través de la distribución. La estrategia de preservación cambia de la custodia a la replicación. Con 325 KB para siete años de datos, el artefacto funciona como "datos virales"; distribuible por correo electrónico, memorias USB o alojamiento web mientras permanece completamente autocontenido.
Este artículo metodológico describe una arquitectura HTML automodificable demostrada en el Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297), un conjunto de datos económicos longitudinales que rastrea 74 meses de datos regulatorios. El artefacto ejecuta su propio código para regenerar secciones narrativas cada vez que se agregan nuevos datos, manteniendo la alineación entre el análisis y la evidencia sin procesos de construcción externos.
Esto no es ni una página web estática, ni una aplicación web, ni código automodificable en el sentido tradicional. Es un archivo HTML único que, al abrirse, ejecuta código para reescribir sus propias secciones narrativas a partir de datos integrados, generando resúmenes actuales, conclusiones y texto analítico basados en el estado actual del conjunto de datos. Esta es una categoría que aún no tiene nombre. Tomando prestado de la nomenclatura taxonómica, estos se denominan paratipos digitales.
Los conjuntos de datos longitudinales a menudo conservan valor científico durante décadas. Las visualizaciones interactivas y sus cargas de datos que las acompañan a menudo no lo hacen. Muchos despliegues web modernos dependen de cadenas de herramientas en capas, pipelines de construcción, CDN y paquetes versionados que pueden desaparecer o volverse difíciles de reproducir con el tiempo. Cuando una visualización está estrechamente acoplada a esa pila de herramientas, la investigación puede permanecer intacta mientras que la interfaz se vuelve inutilizable. Este es un riesgo de archivo: el registro aún existe, pero el instrumento para explorarlo no puede ejecutarse de manera confiable en el futuro.
Los archivos físicos pueden perderse por el fuego. El daño por agua puede borrarlos. La guerra puede destruirlos. La simple attrición puede eliminarlos, silenciosamente. Los artefactos digitales fallan de manera diferente. Dependen de infraestructura que se degrada con el tiempo. Los frameworks cambian constantemente. Los CDN se rompen. Las API quedan obsoletas. Los gestores de paquetes se vuelven inaccesibles.
Este patrón podría denominarse "teatro de la complejidad", opciones arquitectónicas sofisticadas diseñadas para desafíos a escala empresarial aplicadas a artefactos de investigación que requieren longevidad sobre escalabilidad. La infraestructura es impresionante. Las herramientas son elaboradas. Pero para propósitos de archivo, la complejidad se convierte en la vulnerabilidad.
La comunidad de preservación digital ha reconocido durante mucho tiempo que la replicación protege contra el fracaso institucional. El programa LOCKSS de Stanford ("Lots of Copies Keep Stuff Safe") fue pionero en redes de preservación distribuidas para revistas académicas, demostrando que las copias geográficamente dispersas bajo administración independiente proporcionan una defensa robusta contra la pérdida de contenido. Sin embargo, estos sistemas requieren infraestructura institucional coordinada: repositorios en red, protocolos de auditoría automatizados y compromiso organizacional persistente.
Una arquitectura de cero dependencias invierte este modelo. En lugar de que las instituciones mantengan copias mediante curación activa, la portabilidad autónoma del artefacto permite una distribución sin fricción. La estrategia de preservación cambia de custodia a replicación. Un solo archivo HTML puede copiarse indefinidamente. El almacenamiento redundante es fácil. Abrir el archivo no requiere instalación. Una conexión de red es opcional. Los especímenes tipo físicos son frágiles porque no pueden duplicarse. Las visualizaciones dependientes de frameworks son frágiles porque no pueden duplicarse como objetos funcionales. Los artefactos de cero dependencias sobreviven a través de la distribución misma.
No hay un solo espécimen que proteger. El archivo funciona como el artefacto de referencia. Cada copia permanece completa. La distribución es la defensa.
Este enfoque aplica el concepto de la longue durée de Fernand Braudel a la preservación digital, enmarcando el trabajo en siglos en lugar de ciclos trimestrales. Al mirar más allá de los frameworks transitorios y las tendencias arquitectónicas, el enfoque permanece en los estándares web duraderos—la capa infraestructural que sobrevive a los cambios tecnológicos.
Para el conjunto de datos del mercado de Cannabis de Michigan, la restricción de diseño fue explícita: el artículo interactivo completo debe ejecutarse como un solo archivo HTML abierto localmente en un navegador estándar. El artefacto debe funcionar sin conexión, sin pasos de instalación y sin solicitudes externas.
El conjunto de datos está estructurado utilizando una ontología específica del dominio optimizada para la compacidad: varios años de datos regulatorios que totalizan 34 KB mediante un diseño de esquema consistente. Cada actualización mensual activa el documento para reescribir sus propias secciones narrativas, regenerando resúmenes y actualizando visualizaciones a partir de la carga de datos integrada.
La arquitectura «evergreen»
La solución se apoya en un patrón que llamo «Gojira & Gamera». Separa la carga útil de datos del motor de visualización, manteniendo ambos en el DOM, pero distinguiéndolos con claridad a nivel lógico.
1. Gojira (el motor de datos)
En lugar de recuperar datos desde una fuente externa o un archivo CSV, el conjunto de datos completo se integra directamente en el HTML como una estructura JSON prehidratada. Esto elimina por completo estados de carga asíncronos y la latencia de red.
// Example of the "Gojira" embedded data structure
const rawData = [
["10/1/2019", "Oct", 2019, "$28,594,402", ...],
["11/1/2019", "Nov", 2019, "$26,628,235", ...],
// ... 60+ months of data
];
Listado 1: Estrategia de incrustación de datos. La estructura de arreglo sin procesar inyecta el conjunto de datos completo en el DOM, eliminando las solicitudes de fetch.
2. Gamera (la lógica de visualización)
La lógica de la aplicación utiliza una IIFE (Immediately Invoked Function Expression) para encapsular el estado y evitar contaminar el espacio de nombres global. Se apoya en JavaScript "Vanilla" para manipular el DOM directamente, evitando la sobrecarga del Virtual DOM típica de frameworks complejos.
Listado 2: Encapsulación del alcance. Este diseño crea un contexto de ejecución seguro y encapsulado para la lógica.
Para la capa de visualización, el proyecto utiliza Chart.js. Para cumplir estrictamente el requisito de "zero dependency", la biblioteca no se trata como un recurso remoto que se descarga, sino como un bloque sellado dentro del documento. Técnicamente, esto es "vendoring": el código fuente se minificó y se integró directamente, de modo que el motor de visualización funcione como una infraestructura inmutable, diseñada para sobrevivir a gestores de paquetes o CDNs.
Estilo "zero dependency"
La arquitectura utiliza propiedades personalizadas de CSS (CSS Custom Properties) para el tema. Esto permite alternar de forma instantánea entre modo oscuro y modo claro mediante un simple cambio de atributo, sin cargar ni parsear ninguna biblioteca CSS externa.
Rendimiento y comportamiento "vivo"
Cuando se diseña correctamente, un enfoque basado en ECMAScript nativo puede superar a frameworks complejos para artefactos "evergreen", donde el relato evoluciona dinámicamente a medida que crece el conjunto de datos.
A diferencia de un informe estático, este documento funciona como un motor de estado. Al cargar la carga útil JSON integrada, la página ejecuta una "autoauditoría": recalcula duraciones (por ejemplo, "tendencias de 6 años" → "tendencias de 7 años"), actualiza el año de cita y refresca estadísticas de resumen en el texto del DOM. Como esta lógica se ejecuta de forma lineal, sin capas de hidratación ni diff de Virtual DOM, el documento logra un primer pintado rápido (FCP) y una interactividad casi inmediata, incluso cuando el conjunto de datos aumenta.
Los informes de monitoreo sintético de Catchpoint proporcionan mediciones de rendimiento controladas y repetibles desde sus nodos de prueba globales bajo condiciones estandarizadas (100 ms de latencia, 5 Mbps de ancho de banda). Estas métricas de grado laboratorio, que incluyen inicio de renderizado, primera pintura con contenido y tiempo total de bloqueo, validan el rendimiento de renderizado en menos de un segundo del artefacto en un entorno de prueba consistente, ofreciendo un punto de referencia reproducible distinto de la variabilidad de usuarios reales.
Se realizaron análisis de rendimiento sobre el build de producción para evaluar la estrategia de optimización. Los resultados confirman los objetivos de estabilidad, pero también destacan la compensación inherente a un diseño monolítico:
Este artefacto es una plantilla funcional. Para bifurcarlo (*fork*): guarda la única página HTML, luego actualiza la etiqueta <title> y reemplaza el contenido específico del dominio con el tuyo. A diferencia de los *frameworks* que requieren integración, esto funciona por derivación directa: cada nuevo artefacto comienza como una copia de esta referencia completa e independiente.
Instantánea:2026-01-06 (build de producción)
0.496s
Inicio de renderizado
0.8s
Primer pintado con contenido
0.761s
Mayor pintado con contenido
0.761s
Índice de velocidad
0.099s
Tiempo de bloqueo total
0.002
Desplazamiento acumulado de diseño
250KB
Peso de página
0.834s
Tiempo DC
250KB
Bytes DC
0.984s
Tiempo total
Figura 1a: Métricas de rendimiento de Catchpoint para el artefacto, capturadas desde el despliegue en producción con mediciones de tiempo en dispositivos y redes reales.
100
Rendimiento (PSI)
100
Accesibilidad
100
Mejores prácticas
100
SEO
Figura 1b: Google PageSpeed Insights (PSI), instantánea 2026-01-06 Este puntaje refleja el rendimiento en condiciones reales para la mayoría de los usuarios en dispositivos y redes promedio.
Límites: el techo de 5 MB
Este sistema prioriza la estabilidad y la preservación a largo plazo por encima de la escalabilidad necesaria para aplicaciones transaccionales grandes o flujos de datos continuos. Está diseñado para usos típicos de publicación científica, donde los conjuntos de datos se mantienen modestos, pero requieren longevidad fiable.
La arquitectura se implementa como un único archivo HTML "zero dependency". Esta decisión introduce un techo práctico de aproximadamente 5 MB, por encima del cual la experiencia de usuario disminuye debido a la latencia de descarga y al coste de análisis/parsing. Dentro de esta restricción, el rendimiento se mantiene predecible y manejable.
Esta arquitectura está diseñada para flujos de trabajo de investigación de un solo autor, no para desarrollo colaborativo en equipo. La estructura monolítica previene la división del trabajo típica del desarrollo web moderno - donde especialistas en CSS, desarrolladores JavaScript, ingenieros backend y redactores de contenido trabajan en paralelo en archivos separados fusionados a través de procesos de construcción. Los paratipos digitales intercambian infraestructura colaborativa por independencia archivística.
Sin embargo, esta restricción habilita una forma diferente de colaboración: reutilización derivada. El artefacto puede ser copiado, modificado y bifurcado para nuevos trabajos sin permiso institucional ni dependencias de infraestructura. Los datos embebidos pueden ser extraídos y reutilizados. Un paratipo digital puede ser bifurcado para crear nuevos artefactos independientes - cada uno completo y funcional, sin requerir coordinación con el autor original. Esto difiere de las plataformas colaborativas, donde el acceso a datos depende de soporte institucional continuo e infraestructura de servidor.
Proyecciones Matemáticas
La arquitectura de licencia crea restricciones predecibles. La estructura de datos es ligera y construida con un propósito específico. El conjunto de datos crece aproximadamente 5,3 KB por año. Con una carga útil de 34 KB que representa siete años de datos de producción y un techo de 5 MB, la arquitectura puede permanecer eficiente durante siglos, mucho más allá del objetivo de archivo declarado de 20 años.
Valores
Matemáticas
Tamaño actual de carga útil
34 KB
Tasa de crecimiento anual
≈5,3 KB/año
Techo (límite práctico)
5 MB
Años hasta el techo
≈900 años
Tamaño a 20 años
≈140 KB
Derivado de datos CRA de Michigan
Fuente: Michigan Digital Paratype archive index (74 meses, octubre 2019–noviembre 2025).
Conclusión
Este trabajo muestra que una publicación HTML de un solo archivo sin dependencias puede admitir almacenamiento de datos interactivo y visualización multiserie mientras minimiza los requisitos operacionales a largo plazo. Al integrar el conjunto de datos y vendorizar el código de visualización, el artefacto permanece ejecutable sin conexión y evita modos de falla asociados con infraestructura externa.
Este trabajo demuestra lo que parece ser una arquitectura documental novedosa: artefactos que regeneran su propio análisis a partir de datos integrados. Si bien los documentos HTML autónomos y los compendia de investigación ejecutables existen por separado, no se encontraron ejemplos que combinen ejecución sin dependencias con generación narrativa auto-modificante. El análisis de Cannabis de Michigan contiene la lógica completa para reescribir sus secciones narrativas cuando se insertan nuevos datos mensuales. Cada versión puede producir la siguiente versión. Esta no es investigación reproducible tradicional, donde usuarios externos verifican resultados volviendo a ejecutar código. Esta es auto-modificación por diseño; donde el documento mantiene su propia coherencia mediante ejecución.
Las implicaciones se extienden más allá de la novedad técnica. Si los documentos pueden contener el proceso de su propia regeneración, se convierten en paratipos digitales en un sentido más profundo de lo que sugiere la metáfora taxonómica. Preservan no solo contenido, sino la maquinaria misma de la autoría. Cada copia distribuida es una réplica completa y funcional capaz de producir iteraciones futuras.
El enfoque está destinado a conjuntos de datos modestos a medianos donde la durabilidad y la reproducibilidad tienen prioridad sobre el streaming a gran escala, la autenticación compleja o la rotación rápida de características. Dentro del límite práctico de tamaño de archivo descrito anteriormente, un artefacto HTML monolítico puede funcionar como una interfaz estable y citable para investigación longitudinal y distribución archivística. Con 325 KB para 74 meses de datos, este enfoque demuestra preservación a través de distribución viral en lugar de custodia institucional. El artefacto sobrevive siendo copiado, no protegido.
Para datos que deben persistir, la distribución sigue siendo la defensa. Esta es una implementación funcional, no una propuesta. La metodología se demuestra en https://tjid3.org/.
O arquivo de 20 anos: Uma Arquitetura Sem Dependências para Parátipos DigitaisO arquivo de 20 anos | Parátipos Digitais
Resumo
Esta nota técnica descreve uma forma prática de publicar conjuntos de dados e visualizações como um único arquivo HTML durável que executa offline. A implementação usa padrões nativos do navegador, apenas Vanilla JavaScript (ECMAScript padrão) e CSS3. Ela integra todo o código de visualização no documento. O conjunto de dados é armazenado inline, eliminando chamadas fetch e dependências externas. Emprestando da taxonomia: se o holótipo digital é o conjunto de dados brutos, isso descreve um "parátipo digital", empacotando análise e figuras junto com dados em um único arquivo de arquivo. A metodologia é demonstrada na Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297), um conjunto de dados econômicos longitudinais de 74 meses.
Ao contrário de um PDF estático, o documento se reescreve no momento do carregamento, recalculando durações, atualizando rótulos e atualizando texto resumido a partir de dados incorporados. Isso mantém a narrativa alinhada à medida que o conjunto de dados cresce. O fluxo de trabalho "evergreen" significa que substituir a carga útil JSON mensal aciona recálculo automático sem reconstruções. A mesma abordagem suporta publicação multilíngue; seis idiomas foram adicionados sem API. Validações de desempenho mostram forte interatividade e acessibilidade em dispositivos típicos. Modelos de crescimento padrão sugerem que operabilidade multissecular é matematicamente possível.
Ao contrário de espécimes físicos que requerem proteção contra danos, esses artefatos digitais sobrevivem através da distribuição. A estratégia de preservação muda de custódia para replicação. Com 325 KB para sete anos de dados, o artefato funciona como "dados virais"; distribuível por e-mail, pen drives ou hospedagem web enquanto permanece completamente autocontido.
Disponibilidade: O artefato ao vivo está acessível em https://tjid3.org/
O contexto: Risco de arquivo
Este artigo metodológico descreve uma arquitetura HTML automodificável demonstrada na Michigan Cannabis Market Analysis (DOI: 10.5281/zenodo.18065297), um conjunto de dados econômicos longitudinais que rastreia 74 meses de dados regulatórios. O artefato executa seu próprio código para regenerar seções narrativas cada vez que novos dados são adicionados, mantendo o alinhamento entre a análise e a evidência sem processos de construção externos.
Isto não é nem uma página web estática, nem uma aplicação web, nem código automodificável no sentido tradicional. É um arquivo HTML único que, ao ser aberto, executa código para reescrever suas próprias seções narrativas a partir de dados integrados, gerando resumos atuais, conclusões e texto analítico baseados no estado atual do conjunto de dados. Esta é uma categoria que ainda não tem nome. Tomando emprestado da nomenclatura taxonômica, estes são denominados parátipos digitais.
Os conjuntos de dados longitudinais frequentemente conservam valor científico durante décadas. As visualizações interativas e suas cargas de dados que as acompanham frequentemente não o fazem. Muitas implementações web modernas dependem de cadeias de ferramentas em camadas, pipelines de construção, CDN e pacotes versionados que podem desaparecer ou tornar-se difíceis de reproduzir com o tempo. Quando uma visualização está fortemente acoplada a essa pilha de ferramentas, a pesquisa pode permanecer intacta enquanto a interface torna-se inutilizável. Este é um risco de arquivo: o registro ainda existe, mas o instrumento para explorá-lo não pode ser executado de forma confiável no futuro.
Os arquivos físicos podem perder-se pelo fogo. Os danos por água podem apagá-los. A guerra pode destruí-los. A simples attrição pode eliminá-los, silenciosamente. Os artefatos digitais falham de maneira diferente. Dependem de infraestrutura que se degrada com o tempo. Os frameworks mudam constantemente. Os CDN quebram. As API tornam-se obsoletas. Os gestores de pacotes tornam-se inacessíveis.
Este padrão poderia denominar-se "teatro da complexidade", opções arquitetônicas sofisticadas projetadas para desafios em escala empresarial aplicadas a artefatos de pesquisa que requerem longevidade sobre escalabilidade. A infraestrutura é impressionante. As ferramentas são elaboradas. Mas para propósitos de arquivo, a complexidade torna-se a vulnerabilidade.
A comunidade de preservação digital reconheceu há muito tempo que a replicação protege contra o fracasso institucional. O programa LOCKSS de Stanford ("Lots of Copies Keep Stuff Safe") foi pioneiro em redes de preservação distribuídas para revistas acadêmicas, demonstrando que as cópias geograficamente dispersas sob administração independente proporcionam uma defesa robusta contra a perda de conteúdo. No entanto, estes sistemas requerem infraestrutura institucional coordenada: repositórios em rede, protocolos de auditoria automatizados e compromisso organizacional persistente.
Uma arquitetura de zero dependências inverte este modelo. Em vez de as instituições manterem cópias mediante curadoria ativa, a portabilidade autônoma do artefato permite uma distribuição sem fricção. A estratégia de preservação muda de custódia para replicação. Um único arquivo HTML pode copiar-se indefinidamente. O armazenamento redundante é fácil. Abrir o arquivo não requer instalação. Uma conexão de rede é opcional. Os espécimes tipo físicos são frágeis porque não podem duplicar-se. As visualizações dependentes de frameworks são frágeis porque não podem duplicar-se como objetos funcionais. Os artefatos de zero dependências sobrevivem através da própria distribuição.
Não há um único espécime a proteger. O arquivo funciona como o artefato de referência. Cada cópia permanece completa. A distribuição é a defesa.
Esta abordagem aplica o conceito de la longue durée de Fernand Braudel à preservação digital, enquadrando o trabalho em séculos em vez de ciclos trimestrais. Ao olhar além dos frameworks transitórios e das tendências arquitetônicas, o foco permanece nos padrões web duráveis—a camada infraestrutural que sobrevive às mudanças tecnológicas.
Para o conjunto de dados do mercado de Cannabis de Michigan, a restrição de design foi explícita: o artigo interativo completo deve executar-se como um único arquivo HTML aberto localmente num navegador padrão. O artefato deve funcionar offline, sem passos de instalação e sem solicitações externas.
O conjunto de dados está estruturado utilizando uma ontologia específica do domínio otimizada para a compacidade: vários anos de dados regulatórios que totalizam 34KB mediante um design de esquema consistente. Cada atualização mensal ativa o documento para reescrever suas próprias seções narrativas, regenerando resumos e atualizando visualizações a partir da carga de dados integrada.
A arquitetura "evergreen"
A solução se apoia em um padrão que chamo de "Gojira & Gamera". Ele separa a carga útil de dados do motor de visualização, mantendo ambos no DOM, mas distinguindo-os claramente no plano lógico.
1. Gojira (o motor de dados)
Em vez de buscar dados de uma fonte externa ou de um arquivo CSV, o conjunto de dados completo é incorporado diretamente no HTML como uma estrutura JSON pré-hidratada. Isso elimina estados de carregamento assíncronos и a latência de rede.
// Example of the "Gojira" embedded data structure
const rawData = [
["10/1/2019", "Oct", 2019, "$28,594,402", ...],
["11/1/2019", "Nov", 2019, "$26,628,235", ...],
// ... 60+ months of data
];
Listagem 1: Estratégia de incorporação de dados. A estrutura bruta do array injeta o conjunto de dados completo no DOM, eliminando requisições de fetch.
2. Gamera (a lógica de visualização)
A lógica da aplicação usa uma IIFE (Immediately Invoked Function Expression) para encapsular o estado e evitar poluir o namespace global. Ela se apoia em JavaScript "Vanilla" para manipular o DOM diretamente, evitando a sobrecarga do Virtual DOM típica de frameworks complexos.
Listagem 2: Encapsulamento de escopo. Este design cria um contexto de execução seguro e encapsulado para a lógica.
Para a camada de visualização, o projeto utiliza Chart.js. Para cumprir estritamente o requisito de "zero dependency", a biblioteca não é tratada como um recurso remoto a ser baixado, mas como um bloco selado dentro do documento. Tecnicamente, isso é "vendoring": o código-fonte foi minificado e incorporado diretamente, de modo que o motor de visualização funcione como uma infraestrutura imutável, projetada para sobreviver a gerenciadores de pacotes ou CDNs.
Estilo "zero dependency"
A arquitetura utiliza propriedades personalizadas de CSS (CSS Custom Properties) para o tema. Isso permite alternar instantaneamente entre modo escuro e modo claro por meio de uma simples mudança de atributo, sem carregar nem analisar nenhuma biblioteca CSS externa.
Desempenho e comportamento "vivo"
Quando bem arquitetado, um enfoque baseado em ECMAScript nativo pode superar frameworks complexos para artefatos "evergreen", onde a narrativa evolui dinamicamente à medida que o conjunto de dados cresce.
Ao contrário de um relatório estático, este documento funciona como um motor de estado. Ao carregar a carga útil JSON incorporada, a página realiza uma "autoauditoria": recalcula durações (por exemplo, "tendências de 6 anos" → "tendências de 7 anos"), atualiza o ano de citação e renova estatísticas de resumo no texto do DOM. Como essa lógica executa de forma linear, sem camadas de hidratação e sem diff de Virtual DOM, o documento atinge um primeiro paint rápido (FCP) e uma interatividade quase imediata, mesmo quando o conjunto de dados aumenta.
Os relatórios de Monitorização Sintética da Catchpoint fornecem medições de desempenho controladas e repetíveis a partir dos seus nós de teste globais, em condições padronizadas (latência de 100 ms, largura de banda de 5 Mbps). Estas métricas de grau laboratorial — incluindo início de renderização, primeira pintura com conteúdo e tempo total de bloqueio — validam o desempenho de renderização em menos de um segundo do artefacto num ambiente de teste consistente, oferecendo um referencial reproduzível distinto da variabilidade de utilizadores reais.
Foram realizadas análises de desempenho no build de produção para avaliar a estratégia de otimização. Os resultados confirmam as metas de estabilidade, mas também evidenciam a compensação inerente a um design monolítico:
Este artefato é um modelo funcional. Para bifurcá-lo (*fork*): salve a página HTML única, atualize a tag <title> e substitua o conteúdo específico do domínio pelo seu próprio. Diferente de *frameworks* que exigem integração, isso funciona por derivação directa: cada novo artefato começa como uma cópia desta referência completa e autónoma.
Snapshot: 2026-01-06 (build de produção)
0.496s
Início da renderização
0.8s
Primeira pintura com conteúdo
0.761s
Maior pintura com conteúdo
0.761s
Índice de velocidade
0.099s
Tempo total de bloqueio
0.002
Deslocamento acumulado de layout
250KB
Peso da página
0.834s
Tempo DC
250KB
Bytes DC
0.984s
Tempo total
Figura 1a: Métricas de desempenho da Catchpoint para o artefacto, capturadas a partir da implementação em produção com temporização em dispositivos e redes reais..
100
Desempenho (PSI)
100
Acessibilidade
100
Boas práticas
100
SEO
Figura 1b: Google PageSpeed Insights (PSI), instantâneo 2026-01-06. Esta pontuação reflete o desempenho no mundo real para a maioria dos usuários em dispositivos e redes médios.
Limites: o teto de 5 MB
Este sistema prioriza estabilidade e preservação de longo prazo em vez da escalabilidade exigida por aplicações transacionais grandes ou fluxos de dados contínuos. Ele foi projetado para usos típicos de publicação científica, nos quais os conjuntos de dados permanecem modestos, mas exigem longevidade confiável.
A arquitetura é implementada como um único arquivo HTML "zero dependency". Essa decisão introduz um teto prático de aproximadamente 5 MB, acima do qual a experiência do usuário se deteriora devido à latência de download e ao custo de análise/parsing. Dentro dessa restrição, o desempenho permanece previsível e administrável.
Esta arquitetura é projetada para fluxos de trabalho de pesquisa de um único autor, não para desenvolvimento colaborativo em equipe. A estrutura monolítica impede a divisão de trabalho típica do desenvolvimento web moderno - onde especialistas em CSS, desenvolvedores JavaScript, engenheiros backend e redatores de conteúdo trabalham em paralelo em arquivos separados fundidos através de processos de construção. Parátipos digitais trocam infraestrutura colaborativa por independência arquivística.
No entanto, esta restrição habilita uma forma diferente de colaboração: reutilização derivada. O artefato pode ser copiado, modificado e bifurcado para novos trabalhos sem permissão institucional nem dependências de infraestrutura. Os dados incorporados podem ser extraídos e reutilizados. Um parátipo digital pode ser bifurcado para criar novos artefatos independentes - cada um completo e funcional, sem exigir coordenação com o autor original. Isto difere de plataformas colaborativas, onde o acesso a dados depende de suporte institucional contínuo e infraestrutura de servidor.
Projeções Matemáticas
A arquitetura de licenciamento cria restrições previsíveis. A estrutura de dados é enxuta e construída com propósito específico. O conjunto de dados cresce aproximadamente 5,3 KB por ano. Com uma carga útil de 34 KB representando sete anos de dados de produção e um teto de 5 MB, a arquitetura pode permanecer performática por séculos, muito além do objetivo de arquivamento declarado de 20 anos.
Valores
Matemática
Tamanho atual da carga útil
34 KB
Taxa de crescimento anual
≈5,3 KB/ano
Teto (limite prático)
5 MB
Anos até o teto
≈900 anos
Tamanho em 20 anos
≈140 KB
Derivado de dados CRA de Michigan
Fonte: Michigan Digital Paratype archive index (74 meses, outubro 2019–novembro 2025).
Conclusão
Este trabalho mostra que uma publicação HTML de arquivo único sem dependências pode suportar armazenamento de dados interativo e visualização multissérie enquanto minimiza requisitos operacionais de longo prazo. Ao integrar o conjunto de dados e vendorizar o código de visualização, o artefato permanece executável offline e evita modos de falha associados à infraestrutura externa.
Este trabalho demonstra o que parece ser uma arquitetura documental nova: artefatos que regeneram sua própria análise a partir de dados integrados. Embora documentos HTML autônomos e compêndios de pesquisa executáveis existam separadamente, nenhum exemplo foi encontrado combinando execução sem dependências com geração narrativa auto-modificante. A análise de Cannabis de Michigan contém a lógica completa para reescrever suas seções narrativas quando novos dados mensais são inseridos. Cada versão pode produzir a próxima versão. Esta não é pesquisa reproduzível tradicional, onde usuários externos verificam resultados executando o código novamente. Esta é auto-modificação por design; onde o documento mantém sua própria coerência através da execução.
As implicações se estendem além da novidade técnica. Se documentos podem conter o processo de sua própria regeneração, eles se tornam parátipos digitais em um sentido mais profundo do que a metáfora taxonômica sugere. Eles preservam não apenas conteúdo, mas a própria maquinaria da autoria. Cada cópia distribuída é uma réplica completa e funcional capaz de produzir iterações futuras.
A abordagem é destinada a conjuntos de dados modestos a médios onde durabilidade e reprodutibilidade têm precedência sobre streaming em larga escala, autenticação complexa ou rotação rápida de recursos. Dentro do teto prático de tamanho de arquivo descrito acima, um artefato HTML monolítico pode funcionar como uma interface estável e citável para pesquisa longitudinal e distribuição arquivística. Com 325 KB para 74 meses de dados, esta abordagem demonstra preservação através de distribuição viral em vez de custódia institucional. O artefato sobrevive sendo copiado, não protegido.
Para dados que devem persistir, a distribuição permanece a defesa. Esta é uma implementação funcional, não uma proposta. A metodologia é demonstrada em https://tjid3.org/.