In ReportPortal a test item's metadata is an `ItemAttribute` with a `key`, a `value` and a `system` flag, while an Allure `Label` is always a name and a value. What can the first shape express that the second cannot?

## Two shapes for the same idea Both products attach small pieces of metadata to a test so that a report can group and filter by them. The shapes are close enough that people assume they are the same idea under two names, and different enough that a merge between them loses something. | | Allure `Label` | ReportPortal `ItemAttribute` | |---|---|---| | fields | `name`, `value` | `key`, `value`, `system` | | optional half | neither | the `key` | | provenance marker | none | the `system` flag | | attaches to | one test result | a test item **or** a launch | ## The optional key In ReportPortal's API resource the `value` is the constrained field -- it is declared not-blank, with a minimum length -- while `key` carries no such constraint. A keyless attribute is therefore a legal, ordinary thing: a **bare value**, a plain tag, with nothing on the left-hand side. That matters more than it looks. It means the model supports two different uses at once: - **A keyed attribute** is a named dimension: something like a browser attribute whose value is the browser's name. It is what you group by. - **A keyless attribute** is a flat marker: it says a test is *in a set*, without saying which dimension the set belongs to. An Allure `Label` cannot express the second form. Every label has a `name`, so the closest equivalent is a label whose name is a convention agreed out of band and whose value is the marker -- which works but records something structurally different: it asserts a dimension that may not exist. ## The provenance flag `system` is a boolean on the attribute saying it was set by the product itself rather than typed by a person. It exists because a server that writes bookkeeping onto a launch as it processes one needs a way to tell its own writes apart from a user's afterwards -- when displaying them, when filtering on them, and when deciding whether an edit may remove them. Allure has nothing corresponding. A label written automatically by the adaptor and a label written by hand in an annotation are byte-identical in the result file: both are a `name` and a `value`. You can often *guess* which is which from the name -- `suite` labels are usually derived, `epic` labels are usually declared -- but the file does not record it, and a guess is not something a tool can act on. ## Scope An `ItemAttribute` can hang off a launch as well as off an individual test item, so a fact that is true of the whole run is recorded once, in one place, at the level it is actually true of. An Allure `Label` lives on a single result; a fact about a whole run has to be repeated onto every result the run produced, and the report has no way to know the repetition was one decision rather than many. ## What all this costs when results are consolidated This is the part worth being able to argue, because the losses are structural rather than encoding problems, and each has to be decided rather than converted: 1. **A keyless attribute needs a key or it is dropped.** Inventing one -- `tag`, say -- is the usual choice, but it fabricates a dimension the original data deliberately did not assert. 2. **The `system` flag has nowhere to land.** Once it is gone, machine-written bookkeeping is indistinguishable from a human's annotation, and any filter built on the merged metadata is quietly filtering over both. 3. **Launch-level attributes have to be pushed down or lost.** Copying one onto every result works, but the merged data can no longer say the value was asserted once for the run. 4. **Nothing in either shape is validated.** Both sides are string pairs with no closed vocabulary, so the merged set is only as coherent as the conventions that produced it -- and there is no place in either format to record what those conventions were. ## Reading the difference the right way round Neither shape is better. The extra fields exist because the products sit in different places: one writes files that a generator later reads, the other is a server receiving a live stream and keeping its own state alongside what clients send it. A server has bookkeeping to keep separate from user data and a run-level object to attach things to; a file writer has neither. The useful takeaway for an interview is not the field lists but the consequence: **when you merge metadata from two models, the fields with no counterpart are the whole story**, and deciding what happens to them belongs at the front of the design, not at the end.