Lesson 4: Evidence-Governed Technology Design
Seminar focus: defend the boundaries
Ākonga use a council-style deliberation to decide which source-backed safeguards and governance constraints a proposed technology needs. Each recommendation must state its evidence, affected group, authority boundary, and accountability mechanism.
- Scaffold: Stakeholder testimony, speaking protocol, and recommendation frame
- Seminar outcome: Collective ethics charter with justified safeguards
Learning Intentions & Success Criteria
Learning Intentions
- Extract design requirements from a named project source
- Distinguish a documented need from a learner assumption
- Prototype a technology concept with explicit authority boundaries
Success Criteria
- Every cultural or community claim is attached to its named source and scope
- Need, intended benefit, consent, data use, and uncertainty are visible
- Prototype identifies what requires genuine co-design or approval before use
Kupu / Vocabulary: co-design, prototype, provenance, consent, governance, data sovereignty, scope, authority.
🎯 Learning Objectives
Students will be able to:
- Use a named source to identify a documented technology need or governance requirement
- Separate source evidence, design inference, uncertainty, and decisions held by others
- Design a bounded prototype without claiming that it represents a community
- Evaluate proposals through consent, provenance, benefit, access, accountability, and stop conditions
📚 Key Concepts
- Source scope: The people, project, place, and purpose a source can truthfully represent
- Co-design: Affected people sharing real decision-making power, not merely being consulted after design
- Data governance: The permissions, roles, controls, and accountability governing data across its life cycle
- Stop condition: A clear point at which missing evidence, consent, safety, or authority halts the proposal
🚀 Lesson Structure
Part 1: Source Check - 10 minutes
Opening rule: A project’s own published account can establish its stated purpose and governance approach; it cannot stand for every Māori or Indigenous community.
Activator: Read or preview one primary-source account:
- Te Hiku Media — Papa Reo: A Māori-led language-technology project developing speech-recognition and natural-language-processing capability beginning with te reo Māori. Papa Reo states that smaller Indigenous language communities should retain sovereignty over their data and receive the benefits produced from it. Under Te Hiku Media’s Kaitiakitanga Licence, data is cared for rather than owned, and decisions about its use must respect the people from whom it comes. Read Papa Reo’s own account.
Discussion: According to Papa Reo’s own account, who governs the project and its data, who should receive the benefit, and what limits are stated? Cite the source; do not infer a generic Indigenous model.
Part 2: Source and Authority Design Framework - 15 minutes
Kaiako preparation: Provide a named, public Māori-led source that states the affected community or project’s own design requirements. The source’s scope must remain visible; it does not stand for all Māori.
Authority and design questions:
- Who names the need and intended benefit?
- Who has authority over the relevant data, knowledge, and decisions?
- What consent is required, and how can it be withdrawn?
- What must not be collected, digitised, or shared?
- How will the affected people govern, test, change, or stop the technology?
Discussion Questions:
- Which requirement is stated directly by the supplied source?
- Which proposed feature would still require evidence, co-design, or approval?
Part 3: Evidence Extraction - 15 minutes
Group task: Extract one documented need or governance requirement from the supplied source. Do not brainstorm deficits for a community.
Evidence questions:
- What exact words in the source identify the need or intended benefit?
- Whose perspective does the source carry, and whose perspective is absent?
- What data, language, or knowledge would the concept involve?
- Who may approve, change, challenge, or stop the proposal?
- What claim remains unverified?
Part 4: Design Sprint - 25 minutes
Group Design Challenge: Using a need explicitly identified in the supplied source, students design an authority-aware concept. They must distinguish features they can propose from cultural or governance decisions that require community co-design and approval.
Design Prototype Components:
- Problem Statement: What specific problem are we solving? Who is affected?
- Source Requirements: Which requirement comes directly from the named source?
- User Experience: How will people actually use this? (Sketch interface/flow)
- Data & Privacy: What data is collected? Who controls it? How is it protected?
- Intended Benefit: What benefit does the source identify, for whom, and within what scope?
- Sustainability: How is this maintained and governed over time?
Deliverable: Simple prototype sketch (paper or digital) + brief explanation of design rationale
Part 5: Pitch Presentations - 15 minutes
Activity: Each group presents their design prototype (3 minutes per group)
Feedback Protocol: Using the source-and-authority framework, students evaluate each presentation:
- Evidence: Which design requirement is genuinely supported by the named source?
- Boundary: What assumption, permission, or perspective is missing?
- Revision: What should change now, and what must wait for co-design or approval?
Part 6: Whakamutunga (Closing) - 10 minutes
Reflection: Students complete individual reflection:
- What changed when I separated source evidence from my own design assumptions?
- How has this changed how I think about the apps/tools I use daily?
- Which part of the concept may be prototyped now, and which part must remain with the relevant authority?
Exit check: one sourced requirement, one explicit uncertainty, one named decision-holder.
📊 Assessment
Formative: Observation of source use, scope control, and authority-aware design decisions
Summative: Design prototype (group) + individual reflection
Rubric for Design Prototypes:
- Source and authority: Uses a named source accurately, keeps within its scope, and identifies the people who must co-design or approve the next stage
- Problem/Solution Fit: Responds to a need established by the named source without enlarging its scope
- User Experience: Thoughtful consideration of how people will actually use this
- Data Ethics: Clear protocols for consent, access, care, correction, withdrawal, and accountability
- Next decision: Identifies what requires co-design, approval, or a stop condition
🎓 Teacher Notes
Preparation:
- Prepare the named primary source and verify every project claim against it
- Prepare design template handouts or digital files
- Set up space for group work (tables, whiteboards, materials)
Differentiation:
- Support: Provide more structured template with prompts for each section
- Extension: Students create functional prototype using no-code tools (Figma, Bubble.io)
- Digital Literacy: Pair confident designers with those less familiar with tech terminology
Cultural Considerations:
- Offer leadership roles by choice and do not position Māori or Indigenous students as the group's cultural authority
- Do not ask learners to identify community needs from personal identity or presumed cultural knowledge
- Use only public material; restricted knowledge and unapproved cultural content stay out of digital tools
Extension/Homework:
Students annotate one public project source: one documented need, one stated governance requirement, one uncertainty, and one decision that remains with the project or community.
🔗 Connections to NZC
- Te Mātaiaho (2025) · Technology · Phase 4 (Years 9–10) · Knowledge: “Effective design integrates human, environmental, and systemic considerations, using design frameworks, planning tools, and stakeholder input to guide decisions, manage trade-offs, and optimise outcomes.”
💬 Whānau Connection
Students may share their evidence map with whānau and ask: “Which claim is supported, which is still an assumption, and whose permission would be needed before this idea went further?” Sharing is optional and does not seek cultural validation.