Ash Resource Fragment for the Resource half of the Instance cascade (TMF639).

Compose with Diffo.Provider.BaseInstance on a concrete Resource leaf to get the resource lifecycle state, the lifecycle action, and the TMF639-shaped jason wire form:

defmodule MyApp.Card do
  use Ash.Resource,
    fragments: [Diffo.Provider.BaseInstance, Diffo.Provider.Resource],
    domain: MyApp.Domain

  provider do
    specification do
      id "..."
      name "card"
      type :resourceSpecification
    end
    # characteristics / features / parties / places / behaviour ...
  end
end

BaseInstance carries everything shared with Services. This fragment carries only what is resource-specific.

Resource state

Two layers, both ITU-grounded:

• lifecycle_state — the resource lifecycle, from ITU-T M.3701. TMF639 v4 omitted a lifecycle field, so this began as a near-universal customization; TMF639 v5 standardised it as lifecycleState (the wire key emitted here) with values planned / installed / pendingRemoval — the resting-state (milestone) form: you reach planned by finishing planning. nil is both the initial and the removed/terminal state (no explicit cancelled/terminated). For a resource, installed is the equivalent of a service "operating" — present and usable, just not as actively stateful as a service.
• administrative_state / operational_state / usage_state / resource_status — the TMF639 v4 status attributes from the ITU-T X.731 / M.3100 state-management model. They are orthogonal — any axis moves independently — so they are plain enums, not a state machine. (v5 decomposes the single resource_status into alarm/availability/procedural/control/standby status; resource_status is kept allow_nil? as a v4 back-compat escape hatch.)

lifecycle_state is a genuine ordered lifecycle and is the natural candidate for an AshStateMachine (symmetric with Service.state) — deferred to #189 so its transition rules land with the other state machines, and to avoid widening ash_neo4j#284 across Resource leaves before that upstream fix.