Goal-directed frontier
Status: open/planned · Kind: component · Audience: user
Summary
Section titled “Summary”- A goal-directed variant:
get_readywithtoward: [G]ranks nodes that advance goalG(its unfinished ancestors) ahead of the rest of the frontier, plus awhat_blocks(G)query. - Same push engine;
towardis a soft priority (a sort key), not a filter — spare capacity spills to non-goal work. - Sub-capability of C-D2GO-readiness-scheduling.
Statement
Section titled “Statement”“What is runnable anywhere” scatters effort; “what is runnable toward G”
focuses it. toward takes an ordered list of goals and ranks each ready
node by the earliest listed goal whose ancestors() include it (non-goal nodes
last), composed ahead of the normal sorter. limit then fills goal-advancing
work first and spills any spare capacity to the rest of the frontier — so “one
goal with leftover slots” and “a priority-ordered list of goals” are the same
mechanism. When nothing toward a goal is ready, what_blocks(G) returns the
ancestors that are pending but not runnable — the blocking chain to attack.
The strict “only goal work, exclude the rest” case is a filter
(only_toward), not toward.
What it provides
Section titled “What it provides”ReadyOptions::toward— an ordered goal list producing a goal-rank sort key applied ahead of the normal sorter; spare capacity spills to non-goal nodes.only_toward(goal)— a predicate forwhere_fn, for the strict case (drop everything not advancing the goal).what_blocks(schedule, state, goal)— the unfinished ancestors that are not yet runnable.
// goal work first, then spilloverReadyOptions { toward: vec!["M-0011".into()], limit: Some(4), ..Default::default() };
// M-0011 tier, then M-0012, then the restReadyOptions { toward: vec!["M-0011".into(), "M-0012".into()], limit: Some(8), ..Default::default() };
// strictly M-0011 ancestorsReadyOptions { where_fn: Some(Box::new(only_toward("M-0011"))), limit: Some(4), ..Default::default() };
what_blocks(&schedule, &state, &"M-0011".into()); // why it is stuckInputs
Section titled “Inputs”- An ordered list of goal node ids (one or many); the graph and state.
Outputs
Section titled “Outputs”- The frontier ordered by goal rank (goal-advancing nodes first, then spillover); the blocking set.
Underlying implementation
Section titled “Underlying implementation”- No code realizes this yet — the capability is planned. It lands with the crate
at
packages/rust/graph-scheduler/, goal-direction insrc/goal.rs. Until the crate exists there is no anchor to record here. - Deferred past cutover, not part of v0.1. The dispatcher’s first real work
order needs a frontier, filters and an ordering, not goal-direction. The
towardfield is declared onReadyOptionsfrom the start and left unread until this layer lands, so adding it costs no struct change.
- Built on C-409J-dag-core’s
ancestorsquery and C-PC3N-push-readiness-frontier — no engine change. Pairs naturally with the pull variant (C-FD3Q-pull-resolution). Motivated by DR-QKVQ-goal-directed-frontier.