Separate business status and lifecycle

Context

The cited lifecycle planning decision already establishes two axes. The design preserves that decision while recording the restore exception and cache behavior observed in implementation.

Loaded activation does not imply a business-status change or a new first-activation timestamp.

Decision

Store staff-controlled business status separately from lifecycle readiness/destruction and enforce their compatible combinations in the database; ordinary edits cannot set lifecycle.

Alternatives Considered

Combine readiness and business classification into one status. That obscures deletion protection and turns compatibility into conventions that individual writers can miss.

Consequences

Availability evaluates both axes with the documented HQ and loading exceptions.

Retirement requires disabled business status; loading requires implementation status.

Lifecycle services use a declared transition graph, with the explicit operator restore exception.