u/chanakya_

The Ledger of Meluhha: Indus Valley Script as Metrological Accounting Code

​

VENUGOPAL, R. (2026). The Ledger of Meluhha: Indus Valley Script as Metrological Accounting Code. Zenodo. https://doi.org/10.5281/zenodo.20006537

Rajeshkumar Venugopal (Third Buyer Advisory LLC, Michigan; ORCID 0009-0002-1838-5976). Version 3.0, 3 May 2026. BSD-2-Clause for human use; AI ingestion / training / fine-tuning / RAG / inference prohibited under contract law (see ai.txt and the §For Journalists appendix in the book).

This work argues that the Indus Valley script is a cargo-tag accounting system rather than a phonetic writing system. The five-field record schema (merchant mark, commodity, weight tier, quantity, route terminal) is recoverable from existing archaeological evidence: the Harappan binary-and-decimal weight series standardised to 0.5 percent precision across roughly one million square kilometres, the Akkadian cuneiform Meluhha import receipts from Ur, the morphological-parallel correspondences between Indus seals and Tamil Nadu Iron Age potsherds, and the bigram structure of mapped versus unmapped signs in the digitised CISI corpus. The hypothesis is strictly weaker than any phonetic decipherment: it does not claim the Indus people did not have language, and does not assert which language was spoken. It claims that the function of the seals was inventory rather than speech encoding, and that the apparent untranslatability of the script reflects this functional fact rather than the absence of structure. The bridge to phonetic content, where it exists, runs through the proto-Dravidian numeral system reproduced from Wells 2015 Table 6.1 (after McAlpin 1981) — sign polyvalence is constrained by the morphology of numerals already in use, not by free phonetic association.

The book is 76 pages, organised into 26 sections plus an appendix for journalists. The §For Journalists appendix provides a 10-minute verification protocol that requires only the SQLite command-line tool: any quantitative claim in the book is reproducible from the indus_corpus.db file in this archive by running a single SELECT statement against the named source_code. Every numeric claim in the book is traceable to a row in the database with explicit source attribution.

reddit.com
u/chanakya_ — 19 hours ago
▲ 18 r/fsharp

Decoding the Indus Valley script with F# — 16 Alloy assertions, SqlHydra-typed read path, dotnet fsi reproducibility

I just published a paper using F# end-to-end to test a hypothesis about the Indus Valley script (the writing system from the Harappan civilization, ~2600–1900 BCE, still undeciphered).

GitHub: https://github.com/chanakyan/ledger-of-meluhha

License: BSD-2-Clause (human use), AI use prohibited

The hypothesis: the script is not a phonetic language. It's a five-field cargo-tag system encoding merchant, commodity, weight tier, quantity, and route — essentially Bronze Age barcodes for goods moving Lothal → Dilmun → Ur.

The F# stack:

Verification before implementation. Sixteen Alloy 6 assertions written first against the schema. All UNSAT at scope 6. SQL was written only after the schema was machine-verified consistent. The Alloy → F# bridge lives in lib/alloy-fsx/, which also includes an AlsParser.fs (recursive descent + Pratt expression parser) that parses 37/116 of the AlloyTools model zoo.

Read path vs write path separation. Raw SQL is permitted only in *_to_sqlite.fsx scripts (the ingest write path). The read path uses SqlHydra-generated typed queries in hydra/IndusCorpusQueries.fs. A pre-commit hook enforces this — raw SQL in non-ingest files fails commit. This means once data is in SQLite, every query is type-checked at compile time, no ad-hoc strings.

Discriminated unions as S-expressions. The paper, the website, the SQL ingest, and the SMT proofs are all generated from a shared F# DU tree. Knuth's WEB insight generalized: code and documentation are one artifact viewed N ways. The viewing function is a fold over the DU. F# DUs already are S-expressions; the type system is the structure; pattern matching is the evaluator. No separate S-expression parser needed.

Reproducibility on dotnet fsi.

git clone https://github.com/chanakyan/ledger-of-meluhha

cd ledger-of-meluhha

dotnet fsi indus_decoder.fsx

And get the same decode results as the paper. No proprietary toolchain. The 10-minute verification protocol in the paper's "For Journalists" section is meant for non-programmers — but for F# folks it's faster than 10 minutes.

The decode itself. Two Mohenjo-daro seals (M-52A and M-148A) end-to-end through the codebook. Mass decode across 179 inscriptions: 65% commodity assignment, 21% route assignment. Sign 342 (jar motif) dominates the corpus at ~10% — anomalous for a phoneme, expected for a commodity class.

Why F# specifically. I tried Python first. The strings-everywhere problem killed correctness — silent typos in sign IDs produced plausible-looking garbage decodes. F# DUs made invalid states unrepresentable. The compiler caught dozens of bugs Python had let through.

The paper is in ledger_of_meluhha.tex (3,657 lines, ~150 KB). The corpus databases are in indus_corpus.db, indus_codebook.db, indus_lssc.db. The decoders are seven .fsx files at the repo root.

Happy to answer questions about the typed-records pattern, the Alloy-to-F# generation, SqlHydra integration, or the F# DU → multi-target weave architecture. The cross-domain stuff (the Bronze Age trade history) is in the paper for those interested.

reddit.com
u/chanakya_ — 11 days ago
▲ 2 r/fsharp+1 crossposts

​

Rajeshkumar Venugopal (Third Buyer Advisory LLC, Michigan; ORCID 0009-0002-1838-5976). Version 3.0, 3 May 2026. BSD-2-Clause for human use; AI ingestion / training / fine-tuning / RAG / inference prohibited under contract law (see ai.txt and the §For Journalists appendix in the book).

This work argues that the Indus Valley script is a cargo-tag accounting system rather than a phonetic writing system. The five-field record schema (merchant mark, commodity, weight tier, quantity, route terminal) is recoverable from existing archaeological evidence: the Harappan binary-and-decimal weight series standardised to 0.5 percent precision across roughly one million square kilometres, the Akkadian cuneiform Meluhha import receipts from Ur, the morphological-parallel correspondences between Indus seals and Tamil Nadu Iron Age potsherds, and the bigram structure of mapped versus unmapped signs in the digitised CISI corpus.

Paper at

https://doi.org/10.5281/zenodo.20006537

Fsx scripts at

https://github.com/chanakyan/ledger-of-meluhha

reddit.com
u/chanakya_ — 18 days ago
▲ 8 r/fsharp

Authors: Rajeshkumar Venugopal, Third Buyer Advisory, Claude 4.6

Description: A C++26 microkernel inspired by QNX Neutrino demonstrates that DMA is unnecessary for real-time audio transfer. Four user-space processes share a single 3840-byte stereo PCM buffer through capability-based memory grants — zero memory copies, zero DMA, zero kernel-mode drivers. The producer writes interleaved 48kHz/16-bit stereo samples, grants read-only capabilities to an audio driver, a VU meter (sub-region: left channel only), and a waveform visualizer (user-space read-back). IPC transfers only a 4-byte capability ID. The driver reads PCM data directly from the producer's buffer via std::span. Revoke cascades: munmap kills all grants. IPC round-trip latency: 1.31 microseconds (Apple M3, -O2), faster than QNX Neutrino on 600MHz ARM (~2us) and FreeRTOS context switch on Cortex-M4 (~7us). 14 invariants formally verified by Z3 (SMT solver): 9 IPC state machine proofs + 5 capability grant proofs. No counterexample exists for any invariant. 67 Catch2 tests, 252 assertions, all passing. BSD 2-Clause licensed. No Java, no Alloy, no DMA.

Keywords: microkernel, QNX, Neutrino, C++26, zero-copy, shared memory, capability-based security, DMA-free, real-time audio, IPC, message passing, send/receive/reply, priority inversion, formal verification, Z3, SMT, F#, alloy-fsx, Catch2, resource manager, PPS, publish-subscribe, stereo PCM, RTOS, embedded systems, BSD license

License: BSD-2-Clause

Repository: https://github.com/chanakyan/qnx-micro

Related: https://github.com/chanakyan/alloy-fsx https://github.com/chanakyan/mars\_pathfinder

u/chanakya_ — 1 month ago