Event types

The parser classifies each publication into one or more of eleven events. Seven come from machine-readable XML fields. The remaining four (BRANCH_CREATED, PURPOSE_CHANGED in its text form, MERGER and OFFICERS_CHANGED) have no flag in the register’s schema, and are read out of the publication text by Text extractors.

Event	Sub-rubric	Trigger
INCORPORATION	HR01	<registration>true</registration>
BRANCH_CREATED	HR01	A branch designation in the publication text
SEAT_MOVED	HR02	Different seat in commonsNew vs. commonsActual
ADDRESS_CHANGED	HR02	<addressChanged>true</addressChanged>
NAME_CHANGED	HR02	Different company name in commonsNew vs. commonsActual
PURPOSE_CHANGED	HR02	Different purpose in commonsNew vs. commonsActual
CAPITAL_INCREASED	HR02	Structured nominal comparison, phrase fallback
MERGER	any	A merger clause in the publication text
OFFICERS_CHANGED	HR02	A person block in the text that mutates an office
LIQUIDATION	any	Dissolution flags or “in Liquidation” added to the company name
DELETED	HR03	<delete> block with a deletion date

Events are emitted in the order above: the declaration order of EventType, also available as shab_parser.TAXONOMY_ORDER. A single publication can carry several: an HR02 mutation that moves the registered office and increases capital yields both SEAT_MOVED and CAPITAL_INCREASED.

Classification logic

Events are classified from the subRubric code and the <transaction> block. German, French, and Italian publications of the same commercial register act produce identical event types.

Where the register offers both a flag and the underlying values, the values win. seatChanged is set on a street-address update within the same municipality, and taking it at face value made 47.7% of seat moves spurious over a 3,157-publication sample, with Locarno “moving” to Locarno. nameChanged has the opposite fault: it is false on most renames the register nonetheless publishes, including every entry into and exit from liquidation, so gating on it dropped roughly two thirds of real renames. Both events are therefore driven by comparing commonsActual against commonsNew, with the flag read only for the payload’s trigger label.

LIQUIDATION is detected independently of the sub-rubric, and marks the moment a company enters liquidation. A later publication about a company already in liquidation carries no second event. Two signals are each sufficient: a structured dissolution flag under <statusChanged> (including a bankruptcy opening, which the register files under its own branch), or the legal name acquiring a liquidation qualifier it did not carry before. A name whose only change is gaining or losing that qualifier is deliberately not a NAME_CHANGED: the liquidation event already states it.

Capital increases use a two-pass heuristic, because capitalChanged signals only that the capital changed and never in which direction. The parser first compares the structured <nominal> values in commonsNew and commonsActual and emits only on a strict increase. When those are missing or unparseable, it falls back to a reviewed language-specific phrase in the publication text (“Kapitalerhöhung”, “augmentation du capital”). Decrease phrases have no entry, so a reduction matches nothing and emits nothing.

PURPOSE_CHANGED compares the two structured purposes, with one asymmetry: a purpose stated where commonsActual held none counts only when purposeChanged is also set. Over a 21,011-publication sample, 52 HR02 publications printed a new purpose against an empty prior one and only 6 carried the flag; the other 46 were the register restating a purpose it had not previously published, not a company changing what it does.

INCORPORATION carries the founding party set under a nested roster key. Roughly 387,000 foundings in the corpus state their initial team, and routing those through OFFICERS_CHANGED would read as that many executive appointments. Nesting also keeps a top-level persons key meaning what it has always meant: officers that changed.