WEBVTT

00:00:01.000 --> 00:00:04.410
This accompanies our article on OpenAI integration.

00:00:05.320 --> 00:00:08.490
How do you make a model response useful in software that

00:00:08.520 --> 00:00:12.250
needs predictable fields and controlled follow-up actions?

00:00:12.680 --> 00:00:15.650
A fictional application receives a fault report.

00:00:15.880 --> 00:00:18.610
The model proposes a category and summary.

00:00:18.840 --> 00:00:22.650
However, the report does not contain a valid equipment reference for

00:00:22.680 --> 00:00:23.930
subsequent processing.

00:00:24.520 --> 00:00:29.050
The application sends only necessary text, receives a proposal and

00:00:29.080 --> 00:00:30.610
validates the output.

00:00:30.920 --> 00:00:35.930
Only after the agreed review may an authorised next step change another system.

00:00:36.760 --> 00:00:40.210
Document permitted fields, types and values.

00:00:40.520 --> 00:00:43.210
Specify what missing information means.

00:00:43.480 --> 00:00:47.850
Additional fields or an unknown category are not silently accepted as

00:00:47.880 --> 00:00:49.690
valid input for the application.

00:00:50.520 --> 00:00:54.490
A correctly structured response can invent an equipment reference or

00:00:54.520 --> 00:00:56.210
misrepresent the fault.

00:00:56.520 --> 00:01:00.490
Check its meaning against the input and relevant records, separately

00:01:00.520 --> 00:01:02.010
from validating its structure.

00:01:02.680 --> 00:01:05.810
A model cannot replace missing authorisation.

00:01:06.120 --> 00:01:09.170
The application checks the user and business rules.

00:01:09.400 --> 00:01:13.050
Without a valid equipment match, this report goes to a reviewer

00:01:13.240 --> 00:01:15.650
rather than automatic execution.

00:01:16.040 --> 00:01:19.850
Record refusals, limits and timeouts against the task.

00:01:20.360 --> 00:01:23.050
Identify who follows up unfinished work.

00:01:23.720 --> 00:01:28.010
Monitor usage and total response time without unnecessarily retaining

00:01:28.040 --> 00:01:29.210
the original input.

00:01:30.040 --> 00:01:34.130
Start with representative examples and known expected checks.

00:01:34.440 --> 00:01:39.015
Test changes to prompts, model selection or tool definitions before

00:01:39.040 --> 00:01:43.050
the revised version influences everyday operational work.

00:01:43.480 --> 00:01:47.050
An integration involves more than a successful API call.

00:01:47.640 --> 00:01:51.850
Our source article on OpenAI integration explains how output

00:01:51.880 --> 00:01:57.050
validation, data processing and error handling form an application feature.