> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/roadmap/module-3-the-registry-block/3.6-account-for-every-load.md). # 3.6 Account for every load After every load, show that the rows received equal the rows passed plus the rows set aside, and that the rows approved equal the records the register added or changed. {% embed url="" %} Account for every load (\~3 min) {% endembed %} **Watch first (\~3 min).** Then read on: the page carries what the video says, and the AI usage tip. > **Single message.** After every load, show that the rows received equal the rows passed plus the rows set aside, and that the rows approved equal the records the register added or changed. ## The concept After a load, a director asks a simple question: did every learner the schools sent reach the register? Most teams answer with a feeling. You can answer with two lines of arithmetic, and show your working. The first line is about the checks. The rows received must equal the rows that passed plus the rows set aside at bronze. If they do not, rows were lost or counted twice inside the load. The second line is about the register. The rows approved at staging must equal the records the register added plus the records it changed. If they do not, the load did not write what the officer approved. The numbers come from things the GovStack Digital Registries specification already requires. The register logs every change, and shows the value before and after. It can import data and update entries. It answers statistical queries, such as how many records it holds, and it has an operation that says whether a given record exists. So the reconciliation needs no new system. Count the tiers, read the log, and read the record count before and after. Be clear with your readers on one point. No published source describes this reconciliation, neither the GovStack specification nor Giga's flow. It is the practice of the team that wrote this course, built on what the specification does publish. Present it to your auditors that way; it is simple enough for them to check. And keep one hard rule. A line that does not balance stops the next load until someone finds where the rows went and writes down the cause. The walkthrough of this subtopic shows one load of Progressa learners reconciled on a single sheet: rows received, passed, set aside, approved, added and changed, and the register's record count before and after. A good run passes when both lines balance and a sample of the loaded records is confirmed to exist in the register. {% hint style="info" %} **Demonstration.** The reconciliation of one load. It needs RG7 and RG11. Until it is recorded, the storyboard in the script stands in its place; see the [build plan](/experience-digital-transformation/roadmap/the-build-plan.md). {% endhint %} ## Your turn โ€” Write the reconciliation note of a load {% hint style="success" %} **๐Ÿ’ก AI usage tip** ยท Write the reconciliation note of a load **Bring:** The counts of each tier of one load, the register's record count before and after, and an extract of its change log. **Get:** A reconciliation note with both lines computed, and a list of every difference to investigate. **Time:** \~10โ€“15 min ยท **Assistant:** any; the tips are tool-neutral. **Watch for:** A difference is investigated, never explained away by the prompt. {% endhint %} **The problem it solves.** Counting a load is easy; writing it up so that a director or an auditor can follow it is where teams stop. This prompt takes the counts of one load and an extract of the register's change log, computes both lines and names every difference. {% tabs %} {% tab title="Prompt" %} Copy the prompt, replace the bracketed parts with your own context, and run it in the AI assistant of your choice. Never paste personal data or unpublished documents โ€” see [How to use the plays](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/how-to-use-the-plays). ``` Below are the counts of one load into our learner register [paste]: rows received in raw, rows passed and rows failed at bronze, rows approved and rejected at staging. Below them are the register's record count before and after the load [paste] and an extract of its change log for the load, giving the number of records added and the number changed [paste]. (1) Compute line one: rows received against rows passed plus rows failed. (2) Compute line two: rows approved against records added plus records changed. (3) For each line, say whether it balances. (4) Where it does not, state the difference as a number and list the places in the load where the rows could have gone. Do not explain a difference away. Output: a reconciliation note with both lines computed, in five sentences or fewer, then the list of differences to investigate. ``` [Open in Claude](https://claude.ai/new?q=Below%20are%20the%20counts%20of%20one%20load%20into%20our%20learner%20register%20%5Bpaste%5D%3A%20rows%20received%20in%20raw%2C%20rows%20passed%20and%20rows%20failed%20at%20bronze%2C%20rows%20approved%20and%20rejected%20at%20staging.%20Below%20them%20are%20the%20register%27s%20record%20count%20before%20and%20after%20the%20load%20%5Bpaste%5D%20and%20an%20extract%20of%20its%20change%20log%20for%20the%20load%2C%20giving%20the%20number%20of%20records%20added%20and%20the%20number%20changed%20%5Bpaste%5D.%20%281%29%20Compute%20line%20one%3A%20rows%20received%20against%20rows%20passed%20plus%20rows%20failed.%20%282%29%20Compute%20line%20two%3A%20rows%20approved%20against%20records%20added%20plus%20records%20changed.%20%283%29%20For%20each%20line%2C%20say%20whether%20it%20balances.%20%284%29%20Where%20it%20does%20not%2C%20state%20the%20difference%20as%20a%20number%20and%20list%20the%20places%20in%20the%20load%20where%20the%20rows%20could%20have%20gone.%20Do%20not%20explain%20a%20difference%20away.%20Output%3A%20a%20reconciliation%20note%20with%20both%20lines%20computed%2C%20in%20five%20sentences%20or%20fewer%2C%20then%20the%20list%20of%20differences%20to%20investigate.) *(pre-fills the prompt in a new chat; check the bracketed parts before sending)* *What to bring and what you get are in the box above.* {% endtab %} {% tab title="Example input" %} {% hint style="warning" %} **Draft worked example, 2026-10-04.** Progressa is the fictional country used across these courses. The input below and the output in the next tab were made for this page by running the prompt once; they are shortened, and they have not been checked as the worked examples of the method have. {% endhint %} The bracketed parts of the prompt were replaced with the following: **\[paste] Counts of one load (invented: the term list of one pilot district).** Rows received in raw: 4,812. Passed at bronze: 4,590. Failed at bronze: 222. Approved at staging: 4,571. Rejected at staging: 19. **\[paste] Record count.** Before the load: 4,410. After the load: 4,576. **\[paste] Change log extract for the load.** Records added: 166. Records changed: 4,398. {% endtab %} {% tab title="Example output" %} {% hint style="warning" %} **Draft: model output, shortened and unverified.** Read it with the notes in the next tab, not on its own. {% endhint %} **Reconciliation note (draft)** Line one: 4,812 rows received against 4,590 passed plus 222 failed, which is 4,812; it balances. Line two: 4,571 rows approved against 166 records added plus 4,398 changed, which is 4,564; it does not balance, by 7 rows. The record count rose by 166, which equals the records added. Staging also balances: 4,571 approved plus 19 rejected is 4,590 passed. The next load waits until the 7 rows are found and the cause written down. **Differences to investigate** * 7 approved rows have no matching entry in the change log. They may have been refused by the register when written, for example by its rule on school codes or on a unique identifier. * They may be two approved rows for one learner, merged into one record at gold. * They may be rows identical to records already in the register, written without a logged change. * The change-log extract may cover a shorter time than the load. {% endtab %} {% tab title="Reading the output" %} This is the teaching part of the tip. Work through the output the way a chief architect would: what is earned, what is invented, what is missing.
1. The arithmetic is right and shown Both lines are computed with the numbers on the page, and the difference is stated as 7, not "about 0.2 per cent". The run added two cross-checks, staging and record count, that make the 7 rows easier to place.
2. The causes are places to look, not answers The list is plausible, but none of it is known. The third item is the dangerous one: "identical rows, no change logged" is the explanation a tired team will accept, and it would hide a write that failed. Each place must be checked in the logs before it is ruled in or out.
3. Look for where the 7 rows went A sample of the 4,571 approved rows should be confirmed in the register with its "exists" operation, and the 7 named row by row. Present the note as the team's own practice: no published source describes this reconciliation.
{% hint style="danger" %} **Safeguard.** A difference is investigated, never explained away by the prompt. Give the prompt counts and log extracts, never learners' personal data. {% endhint %} {% endtab %} {% tab title="What next" %} The note goes to the data steward and stops the next load until the 7 rows are explained. The share of rows passing bronze, 95.4 per cent here, is the measure the [roadmap](/experience-digital-transformation/roadmap/the-worked-examples/e7-progressas-education-dpi-roadmap-the-shape-of-the-document-with-the-first-horizon-in-full.md) sets at 95 per cent before wave 3; the checks behind it are in [3.4](/experience-digital-transformation/roadmap/module-3-the-registry-block/3.4-quality-checks-that-stop-a-bad-row.md). {% endtab %} {% endtabs %} ## Sources * GovStack Digital Registries specification, version 3.0-alpha (DRS-7, DRS-21, DRS-24, DRS-26; sections 8.1 and 8.2) โ€” --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/roadmap/module-3-the-registry-block/3.6-account-for-every-load.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.