Compatibility is not a file-format question. Two systems can accept the same YAML and produce different permission, network, cancellation, or failure behavior.
That is why Runnable treats the unsupported case as product output. A useful migration tool must be able to say no with enough precision that an engineer can act on the answer.
Parsing is only the first pass
A workflow is a graph of triggers, expressions, jobs, steps, credentials, and runtime assumptions. Copying the file proves only that the destination parser recognized the syntax.
Runnable evaluates the constructs that change execution meaning and classifies the result before opening a migration path. The report is an engineering artifact: it names the file, the construct, and the reason attention is required.
Three outcomes are enough
A workflow can run, it can require review, or it can remain where it is. Those states are intentionally plain. A percentage score would hide the one unsupported construct that matters.
- CompatibleThe workflow fits the published execution contract and can be piloted in parallel.
- ReviewThe workflow can move after a named assumption is confirmed or changed.
- BlockedRunnable will not execute the workflow as though an unsupported construct were harmless.
Refusal is a reliability feature
Silent degradation is attractive during a demo and expensive during a release. A skipped service, broadened token, or altered condition can produce a green run that should never have been green.
Failing closed keeps the migration reversible. The current CI remains the correct home for a workflow until Runnable can preserve its meaning.