Assessment

The model behind the three assignments and how everything is marked: the shared rubric, what you submit, deadlines, extensions, and appeals

The formal assessment rules are ANU policy: penalties, the extension and ECA procedures, appeals and their deadlines. They live in the course’s Programs and Courses entry (COMP4020, COMP8020). This page covers the course-wide practical detail — the things true of every deliverable. Each assignment’s brief and each week’s crit page carry their own specifics, and this page links to them rather than repeating them. One rule up front: there are no late submissions.

On this page: the overview · what you submit · how it’s marked · the assignments · where this model comes from

Assessment overview#

Four deliverables make up the final mark. There are no hurdles: your grade is the weighted sum of the tasks below, and 50% or more overall is a pass — ANU’s grading scale sets out what each letter grade means.

The “studio engagement” mark comes from the ten weekly crits, scored 2% each across weeks 2–11: one mark for shipping by that week’s cutoff, one for your contribution in the session — see how the crit marks work. The three assignments each publish their own brief and rubric on the assessments page.

Every deliverable on one timeline: hover over (or tab to) any marker for the details, and click through to the page for it.

What you submit#

Every prototype is its own repository, generated for you from the course starter template and waiting in the course GitHub org — you never create course repos yourself (the onboarding page covers accepting the org invitation and the start skill that clones each week’s repo). Your “live URL” is always the one derived from your repo — the default GitHub Pages URL (comp4020-agentic-coding-studio.github.io/<repo>/) up to crit 6, <repo>.fly.dev from crit 7 onwards. That URL is the URL of record, where demos, marking and the crit runsheet all point; custom domains aren’t supported for submissions.

Repo-per-week has one exception. From week 9 the crits work on the final project itself, so those three crits and the final-project submission all live in one repository.

Your repo starts private: while you’re building, peers can’t read your source, your prompts or your harness. You can still see your WIP on your local dev server, and the starter template’s check scripts give you the same feedback CI will give you later. Before your cutoff, flip the repo public with the course /ship skill — the day before your crit is the norm, and flipping early costs nothing, since you can keep pushing until the cutoff. When you do, the whole repo goes public, full commit history and CI logs included.

A day out from your cutoff, an automated check DMs you on Ed if your repo isn’t yet public with a working deploy. It’s a nudge, not a safety net: a repo still private at the cutoff hasn’t shipped, and the shipped mark reads from what the post-cutoff sweep finds — see in-crit prototype marks.

The deployed artefact is what gets marked, and the repository is how we read your code; we don’t (in general) pull and build it ourselves. The exact artefacts are listed in each brief, but the shape is consistent. Your repo holds:

• the prototype: your source, in whatever software stack you chose, that builds and deploys to the live site. It’s assessed in the marking environment described below.
• the checks (spec/): run locally with pnpm check while you build, and in CI on every push once the repo is public. The starter ships the invariants — what’s true of any good website whatever the week asks: landmarks, headings, a declared language, alt text, and from crit 7 an automated accessibility floor (axe’s rule set). Where those live depends on the starter: the Assignment 2 course-site starter runs them (axe included) inside pnpm build, and its spec/ ships a single course-data check instead. The final project ships only two: the app answers at /, and /readme/ publishes your README.md; its accessibility checks are yours. The rest is yours to write: turning each week’s published spec into tests is part of the work. Green checks at the sweep are worth half of that week’s shipped mark, and any extra linters, tests or performance checks you wire up run from the same entrypoint. The CI workflow (.github/workflows/checks.yml) is part of your harness too: if a step misfires on a site with nothing wrong in it, fix the step. The shipped checks stay as shipped.
• your reflection (reflections/, crit weeks only): a short markdown file answering the two standing prompts: what was the breakthrough that moved the work forward? and what did this work change about who I want to be as a software developer? One entry per crit, named for the crit it answers with the same number as the repo: crit-1.md in comp4020-crit1-<handle>; the final-project repo holds one per crit. It has to be there by the cutoff for that week’s prototype to count as shipped, and the sweep reads no other filename. Assignment repos carry none: the assignment’s written account is its PROCESS.md, and the retro crit presents from that.
• your process overview (PROCESS.md): your own account, written by you for a reader, of how you got from the brief to the harness and agentic workflow behind this submission. Cite commits as you go, as links whose text is the hash or range and whose target is the GitHub commit or compare URL. Uncited claims don’t count as evidence, and markers don’t trawl the repo for what you didn’t cite. The starter’s template shows the shape, and pnpm check:evidence verifies the bundle before you ship; word counts below covers lengths and screenshots.
• your CLAUDE.md: the harness you built to direct the work, carried forward and grown from one deliverable to the next.
• your commit history: the record of how the work actually came together. Commit as you go — a trail that grew alongside the code is far more convincing than one big dump at the end.

The course preflight skill can walk you through this checklist before you hand in, so nothing is missing when your tutor picks it up.

How it’s marked#

Marking asks two questions, and keeps them separate. The checks answer whether it works, while you build: objective backpressure, run locally and in CI. A person answers everything that calls for judgement: markers read your process, look at the live site, and talk with you in the crit. No automation ever judges the quality of your work — when anyone can prompt a plausible-looking result in minutes, an automated grade would just reward plausibility.

The weekly crit marks sit outside that split, because nobody’s opinion is in either of them: the shipped mark is a record an automated sweep captures and your tutor confirms — did you push, is it live, is the reflection there, are the checks green — and your contribution mark is a call about the session, not about your repo. See how the crit marks work.

Marking environment#

Prototypes are assessed live on the web, in a fixed environment: the latest stable Chrome, visiting your deployed URL with the source open on GitHub in another tab, at two viewports:

• 1920×1080 — desktop
• 390×844 — phone (the iPhone preset in Chrome DevTools’ device toolbar)

Both are full marking environments: everything the brief asks for has to work cleanly at both. Most of the web’s traffic arrives on a phone, and a prototype that falls apart there hasn’t shipped.

Those are viewports, not monitor sizes — reproduce both exactly in Chrome DevTools’ device toolbar. “It works on my machine” is not a defence: the deployed artefact is the submission.

The assignments#

The three assignments carry 80% of the course between them, and each is the weekly crit loop run longer: a prototype built with an agentic workflow against a meatier provocation and deployed at a public URL, with the same repo anatomy (set out under what you submit above) and the deadline in the role of the cutoff. The submission is the deployed state of your last commit at the deadline. Assignment 1 and Assignment 2 (static, 20% each) are a deliberate-practice loop — build, reflect, build again — on the same canvas and the same rubric; the final project (full-stack, 40%) carries the same skills onto a new substrate, with the stack yours to choose and justify. Each brief has the full picture: the provocation, the rubric bands, and what’s specific to that assignment. Choosing the no-AI route changes none of this: same specs, same rubric, same repo anatomy.

Each assignment’s identity is its provocation: playful, a little subversive, and published only when the assignment opens. Provocations in this course satirise, expose or stress-test a thing; they don’t ship real harm at real users. The reveal is a moment: the whole cohort gets the same brief at the same time, and the gallery at the end shows what they each did with it.

The week each static assignment lands, the crit is a retro (retrospective): a brief demo, then the breakthrough that made the assignment click, shown as a before/after and drawn from your PROCESS.md. The retro carries that week’s crit mark — see in-crit prototype marks.

Marking rubric#

Every assignment is marked on the same three things:

• process: how clearly a reader can see how you got from the brief to the harness and agentic workflow behind the submission — your PROCESS.md, the CLAUDE.md and spec/ checks behind it, and the commit history. A marker follows the overview’s citations into the history, and claims it doesn’t corroborate don’t count.
• artefact: whether the deployed thing works, and is good, at both marking viewports.
• response: the answer the whole submission gives to the brief, scoped and concise, and at its best pointed and surprising.

Each criterion is marked out of 100 against a published band, then weighted and summed into three holistic judgements. What changes across the three tasks is the weighting:

Process always carries the most weight: shipping is necessary but not sufficient, and the marginal marks sit in reading how the work came to be. Response is where standout work pulls ahead — the whole cohort answers the same provocation, so wit and judgement can be rewarded side by side. At the final project process rises to half — its account also has to make the case for the stack and workflow you chose — and the artefact and the response split the rest evenly: a real system under real constraints, answering an open brief with judgement. COMP8020 students also carry a critical research note in the final project; see the brief for how the 40 reweights.

The bands are HD 80–100, D–Cr 60–79, P 50–59, N below 50. The marker places your work in a band against the criterion’s descriptors — published below, so you can see why work lands where it does — then picks a mark within it. Your final course grade uses ANU’s usual letter grades, which separate D (70–79) from CR (60–69); the criterion bands group them because the descriptors don’t split usefully at that level, and the comment beside your mark shows each criterion’s letter on that finer scale. Markers cross-mark a sample of submissions and calibrate to a shared standard before marks go out.

Band descriptors#

All three assignments are marked against one shared set of descriptors, criterion by criterion. The descriptor for the COMP8020 research note is on the final project’s brief.

Legibility of process (/100)

• HD — corroborated and skilled: beyond checking out, the evidence shows deliberate direction — failures diagnosed and fixed at the harness level rather than retried, judgement visible in what was thrown away — and the account justifies the calls: why one beat the obvious alternative, and how you knew the result was right before accepting it.
• D–Cr — corroborated and competent: the account checks out and shows a real working process, but the directing is routine — attempt, accept, repeat — or the evidence has thin spots.
• P — process asserted rather than shown: claims uncited, or only weakly supported by the evidence.
• N — no real evidence of a directed process, or a commit history that contradicts the account.

Working deployed artefact (/100)

• HD — holds up under use it wasn’t designed for: the keyboard, a resize mid-interaction, a slow connection.
• D–Cr — deployed, live, and does what the brief asks at both marking viewports.
• P — notable gaps: the core interaction is unreliable, or one viewport is broken.
• N — doesn’t deploy, or doesn’t work.

Response to the brief (/100)

• HD — a pointed, surprising answer to the provocation, scoped with judgement: one idea, carried all the way.
• D–Cr — a well-scoped response with a real idea behind it; minor drift.
• P — meets the brief only loosely; over- or under-scoped, or an answer without a point of view.
• N — off-brief.

The gallery#

When marks come back, each assignment gets a public gallery, in the same spirit as the crits’ hall of fame: every submission, listed by prototype title and live URL, with no added attribution. (If you’d rather your work weren’t listed, tell the convenor in a private Ed thread before marks are returned.)

The whole cohort answered the same provocation, so the gallery is the full spread of answers to one question — reading it is how you calibrate your own sense of what good looks like. Those submissions are public from the deadline, so building on them is permitted under the academic integrity rule, and they seed pod riffs and later work.

The final project gets a live version of the same thing: a capstone showcase, in person, on Wednesday 11 November 2026, 11am–3pm in the Birch Building (#35), as part of the School of Cybernetics’ Cybernetics Showcase (free, but register). It carries no marks: it’s the course’s closing look at what the cohort built.

Word counts#

Word counts on written components are indicative guidance: 400–600 words for an assignment’s PROCESS.md (900–1100 for the final project’s, which also makes the case for the stack and workflow), 400–600 words for the final project’s README.md, 150–300 words per reflection entry, and 600–800 words for the COMP8020 research note. A weekly crit repo’s PROCESS.md runs to 150–300 words, in proportion to one week of work; in the final-project repo it is rewritten at each crit and grows towards its 900–1100. There is no word-limit penalty, but writing an appropriately scoped, concise response is itself part of your response to the brief, so work that badly overshoots can lose marks there.

Images don’t count towards any of those lengths, and they’re welcome wherever one carries the point better than a sentence does — a failing check beside its fix, a before/after at the mobile viewport. Commit them to your repo and link them with a relative path, which is what makes them render on GitHub, where your markdown is actually read. An image is evidence: it sits alongside the commit link it belongs to, and a screenshot of a transcript still leaves you owing the curated prompts the brief asks for. Nothing checks that your images render, so open your PROCESS.md on GitHub before you ship: that rendered page is what your marker sees.

Deadlines#

Assessment due dates are listed on each brief, and they fall at noon on a Monday. The midday slot is intentional: if something breaks at the last minute, you have the rest of the working day to ask for help.

The submission timestamp is the last commit pushed to the main branch. There’s a 15-minute grace period beyond the published deadline, so a noon deadline really means 12:15pm. Don’t cut it close.

Late submission#

There are no late submissions. Once the deadline (plus the grace period above) passes, the submission is closed and a missed deadline scores zero. There’s no 5%-a-day taper to lean on.

That’s deliberately blunt, so it’s balanced by the other half of the policy: extensions are easy to get. Hand in on time, or arrange more time before the deadline.

Extensions#

If something is going to stop you submitting on time, request a short one through the ANU School of Computing extension app before the deadline. You don’t need to be on death’s door; you just need to ask before the due date, and short extensions are granted routinely.

For longer or unforeseen situations (illness, injury, unexpected caring duties), the Extenuating Circumstances Application (ECA) is the formal route. ANU sets its outcomes, not the convenor: an altered due date, an alternative assessment, or modified weighting (a missed component’s weight redistributed across the rest), never a direct mark bump. If you’re not sure which you need, ask early.

Feedback and re-marks#

Every assignment mark comes with written feedback from your marker, written to be useful for the next assignment rather than to justify the number — and there is a next one, twice.

The final project is the exception, because there is no next one: its result comes without written feedback. If you’d like feedback on it, ask on a private Ed thread once results are published, and your marker will email it to you.

If you want more than the written feedback gives you, ask your tutor. They marked your work and they’re happy to talk it through, particularly if you bring a specific question about it.

If you’re unhappy with the mark itself, you can ask for an independent re-mark: a different marker marks your submission from scratch, without seeing the original mark or feedback. Their mark replaces the original, and in asking for one you accept that outcome — in the University’s words, it “may be a higher mark, the same mark, or a lower mark”.

This is ANU’s Stage 1, informal consideration, and re-marking your work, or organising another person to re-mark it, is exactly what that stage empowers a convenor to do. So its deadline is the University’s rather than ours: ask on a private Ed thread to the convenor within 20 working days of the result being published. You’ll have the re-mark back within 20 working days of asking.

If that doesn’t resolve it, Stage 2 is a formal appeal to your Associate Dean; the assessment appeals page sets out how. A Stage 2 appeal against a single assessment task is considered as a component of the final grade, after that grade is published, rather than settled mid-semester.

All marking in this course is done by people — no AI grades your work — and it’s blind-moderated across the teaching team.

Where this model comes from#

The same studio literature that shapes the crit shapes the assignments; the additional reading behind this page is about practice, transfer and standards:

• K. A. Ericsson, R. Th. Krampe & C. Tesch-Römer (1993), “The Role of Deliberate Practice in the Acquisition of Expert Performance”, Psychological Review 100(3). The two static assignments and their retros are a deliberate-practice loop: effortful attempt, specific feedback, another attempt.
• D. N. Perkins & G. Salomon (1992), “Transfer of Learning”, in International Encyclopedia of Education (2nd ed.). Skills don’t move to new contexts for free, so the final project is the course’s transfer test.
• J. Biggs (1996), “Enhancing Teaching Through Constructive Alignment”, Higher Education 32(3). What’s assessed is what’s learned, so the criteria are the learning outcomes restated.
• D. R. Sadler (1989), “Formative Assessment and the Design of Instructional Systems”, Instructional Science 18(2). Students need to internalise the teacher’s concept of quality — hence published bands, plus the gallery and the crits, where the standard is embodied in real work.