¶ case file 1 of 7 · agentic automl platform — filed 2025-09 · last verified 2026-08
status: in progress — core shipped, run ledger pending
↳ consigned at agentic automl — ¶ 09 · 22:05 · waybill: automl’s halted run → manifest
the line stands dark at 22:05 — the archive lamp is lit; a record is read in the light it needs.
Agentic AutoML Platform
A public agentic AutoML platform. Datasets and domain documents become auditable pipeline decisions — and a human approval gate holds every generated action before it alters the workflow.
[ problem ] · § as found
Between a raw dataset and a useful model sits a chain of repetitive judgment: ingestion, feature decisions, training, evaluation, deployment packaging. Automate the chain carelessly and the judgment disappears with the labor.
constraints —
- Make pipeline decisions auditable instead of opaque.
- Support domain documents through retrieval and MCP-based orchestration.
- Require human approval before generated actions alter workflow state.
- Keep training workflows reproducible with containerized execution.
- Validate the product flow with browser-level checks.
fig. 1 — the halt, on file: six gates opened, the seventh held. deploy never lights itself — that word belongs to a person.
a drawn plate, at rest — not a screenshot. the twelve tools are mcpServer.ts’s at e506c91, in source order; no metric is drawn because none is claimed — the receipts say why.
[ architecture ] · § fig. 2, inked
A React and TypeScript interface coordinates Express/PostgreSQL services, LangGraph + MCP orchestration, notebook-based training workflows, Docker execution, and Playwright evaluation.
React 19 UI
Dataset and workflow surface
workflow requests
Express 5 API
Pipeline orchestration
approved actions
LangGraph + MCP
Agentic workflow routing
training jobs
Docker runtime
Reproducible runs
run records
PostgreSQL 16
Run metadata
Playwright evals
Workflow validation
browser proof — back to React 19 UI, closing the loop
generated actions hold at the approval edge until a human says go
- 038 · log-regmetrics not publishedapproved
- 039 · random forestmetrics not publishedapproved
- 040 · gbmmetrics not publishedapproved
- 041 · xgboostmetrics not published
[ decisions ] · § as filed
d1 — use langgraph + mcp for orchestration · accepted
The platform needs phase-aware routing, tool calls, and auditable decisions tied to domain context.1
1 tradeoff — More infrastructure than a simple model runner, but better for traceable workflows.
d2 — keep human approval gates · accepted
Generated preprocessing, training, and deployment actions should be reviewed before they alter the workflow.2
2 tradeoff — Approval gates slow down full automation, but they make the system safer and easier to debug.
d3 — containerize execution · accepted
Training runs need reproducible environments.3
3 tradeoff — Docker adds setup cost but reduces machine-specific drift.
[ validation ] · § the receipts
validation
walks the receipts below, top to bottom, and marks each row this page can verify: a check where a pinned artifact resolves, a ring where the trail ends in an on-page capture, a dash where a claim is described only. walked once, the result settles here and stays.-
01claim: The platform is the public repo yadava5/ai-augmented-auto-ml-toolchain; its README titles it Agentic AutoML Platform and states the seven-phase lifecycle, the LangGraph and MCP core, and a human approval gate at every step.
[public]
-
02claim: Upload, EDA, NL-to-SQL, preprocessing, training, experiments, and deployment are the seven lifecycle phases.
- artifact: see fig. 4 — the expo poster
[private-safe]
-
03claim: HPO, multi-model search, notebook training, and automated workflow evaluation are built into the platform.
- artifact: see fig. 5 — the presenter deck
[private-safe]
-
04claim: Presenter slide 8 records the stack and validation posture: all-green tests, coverage, logs, packages, and migrations.
- artifact: see fig. 5 — the presenter deck
[private-safe]
-
05claim: My slice of the build: the Monaco/Jupyter runtime with live WebSocket sync, Docker sandbox constraints, the eval runner, and the Optuna study streaming UI.
- artifact: see fig. 5 — the presenter deck
[private-safe]
-
06claim: Training runs execute in a Dockerized runtime for reproducibility.
- artifact: see fig. 4 — the expo poster
[private-safe]
outcomes
-
07claim: A dataset and a goal become a structured, auditable workflow — planned and argued for by agents that still cannot press go.
artifact: no linkable artifact — described only
[private-safe]
-
08claim: Pipeline decisions run through LangGraph tool calls rather than free-form output: the platform defines 44 tools across seven groups — preprocessing (14), cells (8), features (6), training (6), data (4), packages (3), UI (3) — and registers twelve of them, the data and cell groups, over MCP: 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. The other 32 are function-calling definitions the LangGraph phases consume directly.
ci rows link the public run · repo pins are the exact commits verified 2026-08.
what i’m NOT claiming —
- No per-run metrics are published here. The registry excerpt shows run, model, and status only — a demo-data run ledger with a complete metric trail has not shipped yet.
- The source is now public and pinned above, so the architecture claims are inspectable. What is still NOT claimed is a result: no accuracy, throughput, or benchmark figure appears on this file, because no committed eval artifact earns one. The work this file argues is the architecture and the human gate.
[ corrections ] · § the register
note · 2026-07
Per-run metrics remain withheld because no committed eval artifact earns one; the eval protocol for the platform’s own model runs is not yet publicly documented. Nothing here has been retracted — this register is waiting on a demo-data run ledger.
erratum · 2026-07-30
The repository is no longer private, and until today this file said it was. Receipt 01 read “The platform lives in the private repo …” and carried no artifact at all — true when written, false the moment the visibility changed, and it was the one incorrect sentence on the page. yadava5/ai-augmented-auto-ml-toolchain now answers anonymously; both paths cited here were fetched without a token and returned 200 before the rows were rewritten. Two claims moved from a photograph of a poster to the source that decides them: the seven-phase lifecycle and the human gate now cite the README at e506c91, and the MCP claim cites the server file, which registers exactly twelve tools — named here in source order because this project’s booklets once shipped fabricated tool names and an audit had to replace them. The note above stands with its reason corrected: going public makes the ARCHITECTURE inspectable, not the results. No accuracy or throughput figure appears on this file, because no committed eval artifact earns one.
erratum · 2026-08-06
The evidence aside above still said the repository was private, and it had said so for a week after it stopped being true. The 2026-07-30 round pinned the repo, removed the private stamp and rewrote receipt 01, but missed the one paragraph whose entire job is to tell a reader what they are not being shown — so the file contradicted itself three sections apart, and the erratum directly below it. Rewritten to name what is actually withheld: the source is public and pinned, and no accuracy, latency or throughput figure appears anywhere on this file because no committed eval artifact earns one. Found while rebuilding the archive as static HTML, by reading the generated page rather than the component that used to render it.
erratum · 2026-08-08
The tool count named the wrong noun, and this file has been under-claiming since 2026-07-30. “The server registers exactly twelve tools” was, and remains, true of mcpServer.ts: twelve registerTool call sites, one server, none anywhere else in the tree. What was wrong was presenting that as the platform’s tool surface. backend/src/services/llm/tools/ defines 44 tools across seven groups — preprocessing 14, cell 8, feature 6, training 6, data 4, package 3, UI 3, listed by name and de-duplicated with zero collisions — of which the MCP server registers the data and cell groups, the twelve; the other 32 are LLM function-calling definitions the LangGraph phases pass directly, and they are the preprocessing, feature-engineering and training lifecycle — the more substantial half of the surface, and the half the site omitted. The twelve reproduced at six refs, which is what made it convincing: a reproducible count of the wrong noun is still wrong. No document this site served ever said 44 before today — the résumé said “an MCP tool registry”, uncounted — so the site alone put a number on the surface, and the number it chose was the subset. Recorded as an erratum rather than a note because the fact never moved: the tool files at main’s head are byte-identical to trees months older, so all 44 were there when the twelve was counted, and the audit counted the subset and called it the registry. The pins now split by noun: e506c91 vouches for the twelve alone, and the 44 is counted at 5c5b762, main’s public head, which the evidence row pins and links. A first attempt at that pin named 5f8b7da instead — it resolves, its tool files are the same blobs, and it is the head of an imported gitlab/main-history branch with no common ancestor with main. Fetching a sha proves it exists, not that it is yours.
[ appendix ] · § plates & artifacts
§2 — an agent you can approve§3 — one langgraph, every step auditable§4 — measured on the public leaderboardfig. 4 — Expo poster proof.panels cropped at column width from the checked-in capture — the titles are the poster’s words, not this file’s claims.source: senior design expo poster, spring 2026 · 2026-05 · open to inspect ⟶
fig. 5 — Presenter stack proof.source: senior design presenter deck, slide 8 · 2026-05 · open to inspect ⟶