A record you can trace back to.

MovePacket is being built as a dependable system of record for athlete data. The first foundation is an original file that stays unchanged, a stable activity ID, and inspectable processing details.

A system of record preserves evidence and its history. It does not certify that every sensor measurement is accurate or that an application’s interpretation is correct.

What the beta records#

Identical bytes uploaded within one workspace reuse the activity ID. This does not identify two different files as the same real-world session. Cross-source duplicate reconciliation is planned.

Inspect and verify a record#

Open a ready activity from Data. Source and parser details shows its record ID, parser, decoded schema and recording checksum. For compressed imports, the checksum identifies the recording, not the compressed original file.

Original file and Full decoded data download the preserved original and the decoded JSON. Download both when moving the activity into another system. The quickstart demonstrates checksum verification from your server. A matching checksum confirms that the retrieved bytes match the stored record; it does not verify device calibration, athlete identity, consent or coaching conclusions.

Where the record stops today#

The beta does not record a provider account connection, verified athlete identity, athlete consent, complete access history or a complete sequence of reprocessing versions. Missing links are shown as unavailable rather than inferred from device fields.

Workspace and scoped app access are enforced server-side. Owner tools support a workspace processing pause and a bounded procedure for linked live athlete-data deletion. Request tracking alone does not execute these controls. Linked app content, unassigned information, backups and outside services need separate review; complete transformation history is not available. See Privacy operations for the supported steps and limits. These controls are not a claim of complete compliance.

Shared responsibility#

MovePacket operates the storage, file processing and workspace access in this service. It preserves source files and provides authenticated retrieval and integrity verification.

Your coaching business establishes permission to use athlete data and determines how it should be used. Your application must enforce its own end-user permissions, protect downloaded copies and server keys, and control its coaching recommendations and decisions. A broad workspace credential is not an athlete-specific grant; use the supported scoped access where applicable.

The intended product direction is to make these responsibilities easier to meet with built-in access controls, traceability and portable records. Operational responsibilities need to be supported by the service terms and applicable data-processing arrangements; this guide does not assign legal controller or processor status.

Evidence before interpretation#

Keep original evidence separate from derived results. When your software computes aggregates or prepares context for AI, retain the activity references, source window, units, missing-data information and method version needed to explain the result.

Coaching judgments, readiness scores, training recommendations and race strategy belong in the application built on MovePacket. See the data model for the beta’s exact fields and units.

Business and athlete packages#

The workspace owner can use Settings → Privacy & exports to prepare a private business archive or an athlete-specific review package. It includes available records, original uploads, decoded files and relevant projects, plus a guide and SHA-256 manifest. Packages expire after 24 hours and require owner sign-in to download. Preparation failures and missing referenced objects are reported; a partial archive is not labelled ready. Larger packages beyond the current 2 GiB, 2,000-file or metadata limits require assistance.

Athlete packages depend on explicit associations. Unassigned records are counted for review and remain in the business export. App builders can associate their records with athletes. Shared records and notes need review before release to avoid exposing another person’s information.

The request log records receipt, a one-month target, identity verification, review history and the coach’s response. It does not send the response or automatically delete or restrict information. Requests may also require privacy information, records held outside MovePacket and legal review.

Athlete context supplied by apps#

Athlete memory can retain selected information collected by an authorised app. Data → athlete → Athlete memory shows that information with its source and dates. Enter and update it in the source app; Data has no context editor.

Supported structured context includes daily availability, a weekly time budget, reported strength-training experience, goals and practical constraints. Availability uses minutes, keeps unknown separate from zero, and supports a recurring week plus dated exceptions. Dates use the timezone supplied with the athlete context.

Only promote information needed for the supported task. For example, record an unavailable evening without copying a private family explanation. No diagnoses, payment details or conversation transcripts are part of these structured types. Short descriptions are source-supplied text, not automatically screened or verified by MovePacket.

An app must already have owner-configured rights for the specific athlete. Its server key cannot grant itself access. Keep context private to the source app unless the owner has granted sharing and the app explicitly selects it. Another app needs its own read permission. Access to a workspace or a published page alone is insufficient.

Current context requires a refresh deadline. Availability, budgets and constraints expire within 90 days of confirmation; goals and reported training history within 366 days. Apps can set shorter periods. Expired entries stop appearing in current memory and become eligible for bounded cleanup 30 days later. This removes the promoted copy, not its original app record, exported copies or backups. Source edits, withdrawal and revoked grants can remove it from current memory sooner.

Server integration

Use GET /v1/software/{app}/memory/{athlete} to read permitted evidence. Each structured entry includes a context description with its type, applicable dates, timezone and current or scheduled status. Do not treat a future schedule as today's availability. Claims from different apps remain separate; MovePacket does not choose a winning claim or calculate a training recommendation.

To supply context, first save a private app record associated with exactly one athlete. Explicitly promote its selected field with POST to the same memory endpoint. The request identifies the source; it cannot supply a replacement value. For example, the source record can contain:

{
  "availability": {
    "schema_version": "1",
    "reported_by": "athlete",
    "confirmed_at": "2026-09-22T00:00:00.000Z",
    "timezone": "Australia/Sydney",
    "valid_from": "2026-09-22",
    "valid_until": "2026-09-28",
    "minutes_by_weekday": [null, 0, 90, 60, 30, 180, 120],
    "exceptions": [{"date": "2026-09-25", "minutes": 0}]
  }
}

The seven values run Monday through Sunday. null means not supplied; zero means unavailable. A dated exception replaces that day's recurring value, including an explicit unknown. The corresponding promotion is:

{
  "record_key": "week_39",
  "path": "$.availability",
  "kind": "preference",
  "key": "context.availability.week_39",
  "unit": null,
  "visibility": "app_private",
  "effective_at": "2026-09-22T00:00:00.000Z",
  "expires_at": "2026-09-28T14:00:00.000Z",
  "request_id": "availability_week_39_v1",
  "supersedes": null
}

These are illustrative dates; supply real confirmation, applicability and expiry dates. confirmed_at is the source app's claim about confirmation, not proof of athlete identity or consent. Confirmation must be no later than effective_at, which must not be in the future. expires_at must still be in the future, within the type's refresh limit and no later than the end of valid_until in the supplied timezone.

Every type requires schema_version, reported_by (athlete or coach), confirmed_at, timezone, valid_from and valid_until. Additional required fields are:

Unknown fields and types are rejected. All structured values have unit: null; minute fields carry their own explicit units. The selected source object must fit within 1,200 UTF-8 bytes. History here means reported experience; earlier versions of all types are retained separately until their retention limit or deletion applies.

Availability, budget, goal and constraint keys can have a stable suffix of up to 40 lowercase letters, digits, underscores or hyphens. Use distinct period keys for future schedules so current availability stays available. Replacing a head is immediate: provide its evidence ID in supersedes, preserve the same app/athlete/key, and use a new request ID. A change to the underlying source record invalidates its earlier promoted claims, so use separate source records for independently changing periods. Repeating an identical promotion request is idempotent.

Use DELETE on the memory endpoint with {"id":"mem_…"} to withdraw your app's evidence. Current reads stop returning it; withdrawal is not immediate deletion of the original record or retained history. Owner privacy/export procedures still apply. These endpoints require a supported server integration; credentials must never be placed in a browser page.