Shareholder register workflows (coming later)

The ledger separates legal ownership from app membership. A BoardKite user may attend a meeting, but the rights are held by legal parties in the aktiebok.

• Legal parties represent rights holders: natural persons and legal entities.
• Person records are used only when a legal party is linked to someone in the workspace for identity, history, or future attendance flows.
• Current holdings are a projection of recorded ledger events, so the audit trail remains readable when ownership changes.

Create one legal party per rights holder, then link it to a BoardKite person only when that connection is known.

• Use organization number, personal identity reference, name, address, and country to detect likely duplicates before import or manual creation.
• Encrypted fields should be treated as restricted operational data, not ordinary profile text.
• A person can later attend for themselves, for a company, or as proxy for another party without changing who owns the shares.

Share classes define the rights and vote weight that holdings use.

• Record each aktieslag with its votes per share before recording holdings.
• Changing votes per share after holdings exist is legally sensitive and should remain audited.
• Reconciliation compares issued shares against open holdings so snapshots are not created from inconsistent data.

Events are the durable record of ownership movement. The current register should be reproducible from the event sequence.

• Issue, transfer, cancel, correction, split, and merge events each need typed payload validation.
• Preview an event before recording it so ranges, quantities, pledges, restrictions, and reconciliation can be checked.
• Corrections must add a new auditable event; locked snapshots should not be rewritten.

Imports are an assisted setup path, not a silent write into the legal register.

• CSV imports map known columns into legal parties, holdings, and opening-balance events.
• Euroclear PDF imports detect the source, extract rows, and surface external snapshot data for review.
• Future PDF importers should be source-specific: detect the issuer, run a matching parser, then show a dry-run with duplicate and reconciliation warnings before commit.

A snapshot preserves the register as evidence for an effective date, including the shareholder, share, vote, and validation state at that point.

• Create a snapshot only after missing data, overlapping ranges, and issued-share reconciliation have been reviewed.
• General-meeting snapshots should be locked so later transfers do not alter the evidence used for notice, attendance, or voting.
• Snapshot checksums depend on deterministic serialization and should be reproducible.

The same ledger supports physical, hybrid, and digital general meetings through a linked BoardKite meeting and a locked snapshot.

• A meeting uses a locked share-register snapshot to calculate expected voting capacities and prepare the voting register.
• Attendance is modeled through people and proxies, while voting capacity remains tied to the legal party and locked snapshot.
• RSVP is not attendance: the locked röstlängd includes only approved capacities of present or represented attendees.