# Logline Execution Semantics for AI

Logline evaluates candidate executions of scenarios against one canonical sequential input-record stream.

## Evidence-driven execution

Input records are evidence. The engine reads canonical records and advances scenario candidates when segment semantics are satisfied.

A passing program does not mean the system under test was controlled by Logline. It means the observed records satisfied the declared expectations.

## Canonical stream boundary

For a multi-source run, synchronization and composition happen before ordinary Engine segment execution:

```text
source records
  -> source-native timestamp interpretation
  -> exact canonical timestamp normalization to CTE
  -> deterministic multi-source composition
  -> one canonical sequential stream
  -> Engine
```

The Engine is not a source synchronization engine.

## Deterministic multi-source ordering

The current exact ordering rule is:

1. exact CTE timestamp;
2. resolved/frozen source order;
3. source-local cursor/record order.

Final `record.index` is assigned after this composition. Equal timestamps are allowed; the ordering policy makes their stream position deterministic.

## Segment progression

A scenario progresses through executable segments.

- `transition` evaluates expected signal changes.
- `event` evaluates record-level conditions.
- `group` observes a bounded span of records, freezes a collection at explicit completion, derives immutable values, evaluates assertions, and publishes a result.
- `repeat` executes child segments repeatedly.
- `parallel` executes branch segments according to its policy.
- `crossroads` selects a branch based on branch conditions.

## Direct record-matching leaves

Transitions and events are direct checks that match individual current records.

## Group

Group is a normal executable segment, but not a single-record matcher. While Group is active, the canonical cursor advances normally and Group remains the active segment.

Per inspected record, Group binds the current record, increments its inspected count, evaluates `collectionCondition`, adds the record if selected, then evaluates `completionCondition` against the updated Group state.

When completion becomes true, the captured collection freezes. Derived bindings are evaluated as an immutable dependency graph, named assertions run, and the result is published only if batch processing succeeds. The completing record is consumed by Group and is not replayed into the next sequential segment. A record meeting both conditions is collected before completion is tested, while an uncollected record may also complete Group.

The active `group.inspectedCount` includes the current record during `collectionCondition`; `group.collectedCount` includes the current record during `completionCondition` only if it matched. Derived bindings and `result` are unavailable to both per-record conditions. Source declarations (`GroupMember` in the grammar) are not the collected records.

A completed Group may collect zero records. End-of-input does not implicitly complete an unfinished Group and does not publish its result. Collection/retention safety-limit violations fail with diagnostics, not silent truncation or successful completion. Failed derivation, assertions, or result construction likewise prevent successful result publication. Immutable derived bindings may reference each other in forward order but cannot form cycles.

Downstream use of `GroupName.result` must be guarded by completion and success status. Execution values are candidate-local and cannot be referenced across scenarios; Group results inside Repeat retain their iteration order, and Crossroads branch-local results obey branch scope.

Group does not emit, insert, reorder, or replace canonical records.

A Group name may be used in `attemptedBy`. Group contributes attempt evidence when its completion condition becomes true, before post-completion derivation or assertion success is known. Group `importance` also participates in the essential-executable fallback when explicit `attemptedBy` evidence is absent.

## Structured segments

Repeat, parallel, and crossroads organize child segments and define progression behavior. Parallel is the explicit mechanism when multiple branches must observe the same record progression.

## Attempted, passed, failed, inconclusive, and not attempted

A scenario can fail even when there are no compiler diagnostics. Compiler diagnostics concern program validity. Scenario outcomes concern runtime evidence.

A scenario may be passed, failed, inconclusive, or not attempted according to its evidence and attempt policy.

`attemptedBy` and `attemptedWhen` control attempt classification. `attemptedBy` may name Transition, Event, or Group executable segments.

## Candidate lifecycle

A scenario may have multiple active candidates when records can start overlapping attempts.

`candidateConcurrency` controls whether the engine keeps a single active candidate or spawns multiple candidates.

`candidateOpening` controls whether a candidate opens on profile match or only when the opening condition passes.

## Temporal expressions during execution

The current record's canonical `timestamp`/`t` is already a CTE value when ordinary Engine execution sees it.

Payload temporal values are not automatically converted. Programs explicitly use `time.toCte(...)` and, when needed, preflight-resolved `time.reference(...)`/`time.anchor(...)` bindings.

Derived temporal values are expression data. They do not change record order or the canonical cursor.

## Reports and debugger traces

Execution reports describe scenario outcomes, inputs, attempts, diagnostics, progression, collector values, and expression provenance. Temporal expression provenance can retain named reference/anchor identities.

Debugger traces expose runtime progression for the Workbench. Trace event field names are internal reporting vocabulary, not Logline authoring syntax.