Parallax Course Pilot

Fictional demonstration from an actual local trial. This is not a real customer result. Local links and machine-specific paths are displayed as text.

Created the 30-minute Cedar Design workshop package: complete recording-ready instructor speech with actions and exact examples, a learner handout, six-minute fresh Juniper practice, separate instructor key/rubric, raw demonstration files, and a pilot-feedback plan. Practice and debrief are included in the 30-minute schedule.

The lesson keeps SIGN-01 and SIGN-02 distinct, uses the identifiable cream reference for Mina’s SIGN-02 approval while preserving her wording, and records Leo’s five social posts as a proposed scope change. No reply deadline was supplied for Cedar, so the demonstration explicitly asks to agree it rather than inventing a commitment.

File references, schedule totals, separation of exercise and key, and the case-to-practice progression were checked. Timing remains a rehearsal estimate; no lesson was recorded or taught to real learners and no student outcomes are claimed.

instructor-script.md

# Keep client feedback attached to the right version

30-minute live pilot for new freelance designers. All studios, clients, drafts, messages, and exercises are fictional. No software account or interface knowledge is required. This is a complete teaching package, not a recording or a tested course.

## Learner promise and scope

By the end, each learner can label two revisions, write a review request naming one revision and one decision, log feedback against the correct draft, and distinguish revision approval from an unresolved request or a proposed scope change. Success is an inspectable review request and log, not a guarantee of effortless projects or eliminated scope creep.

Prerequisites: save files in folders and read/send email. Bring paper or any plain-text editor. The instructor prepares the supplied demo materials before the advertised session. No setup is assigned to learners beyond opening the handout. Contract drafting, pricing changes, and software automation are outside this pilot.

## Thirty-minute map

| Time | Purpose | Visible result | Learner action |
|---|---|---|---|
| 0:00–2:00 | Define the problem | One sign, two versions, one decision | Identify what could be confused |
| 2:00–6:00 | Keep revision identities stable | SIGN-01 and SIGN-02 inventory | Point to the cream draft |
| 6:00–10:00 | Request a specific review | Complete SIGN-02 review email | Name the decision and missing deadline |
| 10:00–15:00 | Attach feedback to evidence | Feedback log with two different work types | Classify Mina and Leo's messages |
| 15:00–19:00 | Record approval and scope correctly | Approval record plus proposed scope item | Explain why posts are not authorized |
| 19:00–25:00 | Transfer practice | Learner request and four-row log | Work independently for six minutes |
| 25:00–29:00 | Feedback and correction | Revised practice artifacts | Compare with the separate answer key |
| 29:00–30:00 | Close and collect feedback | One next-use commitment | Submit feedback form |


The map includes demonstration handling, short participant responses, practice, and feedback. It is an estimated facilitation schedule and needs a timed rehearsal. Spoken passages below are not intended to fill every second; use the indicated displays and pauses rather than stretching the narration.

## Node 1 · 0:00–2:00 · One decision, two drafts

**Say:** “Today we are going to make a small client review understandable. By the end, you will have two things you can use in your next project: a review request that points to one draft, and a small log that tells you what happened to that draft. You do not need a project-management system. A folder, an email, and a short table are enough for this exercise.

“Here is Cedar Design's job. Cedar is making one café sign. The first draft has a green background. The second has a cream background. Mina can approve the sign. Leo works at the café, but our case does not say he can approve it. When comments arrive, we need to know which draft they refer to and what the commenter is actually asking us to do.

“Imagine opening your inbox after lunch and reading, ‘Looks good.’ Before you print anything, what would you need to know? Take ten seconds. The useful questions are: which draft, which decision, and whether the person can make that decision. Today we will make those answers visible.”

**Show/input:** Display `demo/revision-inventory.csv`, with the agreed deliverable “one café sign” written above it. Read the two rows in order. These are supplied case facts, not examples of real client outcomes.

**Observable result:** Learners identify that color alone can become confusing if versions continue to accumulate. They can name Mina as authorized reviewer.

**Checkpoint:** If someone says “Use a better app,” respond: “An app can store the record, but the record still needs to identify the draft. We can solve that part here without buying anything.”

**Transition:** “We know what can be confused. First, give each draft an identity that does not change when a newer draft appears.”

## Node 2 · 2:00–6:00 · Name and retain the revisions

**Say:** “These are two different drafts, not one file that we keep replacing. The green sign is SIGN-01. The cream sign is SIGN-02. We keep both. If a client later refers to the green background, we can see what they saw rather than reconstructing it from memory.

“In a shared folder, put the revision ID into the filename and repeat it in the review message. A filename such as ‘final-final-new’ tells you how the designer felt, not which version the client reviewed. Our small example uses SIGN-01-green.txt and SIGN-02-cream.txt. In a real design job the extension could be PDF or another design format; the identity rule stays the same.

“Open SIGN-02 now. Its first line says SIGN-02, and its description says cream background. Do not rename SIGN-01 to SIGN-02. Do not delete the green draft to make the folder look tidy. We need the old identity because old comments may still arrive.

“Now point to the draft we want reviewed for print. It is SIGN-02. That sounds obvious while there are only two rows. The purpose is to keep it obvious when there are twenty messages.”

**Show/action:** Display the two supplied text draft stand-ins side by side. Copy the filenames into a visible folder list; no software-specific menu is required. Explain that the text files stand in for design files and are not rendered artwork.

**Expected result:** The inventory contains SIGN-01 / green / retained and SIGN-02 / cream / current print-review draft. No approval is inferred merely from the filename.

**Checkpoint:** “If I change the cream draft after it is approved, can I save over SIGN-02 and carry the approval forward?” After a brief response, say: “No. The changed draft needs a new revision identity and the approval relevant to that revision. The old approval describes the old artifact.”

**Transition:** “The folder now identifies the draft. The review request should identify it just as clearly.”

## Node 3 · 6:00–10:00 · Ask for one explicit decision

**Say:** “A review message has three jobs: point to the exact revision, name the decision, and say when a response is wanted. Let us write the message for SIGN-02. We are asking whether this sign is approved for print. We are not asking for approval of social posts, a new fee, or every future version.

“Read the subject first: ‘Print review — SIGN-02 cream café sign.’ Read the opening: ‘Mina, please review SIGN-02, the cream-background sign attached to this message.’ The attachment must actually match that name when you use this in real work. A correctly written message with the wrong attachment is still the wrong review request.

“The case has not given us a real reply deadline. That is a missing field to resolve, not a date to invent. The draft below is complete about the revision and decision. Its timing line asks Mina to agree a reply time. Before using a deadline as a commitment, agree it and replace the timing line with the actual time.

“Notice how the request creates the evidence we need later. If Mina replies naming SIGN-02, we can attach that decision to one record. If she says only ‘looks good’ in a context where several drafts could be meant, we ask which one before using it as approval.”

**Exact demonstration input:** Open `demo/review-request.txt` and read it aloud:

> Subject: Print review — SIGN-02 cream café sign
>
> Mina, please review SIGN-02, the cream-background café sign attached for review. Please reply with either “SIGN-02 approved for print” or the changes needed on SIGN-02.
>
> What reply time can we agree for this print decision? I will record the agreed time in this request before treating it as a deadline.
>
> This review covers the one café sign in our agreement. Matching social posts, if wanted, need a separate scope decision.

**Status:** This is a draft for teaching, not a sent email. The timing question is deliberately explicit because no deadline was supplied.

**Checkpoint:** Ask learners to point to revision, decision, timing, and scope. If someone treats “approve the project” as equivalent, ask what specific artifact that approval would authorize for print.

**Transition:** “Now the messages arrive. The next job is to record them without turning every comment into approved work.”

## Node 4 · 10:00–15:00 · Two messages, different meanings

**Say:** “Mina writes, ‘The cream one is approved for print.’ In this case the inventory has exactly one cream draft, SIGN-02, and Mina is the authorized reviewer. That makes her reference identifiable. We can connect her message to SIGN-02 and retain the original wording. We should not rewrite the source quote as though she typed a revision ID she did not type.

“Our log therefore records the identified revision, the commenter, the requested decision or change, and the status. Add a small evidence note saying that cream maps uniquely to SIGN-02 in this case. If two cream drafts existed, the same sentence would no longer be enough to identify one of them. We would ask Mina which revision she meant.

“Leo writes, ‘Could we also get five matching social posts?’ That is a new deliverable. It is not feedback to apply to the sign file. We record it as a proposed scope change linked to the sign project, with no sign revision changed. We do not make five posts and hope the fee will be understood later.

“A log should make the difference visible. One row is an approval of an identifiable sign revision. Another row is a request for work outside the existing agreement. The fact that the design is approved does not approve a new fee. The fact that someone works for the client does not automatically give them authority to make every decision.”

**Show/input:** Read `demo/incoming-messages.txt`, then reveal `demo/feedback-log.csv` one row at a time. Keep the original messages visible beside the log.

**Expected result:** SIGN-02 is recorded with Mina's identifiable print approval and its source wording. Leo's posts remain a proposed scope change, not approved production or an applied sign edit. No client email is sent during the workshop.

**Checkpoint:** “What if Leo had written ‘Make the green one darker’?” Allow a response. Explain: “That identifies SIGN-01 in our inventory, but it does not tell us that the current cream draft should change. Log the reference and clarify whether the request concerns the retained draft or asks us to revive it.”

**Transition:** “We can now answer what happened to the sign and what is still undecided. Let us make those answers easy to use.”

## Node 5 · 15:00–19:00 · Use approval without expanding it

**Say:** “The record is useful only if the next person can act on it. For our one sign, the identifiable revision is SIGN-02, the reviewer is Mina, and the decision is approved for print. Keep the message that supports that status. If you change the artwork, the status does not move itself onto the changed file.

“For the five social posts, the next action is a separate scope decision. We need to establish what is being requested, who can authorize it, and what timing and fee would apply. None of those details was agreed in the case, so our log does not pretend they are settled. We can draft a response: ‘I have recorded the request for five matching posts separately. Our current agreement covers one sign. We can define the additional scope, timing, and fee before any posts are started.’ That is a proposed response, not a message we send in class.

“Now read the record from the perspective of tomorrow morning. Which file can we identify? SIGN-02. What tells us the decision? Mina's retained message plus the unique cream reference. What is not authorized yet? The five posts and any new fee. A small record has prevented three different decisions from collapsing into one vague word: approved.

“In the practice, the colors and names change. The questions stay the same. Which revision? What decision? Which person? Is this within the current deliverable?”

**Show:** Display the two log rows and the exact proposed response above. The demonstration is supplied/fictional, not a measured claim that this method eliminates disagreements.

**Expected result:** Learners can explain why “sign approved” and “posts requested” must remain separate statuses.

## Node 6 · 19:00–25:00 · Practice

**Say:** “Open the Juniper practice in your learner handout. Work on your own for six minutes. Make a four-row feedback log, then draft one review request for MENU-05. Keep the originals. Do not place an uncertain comment onto a draft merely to fill the revision column. Use ‘revision unresolved’ when that is the truthful state. There are no hidden files you need to find.”

**Input:** `practice/source-messages.txt` and `practice/revision-inventory.csv`. The learner handout contains the task, required output fields, and blank working table. It contains no model answer.

**Facilitation:** At minute three, give a neutral time reminder. If a learner asks what “looks good” refers to, point back to the source and ask what evidence identifies it; do not reveal the answer. No new teaching topic is introduced here.

**Expected result:** Each learner produces their own log and review email. Do not label it correct before checking the separate rubric.

## Node 7 · 25:00–29:00 · Debrief

**Say:** “Compare your record with the instructor key. The point is not to copy the same sentences. The point is to preserve the same decisions. A message without a revision stays unresolved until the reference is established. A named revision can receive a decision from the authorized person. A request for another deliverable needs a separate scope decision.

“Look at your first row. Did you assign an uncertain comment to the latest draft just because it was latest? That is the mistake we want to catch. Look at the approval row. Did you retain the exact ID and the authorized reviewer? Look at the extra table cards. Did you treat them as five more edits to the menu, or as a separate request?

“Make one correction to your own log now. Then read your review email and point to the revision, decision, and requested reply time. A correct record can use different wording from the example. It cannot merge unresolved and approved states.”

**Show:** Open the separate `instructor-key.md` only now. Apply the rubric to artifacts, not participant confidence. Treat the suggested score threshold as a trial teaching rule, not evidence of course efficacy.

## Node 8 · 29:00–30:00 · Close

**Say:** “You now have a small routine you can try on one real review: name the draft, ask for one decision, record the response against its evidence, and separate additional scope. This does not remove every commercial disagreement. It gives you a clearer record of what was actually requested and approved. Complete the short feedback form before leaving. Tell us the step that was unclear, not only whether you enjoyed the session.”

**After class:** Preserve submitted exercises and collect feedback only within the host's normal consent and privacy arrangements. Do not claim student results before the trial happens. Use `pilot-plan.md` to decide what to revise.

learner-handout.md

# Keep client feedback attached to the right version

You will leave with a revision-specific review request and a feedback log. Use paper or any text editor. No project-management account is required.

The working routine: retain each revision; name the exact revision in the review request; state the decision and requested response time; log feedback with its source; clarify unidentified drafts; record additional deliverables separately; use approval only for the identified revision and authorized reviewer.

## Six-minute practice: Juniper Menu

All details are fictional. The agreement covers one printed café menu. MENU-04 has a charcoal heading. MENU-05 has a cream heading. Keep both. Rosa is the authorized reviewer. Sam is a staff member; no approval authority is stated for Sam. For this exercise only, the proposed review reply time is Thursday at 15:00; it is a teaching scenario, not a real client deadline.

Messages, in order:

1. Sam: “Can you make it brighter?” No file or revision is named.
2. Rosa: “Looks good.” No quoted thread, attachment, or identifiable draft is available for this message.
3. Sam: “Could we add six table cards using the same look?”
4. Rosa: “MENU-05 is approved for print.”

Create a four-row log with: message number, revision or unresolved reference, commenter, requested change/decision, status, evidence/next action. Then write a review request for MENU-05 that names the decision, the fictional reply time, and the existing one-menu scope. Treat it as a reusable review-request draft, not a message to send after the approval already received.

| Message | Revision/reference | Commenter | Change/decision | Status | Evidence/next action |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
| 4 | | | | | |


Do not guess which version an unclear comment means. Do not send anything. The instructor will reveal a separate key after practice.

## Submit

Your four-row log and review request are the artifacts to check. Keep your original attempt so you can see what you corrected. Different wording is welcome if the decision boundaries stay intact.

instructor-key.md

# Instructor key — reveal after practice

## Log reasoning

1. Sam's “make it brighter” has no identifiable revision. Record reference unresolved, requested visual change, awaiting clarification. Ask which revision and which part. Do not apply it to MENU-05 by recency.
2. Rosa is authorized, but “looks good” has no identifiable artifact in the supplied context. Record approval intent unclear / revision unresolved, awaiting exact revision confirmation. Authority alone does not supply the missing reference.
3. Six table cards are outside the one-menu agreement. Revision can be “not applicable — additional deliverable,” with the related menu project noted. Status: proposed scope change, not authorized. Ask for the scope, timing, fee, and appropriate approval separately. No fee is invented.
4. Rosa explicitly approves MENU-05 for print. Record MENU-05, Rosa, print approval, approved, preserving the exact quote. Do not let this resolve Sam's separate extra-deliverable request.

## One acceptable review request

Subject: Print review — MENU-05 café menu

Rosa, please review MENU-05, the cream-heading menu. Please reply by Thursday at 15:00 with either “MENU-05 approved for print” or the changes required on MENU-05. This request concerns the one printed menu in our agreement. The six table cards remain a separate scope request.

This is the requested reusable teaching draft, not an instruction to send a redundant email after message 4. The deadline belongs only to the fictional exercise.

## Ten-point rubric

| Criterion | Points | Correct evidence | Serious misunderstanding |
|---|---:|---|---|
| Revision identities retained | 2 | MENU-04 and MENU-05 remain distinct | Overwrites or renames the old revision |
| Ambiguous messages handled | 2 | Messages 1 and 2 remain unresolved with a clarification step | Assigns them to the latest draft without evidence |
| Approval recorded | 2 | Message 4 approves MENU-05 by Rosa for print | Approves all revisions or uses Sam's authority |
| Additional scope separated | 2 | Six cards are a proposed change; no fee/authorization invented | Starts cards or treats signoff as fee approval |
| Review request specific | 2 | Names MENU-05, print decision, stated exercise time, and one-menu scope | Vague “approve project” request |


Award 1 for a partially correct item that preserves the key decision but misses a useful field; 0 when the decision is wrong. Equivalent wording earns full credit. As an initial teaching rule, 8/10 with no mistaken approval or automatic scope acceptance suggests the learner can try the routine on one simple review. This threshold is illustrative, not validated assessment science. Re-teach the specific failed distinction before adding complexity.

## Demo interpretation note

Mina's original “cream one” message can identify SIGN-02 because the supplied inventory has one cream draft. Preserve that reasoning and quote. Do not teach that every color reference is always sufficient or that every approval must literally contain an ID regardless of unambiguous context.

pilot-plan.md

# Pilot and feedback

Run once with 4–6 designers who can manage folders/email but have not used a project-management system. This is a proposed convenience trial, not an enrolled cohort. Rehearse first with a timer; shorten explanations before reducing the six-minute practice. Keep the advertised session at 30 minutes.

Collect each original practice artifact and its corrected version. Note where a learner asks for clarification and how long the exercise takes. Do not confuse attendance, compliments, task completion, or willingness to pay.

Use these neutral questions:

1. Before today, how did you identify the version a client was reviewing?
2. Which parts of the log and request did you complete without help?
3. At which exact instruction or message did you pause or become unsure?
4. What would make this routine difficult to use in your next real project?
5. What related task do you need to handle next?

Initial revision rule: if two or more learners assign ambiguous feedback to the latest draft, replace Node 4's explanation with a side-by-side ambiguous/identifiable example and repeat that practice distinction. If most learners cannot finish in six minutes, simplify the worksheet or reduce lecture examples rather than claiming the audience is unsuitable. If everyone completes the sheet but cannot explain scope separation, add one oral transfer question before expanding to a longer course. These are practical pilot decisions, not statistically validated thresholds.

No price, launch date, student results, testimonial, or download service has been invented. The next step is a rehearsal and a real pilot, not a claim that the course is already effective.