Participation Modes

hustle.Participation selects one immutable session lane. The lane is a definition property, not a per-request hint.

Blocking and background

Both modes validate input, persist HustleStarted, run bounded inference, and persist one terminal audit event. A background mode does not make the output public or remove finalization ownership.

Proof: participation constants and lane execution tests.

Admission capacity

Each lane has executing and queued capacity. A run owns one slot across its queue and execution; queue capacity is not an additional unbounded backlog. FIFO order applies within a lane. A canceled queued run is finalized with a queue failure and releases ownership.

%%{init: {"theme":"dark"}}%%
flowchart LR
    R[facility request] --> V[definition and input validation]
    V --> B{blocking or background}
    B -->|blocking| BL[blocking lane]
    B -->|background| BG[background lane]
    BL --> E[execute and finalize]
    BG --> E
    E --> A[internal terminal audit]

Proof: lane controller and queue cancellation tests.

No caller-controlled lane switch

The definition’s Participation is included in its descriptor and policy revision. A facility selects a registered name; it cannot change a blocking definition into background execution by changing request JSON. Rig validation also requires compaction definitions to be blocking.

Proof: descriptor participation validation and compaction Hustle compatibility checks.

Source and proof

• Hustle participation and definition
• Runtime lane limits
• Scheduler lane implementation