Skip to main content
Configuration for defect reporting through the reporter app: the values a report can be classified with, guidance for the assistant, and where submitted reports are delivered. The Swedish label is Felrapportering, under Project Config.

​
Tabs

​
Code lists

Five lists, one tab each. Every project keeps its own. A report cannot be started until the severity list has at least one active entry. Each entry has these fields:

​
Code, label and description

The three fields have separate jobs, and keeping them apart is what makes the lists work.
  • The code must be the maintainer system’s own value. It is what the integration sends, and it is what lands in the defect row, alongside the codes the maintainer’s daily file delivers for imported defects. A code outside the maintainer’s catalog means nothing in their system and splits the defect statistics. Align every list with the maintainer’s catalog before going live.
  • The label is display text. It is what the reporter reads and taps. It can be changed at any time without affecting stored reports.
  • The description is read by the assistant. It decides whether the reporter’s own words match a value without asking. Write it as a rule: “Use when the fault was found during a scheduled inspection rather than reported in traffic.” An entry without a description is still offered, but the assistant has only the label to go on and asks more often.
The defect row receives the code for severity, category, consequence and fault indication, plus the consequence label as its consequence description. Location is the exception: the row receives the location label, because defect.location is free text. The integration always receives both code and label for every field.

​
Active and deleting

An inactive entry is hidden from reporters and the assistant, but reports that already use it stay valid and keep it. Deactivate an entry to retire it. An entry that any report uses cannot be deleted; the request is refused and the entry must be deactivated instead. Unused entries can be deleted.

​
Locations per vehicle type

LOCATION is the only list that can be scoped to a vehicle type, because places on a vehicle differ by type. The Location tab has a vehicle type selector:
  • All vehicle types — the entry applies to every vehicle in the project.
  • A specific type — the entry applies only to vehicles of that type.
A report sees the project-wide entries plus those of its vehicle’s type. The same code can exist once project-wide and once per vehicle type; for a vehicle of that type, the type-specific entry wins. When a report has a slot — a mounting position from the vehicle structure — the slot already says where the fault is, and the assistant does not ask for a location.

​
Import

Import adds many entries to the list on screen at once, from a pasted text or a .csv or .txt file. For the Location list, entries are created in the vehicle type scope that is selected.
The import is all-or-nothing. Lines with a missing code or label, an over-long value, or a code repeated in the file are listed by line number and block the import. A code that already exists in the list is refused by the server, and then nothing is created either. At most 500 entries per import.

​
Assistant

Free text, at most 4,000 characters, added to the assistant’s instructions under a heading of its own. Use it for what the code lists cannot carry: depot and station names, the fleet’s naming conventions, which severity to choose in which situation. The assistant follows these instructions unless they conflict with its built-in rules. It already sees every code list with its descriptions, so the lists should not be repeated here.

​
Maintainer integration

Where submitted reports are delivered. See Maintainer integration for the delivery model. Test connection checks the saved settings against the maintainer’s system, whether or not the integration is enabled, so it can be tested before reports start flowing. Save before testing.

​
How the assistant interviews

The assistant works through five layers, in order: Interview rules:
  • Anything the reporter says is saved before the next question, whichever layer it belongs to.
  • A value is inferred from the code-list descriptions before it is asked for. An inferred value is mentioned in the next question so the reporter can object.
  • One question per turn, mandatory fields first, then the optional ones. Each optional field is asked about at most once; “don’t know” is accepted and the field stays empty.
  • Where a field has fixed values, the assistant offers tappable choices.
  • The report time is set when the report is started. The assistant confirms when the fault actually occurred.
  • A delay is recorded only when the reporter states one or says there was none.
  • A component named by type — “the motor”, “the bogie” — resolves to the product group of the slot where such a component is mounted on this vehicle. If there are several, the assistant offers their positions. It never asks for a serial number; the slot determines it.
  • A broad product group is narrowed once by offering its child groups.
  • Before completing, the assistant asks once for any other relevant information — weather, track or station, traffic situation, what was tried on site.
  • It then writes the title and the description and marks the report ready for review.

​
Validation rules

The assistant proposes values; the server accepts or rejects each one. Nothing outside the configured lists and the vehicle type’s own structure can be stored. A report can be submitted once these are set:

​
Tables

Field reference

reporting_code_list, reporting_settings and integrations_maintainer_integration.

​
Roles

Every tab requires Project Admin, and the Reporting entry is hidden from everyone else. Defect Reporters and other project members can read the active code lists, which the reporter app uses for its pickers.