MAIE6000C Engineering AI Products: From Prototype to Production

How MAIE6000C is assessed

The published syllabus and the assessment overview list the same six components with the same weights, and they total 100%. No examination appears in the structure, and the two components timed for the examination period are a written brief and an oral defence rather than a paper. The word hurdle does not occur anywhere in the course materials, and no pass mark, grading scale or late-penalty rate is published, so the hurdle column records that the condition is not stated rather than claiming there is none. Two obligations sit outside the table: the confidential peer evaluation belongs to what Week 13 asks of you individually, and attendance at your scheduled oral defence slot is your own responsibility. A numeric threshold is not stated for either. Check the course Canvas pages for anything that governs whether you pass, and for deadlines and the current split.

Current MAIE6000C dates

Dates are as published in the course home page, the schedule announcement and the assignment pages on the course site for this offering. Confirm exact deadlines and submission settings in the live LMS.

What MAIE6000C covers

Eleven chapters follow the published weekly topics, from the prototype and production distinction and requirements work through schema, interfaces, worker paths and the midterm vertical slice to AI integration, deployment, observability, scaling, security and handover.

Teams design, build, test and demonstrate a complete AI-enabled system for a realistic operational problem, and the published course description is explicit that the primary challenge is engineering the system rather than inventing new machine learning methods or training large models from scratch. There is no examination.

All six assessed components are things you can show: a repository, a demonstration, a written evaluation of your own system, and a conversation in which you explain a decision you made.

The system contract every project has to satisfy

The course states the same ten requirements in three separate places, so treat them as the specification rather than as advice.

A team project only passes if it carries relational persistence, 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 AI-enabled function is one item on that list, and the course says directly that it is important but is not the main grading target, which is the single most useful sentence for planning how a team spends thirteen weeks.

From Prototype to Production

The opening chapter fixes the distinction the whole course is organised around.

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 readable interfaces, has a defined response to breakage, starts the same way every time, carries verification, and reports on itself through logs, health endpoints and documentation.

The gap between those two lists is what the rubrics measure, and each property in it has a specific repair rather than a general one.

Requirements and System Decomposition

Scope is set in Week 2 and rarely recovered afterwards.

The chapter works through the six questions that come before any tool choice, the published shape of a problem statement, the difference between functional requirements that contain verbs and non-functional requirements that name qualities with thresholds, and the candidate records a workflow of this kind always produces.

It closes on scope cuts, which the course treats as evidence of judgement rather than as a retreat.

Engineering Foundations and Bounded Change

The individual readiness assessment lands in Week 3 and its rubric is unusually informative: thirty five of its hundred points are available before the required task is attempted, for repository correctness and environment readiness, and another thirty depend on verification and written explanation afterwards.

The chapter reads that as a work plan, covers the repository workflow and the three milestone tags, separates unit from integration from smoke testing by what each one cannot see, and builds the habit the rest of the course assumes, which is writing the finish condition before making the change.

Data Persistence and Schema Design

The published claim is that the shape of the data governs how interfaces look, how legible the workflow is, whether anything can be audited, what the background step can do, and how dependable the result is, and that a weak schema creates problems everywhere else.

The chapter derives the record list from the lifecycle rather than the other way round, separates what belongs in the store from what belongs in logs, and makes the case that a schema which overwrites a proposal with a decision has destroyed the only direct measurement of whether the AI step helps.

APIs and Network Communication

Interfaces are where engineering assumptions become checkable.

The chapter sorts the starter's own endpoints into operational probes, reads and creates, sets out how much validation a crossing owes based on who is on the other side, separates liveness from readiness as two questions that fail in opposite directions, and works idempotency as a property of the contract rather than as a hope that callers will be careful.

Background Jobs and Worker Based Processing

The module states that background execution is not just a performance optimisation but frequently the right structural decision for work that takes a while, breaks often or deserves a second attempt, and that ought to stay visible and recoverable.

The chapter builds the job state machine with the two edges teams forget, the retry loop and the expiry that returns an abandoned claim to the queue, and gives the five-line specification a worker path should satisfy before any code is written.

The Vertical Slice and the Midterm Design Review

The midpoint checkpoint asks for five things demonstrated in a single run: a request entering, one persisted state change, one asynchronous step, one persisted output and one operational signal.

The chapter maps those five onto the six published rubric criteria, shows why forty of the ninety rubric points are unavailable to a demonstration whose parts are not connected, and sets out the order in which to update documents, commit, tag and record on the day.

AI Component Integration

The comparison here is between running the AI step as its own service and embedding it in the worker, and the dimensions that actually differ are failure blast radius, replaceability and whether the component has its own operational signal.

The chapter then turns to evaluation, and argues that an accuracy figure cannot answer whether the step is worth having, because the answer depends entirely on what the workflow does with the cases it gets wrong.

Reproducible Deployment

The module's standard is blunt: engineering has not really happened while a system leans on machine state nobody recorded, on setup moves nobody wrote down, or on the particular laptop of one member of the team, and reproducibility is not there yet while exactly one person can start the thing.

The chapter walks the clean-clone procedure as six gates, each of which proves one negative, and treats the exercise as a rehearsal for the final demonstration as well as an audit.

Observability and Debugging

Logs, health checks and metrics answer three different questions and each is blind to what the others catch.

The chapter builds the structured-event habit the starter demonstrates, names the two ways a health check can lie, and works a stuck item through a sequence of questions that narrows four candidate faults to one without opening a file.

It closes on the postmortem habit, which is worth starting in Week 10 because the final brief is assessed on evidence rather than recollection.

Scaling, Security and Handover

Two published weeks meet here, because the course itself merges them for this offering.

The performance half runs on an evidence ladder from claim through measurement, localisation, a targeted change and re-measurement to a documented trade-off, and on the module's own standard that honest bottleneck reasoning is worth more than exaggerated scalability claims.

The security and handover half asks what the system stores, what it logs and what it sends outward, and what a reader who is not on the team needs in order to run it.

How to use this guide

Read the front matter first, then work one chapter at a time against your own project rather than in the abstract.

Each chapter ends in practice items with full answers; write your own answer before reading them, because recognising a good answer and producing one in a design review are different abilities and only the second is assessed here.

The practice chapter mixes the whole course the way a defence does, and the closing chapter is the submission-week sequence.

Evidence and assessment control

Assessment labels, weights and timings follow the published syllabus and assessment overview for this offering, which agree with each other row for row and total 100%.

Teaching explanations, worked examples and practice items in this guide are independently authored and are not University assessment material; any marks shown on them are an AskSia study allocation rather than the course's own marking scheme.

Two published figures do not agree and both are shown where they matter: the Week 7 assignment header states a hundred points while its rubric criteria total ninety, and the Week 4 milestone appears with two different dates, one in a schedule announcement and one on the assignment page.

The course states that the course platform governs deadlines, grade status and the record that you submitted, so confirm every date and the current assessment split there.

Pass conditions, and what is not published

No hurdle, pass mark, grading scale or late-penalty rate appears in the course materials available here, and the word hurdle occurs in them zero times.

Two obligations do sit outside the assessment table and are worth knowing. The confidential peer evaluation is stated to belong to what Week 13 asks of you individually, and missing its deadline is stated to be able to bear on the individual part of your final result according to course policy.

Separately, attendance at your scheduled oral defence slot is stated to be your own responsibility, with a make-up process only where the course provides one, and missing a slot without communication should not be assumed to be excused. A numeric threshold is not stated for either obligation, and no consequence is spelled out beyond those sentences. Check the course Canvas pages for anything that governs whether you pass.

Turn a broad project direction into a slice you can demonstrate

Key terms

Vertical Slice

One complete path through every layer of the system rather than one finished layer. It is what the midterm milestone asks teams to demonstrate, because it is the only evidence that the components are connected rather than merely present.

Worker Path

Work carried out by a separate process outside the request cycle, with its own status record and its own failure behaviour. The course lists it as one of the ten elements every passing project must contain.

Job Record

A stored row representing work that should happen, carrying its own state, the stage it reached and how many attempts have been made. It makes waiting work visible, which a background thread does not.

Idempotency

The property that repeating a request does not change the state again. It is what makes a call safe to retry after a timeout or a double submission, and it is a decision made in the contract rather than in the caller.

Liveness Check

An endpoint answering whether a process is alive, deliberately without depending on anything else, so that an outage in a dependency does not cause a healthy process to be restarted.

Readiness Check

An endpoint answering whether a service can handle real requests, which normally means its dependencies are reachable. It is allowed to report not ready while the process itself stays alive.

Structured Log

A log line emitted as named fields rather than as prose, typically carrying a timestamp, a level, the service, a stable event name and event-specific detail. The stable event name is what makes a log countable and searchable.

Milestone Tag

A named point in the repository that fixes exactly which state a reviewer will inspect. The course specifies three exact spellings, and a tag created locally but never pushed is one of its named invalid submissions.

Clean Clone

Starting the system from an empty directory on a machine that has never run it, which is the only test that exposes hidden machine-specific state, undocumented steps and manually created database tables.

Fallback Path

What the workflow does when an AI-enabled step returns nothing usable: a manual queue, a clarifying question or an escalation. It is a route with a record attached, not a message shown to a user.

Scope Cut

A feature the team decides not to build, recorded with the reason. The course treats it as evidence that a team understands what must be postponed rather than as an admission of weakness.

Technical Debt

Work knowingly deferred, listed with what it would cost and why it was deferred. Naming it supplies the limitation the final demonstration asks for and the trade-off discussion the technical brief is graded on.

MAIE6000C FAQ

How to prepare for the assessments

Pick your team's project direction as early as you honestly can and carry it through every chapter instead of reading in the abstract. Three questions answered against your own system are worth more than any chapter read twice: which of your records has a state that changes, which of your steps does not belong inside a request cycle, and which of your failures is currently invisible from outside.

Those three map onto the schema, worker and observability chapters, and together they are most of what the midterm and the oral defence ask about.

Your AI Computer Science tutor for MAIE6000C

Stuck on a hard MAIE6000C question? Sia is AskSia’s AI Computer Science tutor — ask any MAIE6000C Engineering AI Products: From Prototype to Production question and get a clear, step-by-step explanation grounded in how the course is actually taught and assessed. Read this whole study guide free, then take your hardest questions to Sia.