Readiness
Readiness is a workflow, not a slogan.
The product is ready for controlled beta evaluation when signup, dashboard, demo workspace, artifact inspection, limits, costs, and safety boundaries are visible and testable.
Readiness gates
| Gate | What must work | Current beta expectation |
|---|---|---|
| Signup | Create account and session | Real limited beta workspace |
| Dashboard | Show onboarding and limits | Demo workspace CTA and sandbox quotas |
| Processing | Run bounded execution | Small windows and clear failure states |
| Artifacts | Expose generated JSON | scene graph, evidence, timeline, cost |
| Ask Video | Answer with evidence | No evidence, no confident answer |
| Safety | Block risky claims/actions | Human review required |
| Cost | Show cost context | cost.json and usage limits |
Buyer readiness checklist
- Can a new user sign up and reach dashboard?
- Can they create a demo workspace?
- Can they see limits before they hit them?
- Can they inspect scene_graph.json and evidence_bundle.json?
- Can they ask a question and see evidence?
- Can they understand what is disabled?
- Can the team decide whether to expand capacity?
What is intentionally not ready
Paid checkout, automated email campaigns, CRM writes, production MCP authority, identity decisions, emergency workflows, and destructive actions are not presented as enabled. Readiness improves when the product clearly says what is working and what is deliberately blocked.
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.