Delivered lab demonstration | November 2025 | Synthetic video
If you are planning an edge-AI pilot, borrowed hardware and a limited lab window make scope matter. You need an understandable workload and enough telemetry to judge the next step. Adding live cameras before the platform is ready can introduce dependencies that leave less time to inspect the system you came to evaluate.
The team selected a drive-through journey as a recognizable workload. I led architecture and engagement with a wider engineering team. The documented delivery was a lab application and demonstration using recorded synthetic video, not a restaurant deployment.
Prioritizing GPU monitoring in the edge-AI lab
At the September 26, 2025 scoping discussion, the container environment still needed work. We prioritized GPU monitoring first and a recorded-video drive-through workload second. The loan window made scope important: adding live cameras would have introduced another set of dependencies before the platform and demonstration were ready.
The drive-through example reused an existing demonstration and made the workload understandable to both technical and nontechnical stakeholders. Order, payment and pickup are recognizable stages. They provided a way to explain inference and event handling without claiming that a restaurant had adopted the system.
Separate simulation from edge inference
The phase-one decision was to use prerecorded synthetic footage. The edge device did not need to render the simulated environment and run inference at the same time. Synthetic video could be created separately, with recordings supplied to the lab for car-detection inference.
That choice reduced dependence on a local simulation setup and kept live-camera integration outside the first phase. It also made the test boundary clear. A pipeline working with controlled synthetic recordings does not establish how it will behave with changing light, occluded vehicles, different camera angles or exceptions in a real restaurant lane.
Make both the application and the platform visible
The NVIDIA GPU telemetry documentation describes monitoring stacks with collection, metric storage and visualization. It provides technical context, not evidence of this lab’s specific telemetry configuration or performance.
The architecture described media handling, inference, events and a web application, supported by containerized services and storage. The implementation report records OpenShift configuration, pods and operators, a drive-through analytics application and camera-management views. The application gave stakeholders a way to follow the scenario while the infrastructure views exposed the environment running it.
GPU monitoring was part of the engagement from the beginning. The report and demo recap document a monitoring dashboard and a Splunk walkthrough alongside the application. That let the team discuss workload behavior and infrastructure signals together, instead of treating the visual demonstration as the whole result.
The lab combined recorded synthetic input, local inference, an application interface and GPU observability. That establishes the useful system boundary without treating the lab as a verified production configuration. Local inference alone does not establish that every supporting service is independent of the cloud.
Architecture leadership and engineering delivery
I framed the requirements, presented workload and monitoring options, walked through the scope and coordinated engineering input. Platform configuration, the deployed application and the demonstration involved the delivery team. An infrastructure colleague led the November walkthrough of the application and monitoring dashboard.
That division of work matters. Leading the architecture and engagement does not mean I personally implemented every service. The case reflects a coordinated technical effort, with engineering delivery and demonstration responsibilities shared across the team.
What was delivered in November
The implementation status report documents the application, camera-management dashboard, container-platform configuration and GPU monitoring. The November 21, 2025 meeting recap describes a walkthrough of the deployed demo, stakeholder interest in additional computer-vision use cases and access and support follow-up. Together, those records establish a delivered lab demonstration beyond the initial scope document.
The result gave stakeholders a concrete environment for discussing edge-AI workloads and possible next pilots. It does not establish a restaurant rollout, formal production acceptance, model-accuracy benchmark or reduction in customer wait time. Interest in additional use cases was a discussion outcome, not evidence of a contracted next phase.
Original project materials contain application and monitoring dashboard imagery. The diagram here explains the architecture without reproducing operational identifiers or customer-branded screenshots. It does not stand in for telemetry or an acceptance test.
For the wider workload context, see these edge AI workload examples. Potential use cases should not be read as production results from this lab.
Projected impact: a scenario to test, not a delivered result
All inputs and calculated amounts in this section are hypothetical sample assumptions, not customer measurements, industry benchmarks or a forecast for this project. They are chosen to make the budgeting arithmetic inspectable. No verified delivered ROI is established for this case.
The delivered lab established a demonstration, not measured engineering savings. This projection concerns recurring evaluation and reporting after a similar lab is built. It compares repeated manual evidence assembly with a future reusable run-and-review routine. It does not value restaurant throughput, customer wait time, hardware purchases or unsigned follow-on work.
Hypothetical monthly inputs for an edge-AI lab team repeating workload evaluations: 8 repeat lab evaluation runs; 180 total staff minutes each in the manual baseline; 60 to 90 assisted preparation minutes plus 60 minutes of human review and correction each. Add 2 hours per month for maintenance and exception oversight. Use $100 per hour as an assumed loaded labor value and $200 per month for incremental tools, hosting and usage. These operating allowances are sample budgets, not vendor quotes.
- Projected baseline effort
- 8 × 180 ÷ 60 = 24 staff hours per month.
- Projected assisted effort, including review
- 8 × (60 to 90 preparation minutes + 60 review minutes) ÷ 60 + 2 maintenance hours = 18 to 22 staff hours per month.
- Projected capacity released
- 24 baseline hours minus 18 to 22 assisted hours = 2 to 6 staff hours per month.
- Projected capacity value
- 2 to 6 hours × $100/hour = $200 to $600 per month in labor capacity value.
- Projected capacity value less operating spend
- $200 to $600 capacity value minus $200 incremental operating spend = $0 to $400 per month, before implementation costs.
This is recurring monthly modeled potential, not cash savings or additional revenue. Freed hours only become useful capacity if the team can redeploy them. Payroll does not fall merely because preparation takes less time. Any avoided overtime or outside-service expense would need separate evidence. The dollar balance compares capacity value with operating spend; it is not profit or a cash-flow return.
The range varies only the assumed assisted preparation time. It is not a confidence interval or a promise of typical results. The comparison requires the same completed work and acceptance quality, with review and correction included. Lower adoption, harder cases, failed outputs, added support or higher operating costs can reduce the benefit to zero or make it negative.
One-time implementation costs are unknown and excluded, including setup, integration, training and initial validation. Any required migration or hardware acquisition is also excluded and must be priced separately. With that incomplete investment cost basis, no ROI percentage or payback period is claimed. Do not annualize this sample month as a forecast without validating sustained volume, adoption and costs.
Evaluate a repeatable edge-lab test
Repeat evaluations need AI observability and monitoring alongside application outputs, so the team can inspect both the workload and the platform.
Use an authorized lab, a defined recorded feed, a platform owner and acceptance criteria. The hypothetical routine would need its own validation. Synthetic recordings support controlled comparison, but they do not establish field accuracy under changing light, camera positions or traffic.
Bring the hardware constraints, permitted input feed and the decision your lab must support. We can discuss a bounded workload and a repeatable evidence collection plan before expanding to a field pilot.
