Input
Turn the device spec into requirements a machine can read. Upload the datasheet or the requirements spreadsheet, or sync a Jama Connect project, and each requirement becomes a typed row holding the limits, forced condition and test number the source states; anything the source leaves out you fill in once, in review. The generated program, the limit checks and the production data then all join on those rows.
A requirement in ATE·IQ is not a paragraph of prose. It is a row with a lower and an upper limit, a unit, the stimulus to apply and a test number, and every surface downstream reads those fields directly.
Generate an IG-XL project in which every test carries its requirement's test number and limits.
Test program generation →Compare the spec's limits and forced conditions with the program's, and with what production recorded.
Traceability →Ask whether a spec change reached the program and the lots. The agent's compliance check reads the same rows.
The IG-XL agent →Use whatever the project already has. A spreadsheet is read column by column. A datasheet is read by the model across the whole document, in overlapping windows, under one instruction: leave a value empty rather than guess. When the document states the pin names and supply rails, those are captured too, so generation starts from the pins the spec names. A Jama Connect project syncs over its REST API.
| Source | How it is read | Rows tagged |
|---|---|---|
Spreadsheet (.csv, .xlsx) |
Column by column, so each number comes straight from the cell that holds it | csv-column · xlsx-column |
Document (.pdf, .docx) |
The model reads the whole text in overlapping windows and reports how much it covered; values the document does not state stay empty; pin names and rails are captured when stated | llm-extracted |
Plain text (.txt, .md), or a document the model could not read |
A text parser captures each requirement, its title and its category; the numbers are left for you to fill in during review | regex-fallback |
| Jama Connect | Synced over its REST API with credentials stored encrypted; a plain-http connection to a remote server is refused unless an operator deliberately overrides it | jama-field |
| Hand entry, or a limit changed in review | Recorded as a person's decision | manual |
Every row lands in review tagged with where its numbers came from, so you know which to audit first: limits the model read are flagged, and a limit you change in review is recorded as yours. Each read reports how much of the document it covered and whether anything was cut off, and a document that yields no requirements raises a warning instead of showing a silent empty table.
These fields are the contract the rest of the platform builds on. Every numeric field is optional, because not every requirement is a parametric test.
| Field | Stored as | Why it matters |
|---|---|---|
| Test number | testNumber | The join key. Names drift between the spec, the program and the datalog; the test number links a requirement to its IG-XL test and to the same test in the production STDF data. |
| Lower and upper limit, with their unit | specMin · specMax · units | Normalised before any comparison, so the same current written in microamps or in amps reconciles as equal downstream. |
| Forced condition: current or voltage, how much, in what unit | forceMode · forceValue · forceUnits | The stimulus, kept apart from the limit. "Force a current, measure the clamp voltage" becomes data, so a program that measures the right thing under the wrong drive is caught. |
| Force pin | forcePin | Which pin the force applies to. Real programs apply supply force through the levels sheet rather than a VBA literal, and the check reads the right row because the requirement names the pin. |
| Test method | testMethod | The method and its conditions, including documented measurement-path compensations such as a series termination or a Kelvin drop. A documented compensation is respected instead of being flagged as limit drift. |
| Source tag | provenance | Where the row's numbers came from, as listed in the source table above. |
The demonstration device is a small motion sensor with a 4-wire SPI interface. Its spec was entered by hand as a structured spec: every requirement carries limits and a test number, with test numbers in steps of ten. Downstream, the spec, the generated program and the production data (demonstration lots: seeded synthetic data with planted defects) join on test number for every requirement.
Measured on the demonstration project. Lots are seeded synthetic data with planted defects; a join on test number shows presence, not correct implementation.