From Answers to Processes: Designing Human-AI Co-Construction

Position in Module#

• Unit: 5
• Topic: From Answers to Processes: Designing Human-AI Co-Construction
• Literacy perspective: System, with Interaction
• Collaboration level: Co-construction
• Fundamentals focus: Decomposition, project context, persistent state and reusable skills

Unit 1 supplies the five-phase workflow. Unit 2 deepens clarification and introduces persistent files; Unit 5 develops planning and execution; Unit 6 examines critique and improvement; Unit 8 develops orchestration. These are conceptual relations, not a statement about the order in which the Fridays were delivered.

Delivery Basis and Materials#

This design reflects Michael Winter's teaching on 2 October 2026, documented in Unit_05_Slides.pdf, and the supplied Metrics.xlsx evaluation catalogue. Page references below count PDF pages, including the cover.

The live input labelled «Kognitive Architektur für die KI» is reconstructed from the course organiser's account: organising a project folder for tools such as Codex in VS Code or Claude Code, storing and retrieving Markdown instructions and project artefacts, and using and creating skills. The illustrative folder layout and follow-up check below make that account teachable; they are not a transcript of the demonstration.

Use the evaluation-catalogue guide alongside the original workbook. The challenge remains the authoritative assignment. Its personal experiment, order of runs and submission requirements differ from the cumulative classroom exercises.

Literacy Perspective#

• Primary literacy: System
• Secondary literacy: Interaction
• What this literacy explains: Phases, handoffs, intermediate artefacts, roles, checkpoints and persistent state determine where a person can inspect and influence work. Interaction Literacy concerns the contributions and exchanges within that structure.
• What participants manipulate and interpret: Change the collaboration process for a stable task. Examine which decisions became visible, which interventions changed later work, where errors propagated, and whether the control gained justified the effort.

Collaboration Level#

• Collaboration move being learned: Agree a process, expose consequential choices in intermediate artefacts, and use human checkpoint decisions to steer the developing result.

Co-construction means designing and carrying out a process in which human and AI contributions influence the developing result. Participants agree steps, dependencies, working artefacts and decision authority, then use evidence to assess the design.

Who could influence which decisions while the result was being created?

A longer prompt or a sequence of corrections to a finished answer does not by itself establish this planned control. A single pass may still be proportionate for a simple, well-understood task.

Friday Learning Goals#

By the end of the Friday, participants should be able to:

1. choose between single pass and co-construction in relation to uncertainty, consequences and effort
2. place process cuts where a decision affects later work, an uncertain assumption could propagate, or a useful working state can be inspected
3. distinguish an intermediate artefact from a checkpoint that can continue, revise, stop or restart work
4. distinguish a reviewing perspective from a role with specified inputs, outputs and decision authority
5. organise project instructions, sources, accepted state, decision evidence and reusable procedures so that relevant information can reach the next contribution
6. use the supplied catalogue to compare quality, requirements coverage, transparency, weighted error points and time, and check an LLM's assessment against evidence
7. use PDCA to connect planning, execution, checking and consequential decisions, and derive a bounded transfer rule

Core Concepts and Learning Sequence#

Opening: hidden decisions#

The instruction video and Spaghetti Napoli example expose assumptions about starting conditions, people, location, ingredients, purchasing and sequence (PDF pp. 8–16). Ask which decisions a recipient would otherwise have to infer and where a human would need to intervene. Move from the wording of an instruction to the design of a controllable process.

The terminology map on PDF pp. 20–23 groups questions about input, thinking and acting, feedback, adaptation, boundaries and quality. It supports orientation within this lesson; it does not replace the course's five literacies.

Shared classroom case: equipment loans#

The exercises use «Ausleihe eines Firmengeräts»: employees borrow equipment such as laptops or cameras, from requesting it through a central equipment service to returning it (PDF p. 37). The output is a process description.

Keep two processes distinct: the equipment-loan process being described and the human-AI process used to produce that description. Decisions about requirements, a first draft or exceptions are possible cuts in the latter. For example, checking what happens when equipment is unavailable is a possible teaching illustration, not a reported group finding.

I. From single pass to three process cuts#

Following the classroom sequence, first request a complete process description in one pass. Preserve the request, unchanged result and time. Then develop the description through co-construction with exactly three planned human-AI exchanges before AI completes it (PDF pp. 25–37).

Choose cuts by asking:

• Does a decision here affect later work?
• Could an uncertain assumption carry forward?
• Is there a working state that a person can usefully inspect?

Requirements, draft structure and exceptions are possible cut locations. The purpose is to expose decisions before they become expensive to change. Preserve the dialogue, three human decisions, result and time.

II. Give each cut an artefact and a checkpoint#

Return to the same cuts. Specify the intermediate artefact and the checkpoint: what is inspected, which question or criterion is applied, and what decision follows (PDF pp. 42–56).

A useful artefact is visible, understandable, reviewable, revisable and consequential for subsequent work. A requirements list, draft sequence or exception table can serve this purpose. The checkpoint permits continuation, revision or, when necessary, stopping and restarting. A recorded comment without influence on the next step is insufficient.

Use files as process memory (PDF pp. 51–54):

• retain the single-pass result as a separate, unchanged baseline
• maintain one clearly identified, currently accepted co-construction state
• preserve decision evidence separately so it remains possible to explain how that state arose

One evolving document or several linked files can implement this distinction. Do not silently replace the historical evidence when updating the current state. Record the additional work and time.

III. Add perspectives and roles#

The sales-conversation example introduces potentially conflicting perspectives: sales management, the employee, data protection and customers (PDF pp. 59–74). A perspective determines the questions and criteria used to inspect an artefact. A role determines a contributor's task, input, output, authority and limits. One reviewer can apply several perspectives; a role label does not establish expertise.

In the classroom exercise, examine each intermediate artefact through two perspectives. Define the reviewer contributions, make their findings and conflicts visible, and decide which changes to accept or reject. Update the co-construction result and record the time.

AI can supply reviewing contributions. The human decides what is accepted and passed forward. This prepares later orchestration without making autonomous delegation a requirement here.

IV. Evaluate quality, control and effort#

Connect a relevant property to a criterion, a scale, observable evidence and a decision (PDF pp. 77–86). Evaluate both results yourself with the provided catalogue. Then ask an LLM to assess the co-construction result, compare its judgements with yours, and resolve disagreements by checking the evidence.

The overview calculates co-construction minus single pass. Its error total is not a raw count, and blank inputs can produce zero totals and “not better” flags before any assessment. Follow the catalogue guide for input cells, timing and interpretation.

Keep these dimensions separate. A transparent process may take longer without improving the final result; a shorter run may leave a critical error. Do not turn these observations into an unsupported overall score. An LLM judgement is a further artefact to inspect, not the authority that determines success.

V. Integrate the process with PDCA#

The closing framework uses Plan–Do–Check–Act as one possible basis for combining the four elements: artefacts, checkpoints, perspectives/roles and metrics (PDF pp. 89–97).

PDCA can operate within the course's five-phase workflow. It is neither an additional collaboration level nor a replacement for the experimental learning cycle of prediction, intervention, observation and interpretation.

Use the transfer discussion to weigh benefit against error costs, time, coordination, reuse and possible later automation (PDF pp. 99–108). More process is useful only where its decisions create worthwhile control.

Generative and Agentic AI Fundamentals#

Decomposition explains why a complex request can become more controllable when relevant assumptions and choices are made explicit between generations. Later contributions depend on the context they receive. A flawed plan or unexamined intermediate artefact can therefore carry an error forward; visible intermediate outputs do not expose the model's internal reasoning.

Project context, persistent state and reusable skills#

The live project-folder demonstration contributes to the fundamentals dimension by making the surrounding system concrete: where instructions and working state live, how files become available as context, and how reusable procedures differ from task-specific results. System Literacy supplies the control lens; co-construction remains the collaboration mode.

The demonstrated practices were organising a project folder, including instruction folders such as .agents/, reading and writing Markdown project artefacts, and using and creating skills. The following is an illustrative reconstruction, not a required structure or submission:

A file's presence on disk does not mean the model has received it. Distinguish available files from content actually read or supplied. An arbitrary file inside .agents/ is not automatically an instruction. Use the selected tool's discovery rules and check what information reaches the working session.

For a teaching example, a checkpoint-review skill can specify when to use it, required artefacts and criteria, steps for checking them, a findings format with evidence, and a boundary reserving release to the human. Keep the reusable procedure separate from the current project's findings. Clear Markdown headings help separate purpose, inputs, steps, outputs and limits.

In Codex, a skill uses a directory containing SKILL.md, with name and description metadata followed by instructions; supporting resources are optional. Repository skills can live under .agents/skills/. Discovery initially exposes metadata, with the full instructions loaded when the skill is used. Ordinary project notes do not become skills solely because they are Markdown files. Other tools require their own supported conventions. See the official skills documentation.

Suggested continuation check: predict what a fresh session needs to resume the work. Supply the agreed instructions, accepted state and relevant sources, invoke the review procedure, and inspect whether the session uses the correct state and respects the human decision boundary. Missing context is evidence for revising the handoff. This is a proposed follow-up activity, not a claim that this exact check took place.

The progression is concrete: Unit 2 introduces persistent files; Unit 5 organises context, accepted state and reusable procedures; Unit 8 extends these foundations into orchestration. Folder structure and skills support continuity but do not guarantee correct retrieval, judgement or execution.

Recurring Agentic Coding Demonstration#

Coding remains an optional transfer case. The supplied slides document the equipment-loan exercises and sales example, not a separate coding experiment. If used, show how a specification, implementation, tests and review can be connected through accepted files and human decisions, then relate that structure to non-coding work.

Friday Activity Table#

This sequence records the teaching structure without assigning undocumented activity durations.

Experiment Focus#

• Experiment focus: Compare single pass with a process containing three human checkpoints, inspectable artefacts and reviewing perspectives; assess quality, control and effort using the provided catalogue.
• Classroom comparison: single pass first, followed by cumulative co-construction refinements on the same case. Keep task, source information, intended output and model stable where practicable; disclose changes.
• Personal challenge: freeze the shared task package, three result requirements and direct request, develop and approve the plan, execute co-construction first, then run single pass in an isolated context.
• Interpretation limit: neither design isolates planning from extra interaction, feedback or learning. The slides explicitly warn that doing single pass first can inform subsequent co-construction (PDF p. 103). Reversing the order and isolating the AI context do not remove the participant's growing task knowledge.

Observation Focus#

Capture the baseline, accepted intermediate and final states, decisions and their consequences, evidence for ratings, and time. Ask which checkpoint detected or propagated an error, which perspective changed a decision, and whether the resulting quality and control justified the effort. Preserve differences and disagreements rather than reporting only a favourable final score.

Challenge Kickoff Deliverables#

Prepare the elements required by the challenge:

• a personally relevant, already-aligned task and intended result
• the shared task package, three result requirements and frozen direct request
• an AI-supported, human-approved plan with three checkpoints and at least two review perspectives overall
• reasons for planning choices and a prediction recorded before execution
• a method for retaining checkpoint evidence and recording active time and AI requests

Classroom methods are available for transfer: PDCA, separate accepted-state and evidence files, the evaluation catalogue and reusable review instructions. They do not add submission requirements. In particular, the challenge requires at least two perspectives overall; the classroom exercise applies two to each intermediate artefact. The challenge's extra AI judgement is optional.

Submission remains one ZIP containing exactly three documents: both results and Nachweisdossier.pdf of four to six pages, including selected evidence. Working files, the workbook and full chats are not additional submissions. The challenge defines the documented-stop exception; improvement over single pass is not required.

Teacher Setup#

Prepare the equipment-loan brief, original slides, workbook and guide; an accessible AI interface and document editor; and a non-sensitive project folder for the live input. Verify file access and the selected tool's skill conventions before teaching. A prepared file walkthrough can serve as a fallback.

Establish requirements before rating coverage. Explain weighted error points and agree timing boundaries before collecting measures. Preserve the baseline separately from the evolving co-construction result. Keep the four exercises cumulative and the three classroom cuts visible, while allowing different concrete artefacts and reviewing perspectives.

For transfer, vary tools and folder names while retaining the same control questions: what is accepted, what context is available, what evidence supports the judgement, and who can decide the next action?