How to build a company brain, part 7: the rules, and how to keep personal data out

Every agent and every person at Kranich follows these.

• Never delete anything. If something looks redundant, report it and let a person decide.
• Never move originals. Copy them, and note in the manifest where the copy came from.
• Never invent a date, an amount or a document. Write "unknown" and say what would confirm it.
• Read the folder's summary first. It tells you what's missing and what isn't to be trusted.
• Agents draft. People send, pay and file. The brain can prepare INV-2026-041 and remind the founder it's due. Only the founder sends it.

Write short, plain sentences that a new teammate understands. No marketing voice and no filler. Anything a customer will read follows the copy guide and is never improvised.

A knowledge page describes how things are now, and the history goes to the decision log. Measured facts (seen, counted) stay apart from inferred ones (our reading of them). And when something isn't known, the page says "unknown" and names what would confirm it.

1. What never goes in. There's a written list: personal details of team members, HR matters, private finances, credentials, keys and tokens, customers' personal data, raw data dumps. A lint check scans new files for these patterns and stops the sync if it finds one.

2. Zones. One quarantined folder holds customer conversations. It's the only place customer personal data may live, and it is never indexed, so neither keyword search nor embedding search can return it. What leaves the folder is anonymised themes, such as "12 customers asked for a waitlist this month". When a customer asks for their data to be erased, their folder is deleted. That is the right GDPR Article 17 describes. The same article makes an exception for data you're legally obliged to keep, so records like invoices follow their own retention rules. Credentials are listed by file name only, and no agent opens them.

3. Redaction at the boundary. Before a search result reaches an agent, a redaction step runs. Bank account numbers keep only the country code, the check digits and the last four digits. Passport numbers, personal tax IDs, social security numbers and dates of birth become [redacted]. Company identifiers such as the register number and the VAT ID stay visible, because an agent writing an invoice needs them.

4. A guard in front of every model that isn't approved for personal data. The guard either blocks the request or swaps personal data for placeholders such as [E-Mail], [Phone], [IBAN] or [Name], then puts the real values back into the answer where they're needed. It flags too much on purpose. Sending a doubtful request to the approved model costs little. A leak costs a lot.

Redaction is only as good as its patterns, and patterns have holes. In one of my brains, tests with fake documents found two: an ID number format the patterns didn't cover, and the machine-readable lines printed on a passport, whose format is set by ICAO Doc 9303. Both were fixed before any real document went through.

So write the tests first. Plant fake personal data, run a search and a model call, and check that none of it shows up in any request going out to a search provider or a model.

Goal: add a redaction step to our brain search, with tests.

Inputs: the search code in this repository. Fake data only. Do not open any real document or anything in the credentials folder.

Do this: before search results go to an agent, mask IBANs to the country code, check digits and last four digits. Replace passport numbers (including the machine-readable lines), personal tax IDs, social security numbers and dates of birth with [redacted]. Keep company register numbers and VAT IDs visible.

Constraints: write the tests before the patterns. Invent every test value yourself. Do not send any test data to an outside service.

Definition of done: the tests run, and you show me which patterns fail before you fix them, then the passing run after.