Profile and version
Identify the exact subset, rule and profile version being evaluated.
The design goal is a stable integration contract with transparent ownership, mapped input, rule version, result and review boundary.
{
"trip_id": "example-trip",
"consignments": [{
"consignment_id": "example-consignment",
"stops": [],
"parties": [],
"documents": []
}],
"provenance": {
"source_system": "example-tms",
"mapping_version": "example-v1"
}
}This is an illustrative internal shape, not a new exchange standard. Real integration profiles must adopt relevant external specifications and handle multi-stop, multi-consignment access boundaries.
Identify the exact subset, rule and profile version being evaluated.
Link a missing or conflicting value to the system and party that can fix it.
Retain the check time, fixture or payload reference and review state.
| Capability | Status | Meaning |
|---|---|---|
| Browser assessment and field-name scanner | PUBLIC DEMO | Local educational tools only |
| Paid software entitlement | NOT AVAILABLE | No account, live checkout or paid tool release |
| Document Runtime Preflight | TEST DESIGN | Spain DeCA conformance design; scope and limitations |
| Public preflight API / SDK | PLANNED | No public endpoint |
| Read-only Compliance MCP | PLANNED | Same scoped, permissioned rules and evidence as API; no MCP server is deployed |
| Authority submissions | NOT AVAILABLE | Do not treat this project as a certified platform or Gate |
A future Compliance MCP Server would expose get_shipment_readiness, explain_blocking_issue, get_country_requirements, get_rule_source, get_gate_status, check_document_runtime and get_evidence_pack. Every response must carry tenant and user authorization, scope, rule version, source, observed time and UNKNOWN or REVIEW REQUIRED where evidence is missing. No write tools or authority submissions are in the current scope.
Explore the public demo and compare proposed software plans. Paid access is not open yet.