Release & Transport

Transports imported in the wrong order cause activation errors or, worse, succeed and fail at runtime. Software collections are exported without an object they depend on.

• Transport Dependency Analyzer

  CTS transport sequence & cross-transport dictionary dependency validator

  TRANSPORT_DEPENDENCY_ANALYZER

• Software Collection Dependency Guard

  Export software collection cross-reference & release validator

  SOFTWARE_COLLECTION_DEPENDENCY_GUARD

• Transports whose referenced objects are in another, not yet imported request
• Objects contained in several requests with conflicting versions
• Software collections missing items their content depends on

• Transport dependencies: why imports fail or break production in the wrong order

  How dependencies between transport requests arise, what happens when a transport is imported without its predecessors, and how to check sequencing before an import.

Which engines does the Release & Transport preflight run?

Release & Transport runs 2 deterministic engines: Transport Dependency Analyzer and Software Collection Dependency Guard. Each engine documents its rules and input contract in the engine catalog.

Which files do I need for Release & Transport?

The engines in this area accept these file formats: CSV, JSON, XML, and ZIP. You create the exports in SAP and upload them; no direct connection to your SAP system is needed. The outbound-only local agent is optional.

Are the findings produced by AI?

No. Findings come from deterministic rules: identical exports produce identical findings. Where AI helps with explanations, the confidence of that content is capped at INFERRED and marked as such.

How is each finding backed?

Findings reference evidence in the uploaded file: its path, the line and column where the format has them, a redacted snippet and the SHA-256 hash of the file. Each finding carries a confidence class (VERIFIED, RULE_DERIVED, INFERRED or UNKNOWN); findings without verifiable evidence are demoted to UNKNOWN.