declownify is in development and has not been released. This statement describes the security design of the first release. Items marked pending or planned are not yet in place.

• declownify runs entirely on the user's computer. There is no declownify server, no user account with OKASHI SCHOOL LIMITED and no cloud copy of anyone's data.
• Return data leaves the computer only when the user submits to HMRC (and, once built, to Companies House). Reminder emails, if switched on, go out through the user's own email account.
• Government Gateway credentials stay on the user's computer: in the macOS Keychain, or on Linux in the user's own secret store or environment. They are read only at the moment of submission, are never logged and are never sent to an AI service.
• OKASHI SCHOOL LIMITED never receives any user's data or credentials.

• One process holds the secrets. The macOS app is one signed bundle. The Rust core is linked into it, and the SwiftUI layer handles only display, the Keychain, notifications, calendar access and file pickers. The app has no network port or socket that other programs could reach.
• Least authority in code. Each program in the core declares the capabilities it uses, and nothing else is available to it. For example, the scheduled background check cannot submit a return or read a secret.
• External tools run as child processes. These are the schema validators, the email tool and the optional AI assistants. Each one gets a time limit, capped output, a fresh temporary working directory and a minimal environment that contains no declownify secret. On timeout the whole process group is killed.

HMRC's Transaction Engine has no OAuth. Its protocol requires the company's Government Gateway user ID and password inside each message, sent over TLS. declownify handles them as follows.

• macOS: they are stored in the user's login Keychain. Access is tied to the app's code signature.
• Linux: they are read from the user's own rageveil store or the environment.
• Read at the moment of use, then dropped. They are read when a message that needs them is about to be sent, placed in its header and discarded once it is sent.
• Kept out of everything else. They never appear in logs, incident files, the local database, AI prompts, command-line arguments, child-process environments or scheduler files.
• Enforced in code. The secret type cannot be printed, serialised or logged. Request logs record a SHA-256 hash of the message body and the IRmark, never the envelope. The archived copy of each submission has the password removed.
• Checked by a canary. Self-tests push a random value through every secret path, then scan all logs, incident files, the outbox and the database for it. A match fails the build.
• Removable. On macOS the user can delete stored credentials from inside declownify at any time. On Linux they are removed from the user's own store.

The test credentials HMRC issues to the developer are kept separately and are used only with HMRC's test services.

• Storage. Local data lives in the user's own application-support directory. The directory has mode 0700 and the database files 0600.
• No extra encryption layer. declownify does not encrypt the database itself. It relies on operating-system account security and full-disk encryption (FileVault on macOS), which users should keep switched on.
• Mailbox copy. The local mailbox copy used for receipt search is opened read-only.
• In transit. Connections to HMRC use HTTPS. declownify does not pin HMRC IP addresses.

• Test and live submissions are different types in the code.
• A live submission can only be built from a validated return with an IRmark, a recorded director approval and the typed consent "I CONFIRM LIVE SUBMISSION".
• HMRC's test services receive synthetic data only.
• Automated tests never contact HMRC's live service and never send email.

• Language. The core is written in Rust, and the workspace forbids unsafe code. The one exception is the bridge crate, which must allow unsafe in code generated by UniFFI. Its hand-written code contains none, and this is checked.
• Dependencies. Versions are locked (Cargo.lock) and builds run in a pinned Nix development shell.
• HMRC artefacts. Downloaded schemas, samples and tools are treated as data and are never run inside the product.
• Signing. Release builds will be signed with an Apple Developer ID held by OKASHI SCHOOL LIMITED, built with the hardened runtime and notarised by Apple. Developer ID enrolment for OKASHI SCHOOL LIMITED is pending.
• Testing. Every program is tested against an in-memory interpreter, including every failure class of every capability. Generated XML is validated against HMRC's XSD and Schematron. The IRmark code is tested against HMRC's published example. The app's self-test exercises the Keychain, notification and calendar paths on the real frameworks.

• Local only. Logs are written as JSON lines on the user's computer. declownify sends no logs, usage data or crash reports to OKASHI SCHOOL LIMITED.
• Incident files. Every failure produces an incident file with an identifier, the cause chain and the context, never a secret. The user sees a short message and the file's location.
• Support. A user may choose to email an incident file to us. We ask users to read it first.

Email letsmallbusinessesfiletheirowntaxes@okashi.school with "Security" in the subject. Please include the version, the steps to reproduce the problem and its likely impact. We will acknowledge the report, keep you informed and credit you if you wish. Please do not test against HMRC's live service or against other people's data.

declownify holds no customer data centrally, so a breach would most likely be a defect in the software itself. If we learn of a security issue that affects users' data or HMRC's services, we will:

1. tell affected users by email and on https://tech.okashi.school, with steps to protect themselves;
2. report it to HMRC immediately, with full details within 72 hours, giving a breach contact name and telephone number;
3. notify the Information Commissioner's Office within 72 hours of becoming aware of it, where personal data is involved;
4. publish a fixed release.

• Responsible individual: Emilie Michel, Director, OKASHI SCHOOL LIMITED.
• Technical contact: Jons Mostovojs, developer.
• Email: letsmallbusinessesfiletheirowntaxes@okashi.school