VALIDATION

Let the test
tell the story.

Define the measurement before discussing speed. We agree on conditions, methods and acceptance criteria with each customer.

MEASURE → UNDERSTAND → IMPROVE

A useful result is more than a latency number. It explains the conditions, process and limits behind that number.

A test agreement you can inspect and reproduce.

This website describes our evaluation method. Performance data is provided after relevant testing, with the conditions disclosed.

  1. 01

    Define measurement boundaries

    Specify start and end events for media, AI response or control feedback, along with timing method and precision.

  2. 02

    Record the conditions

    Document hardware, software, media specifications, network path, test duration and sample count.

  3. 03

    Include change and failure

    Alongside the baseline, evaluate agreed bandwidth, loss, jitter and reconnection conditions. Record failures as well.

  4. 04

    Report distributions and limits

    Describe percentiles such as P50 and P95, variation, stalls and recovery, together with uncertainty and scope.

PREPARE FOR A USEFUL TEST

Bring these four things.

Download the evaluation checklist
  • Application: who interacts, and what needs to improve.
  • Devices: capture and receiving endpoints, systems and media settings.
  • Network: connection type, deployment regions and known constraints.
  • Goals: metrics and acceptable experience boundaries.

A FEW ANSWERS

Questions, answered

Why not show a single minimum latency?

Without hardware, network, media specifications and measurement boundaries, that number is difficult to use. We start with conditions and methods.

How should solutions be compared?

Use consistent input, endpoints, network conditions, media settings and statistics. Disclose configuration differences and do not compare only the best sample.

Does a test establish production performance?

A test only covers the conditions observed. Production needs ongoing observation and additional validation for device, network and load changes.

PREPARE THE EVALUATION

Real-time media evaluation checklist

Preparation for discovery and a single-application evaluation in AI digital humans, remote safety monitoring or education; not a compatibility or performance commitment.

Version 2026.10-v5 · Updated 2026-10-30

01 Application and goal

Choose AI digital humans, remote safety monitoring or education. For remote safety, describe robot inspection, vehicle observation or another task for discussion. Complete technical specifications are not required at this stage.

02 Endpoints and media

Record device models, system versions, processors, camera and microphone interfaces and browsers. List codecs, stream count, resolution and frame rate.

03 Network and deployment

Record regions, network type, bandwidth, round-trip time, loss and jitter. Describe public, private or local deployment requirements and access constraints.

04 Monitoring task and status sources

For remote safety, list camera priorities, simultaneous viewers, video continuity needs and status sources. Mark whether voice, recording, playback, alerts, AI analysis and assisted actions are needed and who provides them. Skip for other applications.

05 Interfaces and ownership

Prepare media, application and authentication interfaces. For monitoring, assign providers for video, device status and collaboration. If assisted control is required, separately assign permissions, acknowledgments, emergency stop and loss-of-link behavior.

06 Measurement boundaries

Define network RTT, one-way media delay and camera-to-screen latency separately. For digital humans, record recognition, model, synthesis and rendering stages separately.

07 Conditions and samples

Make devices, versions, codecs, bitrates and network conditions traceable. Agree on sample counts, test periods and summaries such as P50/P95. Keep anomalous samples.

08 Change and recovery

Include bandwidth drops, loss, jitter, handovers and reconnection. Record continuity, speech clarity, synchronization and recovery time alongside latency.

09 Evidence status and disclosure

Record versions, maturity, owners and disclosure scope for interfaces, device records, demonstrations and results. State whether recording or storage is needed, who supplies it, and retention location and access. Mark unknown items as undecided.

10 Delivery and acceptance

Agree on deliverables, test scope, acceptance criteria, open issues, owners and support. Confirm pricing, timing and licensing in the written project scope.

Do not include credentials or unnecessary personal data. Entries stay in the file you edit; you choose whether to send it to the team.

Make test records the basis for decisions.

Public methods and checklists help start discovery. Device results, demonstrations and available versions are supplied after confirming test conditions and disclosure scope.

01

Compatibility records

Record devices, system versions, interfaces, codec settings, test date and findings. One passing setup does not establish support for other platforms.

02

Performance reports

Include timing boundaries, tools, samples, P50/P95, anomalies, recovery and applicable scope.

03

Demonstration notes

Confirm the task, media source, version, devices and network. Distinguish live operation, recorded playback and concept illustrations.

LET’S CONNECT

Bring your application
to the conversation.

Share your application, existing devices and the most important problem. Define the integration scope and next step together.

Discuss integration