Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Libraryari os / 2026-10-03

Build Your Team: The Work Comes First

Define the work, its dependencies, and its checks before assigning a human, a script, or a model. Three interactive labs make the handoffs visible.

7 parts / Hover to explore. Click to read.

Define the work, its dependencies, and its checks before assigning a human, a script, or a model. Three interactive labs make the handoffs visible.

Accepted input + revision
           |
         stage
           |
      output + check
           | accept
           v
      next receiver
Input changes? Review dependants.
Assign owners after defining the inputs, outputs and acceptance checks. Correct stage order does not establish that a dependent artefact uses the current accepted input.
Stage And Owner WorksheetContext Pack (for agents)

Before you choose the team, draw the work.

I still use a notebook for this. In a conversation on 25 September, I explained why: a request such as "make a video and publish it" hides several different jobs. I need to see how they connect before I can sensibly hand them out.

Later, someone asked which question about my work I find uncomfortable. My answer was "Why did you do it that way?"

Put that question before the organisation chart. What comes into each stage? What should come out? Who uses it next? What would make us accept it?

Once those answers are visible, choosing an owner becomes much easier.

Work first. Team second.
The work contract

Give the work a shape.

Define what arrives, what leaves, who receives it, and how you check it.

Bounded taskProduce narrationRead the approved text.
Input / Example artefactScript.txt
The harbour opens at dawn.Harbour: HAR-buh

Start from an agreed source.

Approved text and pronunciation notes define what the voice task can use.

Illustrative voice task. Select a field to inspect the work contract and the artefact it describes.

Turn the outcome into observable work

"Make a video" is a useful outcome to discuss. It is not yet a workable handoff. Someone still needs to write the words, record them, align the transcript, make the animation and release the accepted cut.

Another participant in that September conversation used this sequence: Script → Voice → Timed Transcript → Animation → Publish. I am borrowing it as an illustration. It assumes the animation follows the recorded voice and its timings. Other productions can organise their dependencies differently.

StageInputOutputNext receiverAcceptance check
ScriptAgreed outcome and source factsApproved spoken wordsVoice productionReview claims, meaning and intended delivery
VoiceApproved words and pronunciation notesReviewed audioTiming and animationListen for pronunciation, omissions and delivery
Timed TranscriptThat reviewed recordingWords aligned to its timelineAnimationCompare timings with the same audio
AnimationAccepted audio, timings and visual directionPlayable cutRelease reviewInspect sync, readability, framing and intended effect
PublishApproved cut and destination requirementsIntended public itemAudienceHuman approval, correct destination and live verification

Now each stage has an output you can point to. A role name such as editor does not tell you whether the job is fixing language, cutting audio or judging the visual sequence. The deliverable does.

A person might record the voice. A model might propose it. A script might align the transcript. You still need the agreed output and its check when the owner changes.

Give the next person a usable contract

A handoff is where your output becomes someone else's input. Start with four fields:

  • Input: the accepted artefact and the revision this work can rely on.
  • Output: what this stage must produce, in a form the next receiver can use.
  • Receiver: the person or process that needs it next.
  • Check: observable evidence that lets the receiver accept it.

Then add the required judgement, the accepted prerequisites and the person who owns the decision.

Take the transcript. "A file exists" is not enough. It might be complete, readable and aligned to yesterday's recording.

Name the accepted audio revision. State the time units. Check that timestamps are ordered and within the duration. Then compare sync at meaningful points in that same recording. A parser can reject malformed timestamps; listening or viewing checks a different part of the contract.

The parser reading a file does not establish that the words are right, the recording is current or the visual intention survived. Keep those claims separate so the checks can actually support them.

The receiver also determines the useful context. Voice production needs approved words and pronunciation decisions. Animation needs the right audio and timings. A reviewer needs the playable cut and the brief. They do not each need every conversation that led there.

Enough context means enough to do this job and judge its output.

Order and freshness are different checks

You can have the right stages and still build the wrong sequence.

If animation follows the voice, its timings need to come from the recording it will use. Putting a transcript first cannot establish the timing of audio that does not exist yet. If that accepted audio changes later, revisit the dependent transcript and animation.

Move the stages in the lab. Its checks apply to this example's prerequisites. An unusable transcript stays unusable even if Animation appears after it; moving the downstream box does not repair its input.

Stage order lab
Order follows dependencies

Move a stage. Trace the effect.

Use the arrow controls to change the order.

  1. Script

    Approved words

    Starts from the brief

    Ready

  2. Voice

    Spoken audio

    Requires Script

    Ready

  3. Timed Transcript

    Words aligned to audio

    Requires Voice

    Ready

  4. Animation

    Visuals aligned to words

    Requires Timed Transcript

    Ready

  5. Publish

    Reviewed release

    Requires Animation

    Ready

All five stages have valid prerequisites.

One illustrative workflow. Other video workflows can use different stages and dependencies. Here, a stage needs its predecessor to be earlier and valid.

This is a dependency graph. An edge means the job needs a particular accepted output. It means more than proximity on the page.

Our example is a chain. A larger project may branch: visual research and script development can proceed separately when each has the accepted material it needs, then meet for an agreed direction. Parallel work helps when the jobs can genuinely proceed from their own inputs.

Keep two failure types visible:

  1. Order: the required input has not been accepted yet.
  2. Staleness: it was accepted, but downstream work used a revision that is no longer current.

A correct sequence cannot detect yesterday's captions by itself. Record the output, its input revision, its acceptance state and the person responsible for acceptance. When an input changes, mark dependent work for review. Retain the earlier artefact until the replacement is accepted so you can inspect the change.

Match the owner to the judgement

Some work follows an explicit rule. A script can check timestamp ranges, place an approved file into a delivery structure or verify that an output exists. Its contract still needs to handle missing, malformed and already-processed input.

Other work needs interpretation. Which framing carries the idea? Does this line say what we mean? Does the cut feel right? A model can propose options and explain its reasoning; a human defines the outcome and owns the consequential judgement she accepts.

Often the stage needs both. A script checks transcript structure while a listener checks words and sync. A model proposes a treatment while a person decides whether it serves the brief. Saying "the model owns it" leaves too much unresolved.

Use the lab to inspect the responsibility, then compare human, script and model ownership and the oversight each choice needs.

Work owner lab
Responsibility before role

Assign the work, then keep the judgement visible.

Assign the work
Input
Source notes and brief
Output
Approved script
Judgement
Choose the message, structure, and emphasis.
Check
Read for accuracy, omissions, and spoken flow.
Oversight contract

Model owner / Approved script

A model can propose a result within the brief. A human reviews the generated result, including its claims and choices.

Models never grant their own publishing permission.

Human release approval remains required before publishing.
Assign one responsibility and inspect the oversight it still needs. Ownership does not remove review or human release approval.

Responsibility needs a boundary. Permission to propose a cut is not permission to publish it. A successful command is not editorial acceptance. The application and the person operating it grant authority to act.

The same applies to data. Markdown, CSV and database rows organise information. They do not decide which information a model can read or change. Retrieval choices, tool permissions and access controls do that.

Write down who can propose, transform, accept and release. One person may hold several jobs. Making them explicit still shows where oversight belongs.

Check the handoff before building on it

In that September conversation, I said people often skip checking the intermediate steps: "They just test the end."

By the end, the downstream work has consumed whatever went wrong. A final reviewer can catch bad pronunciation in the cut. A listen at the voice stage could have caught it before animation used the recording.

The next lab contains two simple defects. Choose one and switch intermediate checks on or off. It shows the first applicable check in the simulation. A timing comparison does not discover a pronunciation error merely because its box appears earlier.

Step check lab
Check where a defect becomes visible

Catch it before it travels.

Switch checks off to trace the earliest remaining check that examines this defect.

Local checks

Voice

Pronunciation listen

Catches this defect

Timed Transcript

Timing against audio

Different defect

Animation

Speech listen and sync preview

Relevant check
Voice pronunciation

Caught at Voice pronunciation listen.

Transcript timing check does not inspect pronunciation.

Final human release check always active.
These bounded checks illustrate two defects. They don't prove every part of a video is correct. A final human release decision stays in the workflow.

Name the failure you intend to detect. "Check the output" is vague. "Listen to this word in the accepted recording" or "compare this caption transition with the audio" gives the check a bounded job.

Three layers help:

  1. Structure: does the artefact exist, parse and match its declared form?
  2. Relationship: does it use the accepted source and revision?
  3. Outcome: does it serve the next receiver and the intended result?

They can overlap without becoming interchangeable. Correct subtitle syntax does not prove the right audio was used. Good sync does not prove the tone works. A beautiful cut may still be unreadable at delivery size.

The lab detects only the defects it models. It is not a production certificate, a performance measurement or a replacement for final human review.

When a check fails, hold acceptance at that boundary. Keep the failed output for diagnosis, send a concrete failure back to its owner and rebuild the affected work from accepted inputs. Otherwise another full run may simply repeat a problem nobody has named.

Start with one stage you can defend

Use the stage and owner worksheet. Write one outcome, one deliverable and its receiver. Then describe the first stage's accepted input, output, check and permitted decision.

Leave the owner open until you understand the judgement. If a rule can do the transformation, state it. If someone must choose between interpretations, name that choice and the evidence for accepting it.

Follow the output into the next stage. Can the receiver use it? Can you identify what becomes stale when the input changes? Does a failed check have a bounded route back? Would the contract still make sense with a different person or model doing the job?

That is what the map is for. Enough room to solve the work, enough definition to judge what comes back.

Stop prompting. Start defining outcomes.

Draw the work. Make its handoffs visible. Build the team around that.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 9