Lesson 19.1119.11 Each company's own rules and data

In everyday life. A bookkeeper who works for two firms keeps two sets of rules: one firm approves anything of $10,000 or more, the other anything of $2,500 or more. She never applies one firm's rule to the other's invoice, and when a firm leaves, she hands back its folders and shreds her copies.

What you will learn. How each company keeps its own rules, read in its own transaction, and how a company's data is loaded, exported and deleted, with proof at each step.

Why it matters. One company's rule applied to another's invoice is a wrong answer that looks right. And a company that leaves must take its data with it, with nothing left behind.

One request, start to finish. Luis asks the connector about purchase order PO-3103, for $2,688.00.

1. The tool opens Cedar Ridge's transaction, as every tool does (19.9).
2. It reads the purchase order, the invoice, and Cedar Ridge's own approval threshold, from tenant_settings, in the same transaction.
3. Code compares them: $2,688.00 is at least $2,500.00, so needs_approval is true. The model never does the arithmetic that decides a payment (Chapter 14).

Ana asks about PO-7005, for $7,350.00. Brightline's threshold is $10,000.00, so needs_approval is false. Same tool, same code, each company's own rule.

Where do a company's own rules live?

Per-company settings live in their own table, one row per company, read inside that company's transaction like any other data. There is no shared default that silently applies to everyone: a company without a settings row is a loading error, caught before its first tool call.

A company's data life completes Chapter 18's company life, which covered sign-in only:

What should you never store?

Data you never store cannot leak. Brightline's Chapter 17 banking file holds full account numbers and routing numbers. No tool ever returns them: find_vendor returns the last four digits only. So the loader cuts each account number to its last four digits before anything reaches the database, and drops the routing number. The banking table cannot even hold more: its column only accepts exactly four digits. Cedar Ridge sends last four digits from the start. A check in the lab confirms that no full account number exists anywhere in the database.

At work. In Lab 19, Task 4, Claude Code loads Cedar Ridge: 9 vendors, 20 invoices, 8 purchase orders, 3 policy documents and its threshold of $2,500.00. The loader reports one file it did not load, an old pasted email, because Luis, as AP lead, marked it as not counting (19.15). In Task 10, Juniper Trail Outfitters, a trial company, asks for its data and then leaves. Its export holds 2 vendors, 2 invoices and 1 purchase order, its passages without their embeddings, and nothing of anyone else's. After deletion: Every table now holds 0 rows for org_juniper (counted as the owner).

The operating rule: keep each company's rules in its own settings row, read in its own transaction. Load, export and delete one company at a time, through the policies, and prove each step. Do not store what no tool needs.

Figure 19.20. A company's data life, beside its sign-in life. Each step is one company at a time, and each is proved.