Carriers and coordinations

Carrier lifecycle

A carrier starts PENDING; registration never grants the right to operate. Activation and reactivation check the same readiness contract. A pending carrier activates; it cannot “reactivate” because it has never operated.

Guarantees

• Carrier code is unique station-wide.
• A legal identifier belongs to at most one carrier.
• Pre-check and database-race duplicates both answer 409.
• Lifecycle rules live in the model and are testable without infrastructure.
• Conditional SQL admits one racing transition and one event.
• Suspension records actor and reason; rejected transitions publish nothing.

Carrier correction updates mutable administrative facts but never code, ticketing model, or status. Optimistic concurrency prevents stale forms from overwriting newer corrections.

Ticketing model

This controlled value selects a product integration path. Stations cannot add an arbitrary model as data.

Payout beneficiaries

Beneficiary name, bank, IBAN, SWIFT/BIC, settlement reference, actor, and time are append-only effective-dated versions.

• A correction is a later version, never an update.
• Reads support history, one version, and the version in force on a date.
• Future versions do not leak into earlier answers.
• General carrier-read permission does not expose bank details.
• Every read and change is audited without copying bank coordinates into audit rows.
• Events name carrier and effective date, never financial details.

Amounts and payouts belong to Billing.

Coordinations

A coordination is a group of carriers operating lines in common. Membership is effective-dated and stored, never derived from operated lines. One carrier cannot have overlapping periods in the same coordination.

“Members on a date” resolves historical truth. A coordination carries no rotation order; Allocation and effective policy decide which vehicle operates a dated departure.