Editing Openai/694057b6-101c-8007-9a65-c40578c7252d (section)

=== Assistant: Perfect — then I’d explicitly broaden “signals” from “error/health flags” into a structured control channel that can al… ===
Perfect — then I’d explicitly broaden “signals” from “error/health flags” into a structured control channel that can also ask for decision input from your higher-level manager (human or model), without forcing it to read/interpret the whole raw output.

==== ### ====

A signal is a small, machine-readable record emitted by the generation worker and returned alongside the text result (or even with an empty text result).

Minimum fields:
* type: "issue" | "escalation" | "decision_request" | "outcome"
* code: stable short string enum
* severity: "low" | "med" | "high"
* summary: short, human-readable
* meta: small JSON dict (bounded size)
* request_id: for correlation (worker fills this)

===== - Signals are optional. =====
* Signals are bounded (e.g., max 3 per request; max 4KB total).
* Signals are hints, not authoritative—your orchestrator decides what to do.

==== ### ====

Expose a tiny tool set that the worker intercepts. Example tools:
# signal_issue(code, severity, summary, meta={})
# request_escalation(reason, summary, meta={})
# request_decision(question, options, default_option=None, context=None, meta={})
# declare_outcome(code, summary=None, meta={})

Worker behavior:
* Capture the tool call → add to signals[]
* Optionally end early after certain tools (e.g., request_decision)
* No normal “tool round trip” needed unless you want it (keep it one-way for v1)

This keeps it natural for models that already understand tool calling.

===== Your BIOS prompt should explicitly tell the model something like: =====
* “If you need a higher-level decision, call request_decision and stop. Don’t keep guessing.”

==== ### ====
* question: concise decision prompt
* options: list of 2–6 options, each with: - id (short stable key) - label (short) - pros / cons (optional, very short)
* default_option (optional)
* context: short context summary (not full transcript)
* meta: can include “what happens next” hints, e.g. {"next_step": "rerun_with_choice"}

===== When the orchestrator sees a decision_request signal, it will: =====
# store it as a pending decision (keyed by request_id or a decision_id)
# obtain a decision (human or a higher-level model)
# start a new request later with: - the original task restated briefly - the chosen option injected (and optionally the rationale) - and a note like “Decision chosen: X; proceed.”

This matches your “nuke & repave” style: no resuming the same stream required.

==== Keep the enum small and stable: ====
* NEEDS_MANAGER_DECISION
* NEEDS_EXTERNAL_INFO
* NEEDS_HIGHER_REASONER
* TOOL_LIMIT_REACHED
* LOW_CONFIDENCE
* LOOP_DETECTED (your repeated-line detector can emit this too)
* MAX_TOKENS_REACHED
* POLICY_RISK (if you want a safety escalation lane)

==== Add a worker option: stop_on_decision_request = True (default). ====
* If the model requests a decision, the worker ends generation immediately and returns the signal.
* Prevents the model from “making a choice anyway” and wasting tokens.

If you want, we can next define the exact schemas for these control tools (OpenAI JSON schema for parameters) and the BIOS wording that reliably causes models to use them instead of rambling.