Ingesting Documents

Document ingest is the Discovery input source that turns an unstructured set of existing test documentation into a clean, consistent set of test specifications. Source documents can arrive in almost any format: .docx, .pdf, .xlsx, and archives such as .zip. Document ingest converts them into Markdown test specifications, assesses their health, and repairs common problems along the way.

Blue Yonder focus

Document ingest is presently tuned for Blue Yonder Warehouse Management System (WMS) documentation.

One of two input sources

Document ingest runs on its own track inside Discovery. It produces test specifications and does not answer any questionnaire question. Reach it from the input-source hub rather than from a prompt of its own. Earlier versions of Cycle offered a separate document-ingest prompt, which has been retired.

Why ingest documents?

Test documentation is rarely ready for test automation development. It arrives as a mix of file types written by different people in different styles. It can contain duplicated Scenarios, typos, and inconsistent structure.

Document ingest refines that collection into a clear, consistent set of test specifications. Instead of manually triaging dozens of files, you get:

• A consistent format: Every source document becomes a Markdown test specification with the same shape, so they are clear to scan, compare, and reuse.
• A health assessment: A quick read on the utility of the source material, so you can tell early whether a set of documents is a solid foundation or a rough starting point.
• Duplicate detection: A first-pass analysis that flags overlapping test specifications, so you do not build the same test twice.
• Automatic repairs: Low-risk issues such as spelling are corrected for you, and you are walked through the judgment calls that need a person.

The payoff is confidence. You reach Formulation with source material you understand and trust, rather than a folder of documents you are unsure about.

Ingesting the documents

1. At the input-source hub, tell the agent you want to work on document ingest.
2. The agent creates a Customer-Docs folder in your Cycle project and reports its location. Because the folder is new and still empty, the agent asks you to populate it. This is the normal first pass, not an error.
3. Copy your source documents into that folder. Subfolders are fine, and the agent searches the whole tree.
4. Choose document ingest again. The agent reads its ingest workflow and processes everything it finds.

What the agent does

Behind that single choice, the agent works through the following stages:

1. Scans Customer-Docs recursively and records every file it finds.
2. Expands any archives in place, keeping the original archive files intact.
3. Indexes every source file, so each specification can be traced back to where it came from.
4. Converts each file into Markdown test specifications, one per test case, mirroring the source folder structure. Embedded images are copied out and referenced from the specification.
5. Assesses the quality of the results, reporting which specifications are complete, clear, and executable, and which are not.
6. Flags near-duplicate test cases for your review. Nothing is deleted or merged automatically.
7. Repairs low-risk issues such as spelling directly, and records every change it makes.
8. Walks you through the specifications that need a decision only you can make.

Spreadsheets are handled per worksheet, and per row when a single row represents a distinct test case. When a format needs scripted extraction to be readable, the agent writes a helper script and uses its output.

Review as you go

The agent does the typing, but the results are only as good as the source material. Read the summaries it produces and confirm its repair suggestions, especially where it flags duplicates or ambiguous specifications.

Long-running work

Processing may take a long time, especially when the documents are large or numerous.

What you get

Document ingest leaves two folders in your Cycle project.

Test-Specs holds the output and its analysis:

File	What is in it
The test specifications	Your converted test cases, in consistent Markdown format.
Input-Sources.txt	An index of every file that was ingested, so you can trace each specification back to its source.
Executive-Summary.md	A high-level read on the health of the input documents. Start here.
Verbose-Detail.md	A per-specification breakdown of what each incomplete or unclear specification needs.
Duplicate-Detection.txt	A first-pass analysis of test specifications that appear to overlap.
Repair-Log.md	A record of every repair that was made, so nothing changes silently.

Conversion-Helpers holds the scripts the agent wrote for formats that needed scripted extraction. Keep these if you want to re-run or adjust the conversion later.

Each test specification also records whether it has been reviewed. A later ingest pass skips the specifications you already worked through, so returning to the review does not start over.

Example

You say:

I want to ingest documents.

The agent:

1. Creates the Customer-Docs folder in your project and asks you to copy your documents into it.

You say:

The documents are in. Go ahead.

The agent:

1. Scans the folder, expands the archives it finds, and writes an index of every source file.
2. Converts each file into Markdown test specifications under Test-Specs, mirroring the source folder structure.
3. Assesses the results and writes the executive summary and the per-specification detail.
4. Flags likely duplicates and repairs low-risk issues, logging every change.
5. Walks you through the specifications that need your input.
6. Returns you to the hub with document ingest marked as done.

Turning specifications into Cycle tests

• The generate-tests-from-specs prompt converts a Test-Specs folder into runnable tests, one per specification. See Prompts.
• Return to the hub to layer in another input source, or to answer questions. See Answering Questions.