@@ -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 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.
+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)). Each release also copies them into its entries in the [package index](../loader/README.md#the-package-index), so a card change reaches Rock with the next release (decision 144). Every field is required, and the builder refuses a manifest that is missing one.
 
 | Field | Meaning |
 |---|---|
 
@@ -23,7 +23,7 @@ This log wins over the [design spec](design-spec.md) wherever the two disagree.
 | 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. |
+| 123 | 2026-10-23 | The hosted package list is `index.json` (format 1): a list of packages, each with its dataset, its dataset card (decision 144), 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. |
@@ -32,6 +32,7 @@ This log wins over the [design spec](design-spec.md) wherever the two disagree.
 | 129 | 2026-10-21 | A prerelease tag (`v1.1.0-beta.1`) publishes the loader as a NuGet prerelease and uploads its packages, but changes only `packages/index-prerelease.json`: the stable index plus the prerelease. A stable release writes both indexes. | Rock's installer block reads `index.json`, so a church never gets a prerelease. Testers point the block at the prerelease index instead. |
 | 130 | 2026-10-21 | Publishing stores no secrets. The publish job runs in the `release` GitHub environment, which needs a person's approval and allows only `main` and `v*` tags. It signs in to nuget.org with trusted publishing, and to Azure with OpenID Connect as an identity that trusts only that environment and whose only role is Storage Blob Data Contributor on the `sampledata` container. | There is no key to leak, rotate, or expire. The identity can write only sample data, and a person approves every publish. |
 | 136 | 2026-10-23 | Full 7's manifest lists the Crowd: 16,800 generated households, with 3,450 at Phoenix, 2,350 at Chandler, 2,300 at Gilbert, 2,250 at Peoria, 2,200 at Scottsdale, 2,150 at Goodyear, and 2,100 at Tempe. A load has 25,248 people in 16,967 households, businesses included, which is the about 25,000 people decision 2 promises. Unlike Core 3, the main campus gets generated households beside the Cast. The Crowd still gets no photos (decision 30). | Rock's installer installs only what the manifest lists, so until now Full 7 had only the Cast. Phoenix is the original and largest campus, so it gets the most. Chandler has three Sunday services and a large kids ministry, so it comes next. Tempe, the urban young-adult campus, gets the fewest. Household shapes do not change by campus, so the counts are the only way to size one. Each count stays under the campus's share of the address pool (3,600 at Phoenix and 2,400 at each other campus), with room for its businesses, so no household gets a made-up address. The Cast still lives only at the main campus (decision 3). |
+| 144 | 2026-10-23 | Each package index entry carries the whole dataset card from its manifest: the name, the summary as its description, what it is best for, the highlights, and the people, households, campuses, and typical install time. `release/merge-index.js` writes them, and `SampleDataPackageIndexEntry` reads them. The card fields are optional in format 1: a missing string reads as empty, missing highlights as none, and a missing number as 0, and an older loader skips them. `SampleDataDatasets` stays for the CLI, the verify tool, and as Rock's fallback. | Rock's installer can show the cards from the index, so a release updates them without Rock shipping a newer loader. Published entries keep their bytes, so an index from before this change still reads, and so does a newer index in an older loader. |
 
 ## Time
 
 
@@ -34,7 +34,7 @@ The words this project uses, in alphabetical order.
 | **Mass send** | An email, text, or push sent to 25 or more people at once. Calibration part 7 measures them. |
 | **Opportunity** | One way to serve that people can ask about, such as Greeter. Each opportunity places people on its serving team. |
 | **Package** | A zip the builder writes for one dataset and one exact Rock: data files only, never SQL, with a checksum for every file in `package.json`. |
-| **Package index** | `index.json`, the hosted list of packages that Rock's installer block reads, at `storage.rockrms.com/sampledata/packages/`. The release workflow merges each release into it and uploads it last (decision 128). |
+| **Package index** | `index.json`, the hosted list of packages that Rock's installer block reads, at `storage.rockrms.com/sampledata/packages/`. Each entry carries its dataset's card (decision 144). The release workflow merges each release into it and uploads it last (decision 128). |
 | **Pending** | A team member who has connected but is not serving yet. The team leader makes them Active after onboarding. The scheduler only schedules Active members. |
 | **Persona** | A behavior pattern, such as a weekly giver or a holiday-only attender. |
 | **Pledge** | A promise to give a total to a fund over set dates, with an optional frequency. Rock's Pledge Analytics compares it with what the giving unit gave. |
 
@@ -150,7 +150,7 @@ A manual run can also publish: run it on `main`, give a version, and tick "publi
 
 A tag never moves. If a run fails for a reason in the repository, fix it on a branch, land it on `main`, and tag the next version. Delete the failed tag only when nothing was published under it: check nuget.org and `storage.rockrms.com/sampledata/packages/v{version}/` first.
 
-Before a stable tag, read what it will ship: the cards in `datasets/*.json` become the index entries Rock shows, so their people and campus counts must match what each package loads.
+Before a stable tag, read what it will ship: the cards in `datasets/*.json` become the index entries Rock shows, every card field included (decision 144), so their text must be current and their numbers must match what each package loads.
 
 ### Releases so far