Product support
Use this for CommandPad, app behavior, product questions, bug reports, account-facing support, support documentation, and user-facing product requests.
Support
Support routes for Anrixa products and project work.
Use the right contact route so the request can be handled correctly. Product questions, project inquiries, security reports, and administrative matters are intentionally separated.
Security reports
Use this for vulnerability reports, exposed endpoints, access risks, domain/security issues, suspicious behavior, or security-aware engineering review.
General projects
Use this for AI software, digital systems, website rebuilds, automation, brand engineering, product planning, and cooperation discussions.
Administration
Use this for platform operations, developer-account administration, formal business communication, invoices, and account-management matters.
What a useful support message contains
For product or app support, include the product name, device or browser, operating system version, steps to reproduce the problem, screenshots if safe to share, expected behavior, actual behavior, and whether the issue blocks work. For website or server issues, include the URL, time observed, browser, error message, and whether the problem appears on mobile, desktop, or both.
For security reports, include a clear description, affected URL or product area, reproduction steps, expected risk, and safe evidence. Do not perform destructive tests, credential attacks, or public disclosure before Anrixa has reviewed the report.
Support process
Anrixa support should start by identifying the affected product, page, server route, workflow, or account context. For product issues, the first reply should separate user error, documentation gaps, reproducible bugs, policy limitations, and feature requests. For website issues, the first check should distinguish static page problems from backend/API problems, DNS problems, browser cache, and deployment-root mistakes.
For CommandPad and future products, support information should remain practical: version, device, operating system, steps, logs if available, expected result, actual result, and whether the issue creates data loss or security risk. For project clients, support should reference the agreed project scope and maintenance arrangement rather than making open-ended promises from the public website.
Security reports
Security reports should use security@anrixa.com and include safe reproduction detail. A useful report identifies the URL, endpoint, product behavior, account context, expected impact, and proof that does not damage systems. Reports about exposed secrets, account takeover, public data exposure, contact-form abuse, DNS mistakes, or deployment misconfiguration should be treated with priority.
Response expectations
The public support page is not a guarantee of a fixed response time for every possible request. Priority depends on the type of issue, whether the request is connected to an active project or product, and whether the message includes enough evidence to investigate. Security reports, broken contact routes, product-blocking bugs, and administrative account issues should be separated from general feature ideas.
For project support, the strongest working model is a documented support scope: what is included, who can request changes, how urgent fixes are defined, how backups are handled, where source files live, and how deployments are verified. This prevents support from becoming unclear after launch.