Ayush · Yadav the record room · the evidence index

¶ 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, covering the OAS and Tableau figures at ¶03, stays with IT Services, and only the sanitised inventory ledger made it out. Both are verifiable on request; neither is dressed as if a link would settle it.

at a glance: 14 entries · 11 public · 3 private-safe

  1. e-01

    visibility: [public]

    local classifier, three layers

    Applied’s classifier runs three layers: rules, embeddings, and SetFit. The hosted web app runs the rules layer alone, and the two learned layers are not deployed on any surface a reader can open: the desktop client was removed on 2026-08-12 and the browser export’s weights were withdrawn on 2026-08-15.

    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. The deployment sentence is dated 2026-09-23 and was re-checked then, not read out of the pinned doc: this row said all three layers “run on the desktop app and in the browser Space” for weeks after both stopped being true, from 2026-08-15 until 2026-09-23. apps/macos is not on main, and ml/browser carries no weights at 0285675.
    boundary:
    No private email content is shown.

  2. e-02

    visibility: [public]

    rules macro-F1 0.9896

    Applied’s rules v3 gate and its deterministic hybrid v3 gate both pass on the v3 eval set of 96 samples with macro-F1 0.9896, 1 message misclassified out of 96. Both measure the rules stage, because the deterministic profile disables the learned layers.

    date:
    2026-09-10
    verification:
    Baseline re-recorded 2026-09-07 under the rules profile, re-run at 0285675 on 2026-09-22 where it exits 0 against its own 0.001 tolerance, and printed twice by public backend-ci run 34429395505 on 2026-09-10, once for the rules gate and once for the deterministic hybrid gate. This row read 0.9791 with 2 of 96 misclassified until 2026-09-23, measured at 36a2f54 and true there; the artifact also moves from baseline_hybrid_v3.json to baseline_rules_v3.json, which is the file that decides the figure. At three decimals it is 0.990.
    boundary:
    The committed baseline JSON records metrics and label counts, not message content.

  3. e-03

    visibility: [public]

    3,747 backend tests, 0 skipped

    The Applied backend suite passes 3,747 tests with nothing skipped and 13 expected failures, including the Postgres row-level-security module of 26 tests that used to skip and had never executed anywhere.

    date:
    2026-09-10
    verification:
    pytest tests -q --cov=jobtracker against this head, read off backend-ci run 34429395505 of 2026-09-10 rather than a local venv: 3,747 passed and 0 skipped, with 13 expected failures named beside the total instead of folded into it, because an xfail is not a pass. The zero is still the part worth reading. The Postgres RLS module is 26 tests now and sits inside that total; the dedicated rls-postgres job runs the same module again on its own, so the two figures are one set of tests counted twice and must not be summed. This entry read “305 passed and 0 skipped” at 71b74f8 until 2026-09-23, and before that 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 increase of 27 tests 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, 305 again at 71b74f8 and 3,747 here at 0285675, 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. The chain is completed rather than truncated, for the reason the 1,185 to 1,186 move taught: a trailing “now N here” beside a history that stops short is the stale claim a reader is least likely to check.
    boundary:
    The suite runs with a null keyring; no private email or account data is involved.

  4. e-04

    visibility: [private-safe]

    AutoML lifecycle, seven phases

    Agentic AutoML presents an ML workflow of seven phases 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.
    boundary:
    Uses demo/source-truth data and excludes private repository source.

  5. 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.

    date:
    2026-08-14
    verification:
    Both counts taken in source at 5e42233, the commit “ci: core lint/test/build validation on main” of 2026-08-12, which is ON main rather than merely resolving: compare/main...5e42233 answers behind, and this site's link gate now asserts exactly that for every pinned commit it carries, on every run. The MCP subset: 12 server.registerTool( call sites in backend/src/services/mcp/mcpServer.ts, in source order list_project_files, get_dataset_profile, get_dataset_sample, search_documents, list_cells, read_cell, write_cell, edit_cell, run_cell, delete_cell, reorder_cells, insert_cell; there is no second MCP server, since registerTool appears nowhere else in backend/src or frontend/src, so 12 is the whole MCP registry. The tool surface: 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: backend/src/services/workflows/phases/training.ts:148 and phases/featureEngineering.ts:208 return the lifecycle sets, and phaseRequestBuilder.ts:1095 passes LLM_TRAINING_LIFECYCLE_TOOLS. Two prior errors are recorded rather than quietly repaired. 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. And from 2026-08-08 to today it pinned 5c5b762 and e506c91, both of which the 12 August branch consolidation left off main. GitHub now answers compare/main... for each with 404, “No common ancestor”, while every link went on resolving. No count changed at any point: tools/index.ts is blob 83f05ee at all three refs.
    boundary:
    No private data: the tool registry is public source.

  6. e-06

    visibility: [public]

    71 iOS tests, all passing

    The public VisualAssistTests suite executes 71 tests; all 71 pass, none are skipped.

    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, on iPhone 17 Pro under iOS 26.5 and then under 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, which are 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.
    boundary:
    No live camera, location, or user sensor data is shown.

  7. e-07

    visibility: [public]

    1,430 tests, 0 skipped

    Cadence runs 1,430 tests, 772 frontend + 658 backend, with nothing skipped, including the row-level-security suite that had never executed anywhere.

    date:
    2026-08-11
    verification:
    Read off CI at this head: GitHub Actions run 31464527681 on main, of 2026-08-11, all six jobs green: the Frontend Tests job reports 772 passing across 69 files, the Backend Tests job 658 across 33, and neither vitest summary reports a skip. The change worth reading is still that zero. The 11 skips this entry once 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 when the Postgres enforcement suites run zero tests or report any skip, because a skipped security test and a passing one render as the same green tick; that guard is scoped to those suites rather than to the whole run, and this entry said otherwise until 2026-09-28. 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, then 1,186 at abaaea8, now 1,430 here. The +244 is a net, and it is measured per commit off CI rather than read off commit titles: PR #19, the lockout, data safety and correctness work, took the suite to 772 frontend + 664 backend = 1,436 (run 31452962146 at 2905c0e); a revert took it straight back to 1,186 (run 31453305548 at 629f308); the restore put it back at 1,436 (run 31461432198 at 00696bd); and 6 backend tests went out with a dead attachments cleanup route at c39484f, which is the 1,430 here. The serverless boot repair added none. CI is deliberately the instrument rather than a local run: it is the only place the zero is read off a run anyone can open, and each of the two earlier drifts of this number began with a local backend run that skipped and still went green.
    boundary:
    No private data.

  8. e-08

    visibility: [public]

    3.5× on the 256×256 matrix product

    The 256×256 matrix product runs 3.5× faster than the single-threaded -O3 baseline: the speed-up is OpenMP’s, not SIMD’s.

    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, and the scope of each number is the part that was missing. At 20 repetitions, the run this entry cites, every dot size holds a coefficient of variation between 0.1% and 0.9%, with the baseline side at load_avg 4.70. At 10 repetitions, on a machine at load_avg 9.80, the same kernels are looser: benchDot/128 and benchDot/256 reach 2.6% and 1.6% on the openmp+native side. So sub-percent is not a property of the dot family; it is what that family was observed to do at 20 repetitions on a quieter machine, and this entry stated the tighter spread with no repetition count on it until 2026-09-28. Repetition count is not what tightens it, load is: the two runs differ in both, and only one of them is a cause. benchAxpy/256 reaches 4.3%, and that figure exists at 10 repetitions only: the longer run covers the dot family alone and never ran axpy. 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.
    boundary:
    No private data.

  9. e-09

    visibility: [public]

    97.01% MNIST test accuracy

    Glyph scores 97.01% on the MNIST test set of 10,000 images, 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.

    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 test set of 10,000 images, 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.
    boundary:
    No private data.

  10. 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 schema of 35 fields.

    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.
    boundary:
    Raw institutional exports, report names, owner names, and rows are excluded.

  11. 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.
    boundary:
    Raw policy text and Slack messages are excluded.

  12. 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.

    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”. That is 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.

  13. 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 69%.

    date:
    2026-09-23
    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%, and 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 figure is read from its own CI, which runs pytest tests -q --cov=jobtracker on every push: at 0285675, in backend-ci run 34429395505 of 2026-09-10, 9,786 statements, 3,054 missed, 69%, from 3,747 tests with 0 skipped and 13 expected failures, including the Postgres row-level-security module of 26 tests against a real postgres:16. Broken out per-package at that run, all of them, because a 53%-era sub-figure standing beside a 69% total is the more convincing lie: cloud 93.0%, auth 89.6%, database 80.8%, classifier 78.0%, credentials 67.4%, email_clients 42.7%, scripts 40.0% over 2,434 statements, tracking 28.9%, and the package root 92.2%. This row said 53% until 2026-09-23: 8,210 statements, 3,865 missed, from 305 tests at 71b74f8, with cloud at 82.2%, auth 80.5%, database 76.6% and jobtracker/scripts 2,240 statements at 33.7%. Every one of those was true at that commit and every one of them moved, and the direction is worth stating: the site had been publishing a figure sixteen points BELOW the work, which no gate can catch, because nothing goes red when a number is too modest. The 53% reading is kept in full rather than deleted. Measured at 71b74f8, the same command in the project's Python 3.11.14 venv on this machine gave 3,844 missed against CI's 3,865, 21 lines or 0.26pp, and the difference was the platform rather than the test selection, since that CI run collected the identical 305. The CI number is the one quoted here because it is the one a reader can open. Three earlier readings of that 53% 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 at 71b74f8 the same tree measured 8,018 statements there against 8,210 on 3.11, a gap of 192 statements 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: at that commit the loose exclusion reached 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.

  14. 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. Read 2026-08-10: Glyph 6.6, Cadence 5.5, Applied 5.4, LifeQuest 4.9, VisualAssist 4.6, jetpack-compress 4.3, AutoML 3.5.

    date:
    2026-08-03
    verification:
    Read from api.securityscorecards.dev on 2026-08-10, not from a badge image, all seven in one pass: Glyph 6.6, Cadence 5.5, Applied 5.4, LifeQuest 4.9, VisualAssist 4.6, jetpack-compress 4.3, AutoML 3.5. THE PREVIOUS READING WAS 2026-08-03 AND SIX OF THE SEVEN HAVE SINCE MOVED: Glyph 7.0→6.6, Cadence 4.5→5.5, Applied 4.5→5.4, LifeQuest 3.9→4.9, jetpack-compress 3.8→4.3, AutoML 3.6→3.5, with only VisualAssist unchanged at 4.6. Five of those six moved UP, so the stale row was under-claiming five repositories and over-claiming one; a figure going stale in the flattering direction is the one people notice, and it is not the common case. The movement is recorded rather than overwritten because the row below promises exactly that: the direction over time is the thing worth reading, and a number silently replaced by a newer number cannot show a direction. Two caveats on comparing the pairs. The API also reports the Scorecard version that produced each score, and it is not uniform across the estate (Cadence, Applied, LifeQuest and jetpack-compress were scored by v5.5.0 while Glyph, VisualAssist and AutoML were still on v5.3.0), so part of a week-to-week delta can be the instrument rather than the repository, and none of these deltas should be read as an effect of a specific commit. And the seven-day gap is shorter than the weekly analysis cycle for some repos, so a pair can be identical simply because it was not re-scored. 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 to 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.