MAIE6000C Chap.1 From Prototype to Production
From Prototype to Production
A demo and a system are different objects
The course opens by refusing a comfortable idea: that a production system is a prototype with more polish. The two lists it puts up are not points on one scale.
A prototype works along one route, leans on setup nobody wrote down, keeps little that survives a restart, copes badly with breakage, is barely tested, reports nothing about its own behaviour, and cannot be passed to anyone.
A system holds workflow state through a restart, offers interfaces somebody can read, has a defined response to breakage, starts the same way every time, carries verification of some kind, and reports on itself through logs, health endpoints and written documentation.
Moving from one to the other is a set of named repairs, and each repair is different work owned by a different person.
Why prototypes fail after the demonstration
The reasons the opening session lists share a striking property: none of them is about model accuracy. A model sits outside the workflow it was meant to change. Records are kept but never versioned.
Nobody downstream can inspect or amend what was produced. A slow step holds the submitter in place. Breakages leave no trace. Exactly one machine has ever run the thing. And months later the reasoning behind a choice has gone.
Read against the course's own requirement list, that is almost a mirror image, which tells you what the ten required elements are actually for: each one closes one of those failures.
The system contract, stated three times
A team project only passes if it carries relational storage, a service or interface layer, a background or asynchronous route, an AI-enabled function wired into the flow, a local startup that repeats, testing or some believable check, written documentation, logs emitted as fields, health endpoints, and a basic operational view.
The course repeats that list in the opening lecture, on the home page and in the student handbook, which is a strong signal that it is a specification rather than an aspiration. Note where the AI-enabled function sits: one item out of ten, and the course says elsewhere that it is important but is not the main grading target.
The starter system, and why its shape matters
The supplied starter runs four services.
One receives requests, one stores cases, jobs and results, one processes background jobs, and one is an internal AI service. The path a submitted item takes is fixed and worth memorising: the interface accepts the case, stores it, creates a pending job, and returns. Separately the worker claims the job, calls the AI service, persists the result and marks the job complete.
The request cycle ends before the slow part begins, which is the single design decision that makes a slow or failing AI step survivable.
Weak and strong project directions
The contrast the course draws is not between ambitious and modest. Weak directions name a technology and a domain but no user, no trigger and no decision, so there is no single path through them to demonstrate.
Strong directions name one clear user, one concrete workflow, a clear input and output, persistent state, a worker path, a bounded AI function and a human review or fallback route. The instruction that follows is one line: begin from a single workflow and a single slice.
Model work and system work produce different evidence
This is the distinction that decides how a team spends its semester.
Model work asks whether the prediction is good, and its evidence is a score on held-out data. System work asks whether the workflow is better with the prediction in it, and its evidence is a persisted record of what the system did and what a person did next. Every rubric in this course reads the second kind. A team that can produce only the first has not failed at machine learning; it has answered a question nobody asked.
What this chapter covers
- 01
What separates a demo from a system, property by property
- 02
Seven published reasons AI prototypes fail in real settings
- 03
The ten elements every passing project must contain
- 04
The four starter services and the path an item takes through them
- 05
Why the request cycle ends before the AI step begins
- 06
Weak against strong project directions, and what makes the difference
- 07
Model work against system work, and the evidence each produces
- 08
Placing a complaint where its repair actually lives
Four complaints, four different repairs
- 4Name the required element each complaint belongs to.
- 2State the repair for each, in terms somebody could act on this week.
- 2Say what the four have in common about the model itself.
Key terms
- System Contract
- The ten elements the course requires every passing team project to contain, from relational persistence through to basic observability.
- Happy Path
- The single input and sequence under which a prototype works, and the reason a demonstration can succeed while the system is not yet reliable.
- Durable State
- Information that survives a restart because it was written to a store, as distinct from state held only in a running process.
- Operational Visibility
- Evidence of what a system is doing that a reviewer can read without the author narrating it, such as logs, statuses and health output.
- Handover Path
- The condition of being understandable and operable by somebody who did not build the system, which the final milestone assesses directly.
- Internal AI Service
- The starter's separate process that produces the AI-enabled output, reached by the worker over the network rather than called inside it.
- Bounded AI Function
- An AI step narrow enough to be described, tested and given a defined fallback, as opposed to an open-ended capability.
From Prototype to Production FAQ
How does a prototype differ from a system on this course?
The course treats them as different kinds of object rather than as two levels of polish. It sets seven properties of a prototype, among them a single working route, setup nobody wrote down, and nothing that reports on behaviour, against six properties of a system, among them workflow state that survives a restart, a defined response to breakage, and a startup that repeats.
Each property on the prototype side has its own repair, and grouping them under one complaint about quality produces an answer that recommends nothing. The practical use of the distinction is diagnostic: it tells you which of several different pieces of work a specific problem actually requires.
Does the AI component decide my grade on this course?
No, and the course says so twice in its own materials. The opening lecture states that the AI component is one workflow step, and the Week 8 module states that it is important but is not the main grading target.
The final project rubric bears that out: its criteria are problem framing, functional completeness, engineering quality and maintainability, architecture and decision making, testing, documentation and operability, and repository discipline. None of them scores model quality. Teams that spend eight weeks on a model and two on everything else are optimising a criterion that does not exist.
Why does the starter end the request before calling the AI service?
Because it makes a slow or failing AI step survivable. The interface accepts the case, stores it, creates a pending job and returns immediately, so nothing the user experiences depends on how long the AI call takes or whether it succeeds. The worker then claims the job separately, calls the AI service and writes the result back.
If that call fails, the consequence is a job that can be retried rather than a user staring at a browser that eventually times out. That single boundary is why the course lists a worker or asynchronous path among its ten required elements.
Assessment move
Take the ten required elements and mark each one honestly against your own project as present, partial or absent. Do it in Week 3, again in Week 7 and again in Week 11, and keep the three lists. The progression itself is the strongest evidence you can bring to the technical brief, and the elements still marked absent in Week 11 are exactly what the final rubric will notice.
Working through From Prototype to Production in MAIE6000C? Sia is AskSia’s AI Computer Science tutor — ask any MAIE6000C From Prototype to Production 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.
