Deployment waiting or needs action

Start with posture and the current Action Plan:

proof liskov application status APPLICATION_ID
proof liskov application action-plan APPLICATION_ID --json
proof liskov application deployment status APPLICATION_ID --json

Normal waiting

Evidence	Interpretation
Policy/deployment created, no submission yet	Liskov can still be preparing funding, configuration, or launch authority.
Submitted, no processor	Acurast market assignment is pending.
Processor assigned, no runtime contact	The job can still be fetching, starting, and bootstrapping.
Runtime configuring	Identity/configuration/secrets/logging are advancing.
Runtime ready, no Application output	Check the workload's own tick or external-service behavior.

Use the displayed stage timestamps and expected boundaries. Do not resubmit a normal wait.

Needs action

Read conditionClass, disposition, nextAction, decision ID, and scoped identifiers. Correct the named prerequisite. Examples include insufficient credits, missing configuration, unsupported policy, no affordable processor, stale handoff, or ambiguous evidence.

Only use Action Plan retry when it is explicitly offered:

proof liskov application action-plan retry APPLICATION_ID \
  --decision-id DECISION_ID \
  --reason "named blocker corrected" \
  --yes

Submit once, then verify a new activity event. Repeated retries can consume the bounded launch budget or create more review work.

Runtime failure after contact

The first public policy waits to scheduled end rather than automatically registering a fresh job on runtime failure. Check signed fatal/contact evidence, external Acurast execution evidence, and scheduled end. A failure can remain In progress and non-actionable while Liskov waits for honest terminal facts.

Escalate

If the same condition remains past its documented observation window, collect the support bundle. Do not use source-visible platform repair commands or ask an administrator to declare ambiguous evidence successful.