Voice to form: how speech becomes a structured reading

The best field observation is the one made while the technician is still looking at the metal. On a rope, in a confined space, wearing gloves, holding a gauge and a flashlight, the tablet is the problem: it needs two hands and eye contact, and every tap is a moment not spent on the equipment. Voice removes the tablet from between the technician and the work. But voice notes that arrive as audio files or as paragraphs of text are not inspection data. Voice to form is the step that makes speech land in the same fields, with the same types and units, that a typed entry would have used, and then shows it to the speaker for confirmation before it becomes a record.

Why typing on a tablet fails at the CML

Field data quality is lost in the gap between seeing and recording. A technician at a CML sees a reading on the gauge, a coating condition, a pit cluster, and a location relative to a weld. Recording that on a tablet means putting the gauge down, taking off a glove or fighting the touchscreen, finding the CML in the list, selecting the field, typing the number, selecting the next field, and so on. Each step is small; together they change behavior:

• Readings get batched and written on a glove or a clipboard, then transcribed later, which introduces transcription errors and detaches the reading from its photo and its time.
• Condition descriptions get shortened to what is quick to type, so "pitting, isolated, approximately 1 mm deep, 50 mm below the circ seam" becomes "pitting."
• Findings that do not fit a quick tap do not get raised.

None of this is a competence problem. It is friction, and friction wins over time. The point of voice is not novelty. It is that speaking a structured observation while looking at the equipment takes seconds and both hands stay on the job. The field capture patterns this fits into are on the intelliINSPECT page.

What is voice to form, and how is it different from dictation?

Dictation converts speech to text and puts the text somewhere. That is useful for a free-text note and useless for a record. "CML 14 reading 8.7 millimeters, coating intact, no pitting" as a sentence in a notes field cannot be trended, queried, or compared to tmin.

Voice to form does two more things. It recognizes the structure in the utterance: a CML identifier, a thickness value with a unit, a coating condition from a fixed list, a boolean about pitting. And it places each recognized element into the corresponding field of the active form, typed correctly: the thickness as a number in millimeters, the coating condition as an option from the field's reference list, the pitting flag as a boolean. The output is a draft record with fields populated, not a paragraph.

The difference is the same as between a report and a record. Dictation produces something a person reads later. Voice to form produces something the corrosion rate calculation can consume, once the technician has confirmed it.

How does speech map to a field with a type, a unit, and a range?

The mapping has three stages, and each is a place where an error can be caught.

Recognition. Speech becomes text. On a noisy unit this stage will make mistakes, especially on numbers ("eight point seven" and "eight point one" are close in a compressor house), and any design that assumes perfect recognition is broken by design.

Interpretation. The text is mapped onto the active form's fields. The model knows the form's field names, types, units, and, for reference fields, the list of valid options. "Coating intact" maps to the coating condition field's "intact" option; "eight point seven millimeters" maps to the thickness field as 8.7 with unit mm. Values that do not match any field are left out and shown to the technician as unplaced, rather than forced into the nearest field.

Validation. The field's constraints apply exactly as they would to a typed entry. A thickness field expects a number; a number outside the plausible band for that component (well above nominal, or below any credible value) is flagged; a reference field only accepts an option from its list; a required field left empty is shown as empty. Where the form has a relationship to the asset, the CML identifier is checked against the CMLs that exist on it.

The constraints do most of the work. A mishearing that produces a value outside the field's range is caught at validation. A mishearing that produces a plausible wrong value is caught at review, which is why review is not optional.

What happens when the model mishears a number?

It will. The design question is what happens next, and there are three answers that keep the record honest:

• Nothing is saved without confirmation. The interpreted values appear in the form as a draft, each field visibly populated. The technician reads them against the gauge and the equipment, corrects any field by voice or by touch, and confirms. The record does not exist until that step.
• Implausible values are flagged, not silently accepted. A thickness above the nominal for that CML, or a value that implies an impossible corrosion rate since the last reading, is highlighted before confirmation. The technician may still be right (the last reading may have been the wrong one), but the flag forces a look.
• Ambiguity is surfaced. If the model cannot decide between two fields for a spoken value, or two options for a reference field, it asks or leaves the field for the technician rather than guessing.

The result is that voice to form is at least as accurate as typing, because the same person confirms the same value against the same equipment, with the difference that the observation was made and captured in the moment rather than reconstructed. Where an instrument can send the value directly, over Bluetooth or a keyboard wedge, that path is better still, and voice covers what the instrument cannot say: where, what condition, what finding.

How does the form definition constrain the output?

The reason voice to form can be reliable is that the form is defined before anyone speaks. In a metadata-driven platform the form is a definition: fields with names, types, units, valid ranges, reference option lists, required flags, and relationships to the asset and its components. That definition is exactly what the interpretation stage needs, and it is the same definition that governs typed entry, so voice and touch produce identical records.

This has practical consequences for how a site sets up its forms:

• Reference lists over free text wherever the value is one of a known set. "Coating condition: intact, blistered, disbonded, missing" is something speech can land on; a free-text field is not.
• Units on the field, not in the value. If the thickness field is in millimeters, "eight point seven" is 8.7 mm, and "point three four two inches" can be converted or flagged.
• Plausibility ranges per field type, tied where possible to the asset's nominal thickness and prior readings.
• Field names that are speakable. A technician will say "reading," not "measured wall thickness at location," and the definition can carry aliases.

Because tenants own their form definitions and change them through the form designer without code, the vocabulary voice to form understands is the tenant's own, and it changes when the form does.

What does the record show afterward?

A record that came from speech should be indistinguishable from a typed one in how it is used, and distinguishable in how it was made. Afterward, the record shows:

• The field values, typed and validated, in the same schema a typed entry would produce.
• The origin of each value (voice, instrument, or manual) so a reviewer knows which values passed through recognition.
• The identity of the technician who confirmed the record, with the timestamp and, on a shared device, the per-signer identity of any signature.
• The photos bound to the component at capture, if taken.
• The audit trail entry for the record's creation and any later edits.

The origin flag matters for audit and for improvement. A site that sees a pattern of corrections on a particular field can fix the field definition. An auditor who asks how a reading entered the system gets a direct answer. And a completed record pins the form configuration it was executed with, so the fields and options that were valid on the day remain the ones the record is displayed against, whatever the form becomes later. The wider AI layer this belongs to is described on the Spectra page.

How intelliSPEC handles it

Spectra's voice-to-form capability converts speech to structured fields on the form the technician is working in. The form is a metadata definition owned by the tenant, so the fields, types, units, and reference options the speech maps onto are the tenant's own, changed through the form designer rather than through code. The values land in the same fields a typed entry would fill, so the form's own rules and the record's workflow transitions (submit, approve, reject, hold, and owner sign-off) apply to a spoken record exactly as they apply to a typed one, and any change Spectra makes to a record as an action requires approval by default.

For thickness readings the instrument path exists alongside voice: seven device profiles over Bluetooth or keyboard wedge (including DeFelsko, Elcometer, and Evident gauges) bring the reading into the CML record without retyping, and voice covers the location, condition, and finding around it. Photos and video bind to the component at capture, and the signature widget records per-signer identity on a shared device. The field app works fully offline with no time limit on the local store, with offline data encrypted at rest on the device. Every record creation and edit is an event in the hash-chained audit trail with actor and timestamp, and a completed record pins the field configuration it was executed with, so a reading spoken today renders as executed in ten years.