# Requirement, native file and review inputs

Check the exposed field formats, units, bounds and required evidence, then resolve the actual refusal before recording work.

Source: https://help.smartfact.ai/manuals/automation/input-reference

Review edition: 25 October 2026

Roles: author, reviewer, supervisor, viewer

Use this reference for requirement text, native source selection, supported file inputs and review decisions. Author prepares changes; an eligible independent Reviewer performs review. Native product permissions and validations remain authoritative as well as Automation's own roles. A saved requirement, uploaded file or successful proof is not an activated release.

## Record the requirement and exact source

| Field or control | What to enter | Checks and limits | If it is refused |
| --- | --- | --- | --- |
| Title | A short name identifying the required decision. | Required. The screen permits 160 characters, while retained requirement text is limited to 160 UTF-8 bytes. An empty entry or one containing only spaces is refused. | Keep the decision identifiable and within the byte limit; non-ASCII characters may use several bytes each. |
| What should happen? | The complete intended decision, information needed and behaviour when information is missing. | Required, at most 8,000 UTF-8 bytes in the service although the textarea allows 8,000 characters. | Preserve meaningful conditions and missing-information behaviour; resolve open questions rather than inventing an answer. |
| Product | Select the intended enabled native product. | Only connections enabled for this installation are offered. Current native access is checked separately. | Ask the Owner about an unavailable connection or grant. Do not select another product to bypass it. |
| Draft or procedure reference | Copy the exact reference from the owning product. | Required. The read reference is limited to 128 characters, beginning with an ASCII letter or digit; remaining characters may be ASCII letters, digits, dot, underscore, colon, at sign or hyphen. | Check the product's actual reference and intended site. Use a displayed selection where the product offers one. |
| ConfigSheets document format, where offered | Use the format associated with that prepared Data revision. | Original retained format, Version 2 and Version 3 have different supported contexts. Changing the source clears previously loaded work. | Return to the prepared revision/context supplied by Data; do not relabel an old document as another format. |

Saving a new requirement revision does not silently update a pending submission. Current exact revision and contributor history are checked at submission and review. Follow [Requirements and plans](/manuals/automation/requirements-and-plans) and [Product context](/manuals/automation/product-context).

## Supply a complete document or expected cases

Use the product's readable editor where offered. An advanced file input is a complete native document or complete expected-case set, not a free-text requirement or a fragment with missing fields. Products can require their own structured forms, source basis and independent review before a candidate exists.

| Field or control | What to enter | Checks and limits | If it is refused |
| --- | --- | --- | --- |
| Import a prepared complete revision, where offered | A valid JSON object containing the complete supported native revision. | The inline picker accepts files no larger than 200,000 bytes. A top-level list is not a complete revision object. | Correct the prepared file against the owning product's contract; do not remove required facts simply to fit. |
| Import complete expected cases, where offered | A JSON array of complete independent cases, or an object with a cases array. | The inline picker has the same 200,000-byte ceiling. A syntactically valid list still needs the native product's complete case schema and independently established expected results. | Correct the case document from its independent basis. Candidate output is not an acceptable substitute for expected answers. |
| A product-declared complete-file transfer | The whole supported configuration, rule change or case file in the offered transfer control. | The control shows that product's declared maximum. Uploading stages the file; saving it is separate. Do not assume the inline picker's limit applies to every transfer. | Use the displayed complete-file procedure. Check an uncertain original file request before uploading or saving another. |
| Frozen case-set reference | The exact retained case-set identity used by this candidate. | Some product workflows fill it as read-only. It must match the frozen candidate and proof, not just a similarly named set. | Load the actual retained evidence again; do not invent a reference or edit a locked value. |

Keep exact codes, decimal text, units and independently supplied outputs intact. Native validation can reject unsupported fields, missing facts or an inappropriate source even when JSON parses successfully. Use [Native drafts](/manuals/automation/native-drafts), [Independent cases](/manuals/automation/independent-cases) and [Proof and release](/manuals/automation/proof-and-release).

## Explain and record the exact review

| Field or control | What to enter | Checks and limits | If it is refused |
| --- | --- | --- | --- |
| Decision | Choose Approve, Request changes or Reject for the exact whole submission. | The central decision must agree with its native product review. Current release contributors cannot independently approve their own contribution. | Resolve the actual difference or choose an eligible independent reviewer; do not change identities to bypass the check. |
| Review explanation | The factual reason for that decision. | Required and not empty or spaces only. Maximum 1,000 UTF-8 bytes for retained central review, despite the 1,000-character textarea. Native and central review decision and explanation must match exactly. | Check the original reviewed reason, including spelling and spacing, and its byte limit. A different reason needs the proper review path. |

Review and activation require recent second-factor verification where the action demands it. A refusal caused by changed authority, source, recovery or release evidence is not fixed by changing field text. After an interrupted effect, preserve the original request and use the recorded outcome controls in [Activation and recovery](/manuals/automation/activation-and-recovery).