Docs / Optional Verification

Verify the conversation, not just each document

Your 850 order and 810 invoice both map successfully. Are they for the same purchase order? Did the invoice arrive within the agreed window? Are the required acknowledgments present? A scenario adds those checks around the maps you already use.

One example, four concrete pieces

Definition: what should happen?

A retailer sends one 850 order; a supplier returns one 810 invoice within 30 days. The example checks that the PO numbers match, the order maps successfully, and the invoice contains a total, an accepted transport receipt within 4 hours, and an accepted functional or implementation acknowledgment. It does not compare prices or line-item totals. The definition describes business roles, not your workspace's numeric partner IDs.

Binding: which configuration implements it?

Select the retailer partner, your workspace, the incoming 850 and outgoing 810 maps, and the Mapper expressions that read the PO numbers. You may specify exact syntax trees; otherwise ModernEDI resolves compatible trees when applying. The applied revision freezes the resolved dependencies.

Run: which exchange are we checking?

Start an evaluation of that exact binding revision and attach the persisted order and invoice transactions. Documents must satisfy the run's eligibility, identity, and frozen-configuration checks; an arbitrary old transaction is not interchangeable with a new test.

Evidence: why did it pass or fail?

Inspect the occurrences, matching checks, mapping results, and required receipt/acknowledgment evidence. A completed run records what was tested. Its immutable evidence report is available after the run is terminal.

Build on your existing maps

1. Start with working 850 and 810 maps.The first-document guide covers mapping and transaction setup. Scenario authoring is an optional advanced tool in Mapper.
2. Start from an example.In Mapper's optional scenario tools, open New scenario definition and choose Order and invoice. Read its checks and create the draft. Mapper copies the same public definition example with a fresh custom identity; no JSON copying is needed. Use File and version details if you want to change the defaults. The resulting *.scenario.json is fully editable, with JSON completion and hover help. Nothing is published, applied, or sent by creating it.
3. Validate, then publish.Validation checks more than JSON shape: references, conversation rules, fact types, and supported execution. Publishing creates an immutable definition identity. Use a new version when changing an already published definition.
4. Create and apply the binding.Use Bind (New scenario binding) in the scenario Explorer. Choose the published definition, your partner, and the actor represented by your workspace. For each mapped step, select Current runtime mapping and the matching live map. The form creates an editable *.binding.json draft; you do not have to type numeric resource IDs. Complete its fact expressions, validate, and apply to resolve the exact configuration.
5. Run and inspect.Start the applied binding from the authoring workflow or Implementation Verification. Follow the run's expected documents and attach eligible persisted transactions. Inspect each failed or inconclusive check rather than treating a green transport receipt as a complete pass.

“Applied” means the binding's configuration is valid and frozen, not that a business conversation has passed. A binding refresh after a map or partner change creates a new runtime revision; previous run evidence remains about its original revision. A configuration change affecting an active run can be blocked until that run is completed or cancelled.

Other starting points

Warehouse split shipment starts from the validated 940/945 example: one shipping order, two advices for that order within two days, different shipment IDs, and shipped quantities that add up to an expected total. Its binding needs expressions for order number, shipment ID, and shipped quantity. At run start, set expectedAdviceCount to 2 and supply expectedShippedQuantity. To check a different number of advices, change the transition's exact pair count in the definition (and the occurrence bounds if needed), then supply the matching expectedAdviceCount at run start. This example checks document facts, not mapping or acknowledgment success; add assurance requirements if you need those checks.

Minimal starter keeps the one-850 starting point for authors who want to design their own conversation. All three options use the same editor, validation, publishing, and binding controls. Examples describe checks; they do not provision partners or maps, select live resources, or operate your business workflow.

Reuse the expressions you already use in Mapper

A fact is a named business value the conversation needs to compare. For example, purchaseOrderNumber means the same thing on the order and invoice, even though X12 puts it in different places. In the binding form, use Add expression beside each fact:

850 purchaseOrder step

Read purchaseOrderNumber with ST->BEG(03). An order containing BEG*00*SA*PO-1042**20260908~ produces PO-1042.

810 invoice step

Read the same fact with ST->BIG(04). An invoice containing BIG*20260909*INV-73*20260908*PO-1042~ produces the same PO number. The definition's comparison can now detect an invoice for a different order.

These are ordinary X12 Mapper expressions, not another selector language. Selecting a current map can prefill a fact from its primary-key extractor when the names match and the expression is still empty. Review that choice and fill every required fact; the complete binding example also reads invoiceTotal from ST->TDS(01). Its IDs and hash are illustrations, not live resources to copy unchanged.

Leave the syntax tree on Automatic (recommended) unless you need an explicit pin. Apply must resolve one compatible current tree and freeze it. A draft map is not a live runtime target: deploy the map before selecting it for a runnable binding.

Verify again after a configuration change

When a map, partner, or binding change creates a new binding revision, its previous pass does not carry forward. This applies equally to browser changes, accepted Git changes, and reviewed recovery. Saved mapping tests can check proposed outputs before deployment; conversation runs check real evidence after deployment.

1. Open Change history → Conversations in this change.Choose Review new run beside an active revision. ModernEDI checks that the workspace still matches this change and that the exact binding is current. This read does not create a run, prepare an adapter, or send EDI.
2. Review the existing start form.The binding revision and its Test or Production traffic are preselected. Check the flow and enter any required parameters, then explicitly choose Start new run. Test and Production are not interchangeable; this action never converts a Production binding into a Test binding. The separate Warehouse test profile setup helper is collapsed here; expand it only if you need to prepare that managed example, not to switch this binding's traffic.
3. Gather fresh evidence and return to history.Follow the ordinary run controls to attach eligible transactions or explicitly advance adapter-controlled steps. Dispatch is a separate action with the usual permissions. Use the run's View configuration change link to return to history; previous reports remain available.

If the change is still publishing, wait and try again. If configuration or catalog inputs changed, review the current configuration and binding rather than substituting a newer revision. Retired bindings have no new-run action. Read-only members can inspect evidence but need Workspace Operate permission to start. An unresolved earlier request must be reconciled through the existing pending-request controls before starting another run.

This is optional and is not a deployment gate or a whole-workspace pass. The history section lists only the binding revisions created or retired by that change, with its existing bounded-history notice. Mapping-only workspaces require no scenario setup.

One workspace, separate traffic evidence

Once the browser workflow is useful, your application can automate the same run lifecycle through the Integration API. This is optional; it uses the existing evaluator, bindings, and evidence rather than another authoring system.

A binding records the traffic environment it checks: Production or Test. This choice does not create another workspace or deploy separate test maps. Both traffic environments use the same deployed mappings; editing a shared map can affect bindings in either environment. Use saved mapping tests to check unpublished map changes.

1. Complete the Test profile.Configure your workspace and partner's Test AS2 and X12 identities. Agree with the partner to send Test documents (X12 ISA15 T); a Production document (P) is not Test evidence. Managed sends use the selected profile and never substitute the Production identities when Test details are missing.
2. Apply a Test binding.In Mapper's binding form, choose Test under Scenario traffic, select your existing deployed maps, validate, and Apply. Changing an existing binding's environment creates a new immutable revision; it does not move transactions or alter previous runs.
3. Start, exchange, and inspect.Start the exact applied Test revision. For your own partners, exchange fresh Test traffic and attach eligible transactions. For a managed example, advance its guided sends. Inspect the Test-labeled run, transaction links, acknowledgments, and terminal evidence report.

Test partner and Test traffic mean different things. The simple managed 850→810 shortcut uses the ModernEDI-owned test partner with Production traffic. To run that conversation with Test traffic, create and Apply a Test binding instead. For the managed warehouse 940→945 example, choose the same traffic in Warehouse test profile preparation and in your binding. Preparation reports readiness for that profile and sends nothing; it creates shared partner/map dependencies, not a separate test deployment.

Partner and mapping scenario panels filter dependencies and expected documents by Scenario traffic. Transaction context follows the transaction's own environment, and evidence links return to that same traffic store. Recent run history combines both environments with explicit labels. Evidence from one environment does not prove a run in the other, even if the message IDs match. A binding must still be current and runnable before it can start.

Connect an actual transaction to the conversation

Open a persisted transaction and look for Eligible open conversations. Choose the intended run and use Attach transaction. The match checks the partner, direction, document type, X12 version, and frozen execution configuration. If several runs qualify, choose the correct exchange; matching a document type alone does not identify one business conversation.

For example, an 850 processed before a partner or map configuration change may not be eligible for a binding applied after that change. Its successful mapping result proves the old configuration, not the new one. Keep the old run as historical evidence. Apply a current binding and use fresh, agreed test traffic to verify the new configuration; do not rewrite transaction IDs or timestamps to force an old document to qualify.

Saved mapping tests catch changed output before deployment and can optionally validate generated X12. Scenario runs add checks across actual related transactions afterward. Neither a saved test nor a Git commit automatically proves that a live conversation passed.

What needs verification?

In Implementation verification, expand What needs verification? (optional). Choose Test or Production to see the latest retained run for each active binding revision, with earlier-revision reports clearly separated. If an invoice map changes, the old order-to-invoice pass remains historical; the new binding is shown without evidence until you verify it.

A newer failed or active run is not hidden behind an older pass. Missing evidence is not failure. A binding whose referenced configuration changed must be applied again; if its dependencies cannot be checked, the view does not call it current. Retired bindings remain in history. Test evidence never becomes Production evidence.

The open overview and run view check for updates about every 20 seconds while the page is visible, and when you return to the tab or reconnect. Refresh evidence is still available if you want to check immediately. If a check fails, the last successful data stays visible with a warning and automatic retry. Test and Production evidence remain separate.

Refreshing the screen only reads stored status. It does not attach transactions, advance a run, retry a pending command, or send EDI. Use the run's explicit actions when you want to gather or evaluate more evidence. Each checked time is a point-in-time read, not continuous verification or a whole-workspace verification badge. Review new run opens the existing setup for that exact binding and traffic; starting remains a separate confirmation. Mappings remain usable without scenarios.

Optional: rehearse with the ModernEDI test partner

The managed 850→810 flow exercises an exchange with the ModernEDI-owned test partner and records runtime evidence. It is useful for checking the platform setup without waiting for your real partner. It does not prove that your ERP, your customer's application, or an external trading partner participated.

A custom scenario is different: its binding determines the supported execution targets and which persisted traffic it can evaluate. Publishing JSON does not grant arbitrary outbound execution. See the generated reference for execution and evidence requirements.

Understand the outcome

Passed means the declared checks passed for the recorded definition, binding, documents, and environment. Failed means a check failed. Inconclusive means the evidence does not establish completion; it is not a pass. A cancelled run retains its history.

By default, a run without run-state or operation activity for 30 days closes as inconclusive during the scheduled sweep. Viewing a run does not extend that window. The reference documents inactivity, limits, retention, and the exact API contracts.

Verification is not partner certification or regulatory approval. It establishes only what the recorded checks and evidence support. Your application still decides when to fulfill orders or issue invoices.

Keep the same scenario in configuration history

Conversations in this change in Change history lists the exact binding revisions an operation created or retired, with links to their latest retained runs. A tenant-applied run links back to the change that created its binding. These are historical identity links, not a green verdict for today's live settings. See the PO0001 worked example for the complete connection between a map, its saved test, a conversation, and Git.

Published definitions and applied bindings participate in the same aggregate configuration and optional external Git synchronization as your maps and partners. Browser drafts remain separate until published or applied. Credentials, resolved runtime snapshots, and run evidence are not authored Git source.

Use the configuration and Git reference for portable resource keys and envelopes. Use the short guide below to connect a repository without giving up browser authoring.