> ## Documentation Index
> Fetch the complete documentation index at: https://docs.luumen.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Transports and compliance

> How transport state feeds Luumen's compliance checks and security note matching, with example rules you can apply today.

Transport-related properties collected by the agent are first-class inputs to Luumen's compliance engine. You can write checks against them in the rule builder, group hosts by transport state, and use transport activity as a signal when correlating with SAP Security Notes.

For background on what transports are and what Luumen collects, see [SAP transports overview](/enterprise/integrations/sap-transports).

## Transport state in compliance checks

Compliance checks are built in **Acceptance to Run → Checks** using the same rule builder you use for any other property. Transport properties show up in the **left field** picker once the agent has reported them for at least one host in your fleet.

Useful patterns include:

* **Import queue should not pile up.** A check that queue depth is below a threshold (e.g., `import_queue_depth < 20`) flags systems where transports are accumulating without being applied.
* **No outstanding failed imports.** A check that the count of error-status transports equals zero (`failed_imports == 0`) catches systems carrying unresolved import failures.
* **Last import succeeded.** A check that the most recent import status is `success` (`last_import_status == "success"`) catches systems whose latest change broke and was never followed up.
* **Recent activity on production.** A check that production has had no transport imports outside a maintenance window can serve as a basic change-control signal.

Assign these checks to your SAP host groups (e.g., "SAP production application servers") so they only run where they apply. See [Creating checks](/enterprise/compliance/creating-checks) for the rule builder mechanics and [Assigning checks](/enterprise/compliance/assigning-checks) for tying checks to groups.

## Filtering and grouping by transport state

The same properties are available in host group filters. Common groupings:

* **"Systems with a pending import"** — filter on `import_queue_depth > 0`.
* **"Systems with import errors"** — filter on `failed_imports > 0`.
* **"Quiet production"** — production systems where no transport has been imported in N days.

Groups update automatically on each agent run, so as the queue drains and errors are cleared, hosts move in and out of these groups without manual intervention.

## How transport state interacts with security notes

[SAP Security Notes](/enterprise/alerts/sap-security-notes) are matched to hosts using the installed SAP components — not the transport state directly. Transport activity is still relevant during incident response in two ways:

* **Distinguishing applied vs queued fixes.** If a security note has a recommended SAP Note (transport) and you've imported it, the underlying component version on the host should now reflect the fix. If a security note keeps recurring after import, that's evidence the import failed or only partially applied.
* **Correlating recent changes with new findings.** If a host starts failing checks shortly after a transport import on it, the transport is a candidate root cause. The host detail page shows transport history alongside other properties for this reason.

## A worked example

Suppose your QA team imports a transport that touches a custom authorization object on `QAS01`. A few hours later, a compliance check that validates a specific config value fails on `QAS01`. The host detail page shows:

* The failing check (with the expected vs actual value).
* A new transport imported in the recent activity window.
* The transport's return code.

That's enough context to know which transport to investigate without leaving the UI. The agent doesn't tell you the transport caused the failure — but it surfaces the timeline so an SAP basis engineer can decide whether to roll back, fix forward, or proceed.

## Limitations

A few things Luumen does not do today:

* **No automated import action.** The agent reads transport state but does not import, release, or rollback transports.
* **No tight coupling between a transport and a check failure.** Luumen surfaces both on the same host timeline, but doesn't infer causation.
* **Default properties only.** The properties listed in [SAP transports overview](/enterprise/integrations/sap-transports#what-luumen-tracks) are what the agent collects out of the box. If your team relies on additional transport-related signals (e.g., a custom CTS table, transport buffer content), reach out to your account team to discuss adding them as part of white-glove setup.