Feedback

Feedback is the operational intake channel for both user product signal and automated security probes.

Feedback intake and surfaces

Alumia separates feedback into two streams:

• feedback — user reports and signal observations attached to project/session context when available.
• notifications — system notices like schedule failures, usage warnings, and subscription changes.

Both streams are accessible from:

• /admin/feedback for operator review
• /api/v1/admin/feedback for data retrieval and status updates

Security probe filtering

The admin feedback surface can group and inspect common probe families:

• script / injection probes (<script>, javascript: and event handlers)
• command-style probes (sleep, id, shell-like patterns)
• SQL-style probes (UNION SELECT, conditional numeric comparisons)
• template injection patterns
• path traversal probes (../, absolute system paths)
• fuzz patterns (common test-noise payloads)

Administrators can filter by signal family and escalate only the meaningful items.

Workflow states and actions

Feedback items support explicit workflow states and handoff metadata:

• Status: open, triaged, in_progress, done, archived
• Handoff: none, build, build/bugfix flow control
• Automation controls for routing repetitive reports into follow-up tasks
• notes and action timestamps with safe HTML output

This allows the same route to act as bug triage, security triage, and feature request intake in one place.

Signal quality and noise handling

The pipeline computes quality labels at ingest time:

• low_signal
• short_actionable
• actionable
• security_probe

In noisy periods, duplicate and burst groups can be surfaced together so triagers do not process identical submissions repeatedly.

Why this matters

The feedback surface is part of product reliability, not just support chat:

• it catches repeated probe patterns before they become incidents,
• highlights real product issues separately from synthetic test traffic,
• and gives operators concrete state transitions so nothing gets silently dropped.

Bug bounty

Alumia runs an informal bug bounty for reports that uncover real defects in the running product. The program is intentionally simple — we read every feedback submission, and reports that meet the criteria below earn a bounty paid as Alumia credit or an equivalent reward at the team's discretion.

Eligible reports

• A clearly reproducible defect in the running product (canvas, agent runtime, connectors, billing, auth, admin, or any user-visible surface).
• A security finding submitted through the feedback surface — for example, an authentication bypass, missing authorization check, server-side validation gap, or data leak across tenants.
• A reliability issue that produces incorrect, lost, or duplicated state for a user (silent failures count — they are the worst kind).

Out of scope

• Cosmetic-only differences that do not affect comprehension or task flow.
• Feature requests, even very good ones — open a feedback note for those and we will route them to product, but they are not bounty-eligible.
• Findings from automated scanners with no concrete impact path.
• Reports based on outdated builds or local-only environments.

How to submit

Use the feedback button in the dashboard (📝 icon in the top bar) and include:

• a short title in the first line,
• the steps to reproduce, with the route or session you were on,
• what you saw versus what you expected,
• and the impact (who is affected and how).

The submission attaches your current route, viewport, and session context automatically, so you do not need to paste those by hand.

After you submit

The admin feedback queue prioritizes signal items first. Verified bounty-eligible reports get a direct reply with the reward decision and the fix tracking issue, typically within one business week.

The program operates at the team's discretion and is not a substitute for a formal disclosure agreement — for coordinated security disclosures involving third parties, contact the security address listed on the public site.