Runtime
CPU-first runtime for bounded, inspectable video processing.
Runtime design is about cost control, reproducibility, fallback posture, and artifact materialization. It is not a claim that small CPU detectors replace every large video model.
Runtime responsibilities
| Responsibility | Product behavior | Artifact |
|---|---|---|
| Bounded processing | Run small windows during beta | capture_report.json |
| Detector mode | Expose CPU/OpenVINO/ONNX posture and fallback | detector_report.json |
| Semantic refresh | Avoid unnecessary reprocessing where state is stable | timeline.json |
| Artifact materialization | Persist outputs for dashboard/API/agents | scene_graph/evidence/cost |
| Failure state | Return visible error and review guidance | error envelope and dashboard state |
Runtime evaluation questions
- Did processing complete within the beta window?
- Which detector mode and fallback flags were used?
- Are low-confidence regions visible?
- Are outputs deterministic enough for repeated inspection?
- Does the user know when escalation is needed?
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.