# Nexatron analytics and Claude MCP pilot worksheet

Version 1.0 | September 27, 2026 | Published by dotSolved Inc, maker of Nexatron

Use this worksheet to define and document a Nexatron pilot. It contains no
completed test results or product ranking. Edit it locally; no registration is
required. Keep credentials, personal data and confidential records out of shared
copies. Use approved synthetic data for access and failure tests.

## 1. Define the decision before the demo

- Business decision and accountable owner:
- Product edition, version and evaluation dates:
- Required sources and connection method for each:
- Workspace, user role and permitted data scope:
- Metric owner and approved definition:
- Time range, timezone, currency and grain:
- Reference report or independently reviewed query, prepared before the demo:
- Data snapshot or refresh timestamp:
- Required client: web, Claude, embedded application or another workflow:
- Budget, configuration time and acceptance thresholds agreed before testing:

Keep the data snapshot, definitions, role and questions consistent across repeat
runs. Record required configuration and explain any changes before interpreting
a different result.

## 2. Fixed question set

Replace bracketed terms once, then keep the wording fixed across repeat runs. Have a
business owner approve the expected result and allowed tolerance in advance.
Do not use one AI answer as the reference for another AI answer.

| ID | Question or task | Evidence to collect |
|---|---|---|
| Q1 | What is [approved revenue metric] for [closed period]? | Value, units, definition, filters, source and independent reference |
| Q2 | Break that same metric down by [region]. | All groups, null handling, truncation and reconciliation to Q1 |
| Q3 | Compare [period A] with [period B]. | Both values, absolute difference, percentage formula and zero-denominator behavior |
| Q4 | Which [product group] explains the largest change? | Complete ranking, contribution calculation and drill-through evidence |
| Q5 | Show [pipeline stage] alongside [recognized revenue] for [period]. | Separate definitions, cross-system join keys and unmatched-record treatment |
| Q6 | What does “revenue” mean here? | Clarification of ambiguity or explicit selected definition; metric owner and provenance |
| Q7 | Answer Q1 as an approved restricted user. | Independently defined allowed subset; no excluded rows, totals or metadata |
| Q8 | Request a synthetic record outside that user's allowed scope. | Intended refusal or safe empty response, without revealing the excluded record |
| Q9 | Repeat Q1 when an approved sandbox source is unavailable. | Clear failure or partial-result disclosure; no invented complete total |
| Q10 | Repeat the same metric through the required client and export path. | Same definitions and access scope; traceable differences and export behavior |

Q5 is appropriate only when cross-system analysis is a requirement. Do not combine
pipeline and recognized revenue as though they were the same measure. Q8 and Q9
require an authorized synthetic sandbox; do not disrupt production or probe an
unrelated tenant. A grouped sum matching a total proves internal consistency, not
independent accuracy.

## 3. Claude and MCP checks

- Record the remote endpoint, authentication method and connected user role.
- Discover the actual tool inventory. Separate read tools from state-changing tools.
- Start with source and metric discovery, then a bounded analytical read.
- Inspect the actual tool request and result, not only the assistant's explanation.
- Record whether the returned evidence includes source, definition, filters and
  execution status. Mark missing evidence as missing.
- Confirm that reconnecting or changing client does not broaden the intended scope.
- Record expected scope denials. A denied tool is not automatically a product defect.
- Test actions separately, only with explicit authorization and disposable synthetic
  records. Define expected side effects and rollback before execution. A preview is
  not proof that an action committed successfully.
- Record client version, model and tool approval settings. Do not loosen permissions
  to make a demonstration pass.

A connector can expose tools without supporting every application or workflow.
Record the specific supported operation, source and configuration you tested.

## 4. Workflow-specific acceptance checks

| Workflow | Add these acceptance checks |
|---|---|
| Semantic generation and layers | Generated definitions reviewed by an owner; joins, grain, nulls, timezones and version changes validated |
| Conversational analytics | Clarification, numerical reference checks, follow-up context and useful failure behavior |
| Dashboards | Shared metric definitions, filters, refresh status, restricted viewers and export consistency |
| Embedded BI | Host identity, tenant boundary, accessibility, mobile layout and session expiry |
| Enterprise search and agents | Document access and citation accuracy tested separately from numerical analytics |
| Native data platforms | Data locality, required copies, configuration effort and actual billed services |
| Claude and MCP integrations | OAuth, tool discovery, evidence, scoped reads and separately authorized actions |

These are acceptance checks for your pilot, not results.
Mark an irrelevant workflow N/A with a reason before scoring.

## 5. Scoring rubric

Agree on weights before testing. Score each applicable workflow from 0 to 3:

- 0: failed the agreed acceptance condition.
- 1: partial result with a material limitation or manual workaround.
- 2: met the condition in one documented run.
- 3: met the condition in repeated runs, including the agreed edge case.
- Not tested: no evidence yet. Do not silently convert this to a pass or omit it.

| Dimension | Suggested weight | Score | Evidence / unresolved issue |
|---|---:|---|---|
| Numerical correctness and definition fidelity | 30 | Not tested | |
| Access boundaries and safe failure | 25 | Not tested | |
| Source evidence and reproducibility | 15 | Not tested | |
| Required workflows and client usability | 15 | Not tested | |
| Setup effort and ongoing operation | 10 | Not tested | |
| Measured cost and response time | 5 | Not tested | |

The suggested weights total 100. Change them for your decision before testing.
For tested dimensions, calculate sum(weight × score / 3). Report tested-weight
coverage alongside the score; do not treat an incomplete pilot as a passed
evaluation. Any unauthorized disclosure or unauthorized write fails the
acceptance gate regardless of the weighted total.

Record setup time separately from query time. For timing, use the same question set
and at least five measured runs per question, reporting median, range, errors and
cache conditions. Record observed billing and its measurement window; do not infer
cost from a vendor's headline price. No response-time or cost threshold is assumed
by this worksheet.

## 6. Result record (copy for each test)

- Test ID / exact question:
- Date, product version, model/client and configuration:
- Synthetic fixture or approved snapshot reference:
- User role and expected access boundary:
- Expected value/behavior, reference owner and tolerance:
- Actual value/behavior:
- Definition, source evidence, truncation and freshness:
- Elapsed time, errors, retries and cache condition:
- Measured cost, or Not measured:
- Pass / Partial / Fail / Not tested:
- Evidence location (access-controlled where needed):
- Limitation, owner and next action:

Retain failures and retries. Do not select only the best run. Do not publish
customer names, records or results without approval. A synthetic walkthrough is
not a customer case study, an independent benchmark or a promise of future results.

## 7. Make a decision

- Required acceptance gates passed:
- Untested requirements and impact:
- Best fit for this specific workload and why:
- Configuration or migration work still needed:
- Decision owner, review date and next milestone:

Bring the completed non-confidential requirements to your evaluation conversation:
https://nexatron.io/resources

Claude setup and supported workflow guidance:
https://nexatron.io/claude

Measurement principles:
https://nexatron.io/how-we-measure

Claude is a trademark of Anthropic, PBC. Nexatron and dotSolved Inc are not affiliated with,
sponsored by or endorsed by Anthropic.