> ## Documentation Index
> Fetch the complete documentation index at: https://docs.amazingzebra.com/table-mutation-tracker/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Catch retroactive grade and assignment changes in a student information system, and see exactly what changed and when.

A student information system (SIS) parent portal shows the current state of every class. It does not show history. When a teacher changes a grade from two weeks ago, deletes an assignment, or marks work as missing after the fact, the portal updates silently. Families notice only if they kept their own screenshots or spreadsheets.

Table Mutation Tracker keeps that history for you. It scrapes the portal on a schedule, stores every scrape as an immutable snapshot in a private Git repository, and shows the differences between snapshots on a calendar, in the style of the Internet Archive's Wayback Machine.

## Who it's for

The primary user is a parent following one student across six to eight classes. The same pattern applies to anyone who needs an audit trail for a system that only shows its present state.

## What you get

* **A calendar of changes.** Each day is colored by the most significant change it contains: deletions, then modifications, then additions.
* **Field-level detail.** Open a day to see each changed assignment, with the old and new score, grade, category, comment status, and status flags such as late or missing.
* **A deleted-assignments history.** Every assignment that disappeared, with when it was first seen and when it was removed.
* **Weighted GPA over time**, computed from each snapshot's class grades.
* **An audit trail you can point to.** Every snapshot is a Git commit with a timestamp.

> [!NOTE]
>
> Grades in the portal are the source of truth. This project records what the portal showed at each scrape so changes can be discussed with evidence, not memory.

## Explore the docs

> [card] [How it works](https://docs.amazingzebra.com/table-mutation-tracker/concepts/how-it-works.md)
>
> The five runtime boundaries and what each one is trusted with.

> [card] [Change detection](https://docs.amazingzebra.com/table-mutation-tracker/concepts/change-detection.md)
>
> How two snapshots are compared, and what counts as a change.

> [card] [n8n workflow](https://docs.amazingzebra.com/table-mutation-tracker/guides/n8n-workflow.md)
>
> The daily pipeline, node by node, including its fallback path.

> [card] [Runbook](https://docs.amazingzebra.com/table-mutation-tracker/operations/runbook.md)
>
> Deploy, rebuild the index, rotate secrets, and generate test data.

> [card] [Data model](https://docs.amazingzebra.com/table-mutation-tracker/concepts/data-model.md)
>
> Snapshot files and the rolling index, field by field.

> [card] [API reference](https://docs.amazingzebra.com/table-mutation-tracker/api-reference/overview.md)
>
> The scraper endpoints that n8n calls.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.