Verify your setup

Do this verification after instrumenting the first application and after any material SDK or collector configuration change. Your agent does the checks. You open the proof pages it links to.

Ask your agent

Check my Anectico setup with the test customer anectico-verification-user and the error message "anectico verification error". Tell me what is confirmed, what is missing, and give me the links.

Job	MCP tool or action	CLI command
Confirm that the stored customer, trace, error and event connect	instrumentation_doctor	anectico doctor instrumentation
Check that both Anectico origins are reachable	none	anectico doctor
Find the test customer	search_persons	anectico persons search
Read the customer's timeline	get_person_timeline	anectico persons timeline
Find the test error's issue	search_issues, get_issue	anectico issues search, anectico issues view
Find the test trace	search_traces, get_trace	anectico traces search, anectico traces get
Read a metric point	query_metrics	anectico metrics query
Read the saved setup draft of the first application	get_onboarding_setup	anectico onboarding-setup get

The agent can give you a link to the customer, the issue and the trace. Open them to check what it found. The pages are read-only. See Proof pages.

Product events or feature flags only

The customer story above needs a test error and a trace. When the application only sends product events or evaluates feature flags (a JavaScript or Node server, or a direct REST or OTLP integration), it has no test error to send, and it does not need one. Ask your agent to verify that job alone:

Verify the product events my test just sent, by their message IDs, against tracking plan revision 3.

Job	MCP action	CLI command
Verify the selected product events or flag exposures of one test	verify_integration	anectico doctor integration --file request.json

The answer covers only the job you name. Its errors, traces, logs and replay are neither required nor checked. See integration job verification, the workflow in Ask your agent to integrate Anectico and what a verified sample does not prove in What integration verification proves and what it does not. The runnable integration examples run this check after a scripted test of a Node and a Ruby application.

Check intake credentials

Use a browser_capture, mobile_capture or server_capture key for product capture and a separate native_ingest key for OTLP. A management key will be refused by these routes. Create the keys in the setup guide (/get-started), under Agents and keys in the Console, or through MCP, CLI or the API, and check their source and purpose using native intake keys. Verify each configured client separately; the JavaScript core client takes apiKey for native OTLP and captureApiKey for identity and group capture. Go uses WithAPIKey plus WithCaptureAPIKey; Python uses api_key plus capture_api_key. All three read ANECTICO_CAPTURE_API_KEY in server environments. Standalone analytics clients take the capture key in their own API-key field. A facade sharing one key cannot send both signal families.

Before the test, check the product and technical policy: ask your agent to read it with get_family_policy (CLI: anectico usage policy get), or open Billing and usage in the Console. If the policy shows that your allocations need to be chosen, capture and OTLP are refused (a retryable 503) until they are configured. A usage measurement that has not refreshed yet does not block intake; the usage view shows the time its numbers are as of. See usage, model prices and decision scoring.

Send a recognizable test

Use a unique customer ID and error message so you do not confuse the test with real traffic.

distinct_id: anectico-verification-user
error:       anectico verification error
environment: development

If your SDK buffers data, stop it gracefully or call its flush method before ending a short-lived test process.

For a product event, keep its message ID, timestamp, identity and payload unchanged if delivery is uncertain. A capture HTTP 200 contains a per-item ledger: QUEUED means the queue accepted that position, REJECTED needs an input or capacity change, and UNKNOWN permits an exact-ID retry. The ledger is not proof of storage or query visibility. A new OTLP exporter submission has no required retry identity and can consume capacity again. OTLP partial success reports sampled positions and is final for that submission. See capture acknowledgements and plans and limits.

If the event or span does not appear, check the capture item outcome or OTLP response first, then the family's admitted counts (they are a snapshot and can trail by a few minutes). Admission counts are independent of retained rows: a count increase does not establish storage, complete source coverage or a linked customer story. Revoking a credential prevents new admission; records already accepted into the queue still complete. Deleting a project stops both new work and completion.

Sample the controlled test trace

For a service or browser trace test, explicitly set the SDK's trace sample rate to 100% before starting the test: traceSampleRate: 1 in JavaScript, trace_sample_rate=1.0 in Python, or WithTraceSampleRate(1) in Go. The quickstart includes these settings. The Go and Python defaults are 10% of root traces, even in the development environment.

Start a new test trace and preserve its sampled decision across trusted service boundaries. An unsampled parent is not made sampled merely by raising a downstream root sample rate; explicit error capture can be retained while its ordinary parent spans are absent. With an existing OpenTelemetry provider, configure the application's sampler rather than expecting an SDK option to replace that provider's settings. Restore your normal production sampling after the test.

Verify the first application

The setup guide in the Console (/get-started) and the doctor check a small, useful story before browser propagation or replay:

• A service or browser test needs an identified customer, a span with that customer's identity, and the exact named error on that trace.
• A mobile test needs an identified customer, the exact named error, and the named diagnostic event on that customer's timeline within the same time window. It checks across environments and does not verify a trace or session join.

Run the task supplied to your agent, or the manual example. Then ask the agent to run the doctor (instrumentation_doctor, or anectico doctor instrumentation). In the setup guide, select Check my test instead. The guide looks for your test customer and test error on its own and rechecks every few seconds; select Verify customer story to check immediately. Pasting a trace ID is optional and pins the check to one particular run. This checks the last hour and links the real customer and issue only when the required evidence is found. Missing data remains unconfirmed; follow the next action and retry after processing. Re-run the test if it has aged out. See Instrumentation diagnostics.

Add browser-to-backend verification

Ask your agent to run the doctor in journey mode, with a controlled browser-to-backend request:

1. Configure the browser and backend with different service names (for example web and api) and the same project and environment. Enable trace propagation only to your trusted backend and allow traceparent, tracestate and baggage through its CORS policy. See Connect browser and backend.
2. Identify the test customer before the request. Send checkout_started from the browser using the same identity and session as the request.
3. Make that request produce a controlled backend exception inside its active trace. Export both the browser client span and its direct backend server child; preserve person identity across the boundary. Copy this request's trace ID.
4. When testing replay, enable it for this controlled session and wait for an upload. Otherwise clear Verify replay for this test session.
5. Give the agent the trace ID, customer ID, expected event, service names and environment. The doctor accepts a diagnostic time window of 15 minutes, 1 hour, or 6 hours.

A verified result requires an identified person, linked client and server spans carrying that person's aliases, an error on the same trace, the named event in the browser session, and, when requested, a replay session with the same session ID. It links the issue and customer for inspection. It verifies this sample's stored relationships; SDK configuration, complete delivery, replay playback and an AI explanation still need their own checks. If the profile or any required signal is missing, withheld or unavailable, the story is not verified. Retry after export and processing and follow the individual next actions. At most 200 items per required timeline signal are examined.

CLI equivalent (select the same project):

anectico doctor instrumentation --trace-id '<32-hex-trace-id>' \
  --person anectico-verification-user --event-name checkout_started \
  --browser-service web --backend-service api --environment development

The CLI expects replay by default in journey mode; use --expect-replay=false when replay is intentionally disabled. See Instrumentation diagnostics for REST, MCP and permissions.

Check the customer first

1. Ask your agent to search for anectico-verification-user in the expected project and environment.
2. Confirm the customer has recent activity.
3. Open the customer's proof page (/view/person/...) from the agent's link. Confirm the error and the trace point to the same customer.

Finding a trace without finding the customer means ingestion works but identity is incomplete. See Customer activity is not connecting.

Check the issue

Ask your agent for the issue that holds the test error. Open the issue proof page (/view/issue/...) from its link. Confirm that:

• the occurrence is grouped under one issue;
• the affected customer is present;
• the trace link opens the expected request; and
• a replay is linked when browser replay is enabled.

Check metrics when they are part of the rollout

Emit anectico.verification.value with value 1 and label check=setup. Wait for one metric export interval. Then ask your agent to read the metric in the same project and environment over the last hour (query_metrics, or the CLI command anectico metrics query), and confirm that a recent point appears.

If traces arrive but the metric does not, check whether metrics are enabled and whether the test process shut down its client or Meter Provider cleanly. See Record application metrics for SDK examples and a CLI check.

Check the agent's answer

Ask your connected agent a narrow question using the test identifier:

What happened to anectico-verification-user in the last hour? Cite the evidence.

The answer should cite the evidence you just inspected. An answer with no matching evidence usually means the project, environment, or time window is wrong.

Roll out only after this passes

Once the full path works, add the next service or application. Preserve the same stable customer ID and propagate it only across trusted internal boundaries. Re-run this check after each expansion.

For a declared browser or mobile event, optionally add a pinned tracking-plan ID and revision to the instrumentation doctor. It reports project-wide schema observations separately from your person-linked journey verification.