Security

Two things can authorise a message, and there is no third

Either you approve that message, or you decided in advance — for one job, signed in to your own account — that what it drafts may go without a click once it passes that job's checks. Both are decisions made by someone at your business, and both are written down. There is no third thing that can put a message in front of one of your customers.

• A message nobody authorised has no way to reach a send

  The code that sends is only reachable by presenting a receipt, and a receipt can be produced in exactly two places, both of them in one file: the step where a person approves, and the step that checks an item against the rules of a job you put on automatic. This is a property of the type system rather than a rule someone has to remember: a draft step has neither, so a send-before-authorisation path does not compile. A third way in would mean editing that one file and the two tests that watch it.

• Automatic sending is off until an owner turns it on, one job at a time

  Every job starts out asking you about every message and stays that way until only an owner — not another member of your team, and never your operator — changes it in their own signed-in session, for that one job. The change is written to a history you can read, and putting it back is the one direction nothing can block. There is no setting that does it for every job at once, and there is no select-all in the queue either.

• A job on automatic still stops for anything its checks catch

  Before an item can go without a click it has to pass ten checks you can read in full, each written out in plain words with its threshold beside it where it has one, the adjustable ones set by you: the first message this product has ever sent that person, an unusually large amount, someone who wrote to you recently, a firmer tone, words like refund, dispute or complaint, more than a handful in one batch. Anything caught goes to the queue with the same sentence written on the card. On top of those, unless you switch it off, a separate reading by the model can add a hold and can never remove one; if it cannot answer, the item is held. For the first several items after you switch it on, everything is held and labelled with what would have happened — you watch it work before it sends.

• It puts itself back to asking you when something changes

  A job returns to asking about every message — and you are told it has — if a run fails after the checks, if more than half of the last ten assessed items were held by a check disagreeing with you, or if the instructions or the model behind it change underneath it. The code that does this can only move in that one direction; nothing automatic can put a job onto automatic.

• Reading and sending are different capabilities

  The part of the system that reads your mailbox cannot send from it. They are separate interfaces, and a test fails the build if anything but the outbound modules ever holds the sending one.

• Waiting is not consent, and neither is silence

  A draft you do not answer is never sent for you. Reminders may get louder; none of them can approve. If an approval request sits unanswered for a year it ends as expired — not as sent. Sending without a click is a setting you chose, never something you drift into by being slow.

• A link in a notification can never approve something

  Approving requires being signed in. A notification may contain a link that takes you to the app; possession of that link decides nothing on its own.

Where a new account stands, stated plainly: delivery is off. Two pieces of code can hand a message to a mail server, and which one your account uses is a column in the database that starts at "record what would have gone out, send nothing". It moves once, at the end of a checklist that includes your own recorded decision to go live — never by default, never by a build setting, and never for an account still running on demonstration data. Both pieces demand the same receipt, so nothing about going live changes who authorises a message.

Your operator can configure your account, and cannot approve

• Approval is refused for an operator

  When the person who runs New Homestead is inside your account, they see your approval queue with the buttons off and a note explaining why. The refusal is enforced on the server, not in the screen. The same goes for the setting that would make approval unnecessary: an operator cannot put a job on automatic, and cannot raise how many items you may clear in one action — they can only propose that, and you confirm it or you do not.

• They cannot give themselves a login on your business

  An address known to belong to your operator is refused as a user of your business, on every path that could create one. And there is no code anywhere — not in their admin tool, not on their command line — that can set or read one of your people's passwords: your invitations go to your own addresses, and your people set their own credentials on the identity provider's screens. That is what keeps "an operator cannot approve" a fact about the system rather than a habit.

• Every time they look at your account, you can see it

  Operator access to your data is written to your own record and shown in your own trail — not to a log only we can read.

• Changing how it writes does not change who decides

  Your operator can change the instructions the model works from. Those instructions only ever produce a draft, and the draft still stops and waits for you. If the job was one you had put on automatic, changing its instructions or its model puts it back to asking you — so an edit of theirs is never what sends a message.

The record shows what the AI wrote, and what authorised it

• Both versions are kept, always

  If you edit a draft before approving it, the trail keeps what the model wrote and what you actually sent, and marks it as edited. Keeping only one of the two would make the record lie about one or the other.

• Who decided, when, and on exactly what text

  Every decision is recorded against the person who made it, the run it belongs to, and the draft as it stood at that moment. A rejection is recorded the same way an approval is.

• An automatic send is its own line, never shown as approved

  An item that went without a click reads as sent automatically, with the count of checks it passed and a link to every one of them and what it found. It is never displayed as something you approved, and the record of what authorised it points at the day you made that decision, not at the moment the message went.

Encryption

• At rest, as a platform default we did not have to switch on

  The database and the live state behind your queue are encrypted at rest by the platform they sit on. That is stated here as something checked against the provider's documentation, not something we implemented.

• Your Google and QuickBooks credentials get a second layer

  The tokens that let the product read your mailbox and your books are stored encrypted at the field level, on top of the platform's own encryption, and a test asserts against the stored bytes that this is actually true.

• In transit, everywhere

  Every call the product makes to an outside service goes over TLS.

What the AI providers keep, and what we keep

• The model providers do not retain your prompts, where they support not retaining them

  Every model call goes through one gateway we control, with zero data retention switched on. That covers the providers currently routed to; it is a setting that is asserted against the live gateway rather than assumed.

• We do keep our own logs, on purpose

  We keep the request and response of each model call — including excerpts of any documents used to answer — so draft quality can be debugged and supported. That is a separate setting from the one above, it is deliberately on, and those logs are kept on the same schedule as the rest of your data.

Leaving, and getting your data back

• Deletion is refused for at least thirty days after your contract ends

  Not "we aim to keep it" — the code that deletes a business refuses to run until the window has passed. Deleting earlier has to be asked for explicitly, with a stated reason, and is logged.

• The export is a walk over a list, not an archaeology project

  Every table holding your data is registered in one export registry in the same change that creates it, so "give me everything" is one operation. Ask your operator and they run it — there is no self-serve download button today.

• Nothing is deleted for tidiness while you are a customer

  Records older than a year stop appearing in the default views so the app stays readable. They are still there, and still answerable when you ask about something from fourteen months ago. One thing is genuinely deleted, and in your favour: when the product watches a mailbox it keeps a short working list of which conversations are waiting on a reply — sender, subject and the provider's own one-line preview, never the whole message — and deletes those rows once they are older than several times the window that job looks back over, which is three weeks with the settings it ships with. Your mail stays in your mailbox, which is where it belongs.

This website

These pages contain no JavaScript, set no cookies, run no analytics and load nothing from a third party — not a font, not a tag, not a pixel. You can check that by viewing the source. The privacy policy should be able to say so without qualification, which is why the site was built this way first.

Found something?

Report it to support@newhomestead.ai and you will get a person, not a queue. There is no bounty programme; there is one operator who would rather hear about it.