Skip to content

Rulvar API reference


Rulvar API reference / @rulvar/core / OrchestrateAcceptance

Interface: OrchestrateAcceptance

Defined in: packages/core/src/orchestrator/orchestrate.ts:311

The opt-in child completion policy (the v1.40.0 improvement plan's completion contract): run status 'ok' alone never proves the children succeeded, because the model may call finish after any mix of child outcomes. When acceptance is set, the policy is evaluated exactly when the model's finish validates, the verdict is journaled as ONE decision entry (so a resume rolls the SAME verdict forward, immune to drift of the live options), and the workflow result becomes the acceptance envelope { result, completion, childStatusCounts, degradedReasons }. A violated policy fails the run with the typed FailRunError (code 'fail_run', data.source 'orchestrator_acceptance') instead of settling ok. A budget cap settle keeps its atCap policy and acceptance is not judged at the cap: under 'finish-with-partial' the capped terminal carries completion 'partial' in its envelope (RV906) precisely because the declared acceptance went unjudged, and under 'fail-run' the typed failure stands, so the cap can never impersonate an accepted finish.

Properties

PropertyTypeDescriptionDefined in
acceptPartialChildren?booleanThe partial-child salvage switch (RV-210 close-out; default false). When true, a child that settled 'limit' WITH a structured terminal partial (it recorded progress through the stock report_progress tool before the budget expired) counts as a successful child for the policy: under 'all-ok' it no longer rejects the run, and under { minSuccessful: N } it counts toward N. The acceptance verdict then reports completion 'partial' (never 'complete'), lists the salvaged children in salvagedPartialChildren on the result envelope, and keeps a per-child note in degradedReasons. A limit child WITHOUT a partial gave the caller nothing to salvage and still counts against the policy. The whole fold is journaled in the single acceptance decision, so a resume rolls the same verdict forward.packages/core/src/orchestrator/orchestrate.ts:335
acceptValidatedTerminalOutputOnLimit?booleanThe terminal-output salvage switch (the 1.64.0 experiment review, P0.4 + P1.1; default false). When true, a child that settled 'limit' CARRYING a terminal output counts as a successful child for the policy, exactly like acceptPartialChildren counts a partial-bearing one. A limit terminal carries an output ONLY when the child's limits.finalizationReserve summary turn produced one AND, for a schema child, that summary already validated against the declared output schema (an invalid summary keeps output null and is never salvaged), so validation runs BEFORE acceptance by construction. The verdict then reports completion 'partial' (never 'complete'), lists the children in salvagedTerminalOutputChildren on the result envelope, and keeps a per-child note in degradedReasons. A child carrying BOTH an output and a progress partial salvages by its output. The child's digest and get_child_result surface the output unconditionally (paid, journaled evidence is never withheld); this option gates only the acceptance fold, the evidencePreservedValidator cited pool (via FinishValidationChild.salvageableOutput), and the coordination prompt line. The whole fold is journaled in the single acceptance decision, so a resume rolls the same verdict forward.packages/core/src/orchestrator/orchestrate.ts:371
childPolicy| "all-ok" | { minSuccessful: number; }'all-ok' requires EVERY spawned child to have settled 'ok' when finish validates: a child still running counts against the policy, and so does a deliberately cancelled straggler (spawn nothing you do not need to succeed; zero spawned children are vacuously complete). { minSuccessful: N } requires at least N children settled 'ok' and reports every other child in degradedReasons.packages/core/src/orchestrator/orchestrate.ts:320
minSpawnedChildren?numberThe spawned-roster floor (RV507): finish is rejected when FEWER than this many children were spawned, under BOTH child policies. 'all-ok' alone treats zero spawned children as vacuously complete (spawn nothing you do not need to succeed), which lets a fan-out-shaped task settle ok without ever fanning out; the floor makes the intended decomposition binding. The journaled decision (and a rejection's error data) carries the actual spawnedChildren beside the configured floor, so a resume rolls the same verdict forward. Positive integer; policy only, never part of any identity.packages/core/src/orchestrator/orchestrate.ts:348
minTerminalOutputChars?numberThe character floor a limit child's STRING terminal output must clear, after trim, before the salvage arm above may accept it (RV4704, the eighth comparison experiment's first run): that run accepted a child as degraded-with-output on a 16-token finalize summary that carried no answer, and the acceptance decision read "validated terminal output" over bytes nobody could use. Default DEFAULT_TERMINAL_OUTPUT_FLOOR_CHARS; a below-floor string is a limit WITHOUT acceptance, its degraded note naming the character counts. Structured (schema-validated) outputs pass by their validation, exactly as before. 0 restores the pre-RV4704 acceptance byte for byte. Nonnegative integer; policy only, never part of any identity.packages/core/src/orchestrator/orchestrate.ts:386
requireEvidenceFloor?booleanThe binding evidence floor (RV1207, the sixteenth comparison run; default false). A salvage arm above accepts a limit child by the work it carries, which says nothing about the DECLARED evidence contract: in that run a worker settled 'limit' with 10 of 14 declared entries and was promoted through terminal-output salvage with the floor waived, so an 'all-ok' run reported status ok (completion 'partial') over an unmet contract. With this true, a child that declared an evidence contract it did not meet is NEVER promoted by a salvage arm: it counts against the policy exactly like an unsalvageable limit child, so 'all-ok' rejects and { minSuccessful: N } does not count it toward N. Salvage stays DIAGNOSTIC: the roster still records the arm that would have applied and the evidence verdict (marked floorRequired instead of waivedBySalvage), the degradedReasons name the shortfall with its counts, and the child's output stays visible through the digest and get_child_result exactly as before. A child with no declared contract, or one that met its floor, is untouched. Since RV1412 the same flag binds the floor for OK children too: a child that settled 'ok' below its declared floor counts against the policy ('all-ok' rejects; { minSuccessful: N } does not count it toward N), its roster row is marked floorRequired, and belowFloorOkChildren lists it. WITHOUT the flag such a child is visible but uncounted: the shortfall is a degradation note (so completion honestly reads 'partial', never 'complete' over an unmet declared contract), the list is present, and the verdict is exactly what it was before this shipped.packages/core/src/orchestrator/orchestrate.ts:416