Verify your deployment

Overview

Verify one real agent session from collection through completed analysis before you expand your rollout. A ready pod or a passing health check shows that the workloads started. This end-to-end check shows that the analyzer stored the session, analyzed it, and reported the result to Promptless. An analysis with zero findings is a successful result.

Run it after a new installation, and again after a storage migration, recovery, or material identity change. Keep the session ID and analyzer installation name so you can correlate every check.

Host enrolledConfirm the host and deployment identity

Trace storedRead the exact object using the analyzer identitytrace_object_status = written

Analysis completedFind a succeeded run for that sessionstatus = succeeded

Dashboard currentConfirm the session and analyzer status are visible

Follow the same session through all four checks. Ready pods and upload acknowledgments alone do not prove success. A succeeded analysis can have zero findings.

To have a coding agent run these checks for one session, copy this prompt. Set up PIG with a coding agent covers the whole setup.

Verify our PIG deployment end to end for one real session. Follow
https://promptless.ai/docs/governance/deploy-the-worker/verify-your-deployment.md
and phase 7 of https://promptless.ai/docs/governance/agent-setup-guide.md

Scope: read-only checks of this session only. Do not copy session content
into your report.
Inputs (discover these before you ask me):
- Kubernetes context, namespace, and deployment name: [for example, pig and acme]
- Analyzer hostname: [for example, traces.acme.example]
- Session: [agent source (claude, claude-desktop, codex, or cursor) and session ID,
  or "tell me when to run a test session"]

Report each check (enrolled host, stored and readable trace, succeeded
analysis of the current revision, Dashboard acknowledgement, and the
Acceptance condition) as passed, failed, or not run, with its evidence. For
a failure, name the first failing stage and the next action for me.

1. Check the deployment and endpoint

For a supervisor-managed installation, check the deployment conditions, the analyzer logs, and the HTTPS endpoint:

kubectl get pigdeployment acme --namespace pig \
  -o jsonpath='{range .status.conditions[*]}{.type}={.status} {.reason}{"\n"}{end}'
kubectl logs deployment/acme-analyzer --namespace pig --tail=100
curl --fail --silent --show-error https://traces.acme.example/healthz

Run the HTTPS check from the network your enrolled hosts use. Confirm the certificate, hostname, and routing, as in Point DNS at the Ingress. Ready=True means the workloads and dependency checks passed. It passes while analysis is off, so also confirm that instruction repositories are selected and trace analysis is enabled.

Deployment verification and acceptance require a healthy analyzer whose last check-in reached Promptless less than 15 minutes ago. A running pod can still appear stale if its check-ins stop reaching Promptless.

The Acceptance condition reports AwaitingCanonicalAcceptance until the checks below pass for a real session. The supervisor then sets Acceptance=True with reason CanonicalSuccess for the installed release and configuration. Use this condition together with the per-session checks; neither replaces the other.

For the manual worker chart, use deployment/pig-trace-analyzer in log commands and helm status pig-trace-analyzer --namespace pig for release status.

These names assume the release replacement is complete. For an existing installation, find its names with helm list --namespace pig and kubectl get deployments,jobs --namespace pig. Follow the manual release replacement before installing under the new name.

2. Enroll a host and create a session

Follow Enroll your hosts on one supported test device. Confirm that its analyzer address is https://traces.acme.example.
Start a new agent session after the configured analysis activation time. Use an installed Instruction Hub skill in a selected instruction repository and complete the session normally.
Confirm the collector uploaded the session with the runtime’s collect command, as in Verify collection. Record the agent source and exact session ID.

Use claude, claude-desktop, codex, or cursor as the source in the queries below. Replace REPLACE_SESSION_ID with the recorded ID.

3. Verify the enrolled host and durable storage

Connect to the dedicated PIG database with a read-only session. Query only the pilot session:

BEGIN READ ONLY;
SELECT t.id AS trace_record_id, t.source, t.session_id, h.host_label,
       h.last_seen_at, t.trace_object_status, t.trace_object_uri,
       t.trace_object_last_error, t.last_ingested_at
FROM agent_traces AS t
JOIN agent_hosts AS h ON h.id = t.host_id
WHERE t.source = 'codex' AND t.session_id = 'REPLACE_SESSION_ID';
COMMIT;

Confirm that host_label names the enrolled test device, trace_object_status = 'written', and the ingestion timestamp matches your pilot. trace_object_uri records the canonical object location for every supported storage backend.

Use the recorded canonical object location to inspect that exact object with your cloud’s storage tools. Do not infer its name from the session ID or select a nearby object by timestamp. Inspect the raw-object references too if upload reconstruction is under investigation.

Confirm the recorded bucket and key with your normal S3 inspection tools. The recorded URI begins with s3://.

The object must be readable through the analyzer’s workload identity. An administrator’s successful read alone does not verify the workload’s access. The supervisor’s acceptance check reads the object with that identity and compares it with the recorded revision. Do not copy session content into tickets or installation logs.

4. Confirm completed analysis

Allow the configured quiet window to pass after session activity stops. In analyzer logs, find Trace analysis run succeeded for the pilot’s trace_record_id. Keep its analysis_run_id and repository_sha.

Then check that the run analyzed the current revision of the trace and that Promptless acknowledged it:

BEGIN READ ONLY;
SELECT r.id, r.status, r.error_category, r.repository_sha,
       r.successful_finding_write_count, r.completed_at,
       r.source_fingerprint = t.analysis_source_sha256 AS current_revision,
       t.projection_published_revision >= t.projection_revision AS hosted_acknowledged
FROM agent_analysis_runs AS r
JOIN agent_traces AS t ON t.id = r.agent_trace_id
WHERE t.source = 'codex' AND t.session_id = 'REPLACE_SESSION_ID'
ORDER BY r.queued_at DESC
LIMIT 5;
COMMIT;

At least one run must have status = 'succeeded' and current_revision = true, and hosted_acknowledged must be true. Zero in successful_finding_write_count is valid. A queued or failed run, or a succeeded run for an earlier revision, has not passed this check.

5. Check the Promptless Dashboard

Open the Traces page and search for the pilot’s session ID. Confirm that its card shows the enrolled host, your analyzer under Worker, and Succeeded for analysis. A run with no findings shows No linked findings and Analysis completed with 0 successful finding writes. If the run produced findings, open their evidence and check the host and installed instruction attribution. Confirm the connected hub’s issue workflow receives the finding where configured.

On the Workers settings page, confirm the analyzer shows Healthy with a recent Last checked in time.

A local success with stale Dashboard status indicates a synchronization problem. Follow observability and troubleshooting from the first failing stage.

Record acceptance

Keep the analyzer installation name, release, agent source, session ID, trace record ID, analysis run ID, and verification time in your deployment runbook. Record the outcome of all four checks for the same session: enrolled host, readable durable storage, succeeded analysis of the current revision, and Dashboard acknowledgement. Also record when the Acceptance condition became True.