Define remote polling and separated log/event retrieval shape for CUBE

[rudolphpienaar]

Task: Define remote polling and separated log/event retrieval shape for CUBE

Status

In Progress

Priority

P1

Context / Background

Following the async pfcon copy-init work, the next architecture task is to define how remote compute state is polled and how telemetry returns to CUBE.

Meeting discussion established that:

• log transport and event/state transport should remain separate
• CUBE will likely need distinct API handling for logs vs events
• future deployment reality may require swapping out some telemetry/logging components

Detailed Scope

1. Define the polling model for remote compute state.
2. Define the distinction between:

• raw log retrieval
• structured event/state retrieval

3. Identify the CUBE API surface likely needed for each.
4. Record assumptions about buffering, retries, and replay.
5. Explicitly identify which parts of the design must remain swappable for deployment-specific logging backends.

Acceptance Criteria

• Log and event paths are described separately.
• Proposed CUBE retrieval/API shape is documented.
• Buffering/retry/replay assumptions are recorded.
• Swappable component boundaries are explicitly listed.
• Open design questions are listed clearly.

Management Note

This issue is not asking for final infrastructure selection.

Out of scope:

• locking the design to Kafka
• implementing a final production logging backend
• unrelated CUBE changes beyond the telemetry/polling boundary