Skip to main content
SLOP4408 / MASTERMINDIn person preferred · Online availableSemester 1 · 2027

THE DEMONSTRATION STUDIO / WATCH · INSPECT · TAKE CONTROL

When the release authority expires

A complete alternate worked example, followed by meaningful takeover practice.

The method behind this example

Preserve valid decisions and revise only dependencies invalidated by new evidence.

Your independent challenge: This example changes authority while leaving equipment intact. Your disruption concerns availability and needs different replacement evidence.

The investigated explanation and learning record complete this example. The scene delivery is an optional extension.

Start this worked example

  1. Choose Watch the worked example. The student demonstrator explains the task, talks through each action, then reviews the observations and finished submission. Narration starts with this click; Mute narration keeps the same experience captioned.
  2. Choose Take control to try the current chapter. Follow its prompt, change the labelled controls and select Test my decision.
  3. Read the feedback, retry if needed, then continue with Next chapter. Each checked chapter provides evidence for one connected operation.
  4. After every chapter check, return to the mission station, perform the intervention, collect its package and follow the marked checkpoints to complete the handover. Watching performs these same actions with narration. Direct chapter access is a partial preview until the full evidence and handover are complete.
  5. Use Fullscreen mission after opening the scene to keep the instructions, chapter controls and equipment together. Reflections and exports come after your practical attempt.

This is an alternate example, not your assigned exercise. Your course task is linked after the player.

YOUR SKILL

Preserved revision

A NEW SETTING

A conservatory dispatch plan must satisfy a replacement authorisation rule while every route and item of equipment remains available.

WHAT CHANGES

No passage closes and no meter fails. A superseding authorisation rule requires recipient-scope verification and recorded permission before sealing, so the team must reorder dependencies rather than choose another route.

Choose how you want to learn.
You · student in Take controlDr Mara Voss · instructor · not a case character
Scene guide · people, evidence and object placement

Who verifies the new authority

A dispatch plan receives a new authorisation prerequisite while routes and equipment stay available.

Your part
Watch follows a worked solution. Take control lets you move the student avatar and try its decisions. The demonstrator in the explanation is modelling a solution, not an extra witness in the story.
Your instructor
Mara stands in the marked teaching bay outside the investigation area. She guides the exercise. Her presence, appearance and idle gestures are not clues about what happened in the case.
People in this scenario
  • The investigator checks recipient scope. The coordinator receives the result and records replacement authority before sealing. These are assigned responsibilities, not actions performed by Mara.
What counts as evidence
Use the superseding notice, unchanged identity record, revised order and acknowledged stop condition. An open route is not release authority.
Why the objects are here
The before/after boards represent plan versions. They do not prove permission was granted, a case was sealed or a delivery occurred.
An original academy with bronze arches, a central mechanism and illuminated workbenches.
SLOPU · GUIDED WORKED EXAMPLE

Operations Studio

Watch the complete alternate example. Take control of the equipment whenever you are ready.

An alternate example · separate from your assessed work
How to move, inspect and complete the activity

Use WASD or arrow keys to walk. Press E near an instrument to examine it. Inspect means read its details; Use equipment performs the action named in its status message. The task controls let you choose exact settings and test a solution. Once verified, use the mission station to put it into effect, collect the resulting evidence or cargo, follow its checkpoints and complete the handover at the receiving station.

Scroll over the scene or use Zoom + / Zoom − for a closer or wider view. Click and drag to turn whenever the cursor is free. Choose Fullscreen mission to keep the scene, mission instructions and all task controls together. Fullscreen starts with a free cursor so you can scroll the panel and choose options. Press X or Lock cursor (X) to turn by moving the mouse. Press X again to free the cursor and return to click-and-drag turning. Tab also frees the cursor. The X shortcut stays inactive while typing or choosing a form value. Press Escape or Exit fullscreen to return to the page. On touchscreens, drag to look and use the zoom buttons. If your browser cannot enter native fullscreen, the mission expands to fill its window.

Choose Watch to follow the worked example, or Take control to try it yourself. The transcript and completed example remain available if 3D is unavailable. Demonstrations never change assessed progress.

01 / 6
Before we beginYour worked-example briefing

I must revise a dispatch plan after its old authority is withdrawn. The routes stay open and equipment remains valid. I will preserve Version One, identify the new permission prerequisite, assign its checks and reorder the plan so authority is recorded before sealing. The method we are practising is: Preserve valid decisions and revise only dependencies invalidated by new evidence.. Our field objective is: Dispatch under the replacement authorisation rule while preserving Version One. The routes and equipment still work, but the old permission no longer authorises dispatch. The investigation and explained record complete this lesson. A scene delivery is an optional extension. You can pause, mute, replay, or take control at any point. The captions show the same explanation.

Narration starts after you choose Watch or Play. Captions remain available if this browser has no working voice.

Optional scene extension

Each chapter provides evidence for this operation. Inspect, investigate, act, and complete the handover.

FIELD OPERATION · Briefing

Operation Revised Authority

Dispatch under the replacement authorisation rule while preserving Version One.

The routes and equipment still work, but the old permission no longer authorises dispatch.

Inspect the mission station to begin your investigation.

Nothing collected.

Mission actions become available when the activity loads.

Mission record and accessible controls

These controls perform the same actions as the marked stations in the scene. Use them with a keyboard or touch, or when graphics are unavailable. Equipment tests establish whether your intervention is supported. The final handover records a mission outcome; your explanation is assessed separately.

  1. No mission actions yet.

The complete transcript and finished example are available below while the player loads.

THE DEMONSTRATOR’S REASONING

Preserve the originally authorised sequence

Under the original release authority, Version 1 reads: verify ledger, seal case, dispatch case, log receipt. The route is open and equipment checks are valid. The demonstrator preserves this plan before reading the replacement notice.

Why this matters

A useful revision needs an honest original plan and the authority under which it made sense.

A plausible mistake

Pretending the extra checks were always in Version 1 destroys the comparison.

YOUR LEARNING CONTROLS

Make the skill your own.

Arrange Version 1 under its original authority.

Watch the apparatus change as the student demonstrates. Take control whenever you want to test the same idea yourself.

BASED ON YOUR ATTEMPTS

Watching and practising are recorded separately in this visit. These examples do not change your assessed work or skills passport.

NOW TRANSFER THE SKILL

Carry the method into your own work.

This example changes authority while leaving equipment intact. Your disruption concerns availability and needs different replacement evidence.

Week 11 lab ↗

Restart this worked example?

This clears its practice record for this visit. Your course passport and assigned activities stay saved.

A COMPLETE WORKED SUBMISSION

When the release authority expires — completed record

Example work from this demonstration's scenario. Use it to understand the expected evidence and explanation, then make your own decisions in the assigned activity.

Download the complete example
Read the finished work

Completed demonstration example — release-authority revision memo

Authored alternate example. Every route stays open. The disruption changes an authorisation dependency rather than equipment or transport availability.

Version 1 and its authority

Verify ledger → Seal case → Dispatch case → Log receipt.

The original release authority permitted this order. Ledger identity and equipment checks were supplied as valid; the plan was preserved before the replacement notice.

Published disruption

The replacement notice withdraws the old dispatch authority. Before sealing, the investigator must compare the recipient’s request with this ledger’s identity and purpose. The coordinator must record the new authorisation. Neither open routes nor working equipment removes those conditions.

Diagnosis and retained evidence

The failed dependency is the old authority to seal and dispatch. The unchanged signed ledger comparison remains useful for identity. Equipment remains available. Neither finding establishes that the recipient’s current request covers this ledger. No route change is required.

Version 2

Verify ledger → Check recipient scope → Record new authorisation → Seal case → Dispatch case → Log receipt.

The investigator owns scope comparison and sends the result to the coordinator. The coordinator records authority and authorises sealing only when both prerequisites are met. If scope is unresolved or authorisation absent, stop before sealing. The route, verified identity and receipt obligation remain unchanged.

Communication and status

The coordinator reads back the new order and stop condition; all roles acknowledge them. Version 1 stays preserved. This memo records a revised plan, not an invented completed authorisation or dispatch.

Reflection

My first temptation was to choose another route, but availability was not the dependency the notice changed. The important change was the point at which permission had to be established. Adding a scope check after dispatch would mention the new rule without satisfying it. I kept the identity evidence, named an investigator to check scope, and made the coordinator receive and record the result before sealing. In the assigned route or meter disruptions I must identify their different failed dependency instead of copying this sequence.

Named output: revised-plan. No physical dispatch or grant of authority is claimed.

Method to carry forward

Preserve valid decisions and revise only dependencies invalidated by new evidence.

This example changes authority while leaving equipment intact. Your disruption concerns availability and needs different replacement evidence.

The complete example explains one defensible approach. In your own challenge, select observations and tests from the supplied rules, keep your prediction separate from the result, and justify both the checks you perform and those you omit.

The chapter investigation and its explained record complete the core method. The scene delivery is an optional extension; it is not evidence of deeper understanding on its own.

Complete transcript and decisions · readable without JavaScript

Before we begin · expected task and evidence

I must revise a dispatch plan after its old authority is withdrawn. The routes stay open and equipment remains valid. I will preserve Version One, identify the new permission prerequisite, assign its checks and reorder the plan so authority is recorded before sealing. The method we are practising is: Preserve valid decisions and revise only dependencies invalidated by new evidence.. Our field objective is: Dispatch under the replacement authorisation rule while preserving Version One. The routes and equipment still work, but the old permission no longer authorises dispatch. The investigation and explained record complete this lesson. A scene delivery is an optional extension. You can pause, mute, replay, or take control at any point. The captions show the same explanation.

1. Preserve the originally authorised sequence

What I need to do: Step 1. Preserve the originally authorised sequence. I preserve the original sequence under its original authority before reading the change.

Supplied context: Under the original release authority, Version 1 reads: verify ledger, seal case, dispatch case, log receipt. The route is open and equipment checks are valid. The demonstrator preserves this plan before reading the replacement notice.

Watch my actions: I arrange "Original plan" in this order: Verify ledger, then Seal case, then Dispatch case, then Log receipt. I check the demonstrated result.

What I observed: The baseline remains visible as an earlier justified plan. It is not rewritten with later knowledge. A useful revision needs an honest original plan and the authority under which it made sense.

Why: A useful revision needs an honest original plan and the authority under which it made sense.

Decision: Arrange Version 1 under its original authority.

  • Original plan: Verify ledger → Seal case → Dispatch case → Log receipt

Result: The baseline remains visible as an earlier justified plan. It is not rewritten with later knowledge.

Common mistake: Pretending the extra checks were always in Version 1 destroys the comparison.

2. Find the failed authority dependency

What I need to do: Step 2. Find the failed authority dependency. I locate the newly invalid permission dependency; there is no closed passage to work around.

Supplied context: A published replacement notice withdraws the old dispatch authority. Before sealing, an investigator must check that the recipient’s request covers this ledger, and a coordinator must record the replacement authorisation. Routes remain open and equipment readings remain valid.

Watch my actions: For "Failed dependency", I choose "Old release authority". I check the demonstrated result.

What I observed: The notice invalidates the old permission to proceed, not the route or verified ledger identity. An available route does not authorise an action; dependencies include authority as well as hardware.

Why: An available route does not authorise an action; dependencies include authority as well as hardware.

Decision: Which dependency has become invalid?

  • Failed dependency: Old release authority

Result: The notice invalidates the old permission to proceed, not the route or verified ledger identity.

Common mistake: Searching for a west-route detour solves a problem this notice does not contain.

3. Carry forward evidence within its scope

What I need to do: Step 3. Carry forward evidence within its scope. I retain identity and equipment findings only for the questions they answer.

Supplied context: The signed ledger comparison is unchanged, and equipment checks remain valid. Those findings can be retained, but neither proves that the recipient’s current request includes this ledger. That authorisation question remains open.

Watch my actions: For "Retained finding", I choose "Signed ledger identity check". I check the demonstrated result.

What I observed: The team keeps justified work without treating identity evidence as permission. Preserved evidence is useful only for the question it answers.

Why: Preserved evidence is useful only for the question it answers.

Decision: Which finding remains valid without establishing the new authority?

  • Retained finding: Signed ledger identity check

Result: The team keeps justified work without treating identity evidence as permission.

Common mistake: Restarting every equipment test is unnecessary; skipping the new scope check is unsupported.

4. Assign the authorisation checks

What I need to do: Step 4. Assign the authorisation checks. I name the investigator as scope checker and the coordinator as the recipient who records authority before sealing.

Supplied context: The investigator compares the recipient’s signed request with this ledger’s identity and purpose. The coordinator receives that result and records the new authorisation before anyone seals the case. An unanswered scope question stops sealing.

Watch my actions: For "Scope-check owner", I choose "Investigator". I check the demonstrated result.

What I observed: The investigator owns scope comparison; the coordinator records authority and releases the next step. A prerequisite needs both a checker and someone who receives the result.

Why: A prerequisite needs both a checker and someone who receives the result.

Decision: Who checks the recipient’s scope?

  • Scope-check owner: Investigator

Result: The investigator owns scope comparison; the coordinator records authority and releases the next step.

Common mistake: Assigning the check to everyone without a named recipient leaves the dependency unresolved.

5. Put the new prerequisite before sealing

What I need to do: Step 5. Put the new prerequisite before sealing. I insert the two prerequisites before sealing rather than appending them after dispatch.

Supplied context: Version 2 keeps ledger verification, then checks recipient scope and records the new authorisation before sealing. Dispatch and the receipt follow on the same open route. The original four-step plan remains unchanged beside it.

Watch my actions: I arrange "Version 2" in this order: Verify ledger, then Check recipient scope, then Record new authorisation, then Seal case, then Dispatch case, then Log receipt. I check the demonstrated result.

What I observed: The revised order addresses the actual dependency. A check after dispatch would not satisfy the notice. A revision must change the order governing action, not append a warning after the dependent step.

Why: A revision must change the order governing action, not append a warning after the dependent step.

Decision: Arrange the revised plan so authority precedes sealing.

  • Version 2: Verify ledger → Check recipient scope → Record new authorisation → Seal case → Dispatch case → Log receipt

Result: The revised order addresses the actual dependency. A check after dispatch would not satisfy the notice.

Common mistake: Appending authorisation at the end leaves the unsupported action unchanged.

6. Confirm the new stop condition

What I need to do: Step 6. Confirm the new stop condition. I read back the changed order and stop condition and distinguish an acknowledged plan from a completed operation.

Supplied context: The coordinator reads back the revised sequence: no sealing until the investigator confirms scope and replacement authorisation is recorded. The team confirms it will use the same route after that gate is met. This is a revised plan, not a claim that dispatch has happened.

Watch my actions: I set "All roles know sealing waits for the new authority" to yes. I check the demonstrated result.

What I observed: The record identifies authority, order, owner, communication and the still-unexecuted action. Everyone needs the same current action condition; a revised document alone does not establish shared understanding.

Why: Everyone needs the same current action condition; a revised document alone does not establish shared understanding.

Decision: Confirm the new sequencing and stop condition.

  • All roles know sealing waits for the new authority: Yes

Result: The record identifies authority, order, owner, communication and the still-unexecuted action.

Common mistake: Treating acknowledgement as proof that authorisation was granted invents a result.

Optional field extension

All chapter evidence checks are complete. I return to the mission station and activate the revised plan. I am putting the verified solution into effect, then checking what changes.

I collect Version One and Version Two dispatch record. The verified intervention released this package. I now carry it through the marked handover route.

I carry Version One and Version Two dispatch record to Authorisation register. I confirm this checkpoint before continuing so the handover trace records the route actually followed.

I carry Version One and Version Two dispatch record to Revised dispatch station. I confirm this checkpoint before continuing so the handover trace records the route actually followed.

At the receiving station, I deliver the versioned dispatch record. I check the receipt before calling the field operation complete.

My observations and finished submission

The new notice invalidated the old authority, not the route or signed identity result. Version Two checks recipient scope and records replacement authorisation before sealing, then uses the same dispatch route and receipt step. The investigator checks scope; the coordinator receives the result and records authority. Both versions and the stop condition remain visible, without claiming that dispatch or authorisation has already occurred. Preserve valid decisions and revise only dependencies invalidated by new evidence. Open "Read the finished work" or download the complete example to inspect the evidence and explanation together. This example changes authority while leaving equipment intact. Your disruption concerns availability and needs different replacement evidence.

The complete submission is available in Read the finished work above and as a Markdown download.

← All worked examples

SLOP UNIVERSITY · THE ACADEMY OF IMPOSSIBLE SKILLS
An original fictional course. Progress records practice, not academic certification.