Deployment waiting or needs action

Start with posture and the organization 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.

Job identity or execution evidence is unavailable

Job identity not reported means Liskov cannot assign the retained execution to a stable job. Inspect its recorded status, Acurast number, and window in Coverage. Do not assume it belongs to the first job or retry solely to make the identity appear.

Evidence unavailable and Not reported are different from a confirmed absence. A missing processor identity does not prove that no processor took the job, and an unreadable charge does not mean a zero charge. Check the latest successful observation and use the support bundle if the read remains unavailable.

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.

If conditionClass is processorAtMatchCap, Liskov excludes that processor and tries the next eligible candidate within the retry budget. If it is authoringFault, do not retry the same policy. Correct the reported schedule pointer: use at least 60 seconds for durationMs, at most one hour for maxStartDelayMs, and no start more than 24 hours ahead.

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.

Execution report was not filed

If a managed row says Not billed — no report filed, the strict report deadline is closed and the finalized scanner proved absence. The customer was charged zero, the full reserve was released, the financial state is closed, and no customer action is required. Do not retry it to clear a review: there is no review amount.

If the deadline is still open, the scanner is unavailable or outside coverage, the evidence conflicts, or a read failed, settlement remains deferred. Stronger signed-fatal and disagreement states keep their own Action Plan treatment.

Processor record is not found or redacted

The processor page is organization-gated. Confirm that the active organization is the one whose deployment supplied the processor link. An unknown processor and one this organization has never used intentionally share the same not-found result.

Redaction bars mean the active plan does not include Enterprise register intelligence. They do not hide your own deployment history, runtime contact, placement eligibility, attestation, or chain-published hardware. If an Enterprise page says register data was not reported, treat that as missing data rather than an entitlement failure. See Inspect a processor your organization used.

Intended capacity is not running

Coverage can show pending launch, unknown submission, or overdue required work while posture is still In progress. That strip is not a second Action Plan. See Intended capacity versus remaining charges before retrying.

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.