# LEARNING STUDIO WORKBOOK STANDARD
## Unified Workbook / Tutorial / Assessment / Evidence / Coach Standard
**Version:** 2.0  
**Date:** 2026-09-23  
**Status:** CANONICAL WORKING STANDARD  
**Supersedes:** “Truck Standard” as the umbrella name for new workbook production  
**Retains:** Truck Ad as an architecture benchmark; Drop Day / Fresh Impact as instructional-quality benchmarks


**Visual-quality addendum 2.1 — 9 October 2026, explicitly requested by Chad:** Apply [Learning Studio Visual Quality Standard v1.0](../../../VISUAL_QUALITY_STANDARD.md) to finished workbook exemplars, display artwork, presentations and simulations. Primitive placeholder artwork fails finished delivery. Use purposeful sourced or generated imagery, inspect actual rendered compositions before repeating layouts, and record visual quality separately from functional checks. A material failure retains **Draft — visual revision required**. The original 2.0 instructional/system contracts below remain intact; the preserved original is [archived](../../../audit/visual-quality-standard-2026-10-09/LEARNING_STUDIO_WORKBOOK_STANDARD_v2_original.md). This addendum changes the visual production/release gate, not curriculum, IDs, assessment, student evidence or publication authorization.

**Response/Form addendum 2.2 — 10 October 2026, explicitly requested by Chad:** Apply [Learning Studio Response and Form Standard v1.0](../../../RESPONSE_AND_FORM_STANDARD.md) to digital writing and evidence collection. Verify draft recovery/export/restore and an explicit hand-in route. Each substantial assessed project requires the existing-system student Knowledge + Reflection Form and private teacher Evidence Capture Form, with current identity/item mappings and separate access, acceptance and synchronization receipts. Teacher review determines practical achievement. Missing required intake or unrecoverable fields retain **Draft — response/submission route incomplete**. Preserve earlier responses and collection holds; this addendum grants no new assessment identity or publication authorization.

**Client/OCP addendum 2.3 — 10 October 2026, explicitly requested by Chad:** Apply [Software Workbook Standard v1.4](../../../SOFTWARE_WORKBOOK_STANDARD.md) and its [client/OCP contract](../../../collaboration/software-workbook-studio/references/client-and-ocp-package.md). Assessed production packages include client briefs and usable assets, supporting lessons, planning/documentation descriptors, quick factual observation capture with individual evidence details, conversation cards and teacher judgment guidance. Preserve students' concept/style decisions and permit equivalent original directions; resemblance to an exemplar earns no bonus. O/C/P supplies evidence for the same criteria, with support separate. Existing Forms, reviewed feedback and OS handoff require their own receipts. Prior teaching, verification and release requirements remain intact.

---

# 0. PURPOSE

This document defines the current standard for every substantial Learning Studio workbook, tutorial, project, sprint, or production lab.

The unified standard is:

> **Drop Day / Fresh Impact instructional quality + Truck Standard system architecture + Evidence Map assessment contracts + Assistant Coach independence support.**

The standard exists so every resource is:

- instructionally strong;
- independently followable;
- aligned to official outcomes;
- mapped to canonical skills;
- assessable without turning every click into a grade;
- connected to the Technology Evidence System;
- connected to the Outcome Evidence Map;
- compatible with the Assistant Coach;
- compatible with Scribe/video delivery;
- publishable through GitHub;
- auditable and versioned;
- honest about what has and has not been verified.

This is a **Learning Studio standard**, not just a Photoshop standard.

---

# 1. CORE PRINCIPLES

## 1.1 Teach the problem-solving process, not only the clicks

A workbook must not teach a sequence merely because it might produce the final picture.

It must teach:

> **what to select → what to do → why it matters → what the learner should see → what to fix if it does not work**

For software / fabrication work, the core step pattern is:

**SELECT FIRST → ACTIONS → WHY → CHECK → FIX**

For academic / reasoning work, the equivalent is:

**RETRIEVE → LEARN → APPLY → CHECK → TRANSFER → DEFEND**

## 1.2 Guided completion is practice

Following a tutorial successfully does **not** automatically establish mastery.

Stronger achievement evidence comes from:

- independent changed-brief work;
- troubleshooting;
- repair;
- explanation;
- defence;
- unfamiliar transfer;
- editable/layered source files;
- teacher Observation;
- teacher Conversation;
- Product evidence.

## 1.3 Achievement and support are separate

### Achievement bands

- **Beginning**
- **Developing**
- **Secure**
- **Extending**
- **IE — Insufficient Evidence**

### Support / independence bands

- **Guided**
- **Supported**
- **Independent**
- **Transfer**

A learner can demonstrate strong achievement while using access support.

Support must never automatically lower achievement.

## 1.4 Extending requires transfer, not decoration

Extra effects, extra objects, more layers, or more time do not automatically mean Extending.

Extending requires teacher-verified evidence such as:

- transfer to changed conditions;
- deliberate adaptation;
- diagnosis of a non-routine problem;
- effective troubleshooting;
- explanation of why a different control or strategy was appropriate.

## 1.5 The workbook teaches; the Evidence Map records

The **Outcome Evidence Map is not the curriculum generator**.

Curriculum is driven by:

1. official outcomes;
2. prerequisite knowledge and skills;
3. authentic disciplinary practice;
4. progression from guided to independent work;
5. transfer;
6. sustainable assessment.

The Evidence Map validates:

- coverage;
- progression;
- evidence balance;
- gaps;
- overload;
- teacher judgement.

---

# 2. WORKBOOK TYPES

The standard supports two broad sizes.

## 2.1 Learning Studio Lesson

Use for:

- one focused skill;
- one article or source;
- one technique;
- one short lab;
- roughly 45–90 minutes.

Minimum spine:

1. Authentic Context / Launch
2. Outcomes + Skills
3. Learn / Model
4. Practice
5. Check / Repair
6. Evidence Opportunity
7. Reflection / Transfer
8. Submission / Next Step

## 2.2 Learning Studio Project / Sprint

Use for:

- multi-class production work;
- an authentic project;
- a two-week sprint;
- a substantial assessed task.

Common spine:

> **AUTHENTIC CONTEXT → OUTCOMES → SKILLS / CONCEPTS → LEARNING → PRACTICE → CHECK → EVIDENCE → REFLECT → TRANSFER → REPORT**

Domain profiles may change the detailed structure, but not the core contracts.

---

# 3. REQUIRED PACKAGE CONTENTS

Every substantial standardized workbook must contain, or explicitly link to, all applicable items below.

## 3.1 Student delivery

Required:

1. `workbook.html`
2. matching printable PDF
3. student asset pack
4. finished exemplar / reference where appropriate
5. visual checkpoints
6. clear START HERE / download area
7. export / submission instructions
8. Assistant Coach access
9. official Knowledge + Reflection assessment launcher

Where a tutorial says “download/open this file,” that file must actually be:

- included in the package; **or**
- available through a verified stable download link.

Never reference a missing asset.

## 3.2 Teacher delivery

Required:

1. teacher guide
2. expected checkpoints
3. acceptable alternative methods
4. evidence capture guidance
5. independent-transfer / changed-brief task
6. teacher defence / conversation prompts
7. answer guidance for Knowledge Check
8. course/outcome alignment
9. QA / validation notes
10. known limitations

Teacher-only masks, targets, answer keys, or repair references must not be placed in the public Student Pack when they would undermine independent evidence.

## 3.3 Canonical system files

Every full project should contain:

```text
project-manifest.yml
Step_Map.csv
forms-spec.json
video-manifest.json
coach-context.json
evidence-map.md
course-catalog-entry.json
source-provenance.md
asset-manifest.json
QA / validation report
```

The exact folder structure may vary by domain, but these contracts must remain recoverable.

---

# 4. CANONICAL ID RULES

## 4.1 One project ID

Each project has one canonical:

```text
project_id
```

Example:

```text
PS-DROP-DAY
```

Do not create alternate IDs for:

- Scribe;
- Google Forms;
- Evidence Map;
- GitHub;
- Assistant Coach.

## 4.2 One step sequence

Every core technology/tutorial step has one:

```text
project_step_id
```

Examples:

```text
DD-S01
DD-S02
...
DD-S24
```

Technology step IDs generally follow:

```regex
^[A-Z]{2}-S[0-9]+$
```

Digital Society may use its own domain-specific activity/section pattern.

Do not force technology prefixes onto Digital Society.

## 4.3 Workbook HTML hooks

Each core step must expose at least:

```html
id="step-N"
data-project-id="..."
data-project-step-id="..."
data-skill-ids="..."
data-outcome-codes="..."
data-evidence-ids="..."
```

This allows:

- Scribe;
- Assistant Coach;
- assessment mapping;
- GitHub delivery;
- analytics;
- evidence systems

to refer to the **same instructional step**.

## 4.4 Outcome identity is multi-field

Do not force one outcome string to serve every system.

Preferred contract:

```text
course_id
outcome_id
outcome_code
ps_outcome_code
display_code
outcome_title
```

Example conceptually:

```text
course_id: COM11
outcome_id: communications-technology-11-4-4
outcome_code: COM11-4-4
ps_outcome_code: CT11-4-4
display_code: 4.4
```

Legacy aliases should be mapped, not silently rewritten.

---

# 5. SKILL RULES

## 5.1 Workbook skills remain canonical inside the workbook

Current major families include:

### Photoshop / production

```text
PS-*
```

Examples:

- PS-FND-01
- PS-LAY-01
- PS-SEL-01
- PS-RET-01
- PS-COL-01
- PS-TYP-01
- PS-OUT-01

### Graphic / design

```text
GD-*
```

Examples:

- GD-CON-01 — Contrast
- GD-HIE-01 — Hierarchy
- GD-ALN-01 — Alignment
- GD-PRO-01 — Proximity
- GD-REP-01 — Repetition
- GD-COL-01 — Colour
- GD-TYP-01 — Typography
- GD-AUD-01 — Audience / Purpose
- GD-MET-01 — Visual Metaphor
- GD-BRD-01 — Brand Consistency
- GD-DEM-01 — Demographic Fit
- GD-CTA-01 — Message / CTA
- GD-CRIT-01 — Critique / Revision

### Blender / 3D

```text
BL-*
```

### General evidence / QA

Examples:

- GEN-EVD-01
- GEN-QA-01

## 5.2 Evidence Map competencies may use a different namespace

Evidence Map may use:

```text
ct-*
mm-*
ds-*
```

Do not rename the workbook’s PS/GD/BL skills to match Evidence Map.

Use the canonical **skill crosswalk**.

## 5.3 Every workbook must define skill progression

For target skills identify:

```text
PREREQUISITE
→ INTRODUCE
→ MODEL
→ GUIDED PRACTICE
→ INDEPENDENT APPLICATION
→ TRANSFER
→ REVISIT
```

Every substantial project should state:

- **Builds On**
- **New Learning**
- **Prepares For**

A skill should not be assessed independently before it has been taught and practised.

---

# 6. OUTCOME RULES

Every workbook must identify:

- relevant official course outcomes;
- primary outcomes;
- supporting outcomes;
- step-level outcome opportunities where useful.

Do not include an outcome merely because a tool happens to appear.

The task must provide a credible opportunity to demonstrate the outcome.

For each outcome distinguish:

- planned opportunity;
- guided practice;
- independent evidence;
- teacher-confirmed evidence.

**Planned opportunity is not actual evidence.**

---

# 7. AUTHENTIC CONTEXT STANDARD

Substantial workbooks need a believable reason to exist.

Use:

- industry brief;
- client problem;
- campaign;
- investigation;
- real-world case;
- fabrication challenge;
- article/source set;
- simulation;
- authentic production workflow.

The context should answer:

- Who is this for?
- What are we making / investigating?
- Why does it matter?
- What should the audience notice / understand / feel / do?
- What constraint makes the task meaningful?

Avoid disconnected “practice because the software has this tool.”

---

# 8. INDUSTRY / PROFESSIONAL CONNECTION

Where appropriate, include at least one authentic professional reference.

Examples:

- real campaign;
- professional breakdown;
- design case study;
- product launch;
- studio workflow;
- policy document;
- research article;
- technical documentation.

Use rights-safe links.

Do not redistribute copyrighted professional imagery unless licensing permits it.

The professional reference should be used analytically:

- What is noticed first?
- What stays consistent?
- What changes?
- Why?
- How does the design communicate?

---

# 9. ASSET / PROVENANCE RULES

## 9.1 Student assets

Preferred:

- teacher-created;
- rights-safe stock;
- public-domain / appropriately licensed;
- AI-generated instructional assets with provenance;
- student-created original media.

Record:

- source;
- creator;
- rights status;
- prompt/tool/date for AI assets where applicable;
- modification history where important.

## 9.2 Forbidden public-starter practice

Do not publish as student starter assets:

- watermarked images;
- unclear-rights stock;
- publisher/reference images without redistribution rights;
- teacher answer masks;
- fake software screenshots.

## 9.3 Asset consistency

The following must use the same approved source set:

- starter asset;
- step illustrations;
- checkpoints;
- final exemplar;
- transfer task where intended.

Do not teach from one image and assess using an unrelated “close enough” asset unless the change is deliberate transfer.

---

# 10. SOFTWARE / FABRICATION STEP STANDARD

Each complex technical step should contain:

## 10.1 Step header

```text
STEP NUMBER
STEP TITLE
DOCUMENT
SELECT
TOOLS / ROUTE
```

Where useful also include:

- shortcut;
- exact settings;
- panel;
- layer/group;
- mask vs pixel thumbnail;
- object / component;
- machine / tool state.

## 10.2 Actions

Numbered actions must be specific enough that a student can work without the teacher standing beside them.

Prefer:

> Select the `Accent colour` adjustment mask. Choose Brush. Set Hardness 70%, Opacity 100%, Flow 100%. Paint black over unintended neutral-material changes.

Avoid:

> Fix the colour until it looks right.

## 10.3 WHY

Explain the design / technical reason.

Do not merely restate the action.

## 10.4 CHECK

Give an observable success condition.

Example:

> The product accents change, while the neutral laces, pale sole and background remain unchanged.

## 10.5 FIX

Name likely failure modes and the correction.

Example:

> The whole poster changes colour? Check clipping and the adjustment mask.

## 10.6 Visual checkpoint

Every major construction stage needs a meaningful visual.

Preferred visual types:

1. **Action**
2. **Tool-state**
3. **Before / After**
4. **Error / Repair**
5. **Checkpoint**

Use:

- genuine software capture;
- genuine fabrication photograph;
- clearly labelled diagram/schematic;
- source-based instructional composite.

Never fabricate a software interface and present it as a real screenshot.

---

# 11. VISUAL CHECKPOINT RULE

Use the sequence:

```text
BEFORE → ACTION / TOOL STATE → AFTER / CHECKPOINT
```

for complex operations where students need visual diagnosis.

A final exemplar alone is not enough.

A student should be able to answer:

> “Does my file look right at this point?”

---

# 12. COMPLETE COMMUNICATION RESULT

A visual-effects tutorial is not complete merely because the effect works.

Where the task is a communication product, also teach:

- hierarchy;
- composition;
- typography;
- colour;
- alignment;
- spacing;
- brand / identity;
- supporting copy;
- CTA where appropriate;
- audience / purpose;
- finishing;
- export;
- source notes.

---

# 13. ASSESSMENT MODEL

## 13.1 Evidence categories

### Primary achievement evidence

- **Observation**
- **Conversation**
- **Product**

### Supporting evidence

- **Knowledge**
- **Reflection**
- **Transfer candidate / verified transfer**

### Separate learner-support stream

- Guided
- Supported
- Independent
- Transfer

## 13.2 Observation

Observation records something the teacher actually sees the learner do.

Examples:

- selects an appropriate control;
- repairs an edge;
- uses equipment safely;
- checks a result;
- adapts a process;
- troubleshoots.

Do not record vague behaviour labels as competency evidence.

## 13.3 Conversation

Conversation records what the learner can explain or defend.

Examples:

- why one tool was more appropriate than another;
- why a design decision suits the audience;
- why a repair is local rather than global;
- how a mechanism works;
- what evidence supports a judgement.

## 13.4 Product

Product records what the learner actually produces.

Examples:

- layered PSD;
- exported campaign;
- fabricated object;
- video;
- motion graphic;
- Paper 1 response;
- source synthesis;
- design proposal;
- investigation product.

## 13.5 Knowledge

Knowledge Checks are supporting evidence.

Typical range:

```text
5–8 mapped items
```

May include:

- MC;
- matching;
- mechanism tracing;
- short diagnosis;
- terminology.

Knowledge score must **not automatically**:

- assign an achievement band;
- confirm mastery;
- become Product evidence;
- generate a PowerSchool judgement.

## 13.6 Reflection

Reflection should be bounded and useful.

Prefer:

- Which skill mattered most?
- Where did you use it?
- Why was it appropriate?
- What evidence in the file shows it?
- What is your next skill target?

Do not require long workbook journaling when a short Google Form can capture the evidence more efficiently.

## 13.7 Transfer

Every substantial project should include a changed condition.

Examples:

- new client request;
- hidden defect;
- different audience;
- different surface;
- different output format;
- changed stakeholder;
- changed policy;
- changed platform;
- unfamiliar scenario.

Transfer should require the learner to choose/adapt a strategy rather than repeat the tutorial.

---

# 14. GOOGLE ASSESSMENT CONTRACT

One project generates **one active form set**.

## Student Form

Name:

```text
<project_title> - Knowledge + Reflection
```

Contains:

- signed-in email collection;
- course/class selector where needed;
- mapped Knowledge Check;
- bounded technical reflection;
- bounded design/disciplinary reflection;
- growth-skill choice;
- transfer prompt.

## Teacher Form

Name:

```text
<project_title> - Teacher Evidence Capture
```

Contains:

- roster-backed student selector;
- evidence checkpoint selector;
- achievement level;
- observed support / independence;
- evidence note.

Teacher submission sets:

```text
teacher_verified = TRUE
```

## Form Item Map

Visible student question text does not carry system IDs.

Canonical mappings live in the private `Form Item Map`:

```text
form_id
item_id
project_id
form_type
canonical_id
evidence_type
skill_ids
outcome_codes
step_id
field_role
```

## Response flow

Current scalable flow:

```text
forms-spec.json
→ Google Assessment Generator
→ Student Form / Teacher Form
→ raw Form Responses tabs
→ ONE spreadsheet-level submit router
→ Evidence_Log
→ Evidence Map Sync
→ Outcome Evidence Map
→ teacher judgement
→ PowerSchool/reporting
```

Do not create two new Apps Script triggers per workbook.

## Stable assessment launcher

Student:

```text
<ASSESSMENT_LAUNCHER_URL>?project=<PROJECT_ID>&type=student
```

Teacher:

```text
<ASSESSMENT_LAUNCHER_URL>?project=<PROJECT_ID>&type=teacher
```

The underlying Google Form may be regenerated without changing the workbook link.

---

# 15. ASSISTANT COACH STANDARD

## 15.1 Core principle

> **REDUCE FRICTION, NOT THINKING.**

The Coach helps the learner become **less dependent** on AI over time.

## 15.2 Workbook controls

Every substantial workbook should expose:

```text
[ Copy Context for Coach ]
[ Open Assistant Coach ↗ ]
```

Prefer this on each major step / section.

## 15.3 Assignment Context

The workbook provides the Coach with:

```text
course_id
module_id / sprint_id
project_id
step_id / section_id
skill_id(s)
outcome_code(s)
evidence_id(s)
task_title
assessed_cognition
scaffoldable_actions
prohibited_assistance
resources
completion_requirements
```

Preserve existing IDs exactly.

## 15.4 Assessed cognition

Explicitly state the thinking the learner must do.

Examples:

- choose the best technique;
- choose evidence;
- analyse stakeholder perspectives;
- construct the counter-perspective;
- make the judgement;
- decide the design solution;
- explain the repair strategy.

The Coach must not perform this work.

## 15.5 Scaffoldable actions

Examples:

- clarify wording;
- simplify vocabulary;
- chunk directions;
- create a checklist;
- locate a resource;
- provide a timestamp;
- explain a tool using a different example;
- troubleshoot workflow;
- self-check against requirements;
- help prepare a teacher question.

## 15.6 Prohibited assistance

Examples:

- choose the final assessed design decision;
- select the student's evidence;
- write assessed analysis;
- write the final reflection;
- complete the final artifact;
- give the correct answer to the transfer task.

## 15.7 Privacy / identity

The Coach:

- does not need student name/email;
- should use existing pseudonymous `learner_id` where needed;
- does not request diagnoses;
- does not assign personality labels;
- does not store full conversation transcripts;
- does not see/use grades to determine support.

## 15.8 Support events

If the delivery layer records support events, they use:

```text
stream: support
```

They may include:

- learner_id;
- course_id;
- project/sprint;
- step;
- support dimension;
- support band;
- scaffold used;
- learner attempted;
- resolved;
- teacher handoff requested;
- timestamp.

Support events must never enter the academic grade reducer.

---

# 16. VIDEO / SCRIBE STANDARD

Scribe It is a **delivery adapter**, not a curriculum author.

Scribe may own:

- YouTube URL / ID;
- actual start/end timestamps;
- screenshots/frames;
- chapter controls.

Scribe may **not**:

- create a new project ID;
- create alternate step IDs;
- reorder curriculum;
- replace the canonical Step Map.

Every video chapter maps to an existing:

```text
project_step_id
```

The recorded tutorial is a second route through the **same workbook**.

---

# 17. GITHUB / PUBLISHING STANDARD

## 17.1 Control plane

Canonical system metadata belongs in:

```text
ctwadden/classroom-tools
```

Working system branch currently:

```text
technology-learning-system-v3
```

It owns:

- project IDs;
- skill IDs;
- evidence IDs;
- manifests;
- Step Maps;
- forms specs;
- video manifests;
- contracts.

## 17.2 Delivery

Student-facing workbook delivery may live in a course/delivery repository.

Preferred long-term pattern:

- one canonical shared workbook;
- thin COM11 route;
- thin MM12 route;
- no duplicated workbook copies unless necessary.

## 17.3 Course catalog

Every published workbook should have a catalog entry including:

```text
workbook_id
project_id
title
subtitle
course_ids
module_id / sprint_id
route_order
type
status
visible
student_url
teacher_url
assessment_url
coach_url
video_status
outcome_codes
skill_ids
evidence_ids
builds_on
prepares_for
tags
```

No student PII belongs in the public catalog.

---

# 18. WORKBOOK UI STANDARD

A strong student page should make these immediately visible:

## START HERE

- brief / purpose;
- estimated time/classes;
- course route;
- what students will make;
- downloadable files;
- finished reference;
- Assistant Coach;
- official Knowledge + Reflection assessment;
- professional/industry connection where appropriate.

## PROGRESS

Browser-local checkboxes may support student workflow.

They are **not authoritative evidence** unless explicitly submitted to the evidence system.

## STEP NAVIGATION

Students should be able to:

- jump to major stages;
- see current stage;
- return to resources;
- open Coach;
- open video chapter when available.

## ACCESSIBILITY

At minimum:

- meaningful alt text;
- readable contrast;
- keyboard-friendly controls;
- clear headings;
- print/PDF compatibility;
- no essential instruction communicated only by colour;
- language appropriate for course level.

---

# 19. PRINTABLE PDF RULE

HTML and PDF must match in:

- step numbers;
- titles;
- images;
- instructions;
- assessment language;
- references.

Do not maintain two independent versions that drift apart.

The PDF may simplify interactive controls, but must preserve the instructional sequence.

---

# 20. SOURCE / PROVENANCE STANDARD

Every project records:

- content sources;
- asset sources;
- professional references;
- software documentation;
- AI-generated asset provenance;
- licensing / redistribution notes;
- version-dependent software notes.

Where copyright prevents redistribution:

> link to the source and provide teacher-created guidance instead of copying the protected material.

---

# 21. VALIDATION / RELEASE STATUS

Use explicit status vocabulary.

Recommended:

1. **Draft**
2. **Source / asset checked**
3. **Assessment mapped**
4. **Coach mapped**
5. **Rendered / integrated**
6. **Software / mechanism preflight passed**
7. **Teacher reviewed**
8. **Classroom piloted**
9. **VERIFIED**

Do not mark a workbook VERIFIED because:

- the page looks polished;
- the final exemplar looks correct;
- the instructions sound plausible.

VERIFIED requires the real workflow/resources to have been tested.

---

# 22. QA GATE — TECHNOLOGY / PRODUCTION WORKBOOKS

A technology workbook is not VERIFIED until these pass:

1. project/sprint alignment;
2. official outcome mapping;
3. canonical skill mapping;
4. prerequisite chain;
5. authentic brief;
6. all required student assets exist;
7. assets/reference/checkpoints match;
8. software/fabrication workflow preflight;
9. no invented UI presented as screenshot;
10. meaningful visual checkpoints;
11. WHY / CHECK / FIX present for complex steps;
12. independent transfer present;
13. O/C/P evidence mapped;
14. Knowledge Check mapped;
15. Reflection bounded;
16. Assistant Coach boundaries defined;
17. Coach link works;
18. forms-spec valid;
19. Google assessment launcher works;
20. Step Map valid;
21. Scribe/video manifest valid;
22. HTML/PDF match;
23. all links/downloads work;
24. accessibility check;
25. source/provenance check;
26. teacher review.

---

# 23. DIGITAL SOCIETY DOMAIN PROFILE

Digital Society uses the wider Learning Studio architecture but **must not be forced into a software-tutorial shape**.

The core reasoning spine is:

> **TECHNOLOGY → HOW IT WORKS → REAL CASE + EVIDENCE → STAKEHOLDERS → 3Cs → IMPACT → IMPLICATION → COUNTER-PERSPECTIVE → TRADE-OFF → QUALIFIED JUDGEMENT**

## 23.1 DS Learning Studio Lesson

Required sections:

1. Launch / Essential Question
2. Authentic Source
3. What You Need to Know
4. Mechanism / How It Works
5. Stakeholders + 3Cs
6. Evidence Check
7. Impact → Implication
8. Counter-Perspective / Trade-Off
9. Short Independent Response
10. Reflection / Next Step

## 23.2 DS Sprint Workbook

The 15-section sprint structure is authoritative:

1. Sprint Cover
2. Retrieval / Prior Knowledge
3. Chapter / Content Teaching
4. Technology Mechanism
5. Real-World Case + Evidence
6. Practical / Simulation / Investigation
7. Stakeholders + 3Cs
8. Impact → Implication
9. Counter-Perspective + Trade-Off
10. Paper 1 Practice
11. Paper 2 Synthesis
12. Independent Transfer
13. Defence
14. Retrieval + Next Step
15. IA Connection

## 23.3 DS authentic source standard

Every substantial lesson/sprint uses authentic external sources.

For a full sprint, normally:

```text
2–4 credible sources
```

Where contested, include more than one perspective.

Each source card includes:

- title;
- publisher/creator;
- date;
- source type;
- link;
- why it matters;
- what to notice;
- reliability/limitation prompt.

Do not provide the finished analysis.

## 23.4 Mechanism before judgement

Students should not evaluate a technology they cannot explain.

Address:

- input;
- process/model/rule;
- output;
- decision point;
- human oversight;
- infrastructure/data;
- error/bias/uncertainty.

## 23.5 DS assessment pack

Each sprint defines:

1. retrieval / mechanism knowledge check;
2. independent transfer;
3. source synthesis;
4. reasoning defence;
5. Product evidence;
6. reflection / next target.

Guided work is practice.

Independent transfer and defence are stronger evidence.

## 23.6 DS AI / Coach boundary

The Coach may support:

- access;
- vocabulary;
- organisation;
- retrieval practice;
- troubleshooting;
- feedback on learner-generated attempts;
- question preparation;
- process modelling on a parallel example.

The Coach must not:

- select the student's evidence;
- write the analysis;
- build the counter-perspective being assessed;
- synthesize the sources for the learner;
- make the qualified judgement;
- rewrite assessed work into a finished answer.

---

# 24. TECHNOLOGY COURSE PRODUCTION SPINE

For MM12 / COM11 production work, a strong progression is:

> **SOFTWARE / EQUIPMENT DEMO → SHORT GUIDED PRACTICE → VISUAL / MEDIA THEORY → GUIDED LAB → AUTHENTIC PROJECT → CRITIQUE → CREATIVE DEFENCE → REVISION → PORTFOLIO**

Also useful:

> **SEE IT → TRY IT → BUILD IT → USE IT → EXPLAIN IT → IMPROVE IT**

Every substantial project should move toward:

> **DECIDE → CREATE → DEFEND**

---

# 25. REQUIRED EVIDENCE DESIGN PER PROJECT

A substantial project does not need every step formally assessed.

Instead, define a small set of high-value checkpoints.

Recommended pattern:

### Knowledge

```text
5–8 mapped items
```

### Teacher Observation

Usually:

```text
1–2 high-value observations
```

### Teacher Conversation

Usually:

```text
1–2 explanation / defence checkpoints
```

### Product

Usually:

```text
1–3 meaningful product checkpoints
```

### Transfer

```text
1 changed-brief / unfamiliar task
```

### Reflection

```text
1 bounded reflection / next target
```

This is a design guideline, not a quota.

The goal is enough evidence for judgement without creating unsustainable teacher workload.

---

# 26. WHAT MUST NOT HAPPEN

Do not:

- create a parallel ID scheme;
- create a new evidence database;
- create a new roster;
- create one Google Form per lesson;
- create two Apps Script triggers per workbook;
- treat a quiz mark as mastery;
- treat workbook completion as mastery;
- treat AI support as academic evidence;
- treat support as a grade penalty;
- use extra decoration as Extending;
- fabricate software UI screenshots;
- publish missing asset links;
- publish watermarked starter assets;
- duplicate the same canonical workbook in multiple repos without need;
- let Scribe rewrite curriculum steps;
- let the Coach do assessed cognition;
- let the Evidence Map determine the curriculum sequence.

---

# 27. PRODUCTION WORKFLOW

Every full workbook follows this production pipeline:

```text
1. COURSE / SPRINT NEED
2. OFFICIAL OUTCOMES
3. CANONICAL SKILLS / CONCEPTS
4. BUILDS ON / NEW LEARNING / PREPARES FOR
5. AUTHENTIC CONTEXT / SOURCE
6. ASSET / RIGHTS CHECK
7. REFERENCE / PROTOTYPE
8. ACTUAL WORKFLOW TEST
9. VISUAL CHECKPOINTS
10. MANUSCRIPT
11. EVIDENCE DESIGN
12. KNOWLEDGE / REFLECTION / TRANSFER
13. ASSISTANT COACH BOUNDARIES
14. FORMS-SPEC
15. STEP MAP
16. VIDEO MANIFEST
17. HTML + PDF
18. TEACHER GUIDE
19. GITHUB / COURSE CATALOG
20. TECHNOLOGY EVIDENCE SYSTEM
21. EVIDENCE MAP CHECK
22. QA
23. TEACHER REVIEW
24. CLASSROOM PILOT
25. VERIFIED
```

---

# 28. ACCEPTANCE CHECKLIST

Before calling a workbook complete, answer YES to all applicable questions.

## Curriculum

- [ ] Is this workbook in the approved course/sprint sequence?
- [ ] Are Builds On / New Learning / Prepares For defined?
- [ ] Are official outcomes accurate?
- [ ] Are target skills canonical?
- [ ] Are prerequisite skills realistic?

## Instruction

- [ ] Is the purpose authentic?
- [ ] Are directions independently followable?
- [ ] Does each complex step identify the active state?
- [ ] Are WHY / CHECK / FIX present?
- [ ] Are visual checkpoints meaningful?
- [ ] Are software screenshots genuine or diagrams honestly labelled?

## Assets

- [ ] Do all required starter assets exist?
- [ ] Are download links tested?
- [ ] Do starter/reference/checkpoints match?
- [ ] Is provenance documented?
- [ ] Are rights safe for student distribution?

## Assessment

- [ ] Is guided completion treated as practice?
- [ ] Are high-value O/C/P checkpoints identified?
- [ ] Is Knowledge supporting only?
- [ ] Is a changed-brief / transfer task present?
- [ ] Is reflection bounded?
- [ ] Does Extending require transfer/troubleshooting?

## Assistant Coach

- [ ] Does the workbook have Coach access?
- [ ] Does each assessed section define assessed cognition?
- [ ] Are scaffoldable actions defined?
- [ ] Is prohibited assistance defined?
- [ ] Does Coach context preserve canonical IDs?
- [ ] Is no PII required?

## Systems

- [ ] Does `project-manifest.yml` exist?
- [ ] Does `Step_Map.csv` exist?
- [ ] Does `forms-spec.json` exist?
- [ ] Does `video-manifest.json` exist?
- [ ] Does `coach-context.json` exist?
- [ ] Is the project in the GitHub registry/catalog?
- [ ] Does the stable assessment launcher work?
- [ ] Can evidence flow to Evidence_Log / Evidence Map?

## Delivery

- [ ] Is HTML complete?
- [ ] Does printable PDF match?
- [ ] Does Student Pack exclude teacher-only answers?
- [ ] Does Teacher Pack contain expected guidance?
- [ ] Are course routes correct?
- [ ] Is validation status honest?

---

# 29. CURRENT BENCHMARKS

Use these projects for different purposes.

## Drop Day

Current **integrated reference implementation**.

Best benchmark for:

- complete student delivery;
- assets;
- step metadata;
- Assistant Coach;
- forms;
- evidence contracts;
- GitHub publishing;
- shared COM11/MM12 route.

## Fresh Impact

Advanced **instructional-quality benchmark**.

Best benchmark for:

- complex production;
- professional workflow;
- nested editability;
- changed-client revision;
- independent practical evidence.

## Built for the Wild / Truck Ad

Historical **system / architecture benchmark**.

Retain its useful architecture, but use the current Learning Studio terminology and contracts in this document.

The umbrella standard is now **Learning Studio Workbook Standard**, not “Truck Standard.”

---

# 30. SOURCE-OF-TRUTH HIERARCHY

When sources conflict, use this order:

1. approved official course outcomes / syllabus;
2. approved course/sprint map;
3. this Learning Studio Workbook Standard;
4. domain profile / locked Digital Society blueprint;
5. canonical skill and outcome registries;
6. project manifest / Step Map / forms spec;
7. student/teacher workbook artifacts;
8. legacy tutorial documentation.

Do not silently repair a conflict inside one workbook.

Fix the relevant registry/standard first.

---

# 31. VERSIONING RULE

Every canonical workbook records:

```text
project_id
version
date
status
source/reference version
software/version where relevant
```

A revision that changes:

- canonical IDs;
- assessment meaning;
- outcome mapping;
- evidence mapping;
- student assets;
- assessed transfer

must be versioned and documented.

Cosmetic fixes may use a patch-level revision.

---

# 32. FINAL RULE

A Learning Studio workbook is successful when a student can:

> **understand what they are making or investigating, know why the work matters, follow the learning independently, recover from mistakes, explain important choices, demonstrate the skill under changed conditions, and produce evidence that a teacher can trust.**

The technology should reduce friction around that process.

It must never replace the thinking the learner is expected to do.