Glyph

[ architecture ] · § fig. 2, inked

[ decisions ] · § as filed

[ validation ] · § the receipts

ci rows link the public run · repo pins are the exact commits verified 2026-08.

[ corrections ] · § the register

• erratum · 2026-07-30

  Credited the collaborator and stopped claiming the network. This file described a two-person project as though one person had built it, and its summary opened by claiming a neural network that already existed — a course MLP this work optimized rather than authored. Both were omissions on the site’s side: the résumé has consistently said 2-person team and named the kernels as written with a teammate. The meta ledger now scopes the role the way the capstone’s already does, and the not-claiming list states what is not mine. Under-crediting a collaborator is the one error on this site that costs more than a wrong number, because a number can be re-measured and a person cannot be un-omitted. The collaborator is Shree Chaturvedi, named here and in the meta ledger above, and he is the same teammate as on the capstone.

• erratum · 2026-05-28

  Retracted the earlier AVX-512 inference-speedup claim: the committed classify-throughput rows do not support it. The number this file stands behind is the 3.5× dot-kernel speedup, and the receipt above links the committed data.

• erratum · 2026-07-26

  The live-demo outcome row linked fast-mnist.vercel.app. That alias still answers, so nothing 404’d — but it is not the brand URL, and the file was printing one host in its meta ledger and another in the row. The row now links getglyph.vercel.app, the same host as the rest of the file.

• note · 2026-07

  Attribution tightened, number unchanged: the committed 3.5× (dot 256) is the openmp+native configuration measured against the -O3 baseline, and the earlier site copy that credited the speedup to SIMD alone is retired. BENCHMARKS.md’s own analysis records that -march=native alone barely moves the needle. This note then named the winning side “openmp+simd”, which reads as though the vectorisation earns part of the number — a second wrong attribution, corrected by the 2026-08-06 erratum at the end of this register.

• note · 2026-07-30

  The accuracy claim is no longer held. From the first filing this file stamped ~97% HELD, because the number lived in README prose and no committed run reproduced it — the stamp named its own release condition: held until a committed eval run earns it. That run was committed on 2026-07-27 (glyph @ 97de736), and it brings its own generator, apps/eval_model.cpp, the model it scored pinned by sha256, and a 299-row list of every image it got wrong. So the stamp comes off and the number is stated as measured rather than rounded: 9,701 of 10,000, 97.01%, macro-F1 0.9698. Holding a claim that has been earned is not caution, it is under-claiming, and it would empty the stamp of meaning for the claims that are still genuinely unearned. Honest boundary kept: the 10,000-image MNIST test set is not vendored in the repository, so the run reproduces with the standard public dataset rather than from the repo alone.

• note · 2026-07-30

  Receipts and the repo pin now read yadava5/glyph rather than yadava5/fast-mnist-nn. No commit or number moved — c6e5c0b is the same benchmark commit it always was, and the v1.0.0 release is the same tag. The repository was renamed with the product, and the old paths now answer only through a GitHub redirect, which stops resolving if any repo named fast-mnist-nn appears under this account again. Every canonical path in this file was fetched and returned 200 before the labels were changed.

• note · 2026-07

  The ~97% accuracy receipt now carries the HELD stamp: the number is documented in the repo’s README training notes, but no committed eval artifact reproduces it yet. The claim is unchanged and stays on file; the stamp lifts when an eval run is checked in.

• note · 2026-07-27

  The HELD stamp described in the note above is lifted. glyph@97de736 commits benchmarks/mnist_eval.json, its generator apps/eval_model.cpp, and the 299-row miss list, which is the condition that note set. The rounded “~97%” is retired with it: once a number has an artifact, stating it approximately is a second, smaller inaccuracy. The receipt reads 97.01% — 9,701 of 10,000, macro-F1 0.9698.

• erratum · 2026-08-02

  Three receipt labels still read “fast-mnist-nn @ c6e5c0b” even though the 2026-07-30 note above told the reader every label had been changed to glyph. The hrefs had been converted; the visible text had not, so the label and the link it sat on named different repositories. The labels now read glyph. Recorded as an erratum rather than a silent fix because the defect was not the stale name — it was a register entry describing a repair that never shipped, on a page whose argument is that this register can be trusted.

• note · 2026-08-02

  Provenance audit: the MNIST evaluation was re-run from source on an Apple M1 Pro against the standard 10,000-image test set. The regenerated mnist_eval.json and mnist_misclassified.csv are byte-identical to the committed artifacts — 9,701 correct, 299 wrong, macro-F1 0.969822, the same model sha256. The dot-256 kernel benchmark was rebuilt and re-measured at 3.536× — the median of 20 repetitions, committed as docs/benchmarks/runs/bench-20260802-dot20x-{baseline,openmp-native}.json — against the 3.504× December record, which was taken on a different machine (a 4-performance-core M2 Air) and is history rather than the reference. The 3.520× this line used to cite had no committed JSON, and Glyph's own two records disagreed about how it was taken: ENVIRONMENT.md called it a single-repetition re-run, the audit log called it three repetitions. One caveat surfaced and is recorded at the receipt: apps/eval_model.cpp has no add_executable in CMakeLists.txt, so the generator has to be compiled by hand rather than through the project’s own build.

• erratum · 2026-08-06

  This file credited the 3.5× to an “openmp+simd” kernel in five places — the method slip, the benchmark receipt, the SIMD outcome row, the not-claiming list, and the 2026-07 note above that was itself the correction. The fig. 1 plate said it too, in its drawn label and in the sentence a screen reader is given. The number never moved; the attribution did, and it was wrong: the speed-up is OpenMP’s alone. Settled by building rather than by reading BENCHMARKS.md — all three configurations were compiled, and on arm64 the baseline and native binaries come out byte-identical, because -march=native is an x86 flag clang does not act on here. So the hand-written NEON path is in both sides of the comparison and earns none of the ratio; it is also why a SIMD-alone measurement sits at about 1.0, comparing a binary with itself. The run’s ¶ 06 and the proof manifest have carried this attribution since 2026-08-03 while this file carried the other one, on the same site, about the same measurement. Recorded as an erratum rather than a silent edit because a corrections register that carries a stale correction is worse than one that carries none: it is this page’s own promise that somebody checked.

• note · 2026-08-08

  The instruction-set count moves from three back to four — in the dot kernels, which is where the fourth one lives. The 2026-08-02 provenance audit cut this file’s “four” to three, and it was right: at that point the source guarded exactly __AVX512F__, __AVX2__ and __ARM_NEON over a scalar fallback, and the wasm build was -msimd128 auto-vectorisation — a compiler flag, not a kernel. Four days later, glyph@68f1362 (2026-08-06) retired the condition that finding rested on: src/NeuralNet.cpp now carries a hand-written __wasm_simd128__ branch — dot_wasm128_rowvec, wasm_f64x2 intrinsics with two independent accumulators, a shape the kernel’s own comment notes LLVM’s autovectorizer declines to produce for this loop — and the build’s -msimd128 flag means that branch is genuinely compiled into the wasm target. The qualifier travels with the number: four in the NeuralNet dot kernels, while Matrix.cpp still guards three; and the résumé, which said four throughout, is right again — though not vindicated: for the four days between the audit and the commit its four was the wrong number, and it is the source that moved, not the page that failed to keep up. This file’s repo pin (001e9b4) predates the commit and stays where it is — every use of it here is benchmark provenance — so the fourth kernel is cited at its own commit in the outcome row above. Recorded as a note rather than an erratum because the 2026-08-02 entry was correct when written; a register that rewrites a right call to look prescient is worse than one that shows the fact moving.

[ appendix ] · § plates & artifacts

fig. 3 — Local React workbench screenshot.source: local web workbench capture · 2026-06 · open to inspect ⟶

real-screenshot

Local React workbench screenshot

open original ↗ ✕

source: local web workbench capture · date: 2026-06 · boundary: native inference server offline during capture