What counts as an incident
Two kinds, handled by the same process at different speeds. A security incident is unauthorised access to customer data, a credential exposure, or a defect that allowed one workspace to read another's. An availability incident is the service being unable to answer visitors, take a message, or accept a sign in.
A degraded dependency that the product routes around — vector search falling back to keyword retrieval, for instance — is not an incident. It is reported on the status page and watched.
How we find out
- Readiness probes check the database, rate limiting, vector search and object storage on every request to the health endpoint.
- The public status page reports the same probes plus whether scheduled background jobs have run when they should have.
- Application errors are collected when error monitoring is configured by the operator.
- Audit log entries record every API key change, webhook change, public API write and rejected single sign on assertion.
- A report from a customer or a security researcher, at the address below.
What happens, in order
- Contain first. Revoke the credential, disable the endpoint, or roll back the deploy. Preserving evidence comes second to stopping the bleeding, and rolling back is preferred over patching forward.
- Assess scope. Which workspaces, which data, and over what window. The audit log and the runtime event record are the source, not recollection.
- Notify. Affected customers are told what happened, what data was involved, what has been done, and what they should do. Within 72 hours of confirming a personal data breach, and sooner where the answer is already known.
- Fix, with a test. A fix that ships without a test that would have caught the defect is not finished.
- Write it up. What happened, why it was possible, and what changed so it is not possible again.
What we will not do
- Wait for a complete picture before telling you something happened. A first notice that says what is not yet known is more useful than a late one that is complete.
- Describe an outage as planned maintenance.
- Close an incident without the fix that prevents a repeat, or without recording why no fix was possible.
Reporting something
Email links@orhanai.com with what you found and how to reproduce it. Reports are acknowledged within one business day.
Security researchers acting in good faith — no data exfiltration beyond what is needed to demonstrate a finding, no service degradation, no access to another customer's data once the defect is proven — will not be pursued.
