Event classification.
Ownership filings are numbers and dates. On top of them sit two interpretive labels: what a holding is doing over time (trajectory_type) and why it is held (purpose_category). The labels are revisable and may use models; they never change the figures underneath.
Labels, not numbers
An ownership trajectory carries two interpretive fields: a trajectory_type (how the holding is moving) and a separate purpose_category (the stated reason it is held). These are distinct from the underlying figures (stakes, deltas, dates) which are lifted deterministically from typed XBRL and never touched by this layer.
Event classification is not deterministic. It is a labelling layer that may use models, and labels can change as new filings arrive or as the classifier improves. It never alters the underlying numbers, and every label keeps the source doc_id it was derived from. If you need a label to stay stable, pin it with a freeze token.
trajectory_type
Classifies how a reporter cluster’s holding is moving across its amendments. The enum is accumulating, exiting, stable, or new_position.
purpose_category
A separate, nullable field capturing the reporter’s stated holding purpose, normalised from the filing, for example activist, pure_investment, or cross_holding. It is independent of trajectory_type: an activist position can be accumulating or exiting. Like the trajectory label, it is part of the revisable layer and is null when the filing does not state a purpose.
Why it is revisable
A trajectory is built from a sequence of amendments. When a new filing arrives, the sequence grows and a label that read new_position last quarter may resolve to accumulating this quarter. The classifier itself can also improve over time. Both are expected: the labels describe a moving target, so they move with it. What does not move is the data underneath: the stakes and dates the labels are computed from.
Every label keeps its doc_id
Each labelled trajectory point carries the EDINET doc_id it was derived from, resolving at disclosure2.edinet-fsa.go.jp. So even though the label is interpretive and revisable, you can always trace it back to the public filing and check the underlying figures yourself. This is the same provenance contract as the rest of the API, see the verifiability model.