From bullet points to expert prose: notes, writing voice and values from the instrument-display photo

The comparison with a voice note describes a hurdle, not a function. What is meant is: anyone able to note down at the vehicle, in their own words, what they notice has everything the capture requires. Specialist forms, text blocks or a particular structure are not needed. What the platform provides for this is a free-text field per job headed “Your notes & observations”, with the hint that bullet points suffice and that the notes are processed together with the fields into the draft.

What the platform does not provide should be said just as clearly: there is no recording function, no speech recognition and no processing of audio files. Notes are typed. Anyone using the dictation function of their phone's keyboard does so outside the platform; what reaches it is text, and only text is processed. This clarification is not only a matter of accuracy but of evidence: what stands in the job was written by the expert, not understood by a recognition system.

The note “scratch bumper rear right, approx palm-sized, down to primer”, which the product tour shows as an example, is therefore exactly what arrives: lower case, abbreviations, no punctuation. From which material the draft makes a report sentence, and from which it does not, is described in the next section.

The draft arises from two separate sources, and the separation is the most important property of the procedure. The first source is the job's measurement fields: each with key, group, label, value and source, for instance mileage, paint thickness, tread depth, battery SoH, paint condition, prior damage. The second source is the notes. Both are handed to the language model, but with different rights.

The instruction to the model, in its German version, reads at its core: use exclusively the measurement fields handed over and invent no values, facts, standards or findings; every number and every statement of fact in the text must come from a measurement field; per paragraph, name exactly the keys of the measurement fields used; no legal advice, no purchase or sale recommendation, no marketing language; report style in the past tense for findings, “was found”; three to five paragraphs, structured along the groups of the measurement fields. The notes are handed over with their own restriction: they may be used as context and phrasing aid, but facts from them may be taken over only where they do not contradict the measurement fields.

In practice this means: the scratch from the note can appear in the draft as a description of prior damage, because the field for unrepaired prior damage carries it or the note supplements it. A number that stands only in the note, say an estimated area, does not become a reading; it has no field and thus no source. Anyone who wants a value to appear in the draft as a value creates it as a field, if necessary as a custom field alongside the catalogue. That is the division of labour: fields are what was measured or found; notes are what helps the model describe it correctly.

The rule that every paragraph names its fields is not left to the model but checked after the response. Every paragraph delivered carries a list of field keys. The platform matches this list against the fields that actually exist in the job, removes unknown keys and discards every paragraph that has no field left afterwards or whose text is empty. If not a single paragraph remains, because the model delivered nothing or referred exclusively to fields that do not exist, the draft counts as failed. The expert then sees a notice with the option to generate the draft again, not a text that looks finished and is not.

Two further cases are treated the same way. If the model's response breaks off because the output became too long, that is reported as an error and not passed on as a shortened draft, because a shortened draft would look complete. If no language model is available, a draft from text blocks along the field groups takes over, and that too carries per paragraph the fields it rests on.

The draft is thereafter a proposal with a record of origin. In the review view, every paragraph shows which fields it arose from; the model's original text remains stored so that the expert's changes remain recognisable as changes and can be discarded. Nothing is released without this review. We described the underlying principle under No value without a source; the legal classification of AI assistance under the EU AI Act.

Under “writing voice” the office sets the tone in which drafts are phrased. There are three settings: the form of address for the reader, formal or informal; the tone on a scale from sober to approachable; the formality on a scale from relaxed to formal. The two scales are internally mapped to three levels each. For tone these are “matter-of-fact and factual”, “factual, but accessible” and “approachable and explanatory”; for formality “relaxed-professional”, “professional” and “highly formal”. What the model receives of this is a single sentence: tone, level of formality and form of address for the reader, together with the office's name as its voice.

That is deliberately little. The voice changes the phrasing, not the content; the rules from the previous section apply unchanged, however approachable or formal the tone is set. An “approachable and explanatory” draft explains what a reading means; it does not invent one. The preview in the settings shows, on an example sentence, how salutation, core and closing sound at each level.

The writing samples deserve an honest classification. In the settings, up to ten earlier reports can be uploaded, and from two samples the voice counts as calibrated. These samples are stored. What enters the instruction for the draft today are the three settings of address, tone and formality; the stored writing samples are not part of that instruction. Anyone wanting to align drafts with their previous style currently does so via the three controls and in the review view on the text itself.

Readings do not have to be typed. Under “AI data capture from photo”, the capture offers the option of uploading a single photo of a measuring-device display, a type plate or a vehicle document; the platform reads the values from it. The function is part of the Pro access. The instruction to the model is again restrictive: capture only values that are unambiguously legible in the image, and never guess or infer; assign each value to exactly one key from the candidate list handed over and ignore everything without a matching key; format values to suit field type and unit, numbers without unit, for selection fields the closest suggestion; omit fields that cannot be read with certainty, and set the confidence level honestly, low if blurred or ambiguous; and return an empty list if nothing usable is legible.

Here too the platform checks afterwards: only keys from the candidate list and only non-empty values are accepted. If the call fails, for instance because no language model is reachable, this is reported as “not available” and not as “nothing recognised”; an empty result means exclusively that the analysis ran and found nothing unambiguous.

The decisive step is the last one. The recognised values are not written into the fields but presented in an overview “Apply recognised values”. Hits with a confidence level of at least 0.6 are preselected, those below are marked “uncertain”; if a field already holds a value, the overview shows what would be replaced. The expert selects what is applied; everything else is discarded. For visible damage on exterior and interior shots there is a second function on the same pattern that delivers assessments as proposals for confirmation. In both cases a field value arises only through the person's decision, and afterwards it carries the same source note as one entered by hand.

The workflow at the vehicle then looks like this. The job is created, the profile's core fields are prefilled as a checklist. The expert measures the paint thickness, photographs the display, loads the photo into data capture, sees the recognised value with its confidence level and applies it or types it in. They measure the tread depth per wheel and enter the lowest value in the catalogue field, the four individual values in added fields. They photograph the scratch and write in the notes what they see, in their own words. What source each field demands we described using paint thickness, tread depth and SoH.

Back at the desk or directly at the vehicle, they generate the draft. It comes in three to five paragraphs, in the set voice, each paragraph with the fields it arose from. The scratch from the note appears as described prior damage in the paragraph on the bodywork; the estimated palm size from the note does not appear there as a measurement, because it has no field. The expert reads, changes what they do not like, and releases. Only then is the PDF created.

What the run-through shows: the speed does not come from the platform understanding something that was not entered. It comes from the input being allowed in the form that is natural at the vehicle, bullet points and photos, and from the translation into report language being bound to rules that can be checked.

Three habits make the difference between a draft that can be released after a short review and one that has to be rewritten. First: everything that is to appear as a number in the report belongs in a field, not in the note. Second: the note may be untidy, but it should say where and what; “rear right, down to primer” is a good note, “scratch” alone is not. Third: the writing voice is set once and then fine-tuned on the text in the review view, not anew for every job.

And a fourth that has nothing to do with the platform: anyone using their phone's dictation function reads the recognised text before taking it into the notes. The platform cannot know what was said; it knows only what stands in its field.

DIAVAG is a software platform for experts. It employs no appraisers of its own and produces no reports; it provides capture, drafting and delivery under the expert's own brand. The draft arises from fields and notes under fixed rules, in the office's voice, and it becomes a report only through the review and release of the person who is responsible for it.