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

then

Trace storedRead the exact object using the analyzer identitytrace_object_status = written

then

Analysis completedFind a succeeded run for that sessionstatus = succeeded

then

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.

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.

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

2. Enroll a host and create a session

1. Follow Enroll your hosts on one supported test device. Confirm its endpoint and deployment identity match this installation.
2. Start a new agent session after the configured analysis activation time. Use an installed Instruction Hub skill and complete the session normally.
3. 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.

S3

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

Azure Blob Storage

Confirm the recorded account, container, and blob name in Azure Storage Explorer or your approved Blob inspection tool.

Google Cloud Storage

Confirm the recorded bucket and object name in Cloud Storage or your approved storage inspection tool.

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.