A workflow that only works when the original experimenter is in the room is not a workflow. It is a personal habit with witnesses. This post describes the smallest set of roles and the shortest weekly sequence that have let a two- or three-person team regenerate the same MiniMax H3 Turbo and LoRA results on a Monday morning without the original author present.
A Monday That Worked
The shared folder contained four active recipe cards. Overnight a host update had landed. The morning sequence took twenty-two minutes:
The designated probe runner opened the two cards marked “re-probe after host change.”
Both probe sets cleared at the published strengths.
A one-line note went into the team channel: “Host update cleared. All active recipes still green.”
A new operator, onboarded the previous Friday, generated three matching frames for a client revision using only the recipe card. No clarifying questions were required.
Nothing heroic happened. The system absorbed a model-host change and a personnel change without drama. That is the definition of Monday-proof.
A Monday That Failed (and What It Taught Us)
Three months earlier the same team hit a different Monday. One operator had quietly raised a character LoRA strength “just a little” for better detail on a Friday afternoon. The change was never logged. Over the weekend a second operator used the published card, got drifted faces, and spent two hours diagnosing a problem that did not exist in the official recipe. By the time the original change was discovered, a client deadline had slipped.
The failure was not technical. It was a missing role and a missing communication rule. After that Monday we made three permanent additions:
No strength or prompt-block change enters production without a log entry and a re-probe.
Every active card has a named owner who is responsible for answering questions about it.
Model or host changes trigger an automatic re-probe of every active recipe before any production use.
Roles That Survive Absence
We use three lightweight roles. They can rotate; the existence of the roles cannot.
Role | Responsibility | Failure mode if missing |
|---|---|---|
Card owner | Keeps the recipe card current; answers questions | Knowledge lives in one person’s head |
Probe runner | Executes the weekly or post-update probe sets | Silent drift goes undetected |
Change announcer | Posts one-line updates when cards are added, retired, or altered | Team works from stale assumptions |
A new person should be able to produce a passing probe set from the recipe card alone within one working session. If they cannot, the card is incomplete. We treat that as a documentation failure, not a training failure.
Minimum Viable Stack
For a two-person team the entire system lives in a shared folder of plain-text recipe cards, a simple spreadsheet for probe logs, and a short channel for change announcements. Fancy tools are optional. The discipline of the sequence is not.
When a third or fourth operator joins, the same structure still works. The only addition is a short weekly five-minute review of any probe failures that appeared since the last check. The review is not a status meeting; it is a hygiene pass. Teams that skip it eventually rediscover the same silent drifts the Monday sequence was designed to prevent.
Run the test. Save the settings. Show the failure. A small-team workflow is only real when it survives the people who were not in the room when it was invented.
The Monday sequence itself is deliberately short so that it actually happens. Twenty to thirty minutes for a small shelf is sustainable. Anything longer becomes optional in practice and therefore disappears under deadline pressure. The value is not the time spent on the sequence; it is the absence of silent drift that would otherwise surface mid-client-delivery.
Roles beat hero operators for the same reason. A workflow that depends on one person’s memory or taste dies the first time that person is unavailable. Assigning explicit roles spreads the knowledge and makes absence survivable. The roles can rotate; the existence of the roles cannot. Teams that treat every member as a potential solo operator end up with recipes that only one person can run. Teams that treat the recipe card as the source of truth stay functional even when the original experimenter is offline.
Onboarding a new operator is the real stress test of the system. A new person should be able to produce a passing probe set from the recipe card alone within one working session. If they cannot, the card is incomplete. We treat that as a documentation failure, not a training failure. The first time a new operator regenerates a client deliverable correctly without asking clarifying questions is the moment the workflow becomes real. Everything before that is still a personal method with observers.
The most common team-specific failures I have seen remain the same: silent strength drift when one operator “just knows” a better value, recipe cards that exist only in one person’s notes app, probe sets that are run once and then forgotten after the first success, and new model versions adopted by one person without re-probing shared recipes. Each of these is prevented by the roles and the Monday sequence more than by any technical tool.
No comments yet.