Verify your deployment

Verify one session from collection through completed analysis before expanding your rollout. Keep its session ID and deployment ID so you can correlate every check. An analysis with zero findings is a successful result.

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, codex, or claude-desktop) and session ID,
  or "tell me when to run a test session"]

Report each check (enrollment, stored and readable trace, succeeded analysis,
Dashboard visibility) 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 the automatic installation:

kubectl describe pigdeployment acme --namespace pig
kubectl logs deployment/acme-analyzer --namespace pig --tail=100
curl --fail https://traces.acme.example/healthz

Run the HTTPS check from the network your enrolled hosts use. Confirm the certificate, hostname, and routing. Ready=True means deployment checks passed; it does not prove a host can upload and complete analysis. Deployment verification also confirms selected-source readiness: an organization administrator selects instruction repositories in PIG Settings and enables analysis before the analyzer runs it.

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 its endpoint and deployment identity match this installation.
Start a new agent session after the configured analysis activation time. Use an installed Instruction Hub skill and complete the session normally.
Confirm the host checks in and its collector uploads the session. Record the agent source and exact session ID.

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

3. Verify durable storage

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

BEGIN READ ONLY;
SELECT id, source, session_id, trace_object_status, trace_object_uri,
       last_ingested_at, trace_object_last_error
FROM agent_traces
WHERE source = 'codex' AND session_id = 'REPLACE_SESSION_ID';
COMMIT;

Confirm trace_object_status = 'written' and an ingestion timestamp matching 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 configured identity. An administrator’s successful read alone does not verify the workload’s access. 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.

You can also check the database:

BEGIN READ ONLY;
SELECT r.id, r.status, r.error_category, r.repository_sha,
       r.successful_finding_write_count, r.completed_at
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 for the pilot’s completed session must have status = 'succeeded'. Zero in successful_finding_write_count is valid. A queued or failed run has not passed this check.

5. Check the Promptless Dashboard

Confirm the deployment and pilot session appear with current analyzer status. 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.

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

Record acceptance

Keep the deployment ID, 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: enrollment, readable durable storage, succeeded analysis, and dashboard visibility.

Repeat these checks after a storage migration, recovery, or material identity change.