Contact & support

Start here — fastest first

These four resolve the majority of questions without an email round-trip. Work down the list before you write.

Pick the right route

There is no web form on this page, deliberately: a form that posts into an unattended pipeline loses your message silently, and it would ask you to hand over personal data before you have decided to. Plain email keeps the record in your own sent folder, where you can prove what you sent and when.

Put the subject tag at the front of the subject line. It is a reading convention rather than an automated router: it says what a message is before anyone opens it, and it is the same tag the self-service tools at /tools put on the messages they generate. The links below fill it in for you.

The security address is also published, with its expiry, in /.well-known/security.txt (RFC 9116). That file is canonical: if it ever disagrees with this page, believe the file and tell us via [docs].

What to include

A first reply can only resolve your problem if it arrives with enough to reproduce it. For anything in the [help] lane, include:

• What you expected, and what happened instead. One sentence each.
• The exact error text, copied rather than described, including any code or identifier it printed.
• When it happened, in UTC, to the minute. Logs are timestamped in UTC and a local time without an offset cannot be matched against them.
• Which client and agent you were using, and its version — the assistant, IDE or runtime that holds the connection.
• Which plan you are on, and whether it is self-serve or an operator-run deployment.
• What you already tried, including anything on the four surfaces above.
• Whether it is reproducible, and if so the shortest sequence that reproduces it.

For [billing], add the payment rail you used and the last four digits of the card, or the transaction hash for an on-chain payment — never the card number itself.

What never to send

• Never your master seed, private key, or recovery phrase. Nobody legitimate will ask for one. A message asking you for yours did not come from these addresses, whatever it appears to say.
• Never an API token, session token, or password. If one has already gone out in a message, rotate it first and tell us afterwards.
• Never the plaintext of a memory cell. The whole point of the protocol is that it never sees your plaintext; pasting it into an email hands over exactly what encryption was protecting.
• Do not paste ciphertext expecting recovery. SAIHM holds no key of yours and cannot decrypt it. A ciphertext blob tells the wrong lane nothing it can act on.
• Redact third-party personal data out of logs and transcripts before you attach them. Sending someone else’s data to resolve your ticket creates a disclosure you then have to account for.

If a genuine finding cannot be described without sensitive detail, that is a security disclosure: use security@saihm.coti.global and say up front what you are holding back and why, rather than sending it in the first message.

What to expect

SAIHM is an Apache-2.0 protocol, not a staffed help desk, and this page will not promise you a response time it cannot keep.

Enterprise and Enterprise Fast

These plans include a contractual SLA. Its response targets live in your agreement, which governs — not this page. See /pricing.

Privacy and erasure requests

Answered within one month, as GDPR Art. 12(3) requires, and your first request is free. The privacy notice sets out the full position, including your right to complain to a supervisory authority.

Security disclosures

Handled under the published disclosure policy. Findings are acknowledged and, where they are confirmed and material, disclosed publicly rather than quietly patched.

Everything else

Answered on a best-effort basis. There is no queue position and no ticket number to quote. If a message has gone unanswered and the problem is blocking you, reply on the same thread and put [resend] in front of the existing subject tag.

An outage is reported on /status, not by email. The badges there report a state as unconfirmed rather than showing a stale value, so a feed that has gone quiet reads as unknown rather than healthy.

What these routes cannot do

Some limits are consequences of the design rather than of effort, and no route on this page can work around them. Knowing them saves you a round-trip.

• Restore a memory you erased. Erasure is the one operation that is meant to be irreversible. Nothing here can undo it.
• Recover your key, seed or recovery phrase. SAIHM never held it. That is what sovereignty costs, and it is the same property that stops anyone else recovering it either.
• Read, edit or repair the contents of your memories. The protocol and whoever runs its storage tier see ciphertext only.
• Reverse a confirmed on-chain transaction. Public-chain settlement is final; a billing correction is a separate payment, not a rollback.
• Give tax or legal advice. Stablecoin and subscription payments may have consequences in your jurisdiction — take those to a qualified professional.
• Act on your behalf inside your agent. What your agent chooses to remember is set by you and your agent vendor, not here.

If you self-host, or another operator runs your node

The protocol is Apache 2.0 and anyone can run it. If your deployment is operated by someone else, or by you, then that operator holds your logs, your uptime and your commercial terms — and is the right first stop for an incident, an attestation, or a question about retention. Escalate here only when the operator is unresponsive or cannot be identified.

Operator-level attestations and the controls a regulated workload needs are covered in the Trust Center.

For agents and automated clients

These contact routes are published in machine-readable form as well, so an agent can find the right address without scraping this page:

• /agents.txt — short-form directives, including the contact, security, compliance and billing routes.
• /.well-known/security.txt — RFC 9116 security contact, policy link and expiry. Canonical for security.
• /.well-known/saihm.json — machine descriptor for the protocol surface.
• /llms.txt — long-form description of the protocol, pricing and standards work.
• /status-systems.json — the status feed behind /status, carrying the timestamp of its own last check.

Not a support question?

If you are here to start rather than to troubleshoot, the shortest path is /quickstart, and the free tier needs no payment details.

Join SAIHM →   or see pricing first