Input
Spec Ingestion
The device spec is where every test program starts, and it usually arrives as a PDF. ATE·IQ turns a datasheet or a Jama Connect project into structured requirements — each with its limits, its forced condition, and a test number that stays stable for the life of the program. Everything downstream joins on those rows.
Overview
A requirement in ATE·IQ is not a paragraph of prose. It is a database row with typed fields — minimum, maximum, units, forced condition, test number — that the generator, the traceability reconcile and the STDF join can all read mechanically.
Sources are whatever the project actually has. File upload accepts
.pdf, .docx, .csv, .xlsx,
.txt and .md; Jama Connect syncs over its REST API with
stored credentials. Limits and test numbers come from parsing the document,
never from a model's memory — and every row is tagged with its provenance, so
an engineer knows which numbers to audit before trusting them.
What a requirement carries
The fields below are the contract the rest of the platform builds on. All numeric fields are optional — not every requirement is a parametric test.
| Field | Example | Why it exists |
|---|---|---|
| testNumber | 1100 | The stable join key. Names drift between the spec, the program and the datalog; the test number is the contract that links a requirement to its IG-XL test and to the same test in production STDF. |
| specMin / specMax / units | 40 / 87 µA | The measured limit, normalised for comparison — 65 uA and 65e-6 A reconcile as equal downstream. |
| forceMode / forceValue / forceUnits | I · −100e-6 · A | The mandated stimulus, distinct from the measured limit. "Force −100 µA, measure clamp voltage" becomes structured data — so the reconcile can catch a program that measures the right thing under the wrong drive. |
| forcePin | VDD | Which pin the force applies to. Real programs apply supply force through the Pin Levels sheet, not a VBA literal — the reconcile reads the right row because the requirement names the pin. |
| testMethod | measurement-path note | Free-text method, including documented measurement-path compensations (a series termination, a Kelvin drop). The reconcile respects a documented compensation instead of flagging it as limit drift. |
| provenance | llm-extracted | Where each row's numbers came from: csv-column, xlsx-column, llm-extracted, jama-field or manual. LLM-extracted rows are flagged for audit before trust. |
From spec to structured requirements
Upload a file, or connect Jama Connect once — credentials are stored encrypted,
and cleartext endpoints are refused. Limits and test numbers come from parsing
the document, never from a model's memory, and every extraction reports how
much of the document was read and whether anything was truncated — zero
requirements extracted is a warning, not a silent empty table.
Every row lands in review carrying its provenance, so LLM-extracted limits are
audited before they are trusted and hand-edits are recorded as
manual. The device profile — pin names and rails — is captured
from the same document, so everything generated downstream starts from the
device's real pins.
Proven end to end
On the demonstration project, the device datasheet ingests into
34 requirements — DC parametrics, serial-protocol checks,
register read/write tests and accuracy points — each carrying its limits and a
test number that the generated program, the load board and the production STDF
all join back to. On this spec the forced conditions live in the free-text
test-method notes rather than the structured force fields;
an output-level requirement documents a 33 Ω series-termination
drop in its testMethod, which the traceability dashboard reports
as a documented compensation rather than as limit drift.
llm-extracted
and should be audited before they gate a compliance verdict; every other
provenance tag identifies its source the same way. Truncated reads are reported
as truncated — the tool never presents a partial extraction as a complete one.