Two green blocks.
One broken handoff.
Before combining two software blocks, compare what one says it produces with what the next one says it needs. A matching field name can still hide a different meaning, unit, contract version or privacy policy.
Declared output version · field metadata
Accepted versions · required input fields
Check the declared contract boundary
Use the fictional sample, or paste two small JSON manifests that contain only block names and public interface metadata. No workflow files, credentials, customer data or private tokens. The check happens entirely in your browser.
Start with the fictional example. Contract declarations are not runtime evidence.
Even zero declared blockers does not prove two programs run together, agree on real data, handle retries or preserve the right business meaning. A person must review actual source, permissions, test cases and end-to-end outcomes.
What does it check?
The pure moruneva.seam-preflight.v1 block checks a producer's advertised output version against a consumer's accepted versions, then compares required field names, types, semantic labels and units, while treating privacy levels as a boundary. It returns a versioned human_review_required JSON review.
What does it not do?
It does not fetch code, inspect real JSON Schema, transform records, run either block, check the real owner's authorization or connect external accounts. A bad declaration can produce a misleadingly clear result. Treat this as an early checklist, not a substitute for integration tests.
Example guide: why two passing blocks can still fail together → · Check actual pseudonymous field values with the separate Field Mapping Evidence tool → · Privacy →