Key
A matching key is lost, copied, or used by the wrong role. Matching for the affected scope stops. A new key is made. The old key is destroyed. There is no recovery of a lost customer key — that is a different fact, and support cannot undo it.
What this page promises, and what it does not
No response time. No service level. No stated hours. SealRelay is run by one person. A promise of a reply within some number of hours would be a promise that one person cannot keep on every day of the year, so it is not made here — not in this page, not in the terms, and not in any message sent from support.
What is offered instead is a stated way in, a stated order of work, and an honest account of what support can and cannot do. If a committed response time is a requirement for you, it is not something this operation can offer today.
Support is a channel to a person, not a queue with a clock on it. Everything below describes the shape of that channel.
How to reach support
No mailbox yet
The site is live, but the support mailbox is not. No address has been registered yet. No address is printed here, because an address printed before it works is an address that silently drops mail.
The channel will be a single monitored mailbox on this host, published on this page as soon as it exists. Until then there is no support route, and this page says so rather than inventing one.
When the mailbox exists, one address handles everything below. There is no tiered contact list, no phone line, and no chat widget — one person cannot staff three channels, so there is one.
The order work is taken in
Requests are worked in this order. The order is a statement of priority, not of timing: a request at the top of the list is looked at before one below it, and that is the whole of the commitment.
- A security report. Anything that suggests a matching answer, a log entry, or a key is not behaving as described. See the security page for how to send one.
- A live matching failure — a lookup that returns something other than the documented result, or a log that will not verify.
- A request from a person about their own data. These are routed to the process on the privacy page, which is where the legal deadlines live. Those deadlines are set by law, not by this page, and they are the one timing commitment that does exist.
- Integration questions from a publisher or an asker — publishing, lookup, the fields on a result, exports.
- Everything else, including feature requests.
Item three is the exception worth reading twice. A statutory deadline for a data-subject request is a legal obligation and it is met. It is not a support-response promise, and nothing on this page extends it to any other kind of message.
Incidents split three ways
A key event is not a log event. A log event is not an overload. An overload is not a key rotation. They are not one shared story, and they are not staffed as one. Support routes each report to its own track. Roles act. No person is named here.
Log
The growing log, or the short trail kept to investigate abuse, is read by a role that should not see it. The current head is frozen. A copy of the trail is taken before the thirty-day purge removes it. A flood of lookups is not this track unless it is being used as cover.
Overload
The service is flooded so that answers stop. Load is shed. This is an availability event, not a leak. It does not start a breach clock on its own. When matching is down, a lookup fails closed — it does not invent a yes.
What support can do
In scope
- Explain what a lookup result means, and what it does not mean.
- Explain the fields carried on a result and in every export.
- Help a publisher sign and publish a note the way the protocol expects it.
- Help an asker read a hit, a uniform no, and a refusal apart.
- Point you at your tags, which needs no account here.
- Take a security report and act on it.
- Take an incident report and run the matching track against it — key, log, or overload.
Out of scope
- Key recovery. There is none. SealRelay holds no copy of a participant key and cannot reconstruct one. A lost key is lost, and support cannot change that. This is a property of the design, not a policy that can be waived for an important customer.
- Telling you whether an attested fact is true. A yes says a signed note matched. Weighing the fact is the asker’s own work.
- Deleting a copy someone already holds. Already-shared cannot be recalled.
- Confirming or denying whether some named organisation is a participant.
- Naming a witness. Only witness roles are ever disclosed, to anyone, including to you.
- Reviewing the protocol specification. It is not published, and support will not circulate a draft.
Before you write
These are the things that make a request answerable in one round instead of four. None of them is required.
- Which role you holdPublisher, asker, or the person the note is about
- Which applicationAsk, or your tags
- What you expectedA hit, a uniform no, or a refusal
- What you sawThe result exactly as rendered
Do not send a person’s raw identity to support. The operator never holds it in the service, and support is not a way around that. If a request seems to need one, say so and it will be worked another way.
There is no status page
A status page that a single operator updates by hand is a status page that is wrong exactly when it matters. Rather than publish one, the client itself reports what it can verify: whether witnesses have co-signed the log inside the watch window, and whether it is willing to treat the log as fully verified. That signal is on the openness page and on the front page, and it comes from the log rather than from a person’s recollection.
No availability figure is published, and none is promised.