Dashboard workflow
The dashboard turns beta signup into a structured evaluation.
A new user should not land in an empty app. The product needs onboarding, sandbox limits, demo workspace creation, artifact links, and next-step guidance.
Dashboard workflow map
| Panel | Purpose | What it should answer |
|---|---|---|
| Onboarding checklist | Guide new user through evaluation | What should I do first? |
| Sandbox limits | Show quota and boundaries | How much can I test? |
| Demo workspace | Create synthetic artifact bundle | What should success look like? |
| Video list | Show source records and jobs | What did I process? |
| Artifacts | Open JSON and evidence | What did the system create? |
| Ask Video | Ask evidence-grounded questions | What can I safely ask? |
| Cost panel | Show cost context | How much did this workload imply? |
Empty-state quality
Good empty states reduce abandonment. They should say why the user is here, what the sandbox can do, what the next action is, and what is intentionally not enabled. The demo workspace is important because it gives a user a safe first artifact bundle before they risk customer footage.
Dashboard acceptance checklist
- New signup reaches dashboard with cookie.
- Limits are visible before adding a video.
- Demo workspace can be created.
- Artifact cards link to JSON views or downloads.
- Ask Video uses evidence-required behavior.
- Risky workflows show review boundary.
Product boundaries are part of the product, not footnotes. Ayneye is not presented as a replacement for every GPU video foundation model, not a free-infinite-query engine, and not an autonomous surveillance decision system. The current beta path is controlled signup, dashboard, REST API, bounded processing, evidence artifacts, visible limits, and read-only agent/MCP-style evaluation. Hard scenes, identity-sensitive workflows, emergency response, physical access, discipline, and destructive actions require human review or remain blocked.