Let the file system keep the seven-year rule

Keeping the books means keeping the law

Perso promises "The books stay on this device", so the device has to keep them the way the law says. I made Sweden's seven-year rule a property of two folders rather than a sentence in the terms.

Perso runs in the browser as a desktop. It has no sign-in, the files on the device are the user's, and once cached it works without a network.

The files live in the browser's storage, and Settings → Data & privacy is where that shows. Its rows include "Browser storage used", "Kept by law" (once a receipt or record is on the device) and "Protected from cleanup", which has an "Ask now" button that asks the browser for persistent storage. I put that row in Settings because a browser can clear what a site stores unless it has agreed to keep it.

Keep one store, not one per app

I put every app's files in one tree, and its top folders are fixed:

• Incoming: arrived, not yet filed
• Receipts: verifications, kept seven years
• Records: SIE4, bank statements, supplier files
• Files: everything else
• Trash, hidden: deleted, recoverable

Notes are files in that tree, and so are events imported from Google, Outlook or iCloud as .ics files, shown read-only in their own colour, with nothing sent anywhere.

Because notes, events and receipts share one tree, one export covers all of them, and whether a file is kept by law depends on its folder, not on the app that wrote it. The labels are written for people and the policies for the code, and in Receipts the two agree: "kept seven years" on screen, retain underneath.

Two folders refuse a delete

Receipts and Records both carry the retain policy. A file in either opens read-only, and Perso says it is kept by law. In Files, its Delete option is greyed out, with the note "Kept by law — this one cannot be deleted". In the Terminal, receipts and records give the date the law keeps them until.

Why put a law in a file system? Because a sentence in the terms can't stop a delete, and a folder policy can. Not because people can't be trusted with their own receipts, but because the law asks for them to be kept, and with nothing sent anywhere, there is no server copy to fall back on.

Two more rules sit beside it. No app may keep its home folder under Receipts or Records, since anything written there would be kept by law. And I gave the AI a rule of its own: a model may add files, never write over one.

A model that can't write over a file will do less, and I'd rather it did less than had the power to rewrite a verification. The activity log already records whether the user or the AI acted.

On my ventures page I describe Perso as "Intelligence you own and train". The owning is in this beta. The training isn't: longer questions need Perso's assistant, which isn't part of this beta yet.

Leave with the files and their dates

Owning the files includes leaving with them. "Export everything" saves every file on the device as one .zip. A README inside explains the dates: under Swedish law (bokföringslagen, BFL 7 kap. 2 §), accounting records (räkenskapsinformation) must be kept until the end of the seventh year after the calendar year in which their financial year ended. Each record is marked "policy": "retain" with a retainUntil date.

Why does a .zip need a README? Because files on their own can't tell anyone which of them the law still holds, or until when.

Say what was left alone. The README ends: "Perso built this archive on your device and did not send it, or anything in it, anywhere. Exporting removed nothing from Perso." Clearing the desktop ends the same way: "Your files and receipts are not touched."

The browser can still clear the books

The retain policy stops a delete inside Perso, but not a browser clearing its own storage. "Ask now" only asks, and the browser decides. Even when it agrees, clearing the browser's data still removes the books, so I'd treat the export as the backup.

Two tabs don't merge edits. When Perso is open in another tab, it warns that a document edited in both is saved by whichever tab saves last.

Settings → Integrations says connections are coming in a later release, and lists what waits for them: Fortnox (invoices, ledger and VAT), bookings, email, messaging and your website. Until then Perso declines rather than estimates: "I can't see your invoices yet. Fortnox isn't connected in this beta, and I'd rather not guess at figures." It's the rule from my ONEbasket case study, applied to invoices: a wrong price is worse than a missing one.

Owning your data means owning these trade-offs too. Perso 0.1.0 is a beta, and its wording may still change. If you keep books in Sweden and try it, I'd be glad to hear where the folders get in your way.