---
title: "Re-rating: a point in time, one rule book per version"
description: "A TrackForge rating is an event: computed from evidence as of stated dates, under one rule-book version, immutable once issued. A new rating supersedes the last. A draft stored under an older rule book keeps its version and hash and does not reproduce under a newer one."
image: "https://trackforge.studio/docs/img/trackforge-social-card.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://trackforge.studio/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Re-rating: a point in time, one rule book per version

A rating is not a scorecard that updates as the catalogue changes. It is an **event**: a survey run at a moment, under one version of the rule book, written down and never edited.

## A point in time

Every source the survey reads is dated: the tuple's `as_of_by_source` field records, for each source, the date its reading was true as of. The rating is as good as its freshest readings and as old as its oldest, and it says which is which. A reading older than its route's age limit never decides a state; with none fresh, the work is not checked, stale.

## Issued events are immutable

When a rating is issued, its tuple and hash are written to the ledger and cannot be changed. A later survey of the same catalogue writes a new event, which **supersedes** the last; the earlier event stays in the ledger as history. A survey that would produce a tuple identical to the one already stored is refused, and nothing is written: nothing has changed, so there is nothing new to say.

A survey can also be stored as a **draft**: the same tuple, computed and recorded, but not issued and superseding nothing. Drafts are how the method is calibrated on real catalogues before the rule book is frozen.

## One rule-book version per slice

The rule book changes in versions. Each slice of the build gives it one new version; a rule edit inside a slice changes the rule book's hash but not its number. When the method is frozen, the frozen version keeps its number and its status changes from draft to published. There is no silent drift: a rating always names the version and hash it was computed under.

## A draft under an older rule book does not reproduce under a newer one

Reproducing a rating means recomputing its tuple from its stored rows under its own rule book and getting the same hash. A draft stored under an earlier rule-book version carries that version and that hash. Recomputed under the current rule book it gives a different tuple, because the rules moved. The proof bundle says so when it happens, and names both versions. This is the intended behaviour: the alternative, a rating that quietly changes its meaning when the rules change, is what the versioning exists to prevent.

## Comparing two ratings

Two ratings of one catalogue can be compared directly when they share a rule-book version; the before-and-after view of a remediation links them, with `remediated_by` saying who did the work ([independence](/docs/certification/rating/scope-and-independence)). Two ratings under different versions are not directly comparable, and a comparison across versions carries a bridge note saying what changed between them.

## When to re-rate

A rating is re-run when the catalogue has changed (works added or sold, registrations landed, claims resolved), when the sources have moved on enough that readings are going stale, or when the rule book has a new version and the owner wants the catalogue rated under it. Each run reads the sources afresh; nothing is carried over from the last rating except the population's work keys, which never change.

Source: https://trackforge.studio/docs/certification/rating/re-rating/index.mdx