> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mov-eat.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Weight tracking

> How body weight logs and profile weight snapshots work.

# Weight tracking

Weight tracking records body weight over time and keeps the user's profile current.

## Business goal

The product should let users see progress without forcing them to manage unit conversion or duplicate data manually.

## Canonical storage

Platform stores body weight in kilograms.

When the user prefers imperial units, Platform converts values for display. The client should render the returned value without doing its own conversion.

## Weight log

A weight log represents one measurement at a point in time.

Typical fields:

* ID.
* Weight display value.
* Logged timestamp.

The canonical `weight_kg` value remains in the database even if the API response only exposes the display value.

## Current weight snapshot

The profile stores `current_weight_kg` as a convenience snapshot of the latest known body weight.

This is not a replacement for weight history. It exists to make common reads easier.

## API behavior

Weight APIs should support:

* Create a new weight log.
* Read latest weight.
* Read historical logs.
* Optionally filter by date range.

Default reads should be useful without forcing the frontend to pass arbitrary limits.

## Unit system response policy

A good response shape is:

```json theme={null}
{
  "unitSystem": "IMPERIAL",
  "weightLogs": [
    {
      "id": "...",
      "weight": 180.0,
      "loggedAt": "2026-06-13T10:00:00.000Z"
    }
  ]
}
```

The unit system belongs to the response wrapper because it describes how all values are rendered.