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, the reference deployment, and the capability matrix. Complete the worksheets with actual systems, named owners, and observed results. Give unresolved requirements an owner and decision date.

Assemble the Decision Record

For a connected example, follow One Patient, Two Workflows. Inspect the source records, the approved next step, and the scheduling confirmation; then identify what the second workflow reuses and what it owns. The downloadable case is illustrative evidence for understanding the review, not a completed customer acceptance 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.

pilot-worksheet.csv

1KB

Open

Pilot scope, acceptance criteria, evidence, ownership, and decision worksheet.

integration-effort.csv

947B

Open

Integration dependencies, owners, access lead time, implementation, and validation worksheet.

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 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 to collect target-system evidence.

Compare Effort, Cost, and Latency

For hospital integrations, review the exchange patterns and interface scope before estimating effort. Record inbound feeds, outbound scheduling authority, acknowledgments, source-to-agent freshness, and recovery cases. Assemble the hospital handoff documents, including the interface specification, data mapping, test plan, and go-live runbook. 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 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.

Evaluate First-to-Second Workflow Reuse

A platform evaluation should include an adjacent workflow with its own operating owner and accepted outcome. Record what the second workflow inherits and what must still be built, provisioned, or approved. A second conversation on the same service is not, by itself, evidence of a second valuable workflow.

Use Connect Another Workflow for the participation contract and recovery tests. Compare source connections, identity mappings, data definitions, and functions; then account for new action authority, channel setup, task logic, and ongoing support. Include access lead time and unresolved cases rather than reporting only implementation time or successful runs.

workflow-reuse-worksheet.csv

1KB

Open

First-to-second workflow reuse, effort, recovery, and acceptance worksheet. Complete it with observed evidence; no results are prefilled.

The acceptance record should show both workflows working coherently, the incremental effort to reach the second outcome, and an owner who can operate the result. Have another implementation owner repeat the documented setup before calling it a repeatable package. Claims about lower cost, faster deployment, or clinical benefit need their own measured comparison.

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. For patient outreach, attach the channel program review. 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 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, Data Residency, and Cost and Latency 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.