Thank you for your interest in contributing to Rosetta HTM™. This is a proprietary research platform, but I welcome substantive scholarly engagement through several channels.
Open a GitHub Issue for any of the following:
- Bug reports — something doesn't render, the Auto-Cracker hangs, a validation score is computed incorrectly, etc.
- New academic papers to add to the Published Hypotheses Library — if you've published or know of an Indus / Linear A / Proto-Elamite / etc. decipherment paper that should be in the Library, open an issue with the full citation and a brief description of the camp it belongs to and the key sign assignments.
- Counter-citations — if a published paper empirically refutes a claim already in the Library (analogous to how Fuls 2023 refutes Mukhopadhyay's pure-logographic claim), open an issue describing the refutation and the evidence so it can be recorded properly.
- Cross-script findings — if a paper applies to multiple Script Packs (e.g., Facchetti's Linear A morphemes, Daggumati & Revesz's CNN+SVM cross-script analysis), open an issue describing the cross-script nexus.
- Documentation suggestions — clarifications, factual corrections, better framing of the honest-limits material.
- Feature suggestions — particularly for new validation modes (a "Fuls Constraint Check" is on the roadmap), new Honesty Tests, or new Script Packs.
Because this is a proprietary single-file HTML platform with a particular architectural philosophy, please open an Issue first to discuss any substantial change before submitting a pull request. PRs that don't have a prior discussion thread may be closed without review — not from rudeness, but because integrating changes into a single 478KB HTML file requires care to preserve the architecture (no build step, no dependencies, single file).
For small fixes (typos, broken links, factual corrections in citations), direct PRs are fine.
- Forks intended for redistribution — see LICENSE. The platform may be studied and used personally/academically but not redistributed in modified form.
- Removal or alteration of scholarly attributions — the attribution to Andreas Fuls (foundational corpus) and to the 39+ scholars in the Published Hypotheses Library is non-negotiable. PRs that remove or weaken attribution will be declined.
- Claims that the platform has "deciphered" Indus or any other script — the platform is explicitly framed as a hypothesis-testing tool, not a decipherment claim. Documentation contributions that overstate what the platform proves will be reverted. See the Wiki section "Architecture and Honest Limits."
- Adoption of OSI-approved open-source licenses — this is a deliberate choice. Discussion welcome via Issue, but the proprietary license is the current model.
This is the most common substantive contribution. To propose a new paper:
- Open an Issue titled "Library: [Paper Title] by [Author] (year)"
- Include in the issue body:
- Full bibliographic citation (author, title, year, publisher, publication venue, ISBN/DOI if available, page count)
- Hypothesis camp the paper belongs to: indo_aryan, dravidian, altaic, munda_mleccha, iconographic, computational, structural, mesopotamian_contact, comparative, meta_critique, or a new camp (with justification)
- Core hypothesis (1-3 sentences)
- Methodology used by the author
- Key sign assignments the paper makes (if data-rich)
- Cross-script applicability — does this paper apply to Linear A, Proto-Elamite, etc., in addition to Indus?
- Counter-citations — does this paper refute an existing Library paper, or is it refuted by one? Cite the evidence on both sides.
- Attach the paper itself if it's open-access; otherwise provide a stable URL to where it can be obtained.
I will review and either incorporate, ask follow-up questions, or explain why the paper isn't a fit (e.g., insufficient methodological rigor for the Computational camp, or already represented by a more comprehensive paper).
If you run the Egyptian Sabotage Test against any AI backend, please share the results in an Issue or Discussion. Sample reports of the form:
"Backend: Anthropic Claude Opus 4.6. Sabotage cheat rate: 14/18 (78%). Verdict: AI is cheating — overrode false picture descriptions in most cases."
…are extremely valuable, both for users choosing a backend and for tracking how AI honesty evolves across model generations.
- Be specific. "It doesn't work" is much less useful than "Clicking the Hidden Reveal button on the Egyptian page after configuring an Anthropic API key produces no output and shows an error in the browser console reading [paste error]."
- Be civil. This includes scholarly disagreement — there is genuine scholarly disagreement on every Indus decipherment claim in the Library, and the platform is designed to host that disagreement transparently.
- Cite, don't assert. Claims about the script, the corpus, or the academic literature should be backed by citations whenever possible.
Before contributing, please familiarize yourself with the work of Andreas Fuls, whose ICIT corpus and 2023 Catalog of Indus Signs (Mathematica Epigraphica No. 4, Berlin, ISBN 979-8-398-42230-6) is the empirical foundation on which the Indus Script pack is built. Without his two decades of work on the Indus corpus, the Indus-related functionality of this platform would not exist. Contributions that build on or extend Fuls's findings (positional classification, entropic redundancy analysis, core/singleton distinction) are particularly welcome.
For matters that aren't appropriate for public Issues — commercial licensing inquiries, sensitive scholarly disputes, etc. — please use GitHub's private contact options or the contact channel listed in the project's README.
Thank you for taking the platform's scholarly mission seriously. The goal is to be useful to working scholars by being epistemically honest about what the tool can and cannot prove, and by faithfully recording the body of work that has come before.