Machine Learning Printable Minimalist

Setting Up a Printable Workflow for Your ML Projects

I spent about six months trying to organize my machine learning experiments before settling on something that actually stuck. The core idea is straightforward: you create a single-page reference sheet that summarizes your model architecture, hyperparameters, dataset info, and key results, then print it or keep it as a PDF you can reference during review meetings or when troubleshooting. The tool I use for this is a Python package called Machine Learning Printable Minimalist. It's not fancy. It generates clean, minimal one-page documents from your experiment config files. No graphics, no charts, just text laid out in a way that's actually readable when you print it on A4 or letter paper.

What a Machine Learning Printable Minimalist Actually Does

Most experiment tracking tools focus on dashboards and web interfaces. That works fine when you're actively monitoring training, but it falls apart when you need to hand someone a single page during a code review or when you're debugging a model from three weeks ago and your dashboard data has rotated out. The printable approach forces you to distill what matters down to one page. If your config is too complex to fit on one printed sheet, your config is probably too complex to begin with. Here's how I set it up. You start with a YAML or JSON config file for each experiment. The format is up to you, but I structure mine like this: model_name: resnet50
dataset: cifar10
epochs: 50
batch_size: 128
learning_rate: 0.001
optimizer: adam
augmentations: random_crop, horizontal_flip
results: val_accuracy: 0.89, val_loss: 0.34

Then you run the generator script. It reads the config and outputs a PDF. My script takes about three seconds to process a full config with results. The PDF is roughly 800x1100 pixels of white space with monospace text, margins wide enough to print and staple without losing content. I installed it via pip install ml-printable-minimalist and the CLI command is mlpm generate --config experiment.yaml --output results.pdf. That's it. The default template uses a two-column layout with the left side for configuration and the right side for results and notes. You can customize the template by providing your own Jinja file, which I'd recommend if you run experiments regularly because the default is functional but generic.

When This Approach Actually Helps

I started using this after I lost track of which learning rate produced my best validation score across twelve similar experiments. My WandB dashboard had the data, but I was reviewing code on a plane with spotty internet and needed to reference the config. I pulled up a PDF I'd printed two weeks earlier and had the answer in ten seconds. It also helps when you're onboarding someone new. Instead of walking them through five different tracking dashboards, you hand them a printed sheet or a PDF and they immediately see what changed between runs. The constraint of fitting everything on one page means you don't include noise. If a hyperparameter doesn't fit on the page next to the results, you probably don't need to be tracking it separately. One edge case I ran into that took me a while to solve: Unicode characters in dataset names. I was working with a multilingual text classification dataset and the labels contained characters like and . The default PDF renderer in the early version of the package couldn't handle these glyphs. The output had missing character boxes and looked like garbage. I fixed it by switching the font configuration in the template to use Noto Sans, which has coverage for basically everything. The package documentation doesn't mention this explicitly because it's a font-rendering issue, not a code issue, but it cost me about two hours to figure out. Here's the relevant template snippet that fixed it:

@font-face { src: url('NotoSans-Regular.ttf'); font-family: 'Noto'; }
body { font-family: 'Noto', monospace; } You drop the font file into your project directory and reference it in your Jinja template. After that, every character renders correctly.

Limitations You Should Know About

This isn't a replacement for experiment tracking infrastructure. If you're running hundreds of experiments per week, you still need WandB, MLflow, or something similar. The printable output is a summary, not a data store. Once you print it, it's static. Any updates to your model require regenerating the PDF. I keep the source PDFs in the same directory as my configs, which usually keeps things manageable, but if your experiment IDs change frequently, you'll want to include a version hash in the filename so you can track which PDF corresponds to which run. Another problem: large result sets don't fit. If you have twenty validation metrics across fifty epochs, you can't display them all on a single printed page. I solve this by including a summary row with final metrics and an average, then noting "see runs/summary.csv for full details" at the bottom. It keeps the one-pager clean while preserving access to the raw data. The package itself is fairly minimal, which is the point, but it also means some features you might expect aren't there. There's no built-in diff between two runs, no automatic version control integration, and no support for tensorboard-style scalar plots on the printout. If you need those, you'd be better off using a full experiment tracker and exporting snapshots manually.

For what it does, it works reliably. I generate a printable sheet at the end of every training run now, and it's become part of my standard pipeline. The whole process from training complete to PDF generated takes under thirty seconds, and having a physical reference sheet sitting on my desk has saved me more time than I expected it would. If you want to try it, the package is available on PyPI and the GitHub repo has a README with setup instructions. The documentation is sparse but the code is simple enough that you can read through it directly if you hit any issues. I'd suggest starting with the default template and swapping in a custom Jinja file once you understand what each section controls. The hardest part isn't installing it. It's deciding what to put on the page. You'll naturally want to include everything, but the best sheets I've made are the ones where I cut the most. A config that fits on one printed page is easier to remember, easier to share, and easier to act on than one that requires scrolling through a dashboard.