Safety and security boundary
The product reads evidence before it touches decisions.
Video systems become risky when detections are treated as decisions. Ayneye should present evidence, confidence, and review states before any operational decision.
Boundary matrix
| Workflow | Allowed beta behavior | Blocked or review-required |
|---|---|---|
| Security review | Find event spans and evidence | Identity, intent, discipline, emergency response |
| Facility operations | Summarize visible events | Door unlocking or physical control |
| Media operations | Index and search segments | Copyright/legal interpretation without review |
| Agents | Read-only artifact tools | Destructive or external actions |
| MCP preview | Resource catalog and policy docs | Production authority without audit |
Why this improves the product
Clear boundaries make technical buyers more willing to evaluate the product. They can see what is useful, what is risky, and what remains human-reviewed. A product that says no to unsafe actions is more credible than a product that pretends every video question can become automation.
{
"default_agent_permission": "read_only",
"requires_review": ["identity", "intent", "physical_access", "emergency", "disciplinary_action"],
"allowed": ["summarize_supported_events", "retrieve_evidence", "show_cost_context", "recommend_review_step"]
}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.