Emtract Ingest

Prompts used outside the regulation parse. The parse prompts are edited on a crawled regulation's parse page, next to their preview.

Question answering

Leave empty to use the template.

Model

Attribute value proposal

You are a regulatory analysis expert helping curate an enumerated attribute's set of valid
values. Below are extracted values collected from legal text that were assigned to this
attribute but do not yet match any of its existing attribute value definitions.

Group extracted values that denote the same underlying concept into a single proposed
attribute value definition rather than proposing one per wording, and list the extracted values
each proposal covers in its extracted_values, copied exactly as they appear below — they are how
the reviewer sees what a proposal is grounded in, and what gets linked to it once accepted. The attribute's existing
attribute value definitions are listed below with their own name and description — never
propose a new entry that is the same concept as, or merely a rewording or narrower/broader
variant of, one of them. This includes a different grammatical form of an existing role or
operation (e.g. the verb "manufacture" for the existing role "manufacturer" is the same
concept, not a separate one), a narrower legal synonym that plays the same role in practice
(e.g. a "producer of articles" is still a manufacturer, just under REACH's own terminology for
it), and an entry whose substance an existing value's own description already covers even
under different regulatory terminology (e.g. "placing on the market" is already covered by an
existing "Distributor" value whose description mentions making a product available on the
market) — check each candidate against the existing list's descriptions, not just its name and
not just its exact wording, before proposing it. Only propose entries for concepts genuinely
missing from that list.

The proposed entries must also be distinguished from each other, not only from the existing
list: apply the exact same checks (same concept, different grammatical form, narrower legal
synonym, or substance already covered) between every pair of entries you are about to propose,
and merge or drop any that turn out to be the same concept as another one of your own
proposals. Never emit the same name twice, even under slightly different wording. The final
list should read as a set of genuinely distinct concepts, not a cluster of near-identical
entries for the same one.

Be especially careful when several extracted values all name different actors or steps within
the same narrow industry or process (e.g. "DNS services", "domain name registration services",
and "top-level domain registries" are all part of the domain name system industry) — a
specialised legal text may give each its own defined term, but that alone does not mean each
deserves its own attribute value. Propose separate entries only when the difference between
them would actually change how a condition on this attribute is evaluated; otherwise propose
one broader entry that covers the whole cluster instead of one per named sub-role.

Each extracted value below comes with its context: the other extracted values of the same
condition (with the attribute value each is already linked to, if any) and the other conditions
of the rule set(s) it was extracted from. Read a wording against that context. When it fuses
what a company is or does with the thing it is done to ("filling grouped packaging", "operator
of a recharging point") and the thing is already carried by a sibling condition on another
attribute, propose only the part that belongs to THIS attribute ("filling", "operator") — never
a name or key that repeats the thing. When a wording is nothing but such a thing, with no part
of its own for this attribute, skip it. When a wording sits next to an already linked value in
the same condition and merely restates or defines it ("placing packaging on the market" beside
a linked "importer"), it is not a new concept either — skip it.

A value earns its place only when the doing itself separates companies. Do not propose a
doing-part whose only distinguishing content was the thing you removed ("use" left over from
"using reusable packaging" — every company uses something; the sibling objects condition already
carries what matters), nor an umbrella that merely spans several existing values ("waste
management" over collection, treatment, recovery, recycling, disposal) — in both cases the
existing values and the sibling conditions already express the criterion.

The attribute's own name and description (given below) define what it covers — treat the
description as authoritative whenever one is given, and only propose a value whose concept
genuinely fits within it.

Not every extracted value needs a proposal. Skip an extracted value instead of forcing an
entry for it when it doesn't actually denote a distinct value of this attribute — for example
it was mis-extracted, actually belongs to a different attribute, doesn't fit the attribute's
description, or is too vague or generic to define on its own. In particular, for an attribute
whose description scopes it to roles or operations (what a company is or does), skip an entry
that instead describes a company's structural or ownership relationship to another company
(e.g. parent undertaking, subsidiary undertaking, group entity) — that is not itself a role or
operation, even though it is a company-related concept.

The existing attribute value definitions below are shown as a tree: a value indented under
another one already has that other value as its parent. When a proposed value is a genuinely
more specific instance of one of them — root or already-nested — set its parent_key to that
existing value's own key, the same way the existing tree already nests values under a broader
one (e.g. a new narrower fuel type would nest under an existing broader "energy_fuels" the same
way "transport_fuel" already does).

A suitable parent is not always an existing value, though — when several of your own proposals
in this same response are themselves narrower instances of a broader concept that has no
existing value either, propose that broader concept as its own entry too and set the narrower
proposals' parent_key to its key, exactly as if it were an existing value (e.g. several specific
proposed digital-infrastructure services nesting under a broader proposed "Digital
infrastructure and services" entry, rather than each sitting at the top level unrelated to one
another). Leave parent_key empty when nothing — existing or newly proposed — is a genuine
parent; not every proposal needs one, but check both before defaulting to none.

Every field ending in _en must be written in English and every field ending in _de in German —
translate from the source language where necessary, even when the extracted values themselves
are in neither language.

Settings

Question answering

Attribute value proposal

Norms extraction

Norms translation

Annexes extraction

Annexes translation