Six Fields Beginners Should Document Before AI Automation

Six documentation fields can expose whether an AI process is ready for automation before it can send, publish, pay, delete, or change anything. Write down the input, expected output, exceptions, human review, recovery path, and owner with a stop rule. If you cannot complete one field, keep that part manual. This card is a Builderlog teaching device, not an official compliance template. It helps beginners make a process reviewable; it does not prove that the process is safe, accurate, compliant, or worth automating.

Here is the short answer:

Document what enters and what should leave.
Define what requires human judgment and how failure is reversed.
Name the person who can stop the process before testing automation.

The tempting shortcut hides the real work

A beginner often starts with the visible task: “Use AI to prepare this report.” That sentence describes an ambition, not a process.

It does not identify where the source material comes from. It does not explain what happens when information is missing. It says nothing about who checks the result, what counts as acceptable, or how to recover from a bad output.

Those omissions matter because automation can make an unclear process run faster without making it easier to review.

The evidence reviewed on 2026-08-16 supports documenting the process before automating it. The NIST AI Risk Management Framework Core connects documentation with transparency, human review, and accountability. Its human-AI interaction appendix treats human oversight and process definition as explicit parts of risk management.

Public request-for-information workflow guidance also describes a useful pattern: when an input is missing or uncertain, the workflow requests information and waits for human input, review, or action.

These sources provide principles and patterns. They do not certify the six-field card below or establish that a particular workflow is safe.

An automation plan is incomplete until a person can identify the source, exception, output, and stop rule.

The six-field card makes the process visible

Use one card for one bounded task. Do not begin with an entire department, client journey, or publishing system.

Field	Question to answer	Minimum useful detail
1. Input	What enters the process, and where does it come from?	Source, required fields, accepted format, and how freshness is checked
2. Output	What must the process produce?	Deliverable, destination, required structure, and acceptance criteria
3. Exceptions	What prevents normal handling?	Missing, conflicting, sensitive, unusual, or unsupported inputs
4. Human review	What must a person verify before action?	Reviewer, evidence checked, pass criteria, and rejection path
5. Recovery	What happens after a wrong or incomplete result?	Pause, correction, rollback, record retention, and escalation route
6. Owner and stop rule	Who is accountable, and when must the process stop?	Named role, review responsibility, stop condition, and restart authority

Artifact caption: The six-field process card separates normal flow, human judgment, and recovery before automation is introduced.

The fields are deliberately plain. A beginner should be able to fill them without learning workflow notation first. Technical diagrams can come later if the card reveals a process worth keeping.

A fictional example shows where judgment lives

Consider a fictional convenience-store BOGO deals app. Its operator wants AI to turn an approved, non-sensitive product sheet into a draft deal summary.

The first test must stay low-risk. It should use fictional or otherwise approved data. It must not send a message, publish a page, make a payment, delete a record, or change permissions.

The card might read like this:

• Input: An approved product sheet containing item name, offer type, and valid dates. Reject the sheet if any required field is blank.
• Output: A private draft with one deal per item, preserving the supplied dates and offer type.
• Exceptions: Missing dates, conflicting offer labels, duplicate items, or text that cannot be traced to the sheet.
• Human review: A person compares every draft line with the source and confirms that nothing unsupported was added.
• Recovery: Keep the source unchanged, discard the draft, record the reason, and return the item for correction.
• Owner and stop rule: The content owner stops the process when a required field is missing, evidence conflicts, or the reviewer cannot verify a claim.

This example does not demonstrate a production result. It demonstrates how to place boundaries around a possible workflow.

The most important sentence is not the instruction to create a draft. It is the rule that prevents an uncertain draft from moving forward.

A good exception path asks for information; it does not quietly convert uncertainty into an answer.

Build the card from a real manual run

Start by observing the task as a person performs it. Use a fictional or approved non-sensitive example for the first pass.

First, capture the source exactly as the worker receives it. List required fields separately from helpful context. A URL, inbox, or folder name alone is not enough; explain how the worker knows the source is authorized and current.

Next, save one acceptable output. Mark which parts are copied, transformed, calculated, or judged. Turn subjective phrases such as “make it good” into review questions. Can each statement be traced to the source? Are required fields present? Is the output still a draft?

Then, interrupt the happy path. Remove a required field. Introduce conflicting values. Add an unsupported request. Record what the person does in each case. If the answer is “use common sense,” the exception is not documented yet.

After that, write the human review gate. Identify the evidence the reviewer sees, the conditions for approval, and what happens after rejection. “A human checks it” is too vague because it assigns neither a standard nor responsibility.

Finally, define recovery and stopping before considering unattended execution. Recovery should protect the original input and explain how a rejected item returns to a known state. The stop rule should be observable, not intuitive.

The documentation can still fail

A completed card may create false confidence. The fields can contain vague language, outdated sources, or review criteria that no person can apply consistently.

There is also no verified production outcome in this evidence packet. No cost, revenue, user count, conversion rate, experiment duration, or automation return was supplied. Documentation therefore cannot be presented as proof of improved performance.

The demand evidence is narrow too. On 2026-08-16, a zero-cost autocomplete collection returned the exact query “AI process documentation” with seven suggestions. That indicates query-surface attention only. It does not establish search volume, ranking potential, purchase intent, traffic, conversion, or revenue.

Most importantly, neither the NIST material nor the public workflow guidance determines whether an individual process is legally compliant, secure, accurate, or suitable for automation. Those judgments depend on the target context and qualified review.

Documentation improves inspectability, but inspectability is not the same as safety or compliance.

The review checklist decides what stays manual

Before automating, give this checklist to the person responsible for the task:

• The input source is authorized, current, and verifiable.
• Required fields and accepted formats are explicit.
• The expected output has observable acceptance criteria.
• Missing, conflicting, sensitive, and unsupported inputs have named exception paths.
• Uncertainty triggers a request for information or a stop.
• A reviewer knows what evidence to compare.
• Approval and rejection criteria are written down.
• The original input remains recoverable.
• A failed output can be isolated without sending, publishing, paying, deleting, or changing permissions.
• One accountable role owns the stop and restart decisions.
• The first example uses fictional or approved non-sensitive data.
• Every automated action remains reversible and reviewable within the test boundary.

My final decision is simple: do not automate a task when any of the six fields depends on an unwritten assumption. Keep that section manual, observe another run, and update the card. Automation becomes a later implementation choice, not the starting point.

Copy the six-field card and complete it for one bounded process before selecting an automation method.

Related build logs

• AI Task Management for Beginners: Five Decisions Before Delegation
• AI Workflow for Beginners: A Five-Box Map Before Automation