Year 12

Digital Solutions Units 3–4: Innovation, Architecture and Impact

This is the final year of the Digital Solutions pathway, and it is built around one uncomfortable claim: most student solutions fail before a single line of code is written, because nobody checked whether the problem was real. Unit 3 fixes that first. Learners learn to read a workaround as a signal, to screen opportunities against frequency, pain and reach rather than enthusiasm, and to scope a problem down until a prototype can test it inside a weekend. They then build fast and deliberately rough, because the point of a prototype is to be wrong cheaply, and they learn to change a design on evidence rather than on preference — including their own. From there the unit turns to advanced solution design: modular architecture with cohesion and coupling named properly, data structures chosen with a justification and a stated trade-off, algorithm efficiency reasoned about in the plain language a marker rewards, and interfaces designed for a defined audience rather than for the designer's own thumbs. Unit 4 then asks the question senior students are old enough to face: once this thing is deployed, who bears the cost? Security is separated from the comforting word 'encrypted', privacy is separated from secrecy, data sovereignty is treated as a legal and jurisdictional fact rather than a vibe, Indigenous Data Sovereignty is treated with the seriousness it is owed, and algorithmic bias is traced back to training data, proxy variables and feedback loops instead of being waved at. Every impact argument is built as claim, evidence, reasoning, counterargument and qualified conclusion — slogans score nothing. Lesson 4 is the craft lesson: the Units 3–4-style folio from proposal to impact evaluation, the decision log that lets a marker follow your reasoning at speed, test evidence that actually proves something, and how to plan and write under time without panicking. Nothing in this unit requires a device.

🧭 Why it matters: There are two honest reasons this unit matters, and only one of them is your senior result. The first is immediate and it is fine to say out loud: your internal assessment is real, it is moderated, the external assessment is sat under time, and together they produce a subject result that follows you out of school. That is a genuine stake and pretending otherwise helps nobody. What is worth knowing is what the stake actually rewards. It does not reward the biggest feature list, the prettiest screens, or the most hours. It rewards a problem that was shown to exist, decisions that were justified against criteria, evidence that was collected and reported straight, and an evaluation that names the limits of your own work. Those are learnable, they are learnable on paper, and a calm student who documents well will outscore an exhausted one who built more. The second reason outlasts any result by decades. Within a few years you will be in a room — a job, a volunteer committee, a start-up, a council, a family business — where somebody proposes a system. Somebody will say it is secure because it is encrypted. Somebody will say the algorithm is objective because it is maths. Somebody will suggest collecting a bit more data than is needed, just in case. Somebody will not ask where the servers are, or whose data it is, or who was never consulted. Australia has already learned several of these lessons expensively and in public, through large-scale breaches and through automated decision-making that harmed people who could not appeal it. The person who can ask the precise question — what threat does that control actually address, what is the proxy variable in that model, whose law applies to that storage location, who bears the cost of a false positive — is not being difficult. They are the most useful person in the room, and this unit is where you become them.

Big ideas

• Innovation is not novelty — it is a solution that is new to its context, delivers value someone can name, and is actually adopted; a brand-new idea nobody uses is not an innovation, and an old idea applied where it has never been is
• The strongest evidence that a problem is real is a workaround: when people have already built a clumsy manual system, they have proved both the need and their willingness to change
• A prototype exists to be wrong cheaply — its job is to kill your riskiest assumption this week, not to look finished
• Architecture is what determines whether a solution can be changed: high cohesion inside modules and low coupling between them is the difference between a folio you can extend and a folio you can only rewrite
• A data structure is a decision with a trade-off, and the trade-off is the marks: a hash lookup buys speed with memory and unordered storage, and 'I used a dictionary because it was quick' is not a justification
• Efficiency reasoning is about how cost grows with size, not about how fast something feels on your data — and O(n²) is perfectly acceptable when n is thirty and indefensible when n is thirty thousand
• Encryption protects data in specific states against specific threats; it does nothing about weak authentication, over-collection, insider access, or a system that simply shows the wrong person the right screen
• Where data physically lives determines whose law reaches it, which makes data sovereignty a design decision rather than a hosting detail
• Algorithmic bias is rarely in the algorithm: it arrives through the training data, through proxy variables that stand in for protected attributes, and through feedback loops that make the model's own output its next input
• A design decision that is not documented did not happen as far as a marker is concerned — the folio is the reasoning made visible, not decoration around the artefact