Fitness-Toolkit is where I'm bringing that information together with the same systems mindset I use in technology: keep the source, make the process repeatable, and build something useful from it.
From tracking to understanding
Fitness apps are good at collecting information and presenting it within their own interface. But I also want to work with that information outside the app—to ask different questions, keep a durable history, and connect it to the rest of my training and planning.
A weight chart is one example. The longer story includes food intake, changing nutrition targets, training plans, and the context behind individual days.
Having more data doesn't automatically make that story clearer. It needs structure, and the structure needs to preserve what the numbers actually mean.
Start with exports that already exist
The first working data pipeline uses MacroFactor's supported spreadsheet exports.
I manually export the files, put them into the toolkit, and run a local Python command. It reads the exports, merges the records, and rebuilds a set of structured JSON files.
The importer uses the Python standard library. It doesn't need MacroFactor credentials or make network requests. The export step is still manual; the processing after that is repeatable.
As of the October 5, 2026 snapshot, the retained data includes:
- 631 dates in the daily metrics dataset, spanning January 13, 2025 through October 5, 2026.
- 5,426 food entries across 524 dates, spanning April 30, 2025 through October 5, 2026.
Those are coverage counts, not a claim that every measurement exists on every day.
Repeated imports shouldn't create repeated history
Exports overlap. A new file may contain the same dates as an earlier one, along with corrections or newer information.
The toolkit handles that at two levels.
First, it identifies source files by a content hash. Renaming an identical export doesn't make it new data.
Then it merges the actual records. Daily data is keyed by date. Food logs replace the complete list for a date supplied by the newer processed export, so overlapping exports don't inflate the history.
That distinction matters: intentionally logging the same food twice should remain two entries. Importing the same history twice should not create four.
The processing record also keeps source information and parser versions. When something looks odd, there is a way to trace it back rather than just trusting the final number.
Smaller outputs for useful questions
The full exports are worth keeping, but they aren't always the right starting point for analysis.
The toolkit builds smaller views for daily nutrition and weight, nutrition-program history, weight goals, body measurements, recipes, custom foods, and recurring foods.
A latest-summary file brings together the most recent available measurements and completed seven- and 28-day windows. It records dates and missing-data information alongside the values.
If I need detailed food entries grouped by recorded time, a separate command generates that view for a specific date range. It doesn't guess which entries were breakfast, lunch, dinner, or running fuel.
The goal is to give each question the data it needs without making every review start with the entire export.
Keep the uncertainty visible
One of the most important parts of this project is resisting the temptation to make incomplete data look complete.
A scale reading and an app-generated weight trend are different things. An expenditure estimate is still an estimate. A nutrition target is different from what I logged eating.
The summary logic accounts for provisional days, partial logging, and missing values. A period's scale-weight change requires readings at the actual endpoints; if one is missing, it reports that rather than quietly substituting another date.
Some exported micronutrient values also have unresolved unit or scaling questions. The raw values are preserved, but they're excluded from the default compact analysis views rather than “corrected” by guesswork.
A chart can be attractive and still be misleading. I want the data underneath it to be understandable first.
Training needs context too
The toolkit also includes a read-only PowerShell exporter for my Intervals.icu calendar. It retains planned workouts, races, and their structured details in JSON. It's a one-off export helper, not a recurring synchronization service.
Alongside the data are reusable race and long-run checklists, event plans, fueling notes, and post-run review templates.
Those notes capture things a watch can't fully explain: how a run felt, what was uncomfortable, whether fueling worked, and what I want to change next time.
Keeping the numbers and the context is what makes the record useful.
Where this goes next
The next direction is a private workspace that makes recording and reviewing this information easier, with selected public charts and stories on this website.
I'd like a quick post-run form tied to the correct activity, closer connections between training and nutrition data, and eventually more convenient health-data updates.
Another future step is an MCP (Model Context Protocol) interface that lets AI tools work with selected toolkit data through clearly defined queries. The aim is to make AI-assisted review easier and more consistent, with results that identify the source records and dates they used. That would make an answer easier to check and follow up on, while keeping calculated facts separate from the AI's interpretation.
Those features aren't implemented yet. The working foundation today is local export processing, structured records, compact analysis views, and practical planning resources.
The website should receive intentionally selected public outputs. It doesn't need direct access to my private accounts or a copy of every raw export.
The same mindset, a different kind of system
This connects directly to how I approach the HomeLab: preserve the important information, document the process, and improve it when real use exposes a weakness.
The subject here happens to be my own health and training. The engineering problems are familiar—data ingestion, overlapping records, source tracking, useful summaries, and honest limits.
The point is to make the history easier to understand and the next decision better informed.