MAIE6000C Chap.8 AI Component Integration
AI Component Integration
The AI step inside the workflow, not beside it
Attention moves here to where the AI-enabled component actually sits inside the working product. The stated aim is not to display a model on its own; it is to see outputs wired into a system that has inputs which matter, consequences further along, something observable, and a defined response when the result is weak or doubtful.
The published topics name the comparison the chapter is built on: model as a service against embedded patterns, human in the loop design, and product-level evaluation.
Service or embedded, compared where they differ
Both patterns produce the same output for the same input, so accuracy is not a dimension of the choice.
What differs is what a failure takes down with it, how easily the component can be replaced, and whether its behaviour is separately visible.
The starter uses the service pattern, with an internal AI service that has its own health endpoint and its own log prefix, which is why a failure there surfaces as a retryable job rather than as a worker that stopped.
Model logic and product workflow logic
Model logic answers what this input most likely is.
Product workflow logic answers what the system should do given that answer, given how confident it is, and given who is available to check it.
Putting the second inside the first is how a system ends up with a routing threshold buried in a function nobody can find in Week 12. Keeping them apart is what makes the thresholds configurable, documentable and defensible at the oral defence.
Three behaviours every AI step owes
When it returns something usable, the proposal is stored as a proposal, distinct from any decision.
When it returns something the system does not trust, the item goes to review rather than to a default, because a silent default is indistinguishable from a confident answer. When it returns nothing at all, the job fails visibly, the item keeps a state a person can act on, and the system remains usable for everything else.
The module asks you to document how the system behaves when output is uncertain or unavailable, which is those three written down.
A fallback is a path, not a message
The taught fallback examples are concrete: route to a manual queue, ask one clarifying question, or show a policy reference and escalate. All three are things the system does next, with a record.
A fallback that displays an apology and stops is not a path, because the item is now in a state nobody owns.
The test is whether you can name the person or queue that holds the item afterwards, and whether that is visible in a query.
Evaluate the workflow, not the model
The module's learning goal is to think about usefulness at the level of the product, not only about a benchmark score, and the final project rubric never mentions model quality.
Two systems with the same accuracy behave completely differently depending on what happens to the cases they get wrong. The measurement that answers the real question is available from your own schema if you kept the proposal and the decision as separate facts: how often a human changed the proposal, how long a decision took with it present, and what happened to the items where the step returned nothing.
What this chapter covers
- 01
Service against embedded, on failure radius, replaceability and visibility
- 02
Why the starter's shape makes an AI failure a retry rather than a crash
- 03
Model logic and product workflow logic as separate concerns
- 04
Confidence routing, and the two thresholds a team has to defend
- 05
Usable, untrusted and absent output as three documented behaviours
- 06
What makes a fallback a path rather than a message
- 07
Why an accuracy figure cannot answer whether the step is worth having
- 08
Three workflow-level numbers your schema can already produce
An accuracy number that cannot answer the question
- 3Say what the figure measures and what the question is about.
- 3Give two systems with the same figure and different behaviour.
- 3Name the measurements that would answer it.
Key terms
- Model as a Service
- The pattern in which the AI step runs as its own process reached over the network, so that its failures are contained and its health is separately visible.
- Embedded Pattern
- The pattern in which the AI step runs inside the worker process, trading a separate health signal and a contained failure for one fewer service to operate.
- Confidence Threshold
- A configured value deciding whether a proposal is applied, shown for confirmation or sent to manual review, which has to be recorded and justified rather than chosen silently.
- Human in the Loop
- A design in which a person can accept, flag or override a proposal, with each of those three actions stored as a fact.
- Product-level Evaluation
- Assessment of whether the workflow is better with the AI step than without it, measured from stored decisions rather than from a held-out score.
- Silent Default
- An untrusted result applied anyway because no separate route exists, which is indistinguishable downstream from a confident answer.
- Blast Radius
- How much of the system a single component's failure takes with it, which is the main practical difference between the two integration patterns.
AI Component Integration FAQ
Should the AI step run as its own service or inside the worker?
Both produce the same output, so the choice is about failure and change rather than performance. As a separate service, a crash is a failed network call the job can retry, the component has its own health endpoint and log prefix, and swapping it means changing one address. Embedded, a crash takes the worker with it, its behaviour is indistinguishable from the worker's in the logs, and replacing it means redeploying the worker.
The cost of the service pattern is one more thing to run and document. The starter ships the service pattern, so embedding is a deliberate act rather than a default.
What should happen when the AI step returns a low-confidence result?
The item should go to a review route rather than to a default, and the proposal should still be stored. Applying a low-confidence result quietly makes it indistinguishable downstream from a confident one, which removes the information a reviewer needs and makes the later evaluation meaningless. The taught fallback options are concrete: a manual queue, one clarifying question, or a policy reference with escalation.
What makes any of them a path rather than a message is that you can name the person or queue holding the item afterwards and see it in a query.
How do I evaluate my AI component for the final brief?
At the workflow level, using records you already hold if the proposal and the decision were stored separately. Three numbers do most of the work: how often a human changed the proposal, how long a decision took with the proposal present compared with without it, and what happened to the items where the step returned nothing at all.
The third is the one teams forget and it is usually where the honest limitation for the final demonstration comes from. A held-out accuracy figure belongs in the brief as context, but it cannot answer whether the step improved the workflow.
Assessment move
Write the three sentences describing your AI step's behaviour for usable, untrusted and absent output, then test the third one by stopping the service and submitting an item. Most teams discover that the absent case has no defined behaviour at all, and finding that out in Week 8 leaves time to fix it.
Working through AI Component Integration in MAIE6000C? Sia is AskSia’s AI Computer Science tutor — ask any MAIE6000C AI Component Integration question and get a clear, step-by-step explanation grounded in how MAIE6000C is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
