# Runtime tachograph Esper scope processing

This document is kept for compatibility. The preferred architecture is now the common Runtime Processing execution model.

Preferred endpoint:

```http
POST /api/eventhub/runtime-processing/executions
```

Use:

```json
{
  "processingPlanKey": "driver-working-time-v1"
}
```

Legacy compatibility endpoint:

```http
POST /api/eventhub/runtime-processing/tachograph/esper-processing
```

still exists and delegates through the common runtime processing infrastructure.

Legacy profile endpoint:

```http
POST /api/eventhub/runtime-processing/event-processing
```

with:

```json
{
  "profileKey": "tachograph-driver-esper-v1"
}
```

also remains available, but new clients should use `processingPlanKey` and `/executions`.

When the runtime scope must mix file sessions, direct source databases, and EventHub-backed canonical events in one request, use `/executions` with per-source `sourceInputs`. The tachograph compatibility endpoints remain useful for file-session-centric scopes, but they are no longer the best shape for mixed-source runtime execution.

The current `driver-working-time-v1` plan uses these modules:

```text
event-to-activity-intervals
event-to-vehicle-usage-intervals
vehicle-evidence-attachment
support-evidence-normalization
driving-derived-projections
```

It can load runtime events from multiple sources and sessions, partition them by driver, attach vehicle-only evidence by vehicle/time overlap, normalize support evidence, and run the existing tachograph Esper/Java processing chain per driver partition.
