Minor Digital Skills: from idea to a shareable link.

01. Minor Digital Skills — From idea to a link you can share.

Open with the full module purpose, not a tool or AI-history question. This presentation uses the 7 EC brief explicitly supplied by the course owner. It teaches an AI and deployment strand inside the broader minor. The supplied brief names Raluca Radu as field expert; Victor remains the instructor for this presentation. Do not silently conflate the two roles.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

02. What you will leave with

Success today is a live page plus evidence that the student understands how it reached the web. This is a workshop deliverable, not a newly approved assessment rubric. Full teaching detail retained from the text version: WELCOME | What you will leave with | 01 | An explanation | How AI, agents, Git, and deployment fit together. | 02 | A product decision | One customer, one problem, and one useful next action. | 03 | A live page | A small venture site with a public URL. | 04 | Proof of work | A repository, a commit, a preview, and a review note. Visual: reused course-library asset coding-agent-editorial.jpg; illustrative unless it is an existing screenshot. Workshop focus: Start by opening the working starter in the browser and sharing its link. Ask a student to try it. The promise is a small useful thing someone else can open: a new idea or an extra for an existing business. The study-session planner is a learning example, not a required venture. Show the result before explaining the tools. Keep advanced deployment detail available as reference.

Earlier Year 4 opening; see retained source notes

03. Why this is valuable for your venture

The module is about the economy of experience and meaning. Ask for an example where a customer is an active participant rather than only a buyer. Explore how the experience changes business purpose, marketing, community and the business model. Full teaching detail retained from the text version: WELCOME | Create an experience people take part in | Participate | Customers do something meaningful. | Share | The experience gives people a reason to connect. | Create value | Customers, partners and the venture benefit. | Test it | Use your own business case and real observations. | Which experience would your customer choose to join and share? Visual: reused course-library asset station-reimagined.jpg; illustrative unless it is an existing screenshot. Connect the live-page outcome to the module: a tangible customer experience, faster testing of a value proposition and decisions grounded in observation. A live website alone does not establish customer demand. Workshop focus: Examples for existing businesses: a service business shares a quote calculator, a tutor shares a booking-request page, a shop shares a product finder. These are possible small additions, not promises that a static page supplies a production booking or payment system. Ask which repeated customer question or task students could make easier. Measure a relevant action such as completed requests or time saved.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

04. Today’s roadmap: idea, tools, share

Explain the sequence: introduction and Git/Vercel basics, agentic deployment, workflows, then automated content creation. Full teaching detail retained from the text version: THE WIDER MINOR | One venture runs through this series | 01 | Today | Introduce the idea and publish a first page. | 02 | Agentic deployment | Use an agent to improve the site and inspect its changes. | 03 | Agentic workflows | Connect tasks, tools, checks, and human handoffs. | 04 | Content creation | Turn useful source material into reviewed assets. | Earlier course decks remain available as examples and deeper references. Visual: reused course-library asset creator-pipeline-editorial.jpg; illustrative unless it is an existing screenshot. Roadmap: understand why shared AI access changes competitive advantage; understand history and model basics; choose and prompt a model; build a useful page, publish it and test with a peer. This workshop starts a longer venture journey into agentic deployment, workflows and content creation. Workshop focus: Teach toward a link from the first minute. Begin with a small customer problem; demonstrate AI and product tools using their logos; build a first version; publish and share it; improve from feedback. Model theory supports better choices. It is not a prerequisite to attempt the first simple build. ChatGPT or Claude can help with a brief, Codex or Claude Code with code, and GitHub plus Vercel with the illustrated publishing route. Students do not need every tool. Brand marks: chatgpt, claude, codex, github, vercel. Asset sources are recorded in assets/logos/sources.json.

Earlier Year 4 opening; see retained source notes

05. Meet your instructor: Victor Cazacu

Keep this introduction to 30–45 seconds. Name, founder / forward deployed engineering experience, and why it helps students build useful ventures. Portfolio example and QR are included on this slide. Workshop focus: Combined instructor introduction, venture example and portfolio link. Introduce Victor as a founder and forward deployed engineer. Point to LEGIT AGENTIC as a portfolio example. Invite students to scan https://vicorico-fun.vercel.app/ and choose one project whose customer problem they can explain. Keep the spoken introduction short; the QR lets students explore later.

Earlier Year 4 opening; see retained source notes

06. How often do you use AI?

Allow two minutes. Read each prompt separately and reset hands between prompts. Invite two short examples, ideally from students with different experience. Welcome beginners; use the answers to judge how much vocabulary to explain. Full teaching detail retained from the text version: A QUICK SHOW OF HANDS | How often do you use AI? | 01 | Raise your hand if you have used AI today. | 02 | Keep it up if you use it almost every day. | 03 | Raise your hand if you are still getting started. | Two voices: what was the last real task you used it for? Visual: reused course-library asset chat-editorial.jpg; illustrative unless it is an existing screenshot.

Class engagement

07. Which AI tools are already in the room?

Allow two minutes. Hands are optional; students can select more than one tool. Ask one or two volunteers to describe a useful task, not just a favourite brand. Free users and beginners can participate fully; do not ask anyone to buy access. Full teaching detail retained from the text version: A QUICK SHOW OF HANDS | Which AI tools are already in the room? | 01 | Who has a paid ChatGPT subscription? | 02 | Who has a paid Claude subscription? | 03 | Who uses free access, another tool, or neither? | What do you use it for, and what still frustrates you? Visual: reused course-library asset human-agent-team-editorial.jpg; illustrative unless it is an existing screenshot. Brand marks: chatgpt, claude. Asset sources are recorded in assets/logos/sources.json.

Class engagement

08. Everyone can now access intelligence.

Original Course 2 PDF page 10. Explain the shared-access diagram: similar foundational capabilities are available to competitors. It is a strategic framing, not a claim that every model or account is identical.

Course 2 final 38-page PDF, pages 10-12; printed slide numbers 08-10.

09. Intelligence alone is no longer the moat.

Original Course 2 PDF page 11. Keep the equal company positions to show the argument: model access alone is not differentiation. Ask which customer knowledge, workflow or trust advantage is harder to copy.

Course 2 final 38-page PDF, pages 10-12; printed slide numbers 08-10.

10. Into deployment.

Original Course 2 PDF page 12. Preserve the differing deployment outcomes and highlighted company. The positions are illustrative, not benchmark data. Deployment here means applying intelligence to real work; bridge directly to forward deployed engineering.

Course 2 final 38-page PDF, pages 10-12; printed slide numbers 08-10.

11. Forward deployed engineering

Explain working beside the customer: understand the workflow, ship a small change, observe the result, and iterate. Ask students which real person could test their venture this week. Full teaching detail retained from the text version: WHERE THE ADVANTAGE GOES | Forward deployed engineering | Work close to the customer and the real workflow. | 01 LISTEN | Find the costly or frustrating step. | 02 DEPLOY | Fit available AI into a usable product. | 03 LEARN | Test the result; improve what fails. | My teaching question: What did the deployment change for a real user? Visual: reused course-library asset coding-agent-editorial.jpg; illustrative unless it is an existing screenshot.

Earlier Year 4 opening; see retained source notes

12. The shift came when ideas met data and compute.

Neural-network ideas predate today's companies. Explain how data, compute and research met; introduce Hinton and Sutskever through the historical images. Brand marks: openai. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

13. OpenAI meets accelerated computing.

OpenAI was introduced in 2015; NVIDIA delivered a DGX-1 in 2016. The lesson is the combination of research and infrastructure, not a single-founder invention story. Brand marks: openai, nvidia. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

14. The ideas were older. The doorway was new.

Connect Transformers (2017), GPT (2018), and public ChatGPT (2022). Ask what changed when an unfamiliar technology gained a conversational interface. Brand marks: openai, chatgpt. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

15. SOTA = state of the art

Define the acronym before showing any products. Ask: state of the art for what task, measured how and on what date? Avoid turning a product spotlight into a universal ranking. Full teaching detail retained from the text version: THE TERM YOU WILL HEAR EVERYWHERE | SOTA = state of the art | Best demonstrated performance | on a particular task, at a particular time. | A benchmark is one test. Your product has its own test. | Ask: quality, speed, cost, reliability and tool access. | Try the same real task before choosing your tool. Visual: reused course-library asset local-gpu-editorial.jpg; illustrative unless it is an existing screenshot.

16. SOTA map: OpenAI and Anthropic / Claude

Carry over the SOTA/tool-choice lesson from the 38-slide Course 2. These are class examples; verify account access before class. Students may use either tool or make the same change manually. Full teaching detail retained from the text version: SOTA, THE MARKET AND YOUR EDGE | Two coding-agent options from Course 2 | OpenAI Codex | Read a project, propose edits, run checks. | Claude Code | Work with project files, tools and development tasks. | Your role | Give the brief. Inspect the diff. Test the result. | Today's test | Can it make one useful change you can explain? | The coding agent helps make the files. Git records them. Vercel hosts the result. Visual: reused course-library asset coding-agent-editorial.jpg; illustrative unless it is an existing screenshot. Provider overview, not a claim that either provider wins every benchmark. OpenAI develops GPT models; ChatGPT is its app and Codex is a coding agent. Anthropic develops Claude models, available in the Claude app, Claude Code and through APIs. Compare the same real task. Models, account availability and limits change; consult the linked official catalogs. Checked 2026-10-12. Brand marks: openai, claude, chatgpt, codex, anthropic. Asset sources are recorded in assets/logos/sources.json.

https://developers.openai.com/api/docs/models | https://platform.claude.com/docs/en/models/overview

17. Top 50 consumer AI apps

Show the original supplied chart. It is a dated snapshot of observed consumer spending, not a current census of global company revenue.

Earlier Year 4 opening; see retained source notes

18. Benchmarks: three ways to test a model

A benchmark is a repeatable test with defined tasks, conditions and scoring. Standard tests can use exact answers or executable code tests. Human pairwise comparisons measure preference, which can favour style over correctness. Rubric-based expert review is useful for less objective tasks; model-as-judge scoring is another method but should be checked against human judgements. In a venture test, use representative examples and success criteria, including failure cases. Keep prompt, context, tools and generation settings comparable; record model version and date; repeat tests rather than choosing a single good answer. Measure accuracy/task completion separately from latency and cost. Public test leakage, saturated benchmarks and different scaffolding can distort comparisons. Classroom exercise: give two models the same five customer requests, hide the names, score factual accuracy and usefulness, then compare time and cost. Five requests are a demonstration, not a statistically reliable ranking.

https://epoch.ai/benchmarks/about | https://blog.lmarena.ai/blog/2024/arena-hard/ | https://arena.ai/blog/preference-proxy-evaluations

19. Parameters: what does 7B actually mean?

Parameters are learned numerical values, such as weights, adjusted during training. B means billion: 7B denotes about seven billion parameters. This is different from the number of tokens in a prompt, the context-window size, or user-adjustable generation settings such as temperature. Parameter count is one factor, alongside training data, training method, architecture and inference compute; it is not an IQ score or a universal quality ranking. Mixture-of-experts models have a total parameter count and a smaller subset active for each token. Memory and serving costs depend on precision, architecture, context and deployment as well as count. Not every provider discloses counts; do not invent sizes for closed models. Ask: would you choose a larger model if a smaller one passes your real task more cheaply?

https://huggingface.co/blog/moe

20. Parameters are learned numbers. Tokens are text pieces.

Explain the distinction before the thought experiment. Parameters are learned numerical values; they do not map one-to-one to words. Tokens are units processed by the model, often words, subwords, punctuation or bytes depending on the tokenizer. Token IDs index learned representations, which are processed with the rest of the model to produce scores for possible next tokens. Training-token count, parameter count and context-window size are different quantities. A model can generate the same token repeatedly without adding parameters. Ask students which number changes when you paste a longer prompt: input-token count, not model parameter count.

https://huggingface.co/docs/transformers/main/tokenizer_summary

21. The AI IQ bell curve

Use the original supplied image. Do not describe this IQ-like scale as a clinical measure of human intelligence or as a permanent ranking. Use this original image, previously slide 33, to introduce AGI and the possibility of broader model access. Treat it as a dated benchmark illustration, not proof of AGI. Continue immediately to the AGI discussion.

Earlier Year 4 opening; see retained source notes

22. AGI: what if everyone can access stronger models?

Explain benchmark coverage and uncertainty. Bring the conversation back to quality, latency, cost and reliability on the student's own task. Full teaching detail retained from the text version: READ THE EVIDENCE | A model score is a constructed estimate. | Benchmark results | are mapped to an IQ-like scale | Coverage varies | some scores include estimated gaps | YOUR QUESTION | Which model works for our task, budget, and checks? | Source: AI IQ methodology (the site calls IQ a metaphor) Visual: reused course-library asset fact-check-editorial.jpg; illustrative unless it is an existing screenshot. Use the preceding original IQ/models image (formerly slide 33) as a discussion prompt. AGI means artificial general intelligence; definitions differ, but the discussion concerns broad capabilities across tasks, not a single benchmark. The chart is an IQ-like benchmark illustration, not clinical human IQ, proof of AGI or a verified current ranking. Broad access to stronger models is a scenario, not a guarantee: pricing, geography, permissions and release policies differ. Ask: if competitors have comparable model access, what remains distinctive about your customer knowledge, workflow, distribution and execution?

Earlier Year 4 opening; see retained source notes | https://openai.com/charter/

23. A smaller model: where would you draw the line?

User-proposed thought experiment, adapted for numerical and conceptual accuracy. Start by asking students to imagine that they regard a very capable 1-trillion-parameter conversational model as conscious. Imagine a sequence of separately constructed, appropriately trained smaller systems: 1T, 100B, 10B, 1B, 100M, 10M, 1M, 100k, 10k, 1k, 100, 10. Each is one-tenth the previous size. For the thought experiment only, imagine language becoming less fluent, then fragmentary, then repetitive, then a tiny set of output labels. These are stipulated behaviours, not empirical capability thresholds. Do not claim that a particular 1B/100M model must hallucinate at a certain rate, or that ten parameters can implement a normal language model. You cannot literally delete 90% of arbitrary weights while retaining the same working architecture; changing width or depth changes the architecture, and pruning or distillation involves additional choices. Ask: at what point, if any, would you attribute consciousness? Is fluent speech your evidence, or something else? Would every matrix calculation qualify? If not, what additional properties matter? What observation would change your view? Invite students to defend a criterion rather than guess a parameter threshold. Distinguish task competence, AGI and subjective experience. Neither this scaling story nor a benchmark score establishes the presence or absence of consciousness. There is scientific and philosophical disagreement about what would count as sufficient evidence.

Course-owner thought experiment, corrected and framed as hypothetical | https://arxiv.org/abs/2308.08708

24. How does a model learn and reply?

Transition from history into mechanism. Students only need a useful mental model; no maths background is assumed. Full teaching detail retained from the text version: AI FOUNDATIONS | THE MECHANICS | How does a model learn and reply? | Examples become weights. A prompt becomes an output. Visual: reused course-library asset neural-network-editorial.jpg; illustrative unless it is an existing screenshot.

Earlier Course 4: From AI Knowledge to AI in Practice

25. Training is repeated prediction and correction.

Training repeatedly predicts and adjusts weights. Distinguish training from using a trained model; ordinary prompting does not retrain the model for every user. Brand marks: google, cursor. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

26. It generates the reply one piece at a time.

Explain tokens with a short sentence. The next-token process is a simplified account of autoregressive language generation, not every possible AI architecture. Brand marks: google, cursor. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

27. The model can take more than one plausible path.

Ask students to choose between the two potato headlines and explain their choice. A plausible answer still needs facts, audience knowledge and editorial judgment. Brand marks: cursor. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

28. A model call has two sides of the meter.

Input and output both contribute to text API usage. Avoid promising a universal token-to-word ratio or a permanent price. An app subscription may not include API credits. Worked example: 1,000 input tokens plus 250 output tokens. Cost = 1,000 × input rate + 250 × output rate, with rates expressed per token. Provider rate cards often quote per million tokens. Context includes instructions and conversation material sent with the call. Caching, reasoning and tool costs depend on the model and provider; avoid presenting the simple formula as the full bill for every product. Brand marks: cursor. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

29. AI is not one model.

These are examples of model families, not a leaderboard. Hosted and open-weight models can both be accessed through cloud services. Open weights do not automatically mean unrestricted licensing. Full teaching detail retained from the text version: THE MODEL LANDSCAPE | AI is not one model. | Model-family examples from the earlier course; compare current versions on your task. | HOSTED | OpenAI / GPT | Anthropic / Claude | Google / Gemini | OPEN WEIGHTS | Meta / Llama | Qwen | DeepSeek | The provider is not the task. Choose by capability, access and constraints. Visual: reused course-library asset cloud-local-editorial.jpg; illustrative unless it is an existing screenshot. Workshop focus: Explain two separate choices: model type is the kind of task and inputs/outputs it supports; a specific model/version is the implementation you choose. Text/code models generate language or code; reasoning-focused models are designed or configured to spend more computation on multi-step problems; image/audio systems may generate or understand those media depending on the model; multimodal models combine supported kinds of input or output. These categories overlap: one model can support text, code, reasoning and images. Models of the same type still differ in task quality, latency, cost and context limits. Compare the same real business task. More reasoning time does not guarantee a correct answer.

Earlier Course 4: From AI Knowledge to AI in Practice

30. CONTEXT: give the model the right background.

Have a student improve a vague prompt with audience, known facts and a desired action. The context window is the current working material, not guaranteed permanent memory. Full teaching detail retained from the text version: CONTEXT IS THE WORKING BRIEF | Give the model a real brief, not a vague wish. | Cursor Learn, Context. The example study app and product fact are fictional; verify facts before using a real campaign. | VAGUE REQUEST | Write a post for our app. | USEFUL BRIEF | AUDIENCE | First-year students | VERIFIED FACT | One place for class notes | ACTION | Join the waitlist | Earlier chat, files and tool results can also become context. Visual: reused course-library asset inference-tokens-photo.jpg; illustrative unless it is an existing screenshot. Demonstrate a before/after prompt with the same model and supplied schedule. Weak: Write a reply. Better: Draft a 50-word reply to a student requesting a maths session. Use only the schedule below. Ask one question if a detail is missing. Give a small sample schedule and compare the answers for invented dates, prices and claims. The goal is a reusable brief: audience, task, facts, constraints, output format and a check. Students rewrite this example for their own venture. Workshop focus: CONTEXT is the relevant background the model needs for the task: audience, goal, verified facts, constraints and supplied material. Contrast Make a page with the bike-shop brief on this slide. Supply an actual fictional price list during the demonstration; do not ask the model to invent prices. A booking-request button needs a working destination before it is a real booking flow. Context can include prior messages, documents, images and tool results, depending on what the app sends to the model. The context window is the limit on material processed in the current request, not reliable permanent memory. Relevant context helps; more text is not automatically better. Check the result against the facts you supplied.

Earlier Course 4: From AI Knowledge to AI in Practice

31. Cloud can be rented by the task. Local can run on your hardware.

Compare an app, an API call and a local model. Ask which option a simple venture website needs today; it may need no runtime model at all.

Earlier Course 4: From AI Knowledge to AI in Practice

32. Open models: choose the task, then the size

Model-card metadata on Hugging Face describes intended tasks, training or tuning, licences and limitations. Distinguish open-weight from open-source: downloadable parameters alone do not satisfy every open-source requirement. Select an instruction-tuned model for ordinary chat and check runtime/format support. Parameter count helps estimate resources, not guarantee capability. Compare representative business tasks before choosing a larger model. The same family may offer several sizes and quantizations.

https://opensource.org/ai/open-source-ai-definition | https://huggingface.co/docs/hub/model-cards

33. Open weights, cloud and API are different choices

Open-weight means model parameters are available under a licence. It does not automatically satisfy an open-source definition or allow every use. Check the licence and available code/data. Hosting and interface are separate decisions: open-weight models can run locally or on cloud infrastructure and can be exposed through an API. Local operation requires suitable hardware and maintenance; API use introduces service costs and terms.

Teaching distinction: licensing, hosting and interface.

34. More parameters usually need more memory

Illustrative dense-model arithmetic, not a device compatibility guarantee: weight storage in bytes = parameters × bits per parameter / 8. Thus 7B at 16-bit is about 14 decimal GB, while theoretical 4-bit storage is 3.5 GB. Actual quantization includes metadata and may use mixed precision. Runtime buffers and the attention KV cache add memory; longer context and concurrency increase demands. GPU VRAM or shared/unified memory, memory bandwidth and supported acceleration matter more than a vague label such as powerful computer. CPU inference or offloading may work with enough system RAM but can be slow. These numbers describe inference weights, not training requirements. MoE active-parameter count does not replace total stored-weight memory.

https://huggingface.co/docs/accelerate/usage_guides/model_size_estimator | https://docs.ollama.com/context-length

35. Fit the model to the machine you already have

Quantization represents weights with fewer bits and usually reduces memory; it can affect quality and is not a guarantee of speed on every device. More memory enables larger models or longer context; faster supported compute and memory bandwidth help responsiveness. Try a small supported model first. Classroom example: with 8 GB free memory, a hypothetical 70B 4-bit model requiring about 35 GB for weights cannot fit fully there, whereas a 7B 4-bit model might fit only if runtime/context overhead also fits. Do not recommend buying hardware before measuring the workload. A cloud API remains an option when local limits conflict with the task. Workshop focus: Classroom hardware check: open https://www.canirun.ai/devices and select the matching GPU, Apple chip or phone. Check actual RAM/VRAM in the operating-system settings; a listed device configuration may differ from yours. Use model recommendations as estimates, not measured guarantees. Confirm quantization, runtime support and memory headroom, then test one small model with your actual task. Keep existing advice on memory, quantization and observed speed/quality. Website checked 2026-10-13. Brand marks: canirun. Asset sources are recorded in assets/logos/sources.json.

https://huggingface.co/docs/accelerate/usage_guides/model_size_estimator | https://docs.ollama.com/context-length | https://www.canirun.ai/devices

36. Three tools for running AI locally

Choose one runtime, not all three. LM Studio offers a desktop UI and local server; select a local model rather than a cloud model. Ollama manages model downloads and local serving and also offers cloud features, so check the selected model and mode. llama.cpp provides a lower-level local inference engine with supported quantizations and hardware backends. Models and runtimes are different: installing the app does not mean a suitable model is already downloaded. Use official downloads and check compatibility; the local-AI demo is optional and does not block the website lab. Brand marks: ollama, lmstudio, llamacpp. Asset sources are recorded in assets/logos/sources.json.

https://lmstudio.ai/docs/app/offline | https://docs.ollama.com/faq | https://github.com/ggml-org/llama.cpp

37. Why run locally? Privacy, offline access and control

A fully local pipeline can avoid sending prompts to a model-provider cloud. Check selected model, cloud fallback, web search, plugins, telemetry, exports, backups and saved logs before making a privacy claim. Local does not mean automatically private, secure or uncensored. Some locally runnable models are advertised as uncensored or less refusal-tuned; this describes their behaviour and configuration, not factual accuracy or the absence of bias. The benefit is greater choice over models, versions and application behaviour. Costs shift to hardware, electricity, storage and maintenance; offline operation still needs an initial app/model download. Students should verify local mode with a harmless airplane-mode test rather than assume the app name guarantees it.

https://lmstudio.ai/docs/app/offline | https://lmstudio.ai/app-privacy | https://docs.ollama.com/faq

38. Run a small model on your phone

Optional five-minute demonstration after downloading in advance. Use the official PocketPal AI site and its App Store/Google Play links. Check device/OS compatibility and free storage. Use the in-app model list and start with a supported small instruction-tuned GGUF model, around 0.5–3B parameters if compatible; size is a starting point, not a universal phone requirement. Download on Wi-Fi, load the model, switch to airplane mode with Wi-Fi also off, and send a new benign prompt. Ask it to draft a 50-word customer reply, then inspect accuracy, response speed, battery and heat. Restore connectivity when finished. If it fails, try a smaller model or context; do not require a new phone. Google AI Edge Gallery is an alternative on-device demo app for Android and iOS; select its supported bundled models. App/runtime and model licences are separate. This research verifies the documented workflow, not performance on the student’s specific phone. Brand marks: pocketpal. Asset sources are recorded in assets/logos/sources.json.

https://www.pocketpal.dev/ | https://github.com/a-ghorbani/pocketpal-ai | https://developers.googleblog.com/on-device-function-calling-in-google-ai-edge-gallery/

39. What is worth putting online?

Give students two minutes to state a user, problem, promise and action. They will reuse this brief in the lab. Full teaching detail retained from the text version: OPENING EXERCISE | What is worth putting online? | 01 | Who? | Choose a specific customer or community. | 02 | What? | Name the problem or desired outcome. | 03 | Why? | Explain why they would participate or return. | 04 | Next? | Choose one action they can take on your website. | Write your venture idea in one sentence before choosing a tool. Visual: reused course-library asset bike-shop.jpg; illustrative unless it is an existing screenshot. Workshop focus: Offer two equally valid routes: explore a new idea or add one capability to an existing business. Ask students to choose a named customer, one problem and one action. Example: a bike shop spends time answering rough service-price questions, so build an estimate calculator with a clearly labelled estimate and a contact action. A clickable prototype is distinct from a fully integrated operational service.

Earlier Year 4 opening; see retained source notes

40. A landing page should answer the buyer in order.

Ask students to read a landing page as a buyer: who it is for, what problem it solves, what evidence supports it, and what to do next. Use this order in the starter rewrite.

Earlier Course 4: From AI Knowledge to AI in Practice

41. Models can now use tools.

Combines the former pages 40–42. A tool-capable model can request actions through tools supplied by an application. It has no automatic access to a Google account. An integration, authentication and appropriate permissions are needed. The software executes the requested operation and returns the result. Examples: create or update a Google Doc; check free time or create a Google Calendar event. These are illustrative integrations, not a claim that every chat app supports both. Choose a suitable model, try one real task and inspect the actual document or event as evidence. Use the smallest useful workflow. Brand marks: googledocs, googlecalendar. Asset sources are recorded in assets/logos/sources.json.

https://ai.google.dev/gemini-api/docs/function-calling | https://developers.google.com/workspace/docs/api/how-tos/overview | https://developers.google.com/workspace/calendar/api/guides/overview

42. Jev: a model for structured decisions.

Jev is TypeSafe AI’s example of a decision-oriented model. The vendor describes typed choices, scores and probabilities rather than free-form generated prose. Illustrative bike-shop routing example: input customer says their brakes squeak; allowed options are repair, sales and other; a possible output is repair plus probabilities. This is a teaching example, not a recorded model response. Surrounding software decides what action follows. Use the existing Jev media clip as a vendor demo and ask students what the input, allowed options and output are. Type safety does not establish factual correctness. Benchmark accuracy, calibration, latency and cost on actual cases; do not present the vendor’s speed or reliability claims as independently proven. The original Rick and Morty Jev meme is restored on the slide. It humorously compares learned decision logic with nested if-statements; it is not a benchmark or a claim that every rule should be replaced with AI. Brand marks: jev. Asset sources are recorded in assets/logos/sources.json.

https://typesafe.ai/blog/introducing-system-one-models-and-jev | Original course Jev meme.

43. An agent connects the steps and checks the result.

Combines former pages 44–46: tool calling, the agent loop and a reviewed change. Illustrative goal: prepare a client meeting. The agent reads the supplied brief, uses a connected Docs tool to prepare an agenda, checks Calendar availability and proposes an event. After approval the application creates it, returns the event identifier/link, and the agent verifies the outcome. Missing information or a tool failure should trigger clarification or a stop, not an invented success. The same pattern applies to a website edit: brief, edit, test, review and publish. A named person owns the final action. Not every task needs an agent loop. Brand marks: googledocs, googlecalendar. Asset sources are recorded in assets/logos/sources.json.

https://ai.google.dev/gemini-api/docs/function-calling | Classroom workflow example.

44. Keep a human in the loop.

Discuss apocalyptic or worst-case AI scenarios as scenarios, not predictions or established outcomes. Connect the concern to concrete design choices: do not hand an AI unrestricted authority over accounts, money, publishing or other consequential operations. A person defines success and limits, sees the evidence and approves important actions before execution. The application enforces permissions, spending limits, stop conditions and logs; asking the model to be careful is not an access-control mechanism. A responsible human must be able to pause the workflow and recover where possible. Human review is one safeguard, not a guarantee against every failure. Ask students which action in their business an AI may do alone, which needs approval and which it should never be allowed to do.

Class discussion: hypothetical AI risks and practical human oversight.

45. From a website to a useful product

Adapt Course 2 slides 2, 5 and 6. Ask each student to name the action after a visitor reads their website. A live page is a starting point; a completed useful task gives something to observe. Full teaching detail retained from the text version: CHOOSE THE TOOLS FOR YOUR PRODUCT | From a website to a useful product | 01 | Idea | A specific user | A real problem | 02 | Action | One useful task | A clear result | 03 | MVP | The smallest flow | Someone can try | 04 | Evidence | Watch what happens | Choose the next edit | Your next feature should help you learn something. Visual: reused course-library asset agent-tools-editorial.jpg; illustrative unless it is an existing screenshot. Workshop focus: Introduce the tool tour by showing the actual outcome first. Use a bike-shop example: a page explains servicing, a calculator gives an indicative estimate, a booking request captures interest. Match tools to the next needed capability. The next slides show actual brand marks and roles. No-code and coding routes are alternatives; the course illustrates GitHub/Vercel without requiring every service in the toolbox.

Course 2: Build Something You Would Use, final 38-slide version, slides 2-19.

46. Match the tool to the task

Adapt Course 2 slide 12. These are the original course examples, not a ranking. Compare the required user flow, account access, export options and usage costs. For this lab keep the existing GitHub/Vercel route. Full teaching detail retained from the text version: CHOOSE THE TOOLS FOR YOUR PRODUCT | Match the tool to the task | Custom workflow | Bubble: prototype the steps and conditions. | Data-driven app | Glide: build around structured records. | Website + content | Webflow: start with the visitor experience. | Structured records | Airtable: organise data and simple workflows. | Existing code | Keep your repository; add the missing capability. | Choose the job first. Then compare the tools. Visual: reused course-library asset creator-pipeline-editorial.jpg; illustrative unless it is an existing screenshot. Tool names restored alongside their logos. The slide lists examples, not a requirement to install every service. Current free-tier limits should be checked on the official pricing pages before use. Brand marks: bubble, glide, webflow, airtable. Asset sources are recorded in assets/logos/sources.json.

Course 2: Build Something You Would Use, final 38-slide version, slides 2-19.

47. Pick one tool for each product job

Adapt Course 2 slide 13. Ask students which layers their first experiment actually needs. Authentication, payments and a database are not prerequisites for the browser-only starter. Full teaching detail retained from the text version: CHOOSE THE TOOLS FOR YOUR PRODUCT | Pick one tool for each product job | Build | Your existing editor or no-code builder. | Data | Supabase or Airtable: shared records. | Users | Clerk or Supabase Auth: account access. | Hosting | Vercel or Cloudflare: serve the application. | Payments | Stripe or RevenueCat: when payment is needed. | A short stack you understand beats an unused toolbox. Visual: reused course-library asset cloud-local-editorial.jpg; illustrative unless it is an existing screenshot. Tool names restored alongside their logos. The slide lists examples, not a requirement to install every service. Current free-tier limits should be checked on the official pricing pages before use. Brand marks: supabase, airtable, clerk, vercel, cloudflare, stripe, revenuecat. Asset sources are recorded in assets/logos/sources.json.

Course 2: Build Something You Would Use, final 38-slide version, slides 2-19.

48. Measure the action you care about

Adapt Course 2 slide 13. Choose one question first, such as whether a visitor completed the request. A supervised peer test may be enough for the first version; install tracking only when it answers a real question. Full teaching detail retained from the text version: CHOOSE THE TOOLS FOR YOUR PRODUCT | Measure the action you care about | Analytics | PostHog or Google Analytics: events and journeys. | Behaviour | Clarity or Hotjar: where people get stuck. | Email | Resend: send a useful confirmation or update. | Errors | Sentry: investigate failures in the flow. | Collaboration | GitHub: review and explain the change. Visual: reused course-library asset transformation-analytics.jpg; illustrative unless it is an existing screenshot. Tool names restored alongside their logos. The slide lists examples, not a requirement to install every service. Current free-tier limits should be checked on the official pricing pages before use. Brand marks: posthog, googleanalytics, clarity, hotjar, resend, sentry, github. Asset sources are recorded in assets/logos/sources.json.

Course 2: Build Something You Would Use, final 38-slide version, slides 2-19.

49. Free allowances can support an early test

Adapt Course 2 slides 14-15, rechecked against official pricing on 12 October 2026. These are selected allowances, not complete plans. Supabase Free pauses after a week of inactivity and limits active projects. Workers has CPU limits. Resend also limits domains. Verify terms before a live business launch. Full teaching detail retained from the text version: CHOOSE THE TOOLS FOR YOUR PRODUCT | Free allowances can support an early test | Supabase | 50,000 monthly active users; 500 MB database. | PostHog | 1 million product analytics events per month. | Cloudflare Workers | 100,000 requests per day on the Free plan. | Resend | 3,000 transactional emails/month; 100/day. | Selected limits checked 12 Oct 2026. Read the full plan before choosing. Visual: reused course-library asset bike-shop.jpg; illustrative unless it is an existing screenshot. Tool names restored alongside their logos. The slide lists examples, not a requirement to install every service. Current free-tier limits should be checked on the official pricing pages before use. Brand marks: supabase, posthog, cloudflare, resend. Asset sources are recorded in assets/logos/sources.json.

https://supabase.com/pricing | https://posthog.com/pricing | https://developers.cloudflare.com/workers/platform/pricing/ | https://resend.com/pricing

50. Build one booking request

Adapt Course 2 slide 16. This is the next-feature example, not a claim that the starter creates real bookings. Keep the existing website and GitHub/Vercel route; add shared storage only when requests must persist and email only when useful. Ask which step provides evidence of demand. Full teaching detail retained from the text version: CHOOSE THE TOOLS FOR YOUR PRODUCT | Build one booking request | 01 | Choose | A subject | A preferred time | 02 | Request | Save the request | Show its status | 03 | Confirm | A visible result | An optional email | Keep the website. Add storage when needed. Make email optional. Visual: reused course-library asset station-reimagined.jpg; illustrative unless it is an existing screenshot.

Course 2: Build Something You Would Use, final 38-slide version, slides 2-19.

51. Before you subscribe, could you build your own?

For many simple needs, AI-assisted building makes a custom first version practical: a quote calculator, internal tracker, landing page or narrow workflow. You may avoid paying for an entire subscription when you only need one feature. This is not a promise that every service can be replaced for free or that a classroom prototype matches production software. Consider build time, hosting, API usage, maintenance, security, reliability and integrations. Keep payments and other specialist requirements with suitable services when building is not worthwhile. Ask students which subscription or repetitive business task they could replace with a small tool, and define the minimum useful feature.

Classroom build-versus-buy discussion; example scopes, not a guarantee of zero total cost.

52. Choose tools you can explain

Adapt Course 2 slide 19. Two-minute pair exercise: explain one choice for the venture, hear an alternative, then record the decision. Connect it to forward deployed engineering: choose from the customer workflow, ship a small change and observe the result. Full teaching detail retained from the text version: CHOOSE THE TOOLS FOR YOUR PRODUCT | Choose tools you can explain | Job | What must this tool do for your user? | Fit | Why is it suitable for this MVP? | Alternative | What other approach did you consider? | Constraint | Which limit, cost or dependency matters later? | Write one decision before opening the deployment tools. Visual: reused course-library asset agent-tools-editorial.jpg; illustrative unless it is an existing screenshot.

Course 2: Build Something You Would Use, final 38-slide version, slides 2-19.

53. From your computer to a working URL.

Ask who has deployed before. Pair students with different experience. The following slides explain the tools before the guided exercise.

54. What each tool does

Ask students to match each tool to a verb. Git and GitHub are different; an editor or agent does not automatically publish the website. Brand marks: github, vercel, git. Asset sources are recorded in assets/logos/sources.json.

55. What deployment actually means

A static site may need no build step. A framework app may compile or bundle first. Deployment makes a version available through hosting; a custom domain is a separate name for it. Full teaching detail retained from the text version: DEPLOYMENT ESSENTIALS | What deployment actually means | 01 | Source | Your HTML, CSS | and JavaScript | 02 | Build | Prepare the files | if the app needs it | 03 | Host | Serve a version | from the platform | 04 | Visit | A URL opens it | in a browser | A file saved on your laptop is not yet a shared website. Visual: reused course-library asset cloud-local-editorial.jpg; illustrative unless it is an existing screenshot.

56. Meet the project folder

Open the downloadable starter and point to each file. README and .gitignore help the team; they are not page content. No package manager is needed for this starter. Full teaching detail retained from the text version: DEPLOYMENT ESSENTIALS | Meet the project folder | venture-site/ | index.html page structure | styles.css appearance | app.js browser behaviour | README.md how to run it | .gitignore files Git ignores | Start small. | Find the headline. | Find the button. | Find its behaviour. | Explain one edit. Visual: reused course-library asset coding-agent-editorial.jpg; illustrative unless it is an existing screenshot.

57. This is the page you will deploy

Open the starter from the course resources. This is an actual screenshot of the provided example. Try the plan interaction first; later change the audience and promise while keeping the action working.

58. Frontend, backend and database

Demonstrate that refreshing the starter clears the plan: it is computed in the browser and not stored. A real booking request would need an intentional backend or external service.

59. Local, preview and production

Show three tabs for the same page if possible. Localhost on another student's laptop points to their own laptop. A preview may require permission depending on protection settings.

https://vercel.com/docs/deployments/environments

60. Three windows you will use

Demonstrate opening a terminal in the project folder. A command runs in a particular directory. Students can use their editor's source-control interface instead of memorising every command. Full teaching detail retained from the text version: DEPLOYMENT ESSENTIALS | Three windows you will use | Editor | Find files, edit text, inspect the agent's changes. | Terminal | Run a command in the project directory. | Browser | Check the appearance and complete the action. | First habit | Read the current folder before running a command. Visual: reused course-library asset coding-agent-editorial.jpg; illustrative unless it is an existing screenshot.

61. Git and GitHub are different

Saving a file, committing it and pushing it are separate actions. Show the same commit identifier locally and on GitHub. Brand marks: github, git. Asset sources are recorded in assets/logos/sources.json.

https://git-scm.com/book/en/v2/Getting-Started-Git-Basics

62. A branch gives a change its own path

Use improve-headline as the branch name. A pull request belongs to the Git hosting workflow. Verify the Vercel production branch; main is the class example.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests

63. Read the diff before trusting the summary

Explain removed and added lines. Ask a student to describe this change without using technical jargon. Review actual files, not only the agent's report. Full teaching detail retained from the text version: REVIEW THE ACTUAL CHANGE | Read the diff before trusting the summary | - <h1>Welcome to our website</h1> | + <h1>Get ready for your next maths exam</h1> | What changed? Why? Does the page still work? | Unexpected file changes deserve an explanation. Visual: reused course-library asset fact-check-editorial.jpg; illustrative unless it is an existing screenshot.

64. Record and share one small change

These commands assume Git is installed, the repository is cloned, origin exists, and authentication works. Explain each command. Do not have students paste them into an unrelated repository. Brand marks: git. Asset sources are recorded in assets/logos/sources.json.

https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository

65. One task. Clear constraints. A visible check.

Read this prompt aloud, then ask students to adapt the audience and message. The constraints fit this simple starter; real projects may need different boundaries.

66. Before you run the project

For this starter open index.html or serve the folder with a local server. Framework examples often need Node and a package manager; do not add them to this static starter just for the exercise. Full teaching detail retained from the text version: DEPLOYMENT ESSENTIALS | Before you run the project | Read README | Find the expected setup and run commands. | Check the folder | Confirm you are in the project you intend to edit. | Understand scripts | Know what an install, build or dev command does. | Keep it bounded | Run the smallest check that proves the change. Visual: reused course-library asset local-gpu-editorial.jpg; illustrative unless it is an existing screenshot.

67. First deployment: import your repository

Walk the dashboard live. Select only the intended repository. UI labels can change; the durable choices are repository, root directory, build/output and environment. Brand marks: github, vercel. Asset sources are recorded in assets/logos/sources.json.

https://vercel.com/docs/git

68. Four settings to recognise

Contrast a plain static site with a framework app. Prefer detected defaults only when they match the project. A monorepo may require a subfolder as root.

https://vercel.com/docs/builds/configure-a-build

69. Our starter needs no build command

For the current Vercel Other preset, an empty build command serves static files; check the output selection resolves to the root containing index.html. The starter README contains the same instructions.

https://vercel.com/docs/builds/configure-a-build

70. Next deployment: preview a branch

After the first production import, create a feature branch for the second change. With Git integration configured, branch pushes produce deployments. Inspect the linked commit instead of guessing from the URL. Brand marks: github, vercel. Asset sources are recorded in assets/logos/sources.json.

https://vercel.com/docs/git

71. Make sure your reviewer can open it

A working preview in your own logged-in browser may be inaccessible to classmates. Use the project's intended sharing settings. Do not ask students to expose private data simply to make a link open. Full teaching detail retained from the text version: DEPLOYMENT ESSENTIALS | Make sure your reviewer can open it | Correct URL | Share the preview for the intended commit. | Access | Check whether deployment protection requires login. | Fresh session | Test in a private browser window or with a peer. | Clear request | Give the reviewer one task to complete. Visual: reused course-library asset human-agent-team-editorial.jpg; illustrative unless it is an existing screenshot.

https://vercel.com/docs/deployment-protection

72. Five checks before you call it finished

Use the session-plan preview as the test action. The browser should show a result without claiming that a real booking was saved. Native required fields should explain missing input. Full teaching detail retained from the text version: DEPLOYMENT ESSENTIALS | Five checks before you call it finished | Content | The audience, promise and next action are clear. | Layout | Read it on a narrow screen without side scrolling. | Interaction | Click, submit, reset, and try an empty field. | Keyboard | Tab to controls and activate them. | Evidence | Record the URL, commit and one observation. Visual: reused course-library asset mobile-testing-photo.jpg; illustrative unless it is an existing screenshot.

73. Which layer failed?

The static starter has no server function; runtime logs matter when a backend is added. Ask students to read the first meaningful error and identify its layer before asking an agent to change anything.

https://vercel.com/docs/observability/runtime-logs

74. Common failures and the first useful check

Run a deliberate broken CSS-path demonstration in a branch. Case differences in file names may work locally but fail when deployed. Change one suspected cause at a time.

75. Environment variables are deployment settings

Explain the concept without creating a real credential. The starter needs none. In real apps, check each framework's rules for client-exposed variables.

https://vercel.com/docs/environment-variables

76. Browser code is visible to the visitor

Students often confuse an environment-variable name with secrecy. Explain that client-side code can be downloaded by the visitor. If a real credential is exposed, rotate it and remove the exposure. This is preparation for later agentic apps; the starter uses no keys. Full teaching detail retained from the text version: A PRACTICAL BOUNDARY | Browser code is visible to the visitor | A private API key belongs in server-side configuration. | Putting a key in app.js makes it public. | A variable is not secret if your framework bundles it for the browser. | Use placeholder values in examples. Keep real keys out of Git. Visual: reused course-library asset fact-check-editorial.jpg; illustrative unless it is an existing screenshot.

https://vercel.com/docs/environment-variables

77. Publish the version you reviewed

For the class repository the production branch is main. Check that setting in the project. A merge triggers a production deployment in the connected Git workflow; verify the actual result.

https://vercel.com/docs/git

78. A URL, a domain and hosting

Domain purchase is not required. If demonstrating an existing owned domain, use the exact records Vercel gives for that domain; never paste a universal record from an old slide. Brand marks: vercel. Asset sources are recorded in assets/logos/sources.json.

https://vercel.com/docs/domains

79. Undo a bad release in two places

A platform rollback changes what serves traffic; it does not automatically undo source code or database changes. Practice with a harmless headline change. Use a revert commit on shared history. Brand marks: git. Asset sources are recorded in assets/logos/sources.json.

https://vercel.com/docs/instant-rollback | https://git-scm.com/docs/git-revert

80. Know what can create a bill

No purchase is required for the static class starter itself. Account eligibility and platform plan rules differ. An AI subscription is not a universal credit for every API or hosting service. Full teaching detail retained from the text version: DEPLOYMENT ESSENTIALS | Know what can create a bill | Hosting | Traffic, compute and platform plan limits. | AI API | Requests, input/output usage and model choice. | Services | Database, email and storage when you add them. | Your habit | Read current limits; set usage alerts where available. | Estimate the cost of one useful completed task, including retries. Visual: reused course-library asset cloud-local-editorial.jpg; illustrative unless it is an existing screenshot.

https://vercel.com/docs/spend-management

81. Start an evidence trail from the first session

This is a suggested way to organise learning evidence across the minor; it does not replace the four assessed products or add a new grading weight. Relate evidence to the five experience steps. Each student should be able to explain their own contribution and distinguish research observations from AI-generated suggestions. Full teaching detail retained from the text version: YOUR MODULE WORK AND EVIDENCE | Start an evidence trail from the first session | Customer | The person, experience and problem you are working on. | Decision | Your tool choice, alternative and reason. | Experiment | What you tried and what actually happened. | Reflection | What changed in your venture and what comes next. | Today: a live link, a reviewed change and one real observation. Visual: reused course-library asset fact-check-editorial.jpg; illustrative unless it is an existing screenshot.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

82. Publish. Change. Review. Recover.

Allow 75-100 minutes for the full lab. Students work in pairs and exchange builder/reviewer roles. The downloadable lab sheet contains setup, commands, a checklist and evidence fields.

83. Write the page before choosing the tool

Write the venture sentence before editing the starter. A clear message makes the first change purposeful. Full teaching detail retained from the text version: BUILD LAB | Write the page before choosing the tool | 01 | Audience | For [specific customer]... | 02 | Problem | ...who needs [specific outcome]... | 03 | Promise | ...our venture offers [clear solution]... | 04 | Action | ...so the visitor can [one next step]. | Use this sentence as the first draft of your homepage. Visual: reused course-library asset inference-tokens-photo.jpg; illustrative unless it is an existing screenshot.

Earlier Year 4 opening; see retained source notes

84. Checkpoint 1: get the starter online

Expected evidence: a repository URL and a deployment URL that a peer can open. Students without Git installed can create a repo and upload the starter through GitHub's browser UI. Brand marks: github, vercel. Asset sources are recorded in assets/logos/sources.json.

85. Checkpoint 2: make a reviewed change

Expected evidence: a branch commit and preview link. The agent may help, but the student must explain what changed. Confirm the live preview serves the expected commit.

86. Checkpoint 3: watch a peer use it

Peer testing is a usability check. Ask each pair to record an observation in the lab sheet. Distinguish a completed task from proof that a real customer will buy. Full teaching detail retained from the text version: BUILD, TEST AND PUBLISH | Checkpoint 3: watch a peer use it | Give a task | Create a maths session plan for next week. | Stay quiet | Watch the first click and any hesitation. | Ask | What did you expect to happen? | Improve | Fix one issue and repeat the task. | Expected time: 10-15 minutes. Visual: reused course-library asset human-agent-team-editorial.jpg; illustrative unless it is an existing screenshot.

87. Checkpoint 4: release and recover

Never deliberately break a live business for this exercise. Use the class practice repo. Students can demonstrate a revert in a branch and explain platform rollback if their account does not offer it.

88. Diagnose the problem before asking for a fix

Answers: A check deployment protection/access; B inspect the CSS path and network response; C check branch, deployment status and commit; D inspect the diff and run a concrete user task. Accept other evidence-backed diagnoses. Full teaching detail retained from the text version: BUILD, TEST AND PUBLISH | Diagnose the problem before asking for a fix | A | The preview opens for you but your partner sees login. | B | The page loads, but the layout has no styling. | C | The feature works locally but production is unchanged. | D | An agent says it is done but cannot name a test. | Pairs: name the layer, then choose one check. Visual: reused course-library asset fact-check-editorial.jpg; illustrative unless it is an existing screenshot.

89. Four links and one lesson

Collect the repository, commit, preview and production links plus one observed issue and its fix. These are workshop evidence, not replacements for official module assessment.

Earlier Year 4 opening; see retained source notes

90. Can you explain the system without the agent?

Suggested answers: a save changes the working file, a commit records a snapshot; Git tracks history, GitHub shares it, Vercel hosts; preview lets you test a candidate; credentials stay server-side; rollback does not itself fix the repository or reverse database changes. Use this as a formative exit check.

91. Could you explain what you just shipped?

Allow three minutes. For confidence, 1 means I need help and 5 means I can explain it to someone else. Confidence is not a grade. Give pairs 30 seconds each, then take two unresolved questions. Revisit those points before the next course. Full teaching detail retained from the text version: A QUICK SHOW OF HANDS | Could you explain what you just shipped? | 01 | Show 1-5 fingers: how confident do you feel? | 02 | Raise your hand if a partner opened your live link. | 03 | Raise your hand if you found and fixed an issue. | Turn to a partner: one thing learned, one thing still unclear. Visual: reused course-library asset human-agent-team-editorial.jpg; illustrative unless it is an existing screenshot.

Class engagement

92. One idea can become a content system

Preview the final course: a real customer insight becomes a script, asset and measured post. Connect the call to action to the website students just deployed. Full teaching detail retained from the text version: FROM SHARED COURSE 4 | One idea can become a content system | 01 | Source | Start with a real customer question or conversation. | 02 | Create | Draft a script and adapt it for each useful format. | 03 | Review | Check claims, rights, quality, and the next action. | 04 | Learn | Measure response and improve the next version. | A preview of the automated content creation course; adapted from the supplied 70-slide deck. Visual: reused course-library asset creator-pipeline-editorial.jpg; illustrative unless it is an existing screenshot.

Earlier Year 4 opening; see retained source notes

93. Give the live page one useful capability.

Close with the next progression: an agent helps add one useful feature, workflows connect repeated tasks, and content brings the right audience to the product. Ask students to name their next test. Full teaching detail retained from the text version: THE NEXT COURSE | Give the live page | one useful capability. | Bring a user problem, a working URL and one observed question. Visual: reused course-library asset agent-tools-editorial.jpg; illustrative unless it is an existing screenshot. Workshop focus: Students choose one next addition for their existing venture or new idea. A quote calculator can be browser-only; submitted leads and shared bookings need a real data flow. Explain the next tool only when its job is needed. Supabase is a data option, Resend an email option, Stripe a payment option; installation of all three is not an assignment. End by asking each student to share their link and explain the benefit in one sentence. Brand marks: supabase, resend, stripe. Asset sources are recorded in assets/logos/sources.json.

94. Five steps for your own business case

Use the five assessed experience steps from the supplied brief. Students should connect each technical choice to their own venture, relevant research and customer evidence. Experimenting with current technologies runs across these five steps. Full teaching detail retained from the text version: WELCOME | Five steps for your own business case | 1. Strategy | Experience Disruptive Strategy: what changes? | 2. Value | Experience Value Proposition: why participate? | 3. Technology | Experience Technologies and Processes: how? | 4. Organisation | Experience Leadership and Organisation: who? | 5. Business model | Experience Business Model: where is the value? | Bring these five questions back whenever you choose a tool. Visual: reused course-library asset human-agent-team-editorial.jpg; illustrative unless it is an existing screenshot.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

95. Today is one part of a broader minor

Map the supplied 15-workshop plan: intro; AI deep dive; Google/Facebook Ads and SEO; email, social and growth; analytics; e-commerce/lead generation; Upwork/Fiverr; guest lecture; influencers; blockchain; crypto; NFTs/DeFi; day trading; AI update; recap/cases. This deck develops the AI, website and workflow foundation. Dedicated sessions and evidence are still needed for the other topics. Workshop dates come from programme management; assessment chances from Google Classroom. Full teaching detail retained from the text version: YOUR MODULE WORK AND EVIDENCE | Today is one part of a broader minor | Discover | AI tools, customer needs and experience strategy. | Reach | Ads, SEO, email, organic social and influencers. | Measure | Analytics, e-commerce and lead generation. | Coordinate | Contractors, guest expertise and team workflows. | Experiment | Blockchain, crypto, NFTs, DeFi and day trading. | This session builds the website foundation for your venture. Visual: reused course-library asset marketing-channels-editorial.jpg; illustrative unless it is an existing screenshot.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

96. Four assessed parts of the module

Weights are from the supplied 7 EC module brief and sum to 100%. Each part and the overall module require at least 5.5. The insufficient participation descriptor includes attendance below 90%; attendance alone does not demonstrate active contribution. The product statements and grade-band descriptions differ for presence, advertising and experimentation. The next slides show the product-statement targets, not a newly invented passing rubric. Brand marks: google, facebook. Asset sources are recorded in assets/logos/sources.json.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

97. Digital presence: build it and keep it active

This is the Digital Presence product statement, worth 30%. Proper profile setup includes logo, hero image, description and contact details. The sufficient/good grade bands describe fewer accounts or posts than the headline target; resolve that discrepancy when issuing the definitive rubric. The live starter for today is a first step, not the completed module deliverable. Full teaching detail retained from the text version: YOUR MODULE WORK AND EVIDENCE | Digital presence: build it and keep it active | Website | A fully functional website for your business. | Measurement | Google Analytics implemented. | Social profiles | At least three properly configured accounts. | Activity | One month; at least 12 posts on each account. | Save the URLs, profile screenshots and dated activity evidence. Visual: reused course-library asset marketing-channels-editorial.jpg; illustrative unless it is an existing screenshot. Brand marks: googleanalytics. Asset sources are recorded in assets/logos/sources.json.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

98. Advertising: plan, run, learn and improve

The supplied Digital Advertising product statement is worth 20% and calls for one campaign on each platform, with optimisation. Its sufficient/good descriptors mention one campaign, so do not present those bands as identical to the product target. Budget and campaign arrangements belong in the dedicated advertising brief; this slide does not initiate a campaign. Full teaching detail retained from the text version: YOUR MODULE WORK AND EVIDENCE | Advertising: plan, run, learn and improve | Platforms | At least one Facebook Ads and one Google Ads campaign. | Setup | Define the audience, objective and ad creative. | Optimisation | Record what you changed and the reason. | Evidence | Show setup, results and the next decision. | Connect the ad promise to the experience on your website. Visual: reused course-library asset transformation-analytics.jpg; illustrative unless it is an existing screenshot. Brand marks: google, facebook. Asset sources are recorded in assets/logos/sources.json.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

99. Experimentation: understand it and show evidence

The supplied Experimentation product statement is worth 35%. Its sufficient band asks only for accounts, whereas the product statement specifies transactions and its excellent band mentions earnings. Preserve that distinction; do not imply that profits are assured or that students must trade during this introductory class. Cover the concepts, practical arrangements and assessment interpretation in the dedicated sessions. Do not invent an additional DeFi transaction requirement. Full teaching detail retained from the text version: YOUR MODULE WORK AND EVIDENCE | Experimentation: understand it and show evidence | Understand | Blockchain, crypto, NFTs, DeFi and day trading. | Create | Create and upload one NFT, as stated in the brief. | Try | One day-trading trade; buy and sell cryptocurrency. | Document | Your account screenshots or short transaction videos. | Explain what happened, what it demonstrates and what you learned. Visual: reused course-library asset agent-commerce-editorial.jpg; illustrative unless it is an existing screenshot.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

100. Take the five steps into the real world

The outdoor business safari is part of the supplied module purpose. This is a suggested learning activity, not a newly weighted submission. Distinguish observations from assumptions; use appropriate customer research and connect the finding to the five experience steps. Full teaching detail retained from the text version: YOUR MODULE WORK AND EVIDENCE | Take the five steps into the real world | Observe | Use the outdoor business safari to study an experience. | Ask | What do customers do, value and share? | Map | Look at strategy, value, technology, people and model. | Apply | Bring one supported insight into your own venture. | Pair discussion: which business creates an experience worth studying? Visual: reused course-library asset bike-shop.jpg; illustrative unless it is an existing screenshot.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

101. Plan for 196 hours across the full module

These workload figures come directly from the 7 EC brief and total 196 hours. They describe the full minor, not this presentation or a single class. Programme management sets workshop dates. Google Classroom announces assessment chances. Prepare before workshops using the assigned resources and bring your own venture materials.

User-supplied Minor Digital Skills brief: 0403EE, Entrepreneurial Essentials, 7 EC, 196 hours.

102. SOTA spotlight: AI content creation

Keep the creative-tool spotlight from Course 4. Demonstrate the workflow brief, generate, review, improve. This is a preview of the later content course; SOTA is task-specific, not a verified universal product ranking. Full teaching detail retained from the text version: CREATOR TOOL SPOTLIGHT | SOTA spotlight: AI content creation | Higgsfield official: higgsfield.ai/apps and higgsfield.ai/supercomputer-intro · features and access can change. | H | HIGGSFIELD | SOUL | CINEMA STUDIO | SUPERCOMPUTER | A creative suite for making | and transforming image and video content. | GENERATE | Create images and video | DIRECT | Use tools, presets and templates | REFINE | Edit, extend and make variations | Try it as a workflow: brief → generate → review → improve. | Judge the result against the audience, message, rights and real call to action. Visual: reused course-library asset content-styles-editorial.jpg; illustrative unless it is an existing screenshot.

Earlier Course 4: From AI Knowledge to AI in Practice

103. Read the AI market chart

Name the measured population and omissions. Ask which recurring customer problem appears to generate willingness to pay.

Earlier Year 4 opening; see retained source notes

104. When software can spend.

Optional extension from the full Course 4 opening. Explain agentic commerce as a capability preview. The introductory deployment lab does not require a wallet or payment.

Earlier Course 4: From AI Knowledge to AI in Practice

105. HTTP 402: the web asks to be paid.

Explain HTTP 402 as a payment-required status used by protocols such as x402. The server and client must implement a compatible flow; the status code alone does not make a payment. Brand marks: openai, google, stripe. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

106. Give the agent a wallet with a limit.

Use the EUR 50 example as a hypothetical budget. The teaching point is bounded authorisation and records, not a request to deposit funds. Brand marks: coinbase, google. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

107. Agents can buy services from other agents.

Discuss a system buying an API service as part of a workflow. Ask which result and receipt a human would need to inspect. Brand marks: coinbase. Asset sources are recorded in assets/logos/sources.json.

Earlier Course 4: From AI Knowledge to AI in Practice

108. The agent can research, pay and bring back options.

Return to the business problem: an agent researches options within limits and brings back evidence. Students can simulate this workflow without moving money.

Earlier Course 4: From AI Knowledge to AI in Practice

109. Keep these references close

Use the linked resource list in the online course and lab sheet. The original Course 2 and Course 4 decks remain available as complete references. Platform details were checked on 12 October 2026. Brand marks: higgsfield, openai, codex, claude, github, vercel, git. Asset sources are recorded in assets/logos/sources.json.

Primary references

• Attention Is All You Need — Transformer paper
• Introducing OpenAI — 2015
• Introducing ChatGPT — 2022
• a16z consumer AI report — chart context
• AI IQ methodology — interpretation and limits
• Pro Git — Git fundamentals
• Vercel Git deployments
• Vercel build configuration
• Vercel environments
• Vercel environment variables
• Vercel instant rollback
• OpenAI Codex · Claude Code
• Higgsfield apps · TypeSafe AI
• x402 · Agent Payments Protocol

Platform documentation checked 12 October 2026. Charts and earlier-course visuals remain historical teaching examples. Recheck current model availability, prices and product interfaces before a live demonstration.