A builder AI manual fallback drill rehearses how a responsible person prepares buyer updates when AI drafts are unavailable or unreliable. Use a copied queue, approved source notes and a written run card. Hold uncertain drafts, assign manual work and reconcile every item before deciding whether drafting can resume under normal human review.
This AgAI Labs guide proposes a practice worksheet. The fictional exercise below reports no actual outage or recovery result. Run it away from production accounts. Simulate missing output with a marked placeholder in a copied queue. Do not disconnect a service, submit a buyer message or activate automation.
When should the AI workflow stop?
Write the stop rule before the exercise. Hold drafting when output is missing, the project reference is wrong or the approved source cannot be identified. A readable paragraph does not clear a source conflict. Record the observed condition without guessing whether a provider, connection or instruction caused it.
Define the boundary of the hold. For this drill, the weekly-update drafting queue stays paused in the practice copy. Record which items were waiting and which had already passed review. Label any output that appears later as held. A late draft needs reconciliation before anyone uses it.
Keep ordinary project work under its existing authority. The drill does not grant permission to send messages, change schedules or make buyer commitments. The AI operations stage explains why the task needs written rules, a reviewer and a manual fallback.
The NIST AI RMF Playbook, MANAGE 2.1 and 2.4, discusses non-AI alternatives and documented bypass responsibilities. This builder run card is a proposed practice, not a NIST template or certification.
Who carries the task manually?
Assign a specific responsible person in the private run card. Record their staff identifier and acceptance of the task. A department label alone leaves the handoff unclear. Name a backup through the same internal process if the primary person cannot accept. Keep personal identifiers out of shared practice examples.
The manual owner assembles the update. The project reviewer verifies field facts. The usual release authority decides whether a real message may leave. One person may hold several roles, but the card records each role separately. A manual handoff changes the drafting method, not approval rights.
Give the manual owner the approved notes, current selection record and approved update format. Include project identifiers and source revisions. If the AI interface is unavailable, the fallback source must still be accessible through the builder's authorized records. Record inaccessible sources as exceptions rather than copying private files into a new tool.
- Match the update identifier to its project and reporting period.
- Read the approved source notes and identify any superseded revision.
- Write completed work, current activity, open decisions and constraints in separate sections.
- Mark missing facts for the project reviewer without inferring progress or causes.
- Compare each statement and attachment reference with the approved source.
- Save the manual draft for ordinary review and record its status in the run card.
The weekly buyer-update drafting method supplies the content checks. During this exercise, use synthetic notes and record a simulated release decision. Nothing goes to a buyer.
Which records belong in the fallback run card?
Copy this worksheet into the builder's existing controlled workspace. Use one card per drill and one row per update in the queue table. Keep evidence references readable to the next authorized reviewer. A filename alone needs its revision and project context.
MANUAL FALLBACK RUN CARD Mode: practice drill / actual incident Drill identifier and workflow version: Task and reporting period: Trigger observed and observation time with timezone: Held queue location, snapshot time and item identifiers: Last reviewed record: identifier, revision and status: Manual source: approved notes, revision and approval evidence: Responsible person: staff identifier and accepted handoff: Project reviewer and normal release authority: Draft status for each item: Exception, question owner and next review point: Restart decision: hold / revise and retest / accept limited test: Decision owner, scope, time and supporting evidence: Separate production authorization reference, if applicable:
| Queue item | Held draft | Manual draft status | Exception | Next action and evidence |
|---|---|---|---|---|
| [Update ID, project, period] | [Revision or no output] | [Assigned, drafted, reviewed or completed] | [Open question or none] | [Owner, disposition and record reference] |
Define completed precisely. A drafted update awaits review. An approved update may still await release. A released update needs its final version and release record. In practice mode, prefix those statuses with simulated. Never let a rehearsal row appear to prove that an actual message was sent.
What does a fictional filled card show?
Drill F-01 covers fictional weekly updates U-41, U-42 and U-43. The trigger is a missing-output placeholder. The held queue is copy Q-01. The last reviewed record is U-40 revision 2, marked complete in the exercise. No live tool is disabled.
The manual source is synthetic field-note set FN-12 revision 3. Office coordinator OC-1 accepts manual drafting. Project reviewer PR-1 checks facts. Release authority RA-1 records simulated decisions. These role identifiers represent fictional people, not shared logins or permission grants.
For U-41, the approved note says framing work continues and a finish choice remains open. The manual draft preserves both statuses. It makes no completion claim. U-42 contains conflicting selection notes, so PR-1 receives the exception. U-43 has complete notes and waits behind the assigned review work.
How do you avoid duplicate work during recovery?
Reconcile by update identifier, project and reporting period. Compare the held snapshot with manual drafts and the final record. Do not rely on filenames such as latest or final. A returned AI draft does not become a new task merely because it arrived after manual work started.
In the fictional exercise, a late AI draft for U-41 appears in Q-01 after its manual version receives simulated release. Mark that late draft superseded in the practice register. Preserve its reference for comparison. Do not put U-41 back into pending work.
| Fictional item | Reconciliation finding | Recorded disposition |
|---|---|---|
| U-41 | Manual version completed; late AI draft held | Keep manual version authoritative; no replay |
| U-42 | Manual draft blocked by source conflict | Keep held; PR-1 resolves notes before redrafting |
| U-43 | Pending review; no completed version | Keep one pending task assigned to OC-1 |
Account for every snapshot item once. Add work received during the hold as separately identified rows. Keep completed items, held exceptions and pending tasks visible. Confirm that each pending row has one owner and one next action. If a release record is missing, mark the outcome unknown and ask the release authority.
Do not replay sends to test whether a message went through. Review the existing release evidence instead. Do not delete an unresolved row to make queue totals agree. Record the mismatch and keep the affected work held until a person resolves it.
What evidence permits a controlled restart?
A drafting restart needs evidence about the failed task and the remaining queue. An available interface or a fluent sample alone does not establish readiness. The small-builder AI tool comparison explains testing the workflow's sources, review holds and usable records.
- Confirm the observed trigger has a documented resolution or an accepted boundary for further testing.
- Review a synthetic draft against its approved source and prohibited actions.
- Test missing-source handling and confirm that the affected output remains held.
- Reconcile every held, manually completed and pending item with its evidence.
- Record the decision owner, accepted test scope and conditions that require another stop.
For F-01, RA-1 keeps U-42 held and accepts only a further synthetic drafting test. Evidence includes Q-01, FN-12, the reviewed manual draft and the reconciliation table. This decision does not activate production. Any later production restart needs separate authorization under the builder's normal controls.
If a source conflict, unknown release status or unassigned item remains inside the proposed restart scope, keep that scope held. Record what must change and who will check it. Save the drill card with its evidence and unresolved actions in the existing authorized workspace.
What else should you check before a fallback drill?
Can we rehearse without taking the AI service offline?
Yes. Use a copied queue and a missing-output placeholder with synthetic notes. Keep live services and buyer communication outside the exercise.
What if approved notes are unavailable too?
The manual owner records a source-access exception and routes it to the project reviewer. Manual drafting does not authorize guessed facts or wider data access.
Does a completed manual draft authorize sending?
No. A completed manual draft still follows the builder's usual fact review and release authority. Practice decisions stay simulated.
Does a successful drill prove a recovery time?
No. A drill records performance under its stated practice conditions. It provides no recovery deadline, availability guarantee or permission for automatic restart.
Find the broader process references in the builder guides directory.