Sentinel API v1

From your first API call to production

Output contract

Language control and quality validation

One explicit setting controls the output language from UI and API through model responses. Machine fields remain stable, so integrations never need to parse or translate model prose. Validate accuracy, false-alert rate, and latency on representative site footage before rollout.

Supported values are zh-Hant, zh-Hans, en, ja, and ko. Common aliases such as English, en-US, and zh-TW are normalized at the API boundary. When en is selected, displayed analysis, prompt-generated reports, and free-form answers stay in English instead of falling back to Chinese.

Set the language

Set language when creating or updating a Monitor. The Console language selector uses the same codes and sends the selected value when it creates a Session or Monitor. Each Monitor is independent, so one Edge node can serve users in different languages.

POST /v1/monitors
Authorization: Bearer <api-key>
Content-Type: application/json

{
  "source_id": "src_front_door",
  "name": "Front-door safety",
  "prompt": "Alert when a person enters the restricted area.",
  "language": "en"
}

Operators may write the prompt in the language they understand; language controls the human-readable output. The Runtime adds the language contract to each dynamic inference request, without requiring separate models or breaking the shared system-prompt cache.

Machine fields stay stable

Displayed labels and descriptive prose are localized, while event JSON fields such as severity, event_type, id, timestamps, and schema_version are not translated. Webhooks and third-party systems should consume those structured fields and never infer severity from model sentences.

{
  "event_type": "monitor.alert.raised",
  "severity": "critical",
  "schema_version": "1.0",
  "analysis": "[Status]: Critical
[Observation]: A person entered the restricted area."
}

Accuracy acceptance

We do not claim one universal accuracy number for every camera. Each deployment should record the evaluation source, camera position, day/night conditions, Monitor version, model version, and labeling policy, then report at least precision, recall, F1, false alerts per hour, and end-to-end latency.

Safety missions

Set the minimum recall first, then control false alerts and latency.

Operator workflows

Set an acceptable false-alerts-per-hour budget, then check recall.

Synthetic images are useful for boundary and regression tests, but they do not replace representative customer-site footage. Re-run the same acceptance set before increasing camera count or changing models.

Audio status

The current RTSP/OpenCV and local Qwen VLM pipeline is image-only, and capabilities explicitly reports audio_input=false. Integrations must not assume sound is captured, stored, or sent to a model unless a future API and provider capability explicitly enable it.