An open protocol is not proof of a finished integration. Before investing, assess the specification, the specific implementation and whether the connector supports your business scenario from end to end. Also establish who owns migration, who monitors operations and what evidence counts as acceptance of interoperability.
In discussions about open protocols, compatibility often covers three distinct levels.
The first is the specification. It describes communication rules, message structures, expected behaviour and protocol boundaries. An open specification can make independent implementations easier to develop. It does not, by itself, confirm how a particular system behaves in live work.
The second is the implementation. This is the actual connector, client, server, adapter or module using the specification. An implementation may support only part of the specification, have its own prerequisites or handle errors, permissions and data differently. An existing connector should not be treated as compatible merely because an open protocol exists or a protocol change has been announced.
The third is the supported business scenario. Connectivity gains business value only when it reliably completes a defined workflow: it receives the right input, applies the right rules, records the result in the official system and leaves an audit trail for control. A technical connection without that workflow may be a successful demonstration, but it may not be ready for operations.
A note describing a protocol change and migration points to the need for this assessment. The MCP specification notes, July 28 2026 can serve as a starting point for editorial and technical review. For an existing connector, establish its actual scope of support, migration plan and behaviour on the selected business workflow.
An assessment of an open protocol in business should not start with whether a supplier says it supports a standard. It should start with the process and its ownership.
Select one important but contained workflow. A hypothetical workflow might start with a stock availability request and end in a reservation or rejected request, including a record of the decision reason. Do not test only the successful call. Include incomplete input, invalid permission, an unavailable dependent system, a repeated request and human intervention.
For each step, record:
An open protocol may solve part of communication between systems. It does not automatically resolve data ownership, business rules, permissions, ERP postings or accountability for the consequence of incorrect input.
Ask for evidence on your own process, not only a list of supported capabilities. That evidence should be repeatable and reviewable.
First, define a test set of inputs. It should include permitted, prohibited and edge cases relevant to the selected workflow. The business process owner confirms rules and expected outcomes. The data owner confirms data quality and permitted use of inputs. The technical owner confirms configuration and the execution record.
Then run the workflow through the real chain of systems. Follow the input, transfer, processing, decision, ERP record and output to the user or next system. When the workflow fails, record where the break occurred, who can see it, who decides recovery and whether the result can be safely repeated.
An acceptance criterion does not need an invented numerical target. It can be verifiable in another way: every pre-approved test case has a defined expected outcome; every result has a traceable record; an unauthorised request creates no official transaction; and every exception reaches a named owner. This type of criterion connects technical behaviour to business control.
A protocol change raises questions often skipped in a demonstration. Which connectors depend on existing behaviour? Is parallel operation needed during transition? Who decides to revert to the previous procedure? Which records are retained for comparison? Who confirms migration completion?
The migration owner should be a named person or role, not an undefined group of suppliers. This role coordinates the sequence of changes, maintains the dependency list, confirms readiness for transition and leads decisions on exceptions. The monitoring owner separately follows operations after transition: failed requests, unusual patterns, manual processing and differences between expected and recorded results.
The cost of maintaining compatibility is not limited to building an adapter. It includes testing after changes, maintaining data mappings, managing permissions, documenting exceptions, monitoring execution and business-user time during checks. Assess this cost through planned responsibilities, rather than as a one-time technical expense.
An open specification can reduce barriers to connection and make approaches easier to compare. It does not remove differences in data models, process rules or implementation quality. It also does not automatically determine who is accountable for an incorrect decision, incorrect record or missed exception.
For this reason, do not reduce the decision to whether the protocol is open. More useful questions are: does the implementation support our priority workflow, under which conditions, with which owners and with what acceptance evidence? If these answers are unavailable, the investment does not yet have a sufficient operational basis.
Before approval, prepare a short working package:
The ORKA approach starts with the business process and clear accountability. Orkasta owns daily collaboration, ERP remains the place for official transactions, and Trueforce is a specialised engineering offering. When a structured starting point is needed, Business process screening can help turn the selected workflow into verifiable inputs, decisions, exceptions and acceptance criteria.