> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/platform-overview/evaluation-packet.md).

# Technical Evaluation Packet

Build a technical decision packet with deployment boundaries, capability confirmations, pilot acceptance criteria, integration effort, and traceable outcome evidence.

Use this packet to record the evidence for a pilot or deployment decision. Engineering, security, operations, and procurement reviewers should be able to identify the proposed scope, verified capabilities, remaining dependencies, and terms of operation from the same record.

Start with [Evaluating Concurrence](/platform-overview/evaluating-amigo.md), the [reference deployment](/platform-overview/reference-deployment.md), and the [capability matrix](/platform-overview/capability-availability.md). Complete the worksheets with actual systems, named owners, and observed results. Give unresolved requirements an owner and decision date.

## Assemble the Decision Record

| Artifact                       | What the reviewer should be able to answer                                                      |
| ------------------------------ | ----------------------------------------------------------------------------------------------- |
| Architecture and data-flow map | Which systems process the data, where the boundaries are, and which team owns each interface    |
| Capability confirmation        | What is enabled in this deployment, what needs provisioning, and what is outside the pilot      |
| Integration plan               | Which source, identity, action, channel, and operational dependencies remain, with named owners |
| Acceptance plan                | Which cases and failure conditions determine whether to proceed                                 |
| Evidence register              | What each result proves, where to inspect it, and what remains unknown                          |
| Decision and operating handoff | Who approved the scope, what conditions remain, and who handles failures after launch           |

Download the editable worksheets below. They are planning artifacts, not API payloads or contractual commitments, and do not require GitHub organization access.

{% file src="/files/Q2hVjgcuD2PCB3CJyxTL" %}
Pilot scope, acceptance criteria, evidence, ownership, and decision worksheet.
{% endfile %}

{% file src="/files/sapxI7KHo6p7R2yj8L5Q" %}
Integration dependencies, owners, access lead time, implementation, and validation worksheet.
{% endfile %}

## Define the Pilot Before Running It

Record the workflow, eligible population, intended channel, source and target systems, configuration selection, and excluded actions. Choose a baseline that measures the same work: include unresolved cases, manual handling, and external outcomes. State the observation window and why the cases represent the deployment.

Agree on thresholds before viewing the results. Separate correct workflow execution, target-system success, conversation quality, time, cost, and business outcome. An aggregate score can hide an unacceptable failure in a small but important segment.

### Synthetic Completed Example

The following is a **fictional evaluation record** for a scheduling test system. Identifiers and observations illustrate how to organize evidence. They are not a Concurrence API response, a customer case study, or measured product performance.

| Decision field    | Example value                                                                                                                 |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Scope             | Move one synthetic appointment to an allowed alternative in a test scheduling system                                          |
| Test channel      | Application text only; phone and messaging are outside this test                                                              |
| Baseline          | A reviewer performs the same fixture cases manually and records the outcome; timing comparison is still unmeasured            |
| Configuration     | Test service `scheduling-review`; record actual selected agent/graph and integration versions before execution                |
| Success criterion | For every approved fixture change, the target read-back matches the requested record and value; no false completion statement |
| Required failures | Unauthorized subject, missing slot, rejected approval, target rejection, and interrupted response after submission            |
| Stop condition    | Any unintended target change or a claim of success without supporting target evidence                                         |
| Decision owner    | Named customer workflow owner, supported by technical and operations reviewers                                                |
| Decision          | Hold until the interrupted-response case has a documented reconciliation outcome and owner                                    |

### Follow One Outcome Through Its Evidence

| Stage                | Synthetic evidence                                                                        | Claim it supports                                               |
| -------------------- | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Source               | Fixture appointment `appt-example-01`, original slot A, read at test start                | The case has an identifiable starting record                    |
| Context              | The test run's inspected context includes that appointment and allowed slot B             | The workflow had the information needed for this decision       |
| Configuration        | Saved service selection and graph/action configuration                                    | The reviewer can identify the configured path used in this case |
| Authorization        | Test principal permitted to change only this synthetic record; a negative case is refused | The tested access boundary behaves as expected for those cases  |
| Approval, if enabled | Reviewer grants the exact A-to-B request; no target change occurred while parked          | The human decision was recorded before execution                |
| Action               | Integration result carries the test target's acknowledgement reference                    | The target acknowledged that particular request                 |
| Read-back            | Test target reports `appt-example-01` at B                                                | The intended external change is independently observed          |
| Agent answer         | The recorded answer states that the appointment moved to B                                | The answer is consistent with the observed target state         |

For the interrupted-response case, the action result is unknown until the target is inspected. Record **unresolved**, identify the reconciliation owner, and hold retries. Do not fill the acknowledgement field from an agent's statement or from the approval record.

The [First Verified Conversation](https://docs.concurrence.com/developer-guide/guides/first-verified-conversation) starter produces a smaller executable evidence file. Its `external_action_verified: false` is intentional: it verifies a durable answer and conversation closure. Extend testing with [Verify an Integration Action](https://docs.concurrence.com/developer-guide/guides/verify-an-integration-action) to collect target-system evidence.

## Compare Effort, Cost, and Latency

For hospital integrations, complete the [HL7v2 integration review](/data/healthcare-interoperability.md) before estimating effort. Record inbound ADT/SIU feeds, outbound scheduling authority, acknowledgments, source-to-agent freshness, and recovery cases. An interface that is not yet verified remains a pilot dependency.

Complete the effort worksheet for access, mapping, implementation, validation, and operations. Track prerequisites and calendar lead time separately from engineering effort. Record assumptions and exclude work that has not been scoped; a universal deployment duration would conceal those dependencies.

Use [Cost and Latency](/platform-overview/cost-and-latency.md) to define the units and measurement boundary. Include retries, incomplete work, human handling, and external-system delay in the comparison where they affect the workflow. Keep contractual price inputs separate from Concurrence's internal cost allocation.

## Make the Decision Reviewable

State what the current meeting is intended to decide: architecture and ownership, a scoped implementation phase, or production purchase and launch. A live architecture walkthrough can resolve scope, access, and pricing together; it does not need to imply those terms are already agreed. Record the decision, remaining conditions, and owners afterward. Purchase approval needs the defined scope, commercial terms, and acceptance milestones for the work being purchased.

For customer-owned agents, attach the [cloud ownership review](/platform-overview/cloud-ownership.md). For patient outreach, attach the [channel program review](/channels/program-readiness.md). Label existing product behavior, deployment configuration, and proposed work separately, including what the customer will be able to inspect through APIs or an operator UI.

Choose **proceed within the recorded scope**, **proceed after named conditions**, or **hold**. Link each condition to an owner, evidence required, and review date. Include region/data-flow confirmation, retained/exportable evidence, support boundaries, staffing, and recovery behavior in the handoff.

After a configuration, source, or channel change, rerun the affected cases and update the decision record. A passed text pilot does not authorize a different channel or a broader clinical workflow. The [Operating Model](/platform-overview/operating-model.md) explains the decisions your organization continues to own.

## Complete the Enterprise Review

Technical acceptance is one part of a deployment decision. Record the following alongside the pilot results, using the proposed agreement and current assurance materials for commitments that product documentation cannot establish.

| Review area                  | Decision record                                                                                                                           |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Product fit                  | Required capabilities, confirmed deployment availability, excluded uses, and any dependency on custom or proposed work                    |
| Architecture and integration | Systems of record, interfaces, data flows, access requirements, mapping ownership, and tested failure handling                            |
| Security and data governance | Reviewed access controls, regional processing, subprocessors, retained artifacts, deletion and hold procedures, and applicable agreements |
| Reliability and support      | Agreed service levels, capacity assumptions, support hours, incident ownership, escalation, and recovery evidence                         |
| Delivery and staffing        | Scope of implementation work, prerequisites, named owners, acceptance milestones, and ongoing operating effort                            |
| Commercial terms             | Pricing units, expected volume, third-party charges, implementation cost, and cost of exceptions or incomplete work                       |
| Portability and exit         | Exportable data and configuration, permissions and formats, transition assistance, migration work, and termination obligations            |

Link [Compliance and Audit](/operations-and-safety/compliance.md), [Data Residency](/platform-overview/data-residency.md), and [Cost and Latency](/platform-overview/cost-and-latency.md) to the corresponding review. Record exceptions explicitly, including who accepts them and when they must be resolved. A pilot approval covers its stated scope; production approval needs the operating arrangements for that scope as well.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.concurrence.com/platform-overview/evaluation-packet.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.