¶ the evidence index — every claim on file · 14 entries
The evidence index
The master ledger behind every number on this site: the claim, the strongest artifact it terminates at, when it was recorded, and the case-file receipt that argues it in full. If a claim is not in this ledger or a case file, the site does not make it — apart from two registers that terminate in documents this site cannot publish. The biographical one (degree, dean’s list, GPA, certificates, the MUCAT grant) rests on the transcript and the awards themselves. The institutional one — the OAS and Tableau figures at ¶03 — is read off Miami’s own systems, and only the sanitised inventory ledger made it out. Both are verifiable on request; neither is dressed as if a link would settle it.
-
e-01
visibility: [public]
3-layer local classifier
Applied’s classifier is a 3-layer rules, embeddings, and SetFit path — all three run on the desktop app and in the browser Space; the hosted web app runs the rules layer alone.
- source:
- docs/ML_STRATEGY.md @ 36a2f54 ↗
- date:
- 2026-07-26
- verification:
- ML strategy doc read against the backend source at the pinned commit; the hosted limit is the cloud short-circuit in classifier/hybrid.py, argued at case-file receipt 09.
- argued in:
- applied case file · receipt 02 ⟶
- boundary:
- No private email content is shown.
-
e-02
visibility: [public]
macro-F1 0.9791
Applied’s rules and deterministic hybrid v3 gates both passed on the 96-sample eval set with macro-F1 0.9791.
- date:
- 2026-03-03
- verification:
- Committed 2026-03-03 baseline (deterministic profile) plus the public backend-ci gate run of 2026-04-20. The artifact is byte-identical at the new pin — re-read 2026-07-26, same 96 samples, same 0.9791.
- argued in:
- applied case file · receipt 05 ⟶
- boundary:
- The committed baseline JSON records metrics and label counts, not message content.
-
e-03
visibility: [public]
305 backend tests, 0 skipped
The Applied backend suite passes 305 tests with nothing skipped, including the Postgres row-level-security module that used to skip and had never executed anywhere.
- source:
- backend/tests @ 71b74f8 ↗
- date:
- 2026-08-07
- verification:
- `pytest tests -q` against this head on 2026-08-07, read off backend-ci run 31152038153 rather than a local venv: 305 passed, 0 skipped. The zero is the part worth reading. This entry previously said “278 passed, 10 skipped”, and named the skips as the Postgres RLS module, which “needs a live database URL and gets one from no workflow” — an accurate description of tests that had therefore never run: not in CI, not locally, not once. They were the only tests capable of demonstrating the isolation this project claims. They now start their own postgres:16 through testcontainers when JOBTRACKER_TEST_PG_ADMIN_URL is absent, creating a non-superuser app role, which is the part that makes RLS mean anything since policies do nothing against a superuser. The remaining 17 of the 27-test increase are the CORS origin-policy suite (10) and the classifier-benchmark layer guard (7). Counts move with their commit: 271 at 36a2f54, 278 at 03fc5c4, 305 at a0d77a1 and 305 still here — each true when taken, and each taken at a commit a reader can open. The pin moved to 71b74f8 on 2026-08-07 without the count moving, because the case file was pinning the same 305 to 03fc5c4 — the 278 tree — and one number standing on three commits is the drift this project keeps re-learning.
- argued in:
- applied case file · receipt 04 ⟶
- boundary:
- The suite runs with a null keyring; no private email or account data is involved.
-
e-04
visibility: [private-safe]
7-phase AutoML lifecycle
Agentic AutoML presents a 7-phase ML workflow with LangGraph and MCP orchestration.
- source:
- expo poster capture — private-safe ⟶[self-hosted — checked into this site’s repository]
- date:
- 2026-05
- verification:
- Private-safe senior design poster and local AutoML repository audit.
- argued in:
- automl case file · receipt 02 ⟶
- boundary:
- Uses demo/source-truth data and excludes private repository source.
-
e-05
visibility: [public]
44 agent tools — 12 over MCP
The Agentic AutoML backend defines 44 LLM tools across seven groups — preprocessing (14), cell (8), feature (6), training (6), data (4), package (3), UI (3). Twelve of them — the data and cell groups — are registered over MCP in one server: the notebook surface the orchestrator drives. The other 32 are function-calling definitions the LangGraph phases consume directly.
- source:
- tools/index.ts @ 5c5b762 ↗
- date:
- 2026-08-08
- verification:
- Two counts, two nouns, both taken in source. The MCP subset, counted 2026-08-02: 12 `server.registerTool(` call sites at the pinned commit and 12 at the head; there is no second MCP server — `registerTool` appears nowhere else in backend/src or frontend/src — so 12 is the whole MCP registry. The tool surface, counted 2026-08-08 at main's public head `5c5b762`: backend/src/services/llm/tools/ defines 44 tools across seven files — preprocessingTools 14, cellTools 8, featureTools 6, trainingTools 6, dataTools 4, packageTools 3, uiTools 3 — listed by name and de-duplicated globally with zero collisions. The plumbing explains both numbers: tools/index.ts assembles only DATA + CELL + PACKAGE into LLM_TOOL_DEFINITIONS, mcpServer.ts registers DATA (4) + CELL (8) = 12 of those, and the remaining 32 are passed as toolDefinitions by the LangGraph phases themselves — training.ts:149, featureEngineering.ts:208, phaseRequestBuilder.ts:1095, line numbers true at the pinned head. From 2026-08-02 to 2026-08-08 this entry presented the subset as the total: a reproducible count, reproduced at six refs, of the wrong noun. Each number now stands on the commit it was read at — the 44 at `5c5b762`, which this row pins and links; the 12 at `e506c91`, which is where the case file still cites them.
- argued in:
- automl case file · receipt 02 ⟶
- boundary:
- No private data — the tool registry is public source.
-
e-06
visibility: [public]
71 iOS tests, all passing
The public VisualAssistTests suite executes 71 tests; all 71 pass, none are skipped.
- source:
- VisualAssistTests @ 22ebdaa ↗
- date:
- 2026-08-03
- verification:
- Executed, having previously only been counted. This entry read “71 test functions” rather than “71 passing” because the suite could not be run: xcodebuild resolved a destination needing an iOS runtime this machine lacked, and CI had no `xcodebuild test` step either, so 71 tests had never executed anywhere. The runtime was installed on 2026-08-03 and `xcodebuild test` was run twice — iPhone 17 Pro on iOS 26.5, then on iOS 26.2 when the simulator resolver picked a different device — giving 71 passed, 0 failed, 0 skipped both times, read from the .xcresult bundle via xcresulttool rather than from console text. Two runtimes rather than one because the second run was accidental, and it is worth more than the first. The static count is unchanged and still corroborates: 8 XCTestCase subclasses, 71 no-argument instance methods named test…, per file 13 · 11 · 10 · 9 · 9 · 8 · 6 · 5, with zero argument-taking, private, or static variants — the cases XCTest would skip — so the collected count could not have differed. The pin still holds: VisualAssistTests/ and VisualAssist/ are byte-identical between this commit and the tree that was executed, which changed only CI, scripts and docs. CI now runs the suite and asserts it ran, since a green xcodebuild proves nothing on its own. The commit that introduced the suite says “68 tests”; that is the stale document, not this number.
- argued in:
- visual assist case file · receipt 01 ⟶
- boundary:
- No live camera, location, or user sensor data is shown.
-
e-07
visibility: [public]
1,186 tests, 0 skipped
Cadence runs 1,186 tests — 635 frontend + 551 backend — with nothing skipped, including the row-level-security suite that had never executed anywhere.
- source:
- cadence @ abaaea8 ↗
- date:
- 2026-08-07
- verification:
- Read off CI at this head on 2026-08-08 — GitHub Actions run 31233308044 on `main`, all five jobs green: the Frontend Tests job reports 635 passing across 58 files, the Backend Tests job 551 across 25, and the skip count is zero. The change worth reading is that zero. The 11 skips this entry previously reported were the Postgres row-level-security module — the only tests capable of demonstrating the isolation Cadence claims — and they had never run: not in CI, not locally, not once, because they wait on an RLS_TEST_PG_ADMIN_URL that no workflow set. They now start their own postgres:16 through testcontainers when the variable is absent, creating a non-superuser app role, which is the part that makes RLS mean anything since policies do nothing against a superuser. CI additionally fails if the suite reports any skip, because a skipped security test and a passing one render as the same green tick. Both the count and the commit moved together, and the commit was confirmed present on the remote before this pin was written: 1,145 at 69a59e7, then 1,159 at 8eee84e, then 1,179 at 2295044, then 1,185 at dbabc74, now 1,186 here. CI is deliberately the instrument rather than a local run: it is the only place the zero is *proved* rather than asserted, because the workflow fails on any skip, and each of the two earlier drifts of this number began with a local backend run that skipped and still went green.
- argued in:
- cadence case file · receipt 01 ⟶
- boundary:
- No private data.
-
e-08
visibility: [public]
3.5× parallel dot kernel
The parallel dot kernel runs 3.5× faster than the single-threaded -O3 baseline at dot 256 — the speed-up is OpenMP’s, not SIMD’s.
- source:
- BENCHMARKS.md @ 001e9b4 ↗
- date:
- 2026-08-03
- verification:
- Three independent measurements now stand behind the 3.5×, taken on different machines with different repetition counts: 3.504× (Dec 2025, 1 repetition), 3.570× (2026-08-02, 10 repetitions) and 3.536× (20 repetitions). The pin moves off c6e5c0b for a reason — that commit predates a correction the document now carries. BENCHMARKS.md used to claim variance was “small enough (sub-percent on a quiet machine) that we don’t publish confidence intervals”, and nothing supported it: the harness the docs told you to run passed no --benchmark_repetitions, so every committed record said `repetitions: 1` with no aggregates and there was no stddev anywhere to check against. Measured, the claim is right about the kernels it matters for and wrong as a blanket statement — the dot family is 0.1–0.4% even at load_avg 4.70, while benchAxpy/256 reaches 4.3%. The reference machine also changed: the December runs carry `Shrees-MacBook.local` and were taken on a fanless MacBook Air with roughly half the performance cores, which for an OpenMP SCALING number measures a different machine's ceiling rather than a noisier version of the same one. The attribution was checked rather than assumed: on arm64 the `baseline` and `native` binaries are byte-identical — same md5 — because -march=native is an x86 flag clang does not act on here, so the NEON path is in both and the entire gain is parallelism. That is why the “SIMD alone” figure sits at ~1.0: it compares a binary with itself.
- argued in:
- glyph case file · receipt 02 ⟶
- boundary:
- No private data.
-
e-09
visibility: [public]
97.01% MNIST test accuracy
Glyph scores 97.01% on the 10,000-image MNIST test set — 9,701 correct, 299 wrong, macro-F1 0.9698 — in a committed eval run whose report names its generator and pins the scored model by sha256.
- source:
- mnist_eval.txt @ 97de736 ↗
- date:
- 2026-08-02
- verification:
- Re-run from source on 2026-08-02, not merely read: the generator was compiled and executed against the standard 10,000-image test set, and the regenerated mnist_eval.json and mnist_misclassified.csv are byte-identical to the committed artifacts — 9,701 correct, 299 wrong, macro P/R/F1 0.970056/0.969845/0.969822, the same model.weights sha256, 784→100→10 sigmoid MLP. Two honest caveats stay: the public MNIST test set is not vendored, so reproduction needs the standard dataset; and apps/eval_model.cpp has no add_executable in CMakeLists.txt, so a third party has to compile the generator by hand rather than through the project’s own build.
- argued in:
- glyph case file · receipt 01 ⟶
- boundary:
- No private data.
-
e-10
visibility: [private-safe]
10,453 deduped rows
The checked-in ledger records 3,731 Tableau and 6,743 Workday rows deduped to 10,453 master rows across a 35-field schema.
- source:
- master-inventory-ledger.json — checked in 2026-06 ⟶[self-hosted — checked into this site’s repository]
- date:
- 2026-06
- verification:
- Sanitized processed-output ledger, checked into this site’s public repository.
- argued in:
- master inventory case file · receipt 01 ⟶
- boundary:
- Raw institutional exports, report names, owner names, and rows are excluded.
-
e-11
visibility: [private-safe]
19/20 structured sweep
The checked-in ledger records a 19/20 structured sweep and a 17/25 keyword sweep, both self-graded, with 4 unsupported topics declined rather than answered.
- source:
- policybot-validation-ledger.json — checked in 2026-06 ⟶[self-hosted — checked into this site’s repository]
- date:
- 2026-06
- verification:
- Sanitized validation ledger, checked into this site’s public repository.
- argued in:
- policybot case file · receipt 01 ⟶
- boundary:
- Raw policy text and Slack messages are excluded.
-
e-12
visibility: [public]
72 tests pass
jetpack-compress compiles clean on JDK 25 and its full suite passes — 72 tests, 0 failures, 0 errors, 0 skipped.
- source:
- src/test/java @ 2caacd0 ↗
- date:
- 2026-08-03
- verification:
- Run, not read: `mvn -DskipTests=false test` on JDK 25.0.3 against this commit on 2026-08-02, and the surefire XML summed across all five test classes gives tests=72 errors=0 skipped=0 failures=0. This entry names the test tree rather than the README status line it used to cite, because a status line is prose about a run and the tree is the run's subject. Re-verified 2026-08-03 under `mvn verify`, which now also emits a JaCoCo report: still 72/0/0/0. That sentence used to end “the repository has no CI, so this local run is the only execution record that exists” — no longer true, and the correction is the interesting part: CI runs the suite on every push and sums the same surefire XML, so the count is now reproducible by anyone from a run record rather than from this paragraph.
- argued in:
- no case file — the repository is the record
- boundary:
- No private data.
-
e-13
visibility: [public]
coverage measured, five repos
Line coverage is measured, not asserted, across five repositories: Glyph 88.9%, jetpack 68.1%, Cadence backend 67.1%, AutoML 67.4%, Applied 53%.
- date:
- 2026-08-03
- verification:
- Every figure produced by running the suite, each with its command recorded beside it: Glyph `tools/coverage.sh` (clang source-based instrumentation + llvm-cov), jetpack `mvn verify` (JaCoCo 0.8.13), Cadence `vitest --coverage` (v8), Applied `pytest --cov`. AutoML's 67.4% was measured during the provenance audit against a documented claim of 97% — that gap is why this row exists at all. The blended totals are the least informative way to read them and are broken out per package for exactly that reason: jetpack's SIMD `vector` package, which is the reason that project exists, is at 98.9% while an untested CLI argument parser drags the average to 68.1%; Applied's deployed `cloud` layer is at 82.2%, `auth` 80.5%, `database` 76.6%, while `jobtracker/scripts` is 2,240 statements at 33.7%. Applied's figure is read from its own CI, which runs `pytest tests -q --cov=jobtracker` on every push: 8,210 statements, 3,865 missed, 53%, from 305 tests with 0 skipped including all ten database-level RLS tests against a real postgres:16. The same command in the project's Python 3.11.14 venv on this machine gives 3,844 missed — 21 lines, 0.26pp — and the difference is the platform, not the test selection, since CI's run collects the identical 305. The CI number is the one quoted here because it is the one a reader can open. Three earlier readings disagreed (52.6%, 53.2%, 55.1%) and only one was right: the spread is the Python version, not the tests. Under PEP 649, 3.14 stops emitting line events for annotation-only class attributes, so the same tree measures 8,018 statements there against 8,210 on 3.11 — a 192-statement gap across 13 Pydantic models. This row previously said 54% and cited a README, which its own rule forbids, and its source field pointed at Glyph's coverage.sh — a different repository. An earlier claim of 61% excluding one-off scripts is dropped rather than restated: the loose exclusion reaches 60.50% only by removing 1,234 statements of code that CI invokes directly as gates, which is not a one-off script by any reading. Cadence's frontend reads 18.0% lines against 67.1% branches — the signature of logic that is unit-tested thoroughly with the components around it covered by Playwright, which a v8 pass over a Vitest run cannot observe; no line-coverage gate is set there, because such a gate pushes work toward shallow component tests that raise the number and find nothing. jetpack gates at 55% in CI, deliberately BELOW its measured 68.1%: a floor pinned at the current value turns every honest refactor red, and what it guards is a collapse — the coverage agent silently detaching and reporting near zero — not a two-point drift. Negative-tested by raising that floor to 95%: fails, exit 1.
- argued in:
- no case file — the repository is the record
- boundary:
- No private data — coverage is computed from the projects' own test suites.
-
e-14
visibility: [public]
Scorecard, scored by the OpenSSF
Seven repositories are analysed weekly by OpenSSF Scorecard against 18 supply-chain checks, with results published by the OpenSSF at scorecard.dev: Glyph 7.0, Applied 4.5, Cadence 4.5, VisualAssist 4.6, LifeQuest 3.9, jetpack-compress 3.8, AutoML 3.6.
- source:
- scorecard.dev · yadava5/glyph ↗
- date:
- 2026-08-03
- verification:
- Read from api.scorecard.dev on 2026-08-03, not from a badge image: Glyph 7.0, VisualAssist 4.6, LifeQuest 3.9, jetpack-compress 3.8. An earlier revision of this row said Glyph 6.4 and linked ?uri=github.com/yadava5/fast-mnist-nn. Both were wrong in the same way: fast-mnist-nn is the repository's RETIRED name, and Scorecard keeps a separate record under it, frozen at 2026-07-20 — so the link resolved 200, served a real score, and the score was a month-old reading of a repo that had since been renamed and improved. A receipt that returns 200 is not thereby a correct receipt, and this one survived review precisely because it did. This is the only row in this ledger whose number the author does not compute. Scorecard is run by the OpenSSF against a public repository and published at a public URL, so anyone can re-read it and, unlike every other entry here, disagree with it using the same instrument. That is also why it carries no `sourceKind` qualifier: those mark evidence that sits closer to the author, and this sits further away than anything else on the page. The scores are modest and are meant to be read that way. Several of the 18 checks grade repository SETTINGS — branch protection, signed releases, required review — that no committed file can switch on, so a correctly configured repo still opens in the 3–5 band. The figure to watch is the direction over time, not the first reading; it is recorded here precisely so that later movement is checkable against a stated starting point.
- argued in:
- no case file — the repository is the record
- boundary:
- No private data — Scorecard reads public repository metadata only.