> ## Documentation Index > Fetch the complete documentation index at: https://docs.a7manager.se/llms.txt > Use this file to discover all available pages before exploring further. # Reporting > Code lists, assistant instructions and the maintainer integration behind A7 Reporter. Configuration for defect reporting through the [reporter app](https://docs.a7manager.se/pages/reporter-app.md): 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 | Tab | Shows | | - | - | | **Code lists** *(default)* | The allowed values for each classification field | | **Assistant** | Project-specific instructions for the assistant | | **Maintainer integration** | The system submitted reports are delivered to | *** ### Code lists Five lists, one tab each. Every project keeps its own. | List | Report field | Required | | - | - | :-: | | `SEVERITY` | Severity | ✓ | | `CATEGORY` | Category | | | `CONSEQUENCE` | Consequence | | | `FAULT_INDICATION` | Fault indication | | | `LOCATION` | Location | | A report cannot be started until the severity list has at least one active entry. Each entry has these fields: | Field | Meaning | | - | - | | Code | The value stored on the report and sent to the maintainer's system. At most 50 characters, unique within the list | | Label | The text reporters and the assistant see. At most 255 characters | | Description | Guidance for the assistant: when this value applies. Never shown to reporters | | Sort order | Position in pickers and choices | | Active | Whether the entry is offered | #### 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. > [!NOTE] > > 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. ``` code;label;description H;High;Use when the vehicle must be taken out of service. M;Medium;Use when the fault must be fixed at the next depot visit. L;Low;Use for cosmetic faults with no effect on operation. ``` | Rule | | | - | - | | Columns | Code, label, and an optional description, in that order | | Separator | Tab, semicolon or comma, detected per line in that order of preference | | Description | Everything after the second separator, so it may itself contain the separator | | Quotes | A cell wrapped in double quotes has them removed | | Header | A first line whose first cell is `code` (any case) is skipped | | Blank lines | Ignored | 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](https://docs.a7manager.se/platform/maintainer-integration.md) for the delivery model. | Setting | Meaning | | - | - | | Adapter | The connector for the maintainer's system. Each adapter has its own settings form | | Send reports to the maintenance system | When off, submitted reports are delivered to the log adapter and nothing leaves the platform | | Credential source | Azure Key Vault or environment variables. Key Vault is refused on a deployment that has none | | Secrets | The names of the secrets this adapter reads. The values are never entered here | **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: | Layer | Covers | Fields | | - | - | - | | 1. Observed behaviour | What the reporter saw, heard or felt | — | | 2. Affected system | The product group | `product_group` | | 3. Specific symptom | What exactly fails, and where | `slot`, `location` | | 4. Fault details | How serious, which indication, which consequence | `severity`, `fault_indication`, `consequence`, `category` | | 5. Context | When it happened, and the effect on traffic | `defect_datetime`, `delay_minutes` | 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. | Field | Rule | | - | - | | Vehicle | Chosen by the reporter; the assistant cannot change it. A vehicle of another type clears product group, slot and location | | Product group | A node of the vehicle type's product-group tree | | Slot | A slot on the product group or one of its ancestors | | Code-list fields | An active entry of that list; for location, project-wide or of the vehicle's type | | Title | At most 40 characters, the width of a SAP notification short text | | Defect time | Date and time with a time zone, not in the future | | Delay | A whole number of minutes, zero or more | A report can be submitted once these are set: | Mandatory | Optional | | - | - | | Vehicle, product group, title, description, defect time, severity | Slot, location, category, consequence, fault indication, delay | *** ## Tables > **[Field reference](https://docs.a7manager.se/data/tables/reporting.md)** > > `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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.