@@ -22,7 +22,7 @@ The manifest grows as the builder reads more settings from it. Campuses are list
 
 ## The dataset card
 
-Rock's installer shows a card for each dataset, so a church admin can choose one (decision D-rock-loader-5). The loader embeds these fields and serves them as `SampleDataDatasets` (see the [loader README](../loader/README.md#the-dataset-catalog)). Every field is required, and the builder refuses a manifest that is missing one.
+Rock's installer shows a card for each dataset, so a church admin can choose one (decision 124). The loader embeds these fields and serves them as `SampleDataDatasets` (see the [loader README](../loader/README.md#the-dataset-catalog)). Every field is required, and the builder refuses a manifest that is missing one.
 
 | Field | Meaning |
 |---|---|
 
@@ -19,13 +19,13 @@ This log wins over the [design spec](design-spec.md) wherever the two disagree.
 | 49 | 2026-10-16 | A dataset's manifest sets how many generated households each campus gets. Core 3 lists 75 at Peoria and 75 at Gilbert, and none at the main campus. `--crowd` still replaces it for speed tests. | Core 3 then matches decision 4 exactly, and the main campus holds only the Cast, as decision 3 promises. |
 | 52 | 2026-10-16 | Each package is for one exact Rock. Its `package.json` records the Rock version and that Rock's newest migration, and the loader refuses a database whose newest migration differs. Development loads can override this with a warning; Rock's own installer cannot. Each Rock release gets its own packages. | The loader writes straight into Rock's tables, so a schema change can break a load partway. A Rock database stores no version number, but its newest migration identifies its schema exactly. |
 | 66 | 2026-10-19 | A package is published only with a passing receipt from the [verify tool](../verify/README.md). The tool loads each package into a trusted base made from the same Rock release (Rock's migrations, start-up steps, and first-night post-install job, nothing else), checks the loader's recorded contract against Rock's schema, runs the invariants, runs Rock's own Rock Cleanup job as a referee, and checks the content standards. It runs when packages are made, never when a church installs one. | The loader skips Rock's business logic, so nothing in Rock says when the data is wrong. A receipt proves each exact package works on its exact Rock, and turns written rules into checks that fail. |
-| D-rock-loader-1 | 2026-10-21 | The loader library builds for both .NET 10 and .NET Framework 4.7.2 from one source, and ships as the `SparkDevNetwork.Rock.SampleData.Loader` NuGet package with both. The .NET Framework build depends on the exact package versions Rock ships. The few .NET 10 features it lacks are internal shims in `loader/compat/`, or call sites written a way both understand. The builder, CLI, and verify tool stay .NET 10 only. | Rock runs on .NET Framework 4.7.2, and the same code must install the same data in Rock as on the command line. Rock's versions keep the package from adding a second version of any assembly to RockWeb/bin. `loader-compat-check/` proves the key derivations behind check scanner fields and mentions give the same bytes on both. |
-| D-rock-loader-2 | 2026-10-21 | A load can choose its parts: photos, attendance and check-in, small groups, serving, giving, check images, prayer, and notes. Church setup and people always load. `SampleDataParts.All` is the one table of parts, their names, and what each needs: check images need giving, and prayer needs small groups. Every part is still planned in memory, and only the writes of parts not chosen are skipped. Cast expectations check only the parts that loaded. | A demo site may not want every part, and check images are slow. Planning everything keeps every seeded stream the same, so a chosen part looks exactly as it does in a full load. A part needs another only when its rows point at that part's rows: an image points at its gift, and some Cast prayer requests point at a small group. |
-| D-rock-loader-3 | 2026-10-21 | The loader refuses a database with any person beyond the five a new Rock install creates: Admin (Person Id 1, since its Guid differs between installs), Anonymous Giver, Presence, Anonymous Visitor, and System Sender. RestUser records never count. `DatasetLoader.CheckDatabase` reports this, and the migration match when given a package, before a load. The load takes an exclusive SQL Server application lock in its transaction and checks again inside it. Rock's block has no override. | It enforces decision 1 in code. A person can never add sample data to a database with real people or with sample data already, and two loads started at once cannot both pass, even on two web servers. |
-| D-rock-loader-4 | 2026-10-21 | The hosted package list is `index.json` (format 1): a list of packages, each with its dataset, name, description, people and campus counts, release version, URL (absolute or relative to the index), the .zip's SHA-256 and size, and its Rock version and migration. `SampleDataPackageIndex.Parse` reads it. The format is in the [loader README](../loader/README.md#the-package-index). | Rock's block can list what it can install, and which Rock each package is for, without downloading any package. The checksum lets it check a download before opening it. |
-| D-rock-loader-5 | 2026-10-21 | Each dataset manifest (`datasets/*.json`) holds its card for Rock's installer: a summary, what it is best for, two to four highlights, and its people, households, campuses, and typical install time, measured from real loads. The loader embeds the manifests, and `SampleDataDatasets` reads them. The builder refuses a manifest without a card, and the verify tool fails a default-seed load whose people or households differ from the card by more than 2%. | Rock's block shows every dataset before it downloads one, from the loader it already has. The card sits beside the settings that make the dataset, and verify keeps its numbers from going stale. |
-| D-rock-loader-6 | 2026-10-21 | Steps are their own part, `Steps`, loaded after notes. Choosing steps loads small groups, serving teams, and giving too. The part holds both step programs, the Discipleship Path and the Student Path (decisions 115 to 119). The Student Path's student check-ins come from the attendance plan, not the attendance rows, so steps do not need the attendance part. Steps plan only when they load, and Cast step stories, the students' among them, are checked only when steps loaded. | Steps are a feature a person can want or not, like prayer or notes. Each Small Group, Serve, and Lead step copies a membership that small groups or serving wrote, open requests to serve come from serving, and each Give step must agree with the journey stage giving writes. So a step needs those rows to be true, which widens the rule in decision D-rock-loader-2 from rows that point at another part's rows to rows that must agree with them. The attendance plan holds exactly the check-ins the attendance step writes, so the student steps are the same as in a full load whether or not attendance loads, and choosing steps does not also force attendance. Without attendance, Rock shows student steps without the check-ins behind them, the way adult steps already count family Sundays from the plan. Nothing after steps reads them, so leaving them out changes no other part. |
-| D-rock-loader-7 | 2026-10-22 | The building campaign (decision 109) is church setup, not a part. Its fund, campus accounts, campaign dates, Create Pledge page, and statement template settings load with configuration in every load. The fund's goal, written into its description from the planned pledges, is written in every load too. The pledges and campaign gifts, the Cast's (decisions 110 to 112) and the Crowd's and businesses' (decisions 113 and 114), belong to the Giving part. They are written in the Giving step, not a step or part of their own, and the Cast's campaign stories are checked only when giving loaded. All pledges are planned in every load, before giving is planned. | A fund, its accounts, and page settings are setup a church has before anyone gives, like the funds and campus accounts that already load with configuration. A person who leaves out giving still gets a Create Pledge page that works. Pledges and campaign gifts are giving records. Most campaign gifts are a line on a usual gift, so they cannot load without giving, and a pledge without its gifts would show every pledger as not started. Planning the pledges in every load keeps the giving plan the same, so prayer, which reads that plan, does not change when giving is left out. It also keeps the fund the same in every load, since its goal comes from the pledged total. The generated pledgers are drawn from the giving patterns people carry, which always load, so the draw needs no other part. No other part reads pledge rows. |
+| 120 | 2026-10-21 | The loader library builds for both .NET 10 and .NET Framework 4.7.2 from one source, and ships as the `SparkDevNetwork.Rock.SampleData.Loader` NuGet package with both. The .NET Framework build depends on the exact package versions Rock ships. The few .NET 10 features it lacks are internal shims in `loader/compat/`, or call sites written a way both understand. The builder, CLI, and verify tool stay .NET 10 only. | Rock runs on .NET Framework 4.7.2, and the same code must install the same data in Rock as on the command line. Rock's versions keep the package from adding a second version of any assembly to RockWeb/bin. `loader-compat-check/` proves the key derivations behind check scanner fields and mentions give the same bytes on both. |
+| 121 | 2026-10-21 | A load can choose its parts: photos, attendance and check-in, small groups, serving, giving, check images, prayer, and notes. Church setup and people always load. `SampleDataParts.All` is the one table of parts, their names, and what each needs: check images need giving, and prayer needs small groups. Every part is still planned in memory, and only the writes of parts not chosen are skipped. Cast expectations check only the parts that loaded. | A demo site may not want every part, and check images are slow. Planning everything keeps every seeded stream the same, so a chosen part looks exactly as it does in a full load. A part needs another only when its rows point at that part's rows: an image points at its gift, and some Cast prayer requests point at a small group. |
+| 122 | 2026-10-21 | The loader refuses a database with any person beyond the five a new Rock install creates: Admin (Person Id 1, since its Guid differs between installs), Anonymous Giver, Presence, Anonymous Visitor, and System Sender. RestUser records never count. `DatasetLoader.CheckDatabase` reports this, and the migration match when given a package, before a load. The load takes an exclusive SQL Server application lock in its transaction and checks again inside it. Rock's block has no override. | It enforces decision 1 in code. A person can never add sample data to a database with real people or with sample data already, and two loads started at once cannot both pass, even on two web servers. |
+| 123 | 2026-10-21 | The hosted package list is `index.json` (format 1): a list of packages, each with its dataset, name, description, people and campus counts, release version, URL (absolute or relative to the index), the .zip's SHA-256 and size, and its Rock version and migration. `SampleDataPackageIndex.Parse` reads it. The format is in the [loader README](../loader/README.md#the-package-index). | Rock's block can list what it can install, and which Rock each package is for, without downloading any package. The checksum lets it check a download before opening it. |
+| 124 | 2026-10-21 | Each dataset manifest (`datasets/*.json`) holds its card for Rock's installer: a summary, what it is best for, two to four highlights, and its people, households, campuses, and typical install time, measured from real loads. The loader embeds the manifests, and `SampleDataDatasets` reads them. The builder refuses a manifest without a card, and the verify tool fails a default-seed load whose people or households differ from the card by more than 2%. | Rock's block shows every dataset before it downloads one, from the loader it already has. The card sits beside the settings that make the dataset, and verify keeps its numbers from going stale. |
+| 125 | 2026-10-21 | Steps are their own part, `Steps`, loaded after notes. Choosing steps loads small groups, serving teams, and giving too. The part holds both step programs, the Discipleship Path and the Student Path (decisions 115 to 119). The Student Path's student check-ins come from the attendance plan, not the attendance rows, so steps do not need the attendance part. Steps plan only when they load, and Cast step stories, the students' among them, are checked only when steps loaded. | Steps are a feature a person can want or not, like prayer or notes. Each Small Group, Serve, and Lead step copies a membership that small groups or serving wrote, open requests to serve come from serving, and each Give step must agree with the journey stage giving writes. So a step needs those rows to be true, which widens the rule in decision 121 from rows that point at another part's rows to rows that must agree with them. The attendance plan holds exactly the check-ins the attendance step writes, so the student steps are the same as in a full load whether or not attendance loads, and choosing steps does not also force attendance. Without attendance, Rock shows student steps without the check-ins behind them, the way adult steps already count family Sundays from the plan. Nothing after steps reads them, so leaving them out changes no other part. |
+| 126 | 2026-10-22 | The building campaign (decision 109) is church setup, not a part. Its fund, campus accounts, campaign dates, Create Pledge page, and statement template settings load with configuration in every load. The fund's goal, written into its description from the planned pledges, is written in every load too. The pledges and campaign gifts, the Cast's (decisions 110 to 112) and the Crowd's and businesses' (decisions 113 and 114), belong to the Giving part. They are written in the Giving step, not a step or part of their own, and the Cast's campaign stories are checked only when giving loaded. All pledges are planned in every load, before giving is planned. | A fund, its accounts, and page settings are setup a church has before anyone gives, like the funds and campus accounts that already load with configuration. A person who leaves out giving still gets a Create Pledge page that works. Pledges and campaign gifts are giving records. Most campaign gifts are a line on a usual gift, so they cannot load without giving, and a pledge without its gifts would show every pledger as not started. Planning the pledges in every load keeps the giving plan the same, so prayer, which reads that plan, does not change when giving is left out. It also keeps the fund the same in every load, since its goal comes from the pledged total. The generated pledgers are drawn from the giving patterns people carry, which always load, so the draw needs no other part. No other part reads pledge rows. |
 
 ## Time