<a id="ch-11"></a>

## Chapter 11 — Customer names stay off the ledger

<!-- open-cyber-academy:lesson-figures:start ch-11 -->
### Lesson map

Lesson 11. Map, example, EX057.

```mermaid
flowchart TD
  A["Names, emails, purchases: Copperleaf's database"] --> B["Ledger: addresses and point balances"]
  B --> C["Checklist row is already met"]
  C --> D{"Does a new-address offer complete a reissue?"}
  D -->|No| E["Leave names off and the offer unfinished"]
```

The passing privacy row stays a pass only while the names stay off.

### Logical drawing

```text
off the ledger
    customer names, emails, purchase details
on the ledger
    pseudonymous addresses and point balances
offer, not a completed act
    a new address if a customer requests one
```
<!-- open-cyber-academy:lesson-figures:end ch-11 -->

### Learning outcomes

After this chapter, you should be able to:

1. Place names, emails, and purchase details off the ledger.
2. Keep the checklist row that already passes.
3. Leave the new-address offer as an offer.

### 11.1 Off-ledger data can still be corrected.

The ledger in this proposal stores pseudonymous addresses and point balances. Customer names, emails, and purchase details stay in Copperleaf's own database. That split is why the checklist row "customer names kept off the ledger" is marked met, and why the print does not list it as a gap. The reason is practical as well as technical. Personal data kept off the shared record can be corrected or deleted when a customer asks, which is the privacy point chapter 3 already made. Putting a name on the ledger to make support easier would flip a passing row into a failing one and would make correction harder. The vendor also agrees to issue a new address if a customer requests it, as a remedy against linkage. The manuscript records the agreement. It does not record a customer who asked, an address that was replaced, or a count of reissues. An offer on request is not a completed reissue. No customer is named anywhere in the file, and this lesson does not add one. The row stays met because the names stay where chapter 3 put them.

### 11.2 Worked example

Move a fact onto the ledger only if the file already put it there.

| Item | Where the file puts it | Decision |
|---|---|---|
| Names, emails, purchase details | Copperleaf's database | Leave them there |
| Addresses and point balances | The ledger | Leave them there |
| "Customer names kept off the ledger" | A met checklist row | Leave the pass |
| A new address on request | An offer, not a finished reissue | Do not mark it done |

> **Synthetic case.** No customer's name is used. The database and the ledger are parts of the fictional map.

### Errors and limits

A met privacy row is not a reason to relax it. The new-address offer does not show that any address was changed.

### Apply

- **EX057 — Where do the names go?** A proposal puts customer names on the ledger so the tills can read them, and treats the new-address offer as a reissue already completed. What stays off, and what is the offer? *Rubric:* 3 = names, emails, and purchase details stay off the ledger; the checklist row stays met; the new-address offer stays a request, not a completed reissue;; 2 = names stay off and the offer stays unfinished;; 1 = one location;; 0 = none.

<!-- open-cyber-academy:chapter-navigation:start ch-11 -->
### Continue studying — lesson 11 (chapter 11 of 20)

[← Chapter 10](#ch-10) · [Course chapter index](../SUBJECTS.md) · [Chapter 12 →](#ch-12)

Continue to the next authored lesson.
<!-- open-cyber-academy:chapter-navigation:end -->

## Worked answers

<a id="answer-ex057"></a>
**EX057.** Names, emails and purchase details stay off the ledger. The new-address offer stays a request, not a completed reissue.
