An AI-assisted workflow needs a rule for when to stop starting. If two outputs await review, another is being prepared and a fourth is blocked, a new request should not enter merely because the assistant is idle. The process owner needs to see unfinished work and the human time available to finish it.
The Kanban Guide defines work in progress (WIP) as items between a declared started point and finished point.[1] It connects WIP control to a pull system: start work only when there is a clear capacity signal.[1] MAJLS adapts those ideas into the admission contract below. This is an operating framework for an AI-assisted team, not a complete Kanban implementation or an AI-specific standard.
MAJLS framework: the work-admission contract
Write this contract with the people who prepare and review the work. Keep it beside the queue so a new request faces an observable test.
Define one item and its finish
For an internal design-production team, one item might be a set of responsive crop candidates from one approved image master. Individual crops are outputs of that item, not separate entries that inflate the finish count.
Use these states:
- Ready: a request exists, but preparation has not started.
- Preparing: the team has pulled the item and begun its crop set.
- Awaiting review: the complete candidate set is available to the named reviewer; include review underway here.
- Blocked: an admitted item cannot advance; retain its previous stage, blocker, owner and next check.
- Finished: the reviewer has accepted the internal set and the evidence is stored.
Count preparing, awaiting-review and blocked items as WIP. A return for corrections stays started; it does not reset the age. For this contract, an authorized cancellation has a separate terminal disposition and frees capacity, but never counts as an accepted finish. Record the reason and original timestamps rather than deleting the item.
Internal acceptance does not authorize public use. Keep publication outside this workflow's finish boundary and under its own approval.
Declare controls and a capacity signal
Record a whole-workflow limit, preparation-stage limit and review-stage limit. Preparation occupancy includes items blocked in preparation. Review occupancy includes items awaiting or undergoing review and items blocked after reaching review. Reserve a review place for each actively preparing item; a preparation-blocked item must regain a reservation before resuming. This MAJLS policy makes future review commitments visible.
A manager may choose a different reservation rule, but must write it before using it. Name the reviewer and the review window; an unassigned future reviewer is not capacity.
Google's SRE chapter on interrupts recommends making ticket handling a dedicated role for a manageable period, rather than spreading it across the team.[2] Its context is site reliability engineering. Our adaptation is narrower: protect a declared review window instead of assuming review fits around everyone's other work.
The manager owns limits and exceptions. The Kanban Guide also says acceptable WIP exceptions should be explicit in the workflow definition.[1] Record an exception's reason, approving person, affected item, revised control and expiry. A full queue must not silently defer safety-critical or legally time-bound work: use the organization's human-owned urgent-work route.
Apply the ready-to-start checklist
Pull a ready request only when all these checks pass:
- The approved master, requested outputs and acceptance criteria are complete.
- The task and input access are permitted.
- Admitting it leaves whole-workflow and preparation WIP within their controls.
- Review occupancy plus preparing reservations plus the new reservation fits the review control, and the named review window remains available.
If any check fails, leave the request ready with a reason and next check time. Use measured state, evidence and policy; a model confidence score cannot create capacity or waive review.
Filled example: an internal crop queue
Everything below is illustrative. Items, owners, limits, ages and times are synthetic policy examples, not client records, performance results or recommended benchmarks.
The fictional team uses whole-workflow WIP of 4, preparation-stage WIP of 2 and review commitments of 3. Manager Leila owns the contract. Reviewer Omar has a protected review window today. Snapshot time is 10:00 UTC.
| Item | State | Elapsed age | Owner and next action |
|---|---|---|---|
| C-21 | Preparing | 2 hours | Assistant prepares the permitted crop set; one review reservation |
| C-22 | Awaiting review | 6 hours | Omar checks subject preservation at 10:15 |
| C-23 | Awaiting review | 5 hours | Omar checks the square crop at 10:45 |
| C-24 | Blocked in preparation | 20 hours | Leila requests the missing replacement master; check at 10:30 |
| C-25 | Ready | Not started | Leila holds the new request; check at 11:00 |
There are four started items. Preparation occupancy is two, including blocked C-24. Review occupancy is two; C-21 reserves the third place. C-24 retains its preparation place but must regain a review reservation before resuming. Holding C-25 is justified even if the assistant finishes preparing C-21 early.
Use one daily decision row:
| Check time | WIP and review commitments | Decision | Named owner | Next check |
|---|---|---|---|---|
| 10:00 UTC | WIP 4/4; review 2 occupied + 1 reserved = 3/3; oldest item C-24, 20 hours | Finish C-22 and unblock C-24; do not admit C-25 | Omar reviews; Leila resolves the master | 11:00 UTC |
This row records a plan, not completion. C-25 becomes eligible only after recorded changes satisfy every admission check. Restoring C-24's input does not finish it or automatically release another place. If Leila changes priority, reassigns work or authorizes a temporary exception, preserve that decision visibly.
Consequential approval remains with named human owners: Leila authorizes exceptions and Omar accepts image quality; a separate human release owner approves public use.
Keep a small flow log
The Kanban Guide defines WIP, throughput, work-item age and cycle time against the workflow's started and finished boundaries.[1] Use those same boundaries in a simple log:
| Field | What to record |
|---|---|
| Snapshot WIP | Count started items without a terminal disposition; show blocked items separately |
| Accepted throughput | Count accepted finishes per declared interval; exclude cancellations |
| Item age | Current time minus original start time for each unfinished item |
| Cycle time | Accepted finish time minus original start time for each accepted item |
Add review occupancy, reservations and cancellation counts alongside those fields. Review actual observations with the team before changing limits. A rising oldest-item age warrants examining its blocker and owner; it is not proof that the limit should increase. Avoid forecasts from the synthetic queue above.
Start by counting today's unfinished items, naming tomorrow's reviewer and writing the admission test. At the next check, reconcile every state change with its evidence before pulling another request.