diff --git a/.agents/skills/author-baseline-dgd/SKILL.md b/.agents/skills/author-baseline-dgd/SKILL.md new file mode 100644 index 000000000000..5e1277a14545 --- /dev/null +++ b/.agents/skills/author-baseline-dgd/SKILL.md @@ -0,0 +1,93 @@ +--- +name: author-baseline-dgd +description: >- + Drafts a candidate baseline DynamoGraphDeployment from interview requirements when no catalog recipe matches the + user's model, hardware, and backend, presenting per-decision evidence for the user's confirmation. Use only from + user-interviewer at interview time, at rung 3 of the baseline-source ladder, and never to deploy or to replace a + baseline the user already provided. +license: Apache-2.0 +metadata: + author: NVIDIA + tags: + - dynamo + - workload + - interview + - optimization +--- + +# Author Baseline DGD + +Draft ONE candidate baseline DGD for a greenfield engagement and present it for the user's explicit confirmation. +Do not deploy, benchmark, apply, or record anything as the baseline: an unconfirmed draft is a proposal, and only +the user's confirmation makes it a user-provided baseline. + +## Inputs + +Require: + +- the interview fact table from `synthesize-user-workload` (model source and revision, hardware type and count, + backend and precision preferences, workload shape, SLOs, Kubernetes context and namespace); +- the recipe catalog scan that established rung 3 (no exact or close recipe), including the nearest recipes + considered and why each was rejected as a base; and +- any user-stated constraints (`resources.pinned` candidates, budgets) already collected. + +If model identity or hardware type and count is missing, return the question to `user-interviewer` instead of +guessing. Backend is different: when the user explicitly has no preference, CHOOSE it here with evidence - prefer +the backend whose nearest catalog recipe scaffolds this model family and hardware, per the knob guides' coverage - +and record the choice and its evidence in the decision table the user confirms. A confirmed draft's backend is a +confirmed decision, not an invented default; the contract's `preferences.framework` still records only what the +user themselves stated. + +## Read The Applicable Knowledge + +Always read: + +- all three files under `agent-docs/guides/model-sizing/` (memory fit, `min_tp`, classification); +- `agent-docs/guides/knob-tuning/tuning-hierarchy.md`; +- the chosen backend's guide (`agent-docs/guides/knob-tuning/vllm.md`, `sglang.md`, or `tensorrt-llm.md`) - + when choosing the backend here, read the candidates' guides as needed to make the choice; +- `agent-docs/guides/knob-tuning/dynamo.md`; and +- the nearest catalog recipes' manifests, as structural scaffolding only. + +Read `agent-docs/guides/rate-matching/matching.md` only when the draft is disaggregated (rare for a baseline; +prefer aggregated unless the user's SLOs demand otherwise). + +## Author The Draft + +1. **Size the model**: compute weight bytes, `min_tp`, and `headroom_ratio` per `memory.md`, showing the + arithmetic. Choose the serving TP per `parallelism.md` (prefer lower TP and more replicas for throughput + workloads; raise TP above `min_tp` only when headroom demands it, recording the replica cost). +2. **Choose topology conservatively**: an aggregated single-node layout unless the user's hardware or SLOs force + otherwise. The baseline's job is to run and measure, not to win; the optimization loop owns improvement. +3. **Scaffold from the nearest recipe**: copy its structure (components, probes, service wiring, image versions + for the chosen backend) and replace model, parallelism, resources, and any hardware-bound fields, naming every + replacement. Never carry a hardware-bound topology, transport, or checkpoint choice across without evidence it + fits the target. +4. **Set knobs to the backend guide's defaults**, deviating only where the sizing arithmetic requires it + (e.g. `gpu_memory_utilization`, `max_model_len` capped to the workload). Leave optimization headroom alone. +5. **Validate the draft**: parse as YAML, exactly one `DynamoGraphDeployment` document, no secret values, and + confirm it would pass `kubectl apply --dry-run=server` semantics (correct API version, resource names, required + fields) to the extent checkable offline. + +## Present For Confirmation + +Return to `user-interviewer`, for relay to the user: + +- the complete draft manifest; +- a per-decision evidence table: each major choice (TP, replicas, memory settings, backend, image, topology) with + the guide citation or arithmetic that produced it; +- the nearest recipes considered and why each was rejected as a base; and +- the explicit statement that this draft is unvalidated on hardware and iteration 0 will characterize it. + +Do not proceed on silence, enthusiasm, or a partial answer: confirmation is the user's explicit acceptance of THIS +manifest (or of it as amended by the user). The confirmed manifest goes to `synthesize-user-workload` for canonical +capture with `deployment.origin: agent-authored` and `deployment.origin_source: inputs/baseline-evidence.md` +(the interviewer writes the evidence table and confirmation there at capture time, per `run-artifacts.md`). + +## Do Not + +- Deploy, benchmark, or apply anything. +- Record an unconfirmed draft anywhere a downstream role could mistake it for the baseline. +- Author when a user DGD exists (that engagement has a baseline) or when rung 1 or 2 produced a viable base. +- Invent model, hardware, or SLO facts; missing facts return to the interview. +- Embed secret values or Kubernetes `Secret` resources. diff --git a/.agents/skills/perform-adversarial-review/SKILL.md b/.agents/skills/perform-adversarial-review/SKILL.md index 1bb55ad0ba70..7e6ccea449ad 100644 --- a/.agents/skills/perform-adversarial-review/SKILL.md +++ b/.agents/skills/perform-adversarial-review/SKILL.md @@ -122,6 +122,9 @@ Attack the proposal from these directions: impact on the primary objective, reversibility, GPU cost, and risk at the target operating region? - **Attribution**: Does the complete diff express one independently testable knob? For a coupled bundle, is every field required for one mechanism or supported by prior interaction evidence, with an ablation where needed? +- **Provenance**: When `deployment.origin` is `recipe-confirmed` or `agent-authored`, reject any framing of the + baseline as a production reference; iteration 0 characterizes an unvalidated starting point, and topology + families inherited from it are open questions, not settled decisions. - **Mechanism**: Does the proposed lever address a plausible reducible gap at the target operating region, or merely move work that evidence suggests is already bounded? Are internal causes still labeled as hypotheses? - **Evaluation**: Is the expected effect tied to the primary objective or failed SLO? Does the proposal state what the diff --git a/.agents/skills/synthesize-user-workload/SKILL.md b/.agents/skills/synthesize-user-workload/SKILL.md index 893bfac908cf..915c77e4cc66 100644 --- a/.agents/skills/synthesize-user-workload/SKILL.md +++ b/.agents/skills/synthesize-user-workload/SKILL.md @@ -24,7 +24,8 @@ not search for or select a recipe, deploy, benchmark, or propose tuning changes. Require: - the user's initial optimization request exactly as received; -- the user-provided DGD as an attachment, local file path, or pasted YAML; +- the user-provided DGD as an attachment, local file path, or pasted YAML, when one exists; otherwise the + ladder-confirmed baseline manifest handed over by `user-interviewer` with its confirmation record; - any attached workload descriptions, traces, or other local file paths; - an optional caller-supplied `EXP_ID` or `EXP_ROOT`; and - an existing `user_workload.yaml` only when the user is refining the interview before downstream work begins. @@ -40,7 +41,8 @@ final YAML. Resolve these blocking fields: -- one concrete user-provided YAML document containing a `DynamoGraphDeployment`; +- one concrete baseline `DynamoGraphDeployment`: either user-provided, or produced by the baseline-source ladder + (`agents/user-interviewer/AGENTS.md`) and explicitly confirmed by the user; - workload profile name, type, and a concrete description of the serving traffic; - exact model source and revision when the user fixes one, plus the fallback policy when the requested revision may be unsupported by the available engine or weights (fall back to a named alternative and mark the target @@ -110,12 +112,17 @@ Create the canonical baseline input: - When the user supplies a file, copy its bytes without editing the source or canonical copy. - When the user pastes YAML, materialize that YAML without changing its configuration. +- When the baseline came from the ladder (rung 2 adapted recipe or rung 3 authored draft), materialize the exact + manifest the user confirmed - byte-for-byte as confirmed, including any user amendments - and record the + matching `origin` and `origin_source`. - Parse the canonical copy as YAML and require at least one mapping document whose `kind` is `DynamoGraphDeployment`. - Reject embedded secret values or Kubernetes `Secret` resources; references to pre-existing Secret names are allowed. - Reject a recipe directory, catalog choice, generated substitute, or inferred default in place of the user's DGD. - A specific manifest the user explicitly presents as their baseline is a user-provided DGD, whatever its origin; - the rejection targets substitutes the USER did not supply. + A specific manifest the user explicitly presents OR confirms as their baseline is a user-provided baseline, + whatever its origin; the rejection targets substitutes the user never confirmed. Record the provenance in the + contract: `deployment.origin` (`user`, `recipe-confirmed`, or `agent-authored`) and `deployment.origin_source` + per the schema. - Do not patch cluster compatibility or performance settings during capture. - Compute the canonical copy's SHA256 before writing the workload contract. - If the DGD contradicts an explicit workload constraint, return the contradiction as a blocking question; do not @@ -136,7 +143,8 @@ Follow the schema and rules in `agent-docs/rules/execution/user-workload.md`. Before finalizing: 1. Preserve all explicit user constraints without rounding or reinterpretation. -2. Record the exact canonical DGD path and SHA256 under `deployment`. +2. Record the exact canonical DGD path and SHA256 under `deployment`, plus `origin` and `origin_source` + (provenance of the confirmed baseline). 2a. Record the user's stated budgets (GPU-hours, wall clock, failed-deploy limit) under `budgets`, verbatim; leave each `null` when the user declined to state one. 3. Represent permitted unknowns as `null`, `""`, or `[]` according to the schema. diff --git a/AGENTS.md b/AGENTS.md index 46e293aa11f3..8c885be56d0c 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -47,7 +47,8 @@ to it — edit only the canonical copy. Reach for the right group first: **For deploying and operating Dynamo:** -- `synthesize-user-workload` — interview the user, capture their DGD, and create the canonical workload contract +- `synthesize-user-workload` — interview the user, capture their confirmed baseline DGD, and create the canonical workload contract +- `author-baseline-dgd` — draft a baseline DGD from interview requirements when no recipe matches, for the user's confirmation - `consult-perf-knowledge` — select one evidence-backed optimization proposal and write its reasoning record - `create-optimization-hypothesis` — materialize a performance consultation as a challenger-ready DGD draft - `perform-adversarial-review` — challenge a generated DGD candidate before it consumes GPU time @@ -81,17 +82,25 @@ write and requires operator consent. Rules: ## Optimization Role Dispatch -When the first user message starts a new Dynamo recipe optimization run, dispatch `user_interviewer` before any other -specialized role. It must invoke `synthesize-user-workload` and produce a validated -`/user_workload.yaml` plus an immutable `/inputs/user_provided_dgd.yaml` copied from the DGD the -user supplied. Do not dispatch `recipe_deployer`, `perf_analyzer`, `hypothesis_generator`, or +When the first user message starts a new Dynamo recipe optimization run, FIRST read +`agent-docs/guides/optimization/optimize-loop.md` end to end - the individual SKILL.md files are auto-discoverable, +but the loop's sequencing, state machine, and stopping rules live only in that guide - then dispatch +`user_interviewer` before any other specialized role. It must invoke `synthesize-user-workload` and produce a validated +`/user_workload.yaml` plus an immutable `/inputs/user_provided_dgd.yaml` copied from the baseline the +user supplied or explicitly confirmed. Do not dispatch `recipe_deployer`, `perf_analyzer`, `hypothesis_generator`, or `hypothesis_challenger` until both exact paths and SHA256 values are available. Pass both inputs directly to `recipe_deployer`; pass the same immutable workload path and hash to every later role. Do not insert a recipe -exploration or selection step before the baseline deployment. +exploration or selection step after the interview: the baseline-source ladder +(`agents/user-interviewer/AGENTS.md`) is the only place selection or authoring happens, always with the user's +explicit confirmation, and always before the loop starts. ## Long-Running Runs And Harness Compatibility -An optimization loop is long-running, unattended work. An interactive harness ends its turn whenever the agent stops +An optimization loop is long-running, unattended work. Know which harness you are in: in a SINGLE-SHOT harness +(headless `-p`/print mode, one-turn API calls), background-job completion notifications can never reach you - the +session is gone when your turn ends. There, poll synchronously with bounded loops and never park the engagement on +a wake-up you cannot receive; parking is only valid where the harness can re-invoke you (interactive sessions, goal +mode). An interactive harness ends its turn whenever the agent stops calling tools — a turn that ends on narrated intent ("now I'll test disagg") silently stalls the loop until a human notices. Two rules: diff --git a/agent-docs/guides/optimization/optimize-loop.md b/agent-docs/guides/optimization/optimize-loop.md index db9409f5a829..24c72c9a3ef1 100644 --- a/agent-docs/guides/optimization/optimize-loop.md +++ b/agent-docs/guides/optimization/optimize-loop.md @@ -33,9 +33,11 @@ rules: # Optimize Loop -Use this workflow for an end-to-end Dynamo configuration optimization job. The user supplies the baseline DGD; -`user-interviewer` captures it and hands it directly to `recipe-deployer`. There is no recipe-discovery or -recipe-selection step in this workflow. +Use this workflow for an end-to-end Dynamo configuration optimization job. The baseline DGD comes from the +interview's baseline-source ladder (`agents/user-interviewer/AGENTS.md`): supplied by the user, or a recipe or +authored draft the user explicitly confirmed. `user-interviewer` captures the confirmed baseline and hands it +directly to `recipe-deployer`. Selection and authoring happen only at interview time with user confirmation; the +LOOP itself has no recipe-discovery or recipe-selection step. When using Codex multi-agent mode, dispatch registered roles through `.codex/config.toml`. Each launcher must read and follow its corresponding `agents//AGENTS.md` contract. @@ -58,7 +60,8 @@ answers; do not advance the workflow meanwhile. ## 2. Validate The Baseline Handoff -Require the exact `EXP_ROOT`, `user_workload.yaml` path and SHA256, `user_provided_dgd.yaml` path and SHA256, and +Require the exact `EXP_ROOT`, `user_workload.yaml` path and SHA256, `user_provided_dgd.yaml` path and SHA256, +`deployment.origin` (with `origin_source` for non-user origins), and zero-based iteration `0`. Confirm that the user-provided DGD's model, framework, hardware, precision, and topology do not contradict the user workload. Do not edit, replace, or select an alternative DGD. @@ -69,11 +72,11 @@ Give the exact assigned DGD path and SHA256, `user_workload.yaml` path and SHA25 `user_provided_dgd.yaml`. No role selects or substitutes a baseline. When the user's DGD cannot run on the target as provided — it targets different hardware, checkpoints, or fabric — the deployer records the blocking incompatibilities in the deployment ledger and returns them; end the engagement with a report that states each -incompatibility and its evidence, and invite the user to start a new engagement with a target-compatible DGD (a -changed user DGD starts a new experiment, per `synthesize-user-workload`). Do not select a substitute, do not -rewrite the captured baseline, and do not park the run waiting for a new manifest. Greenfield engagements — no user -deployment at all — are likewise not supported by this workflow yet: say so at the interview, point the user at -`recipes/README.md` to pick a starting recipe, and invite them to return with it as their baseline. +incompatibility and its evidence, and invite the user to start a new engagement - with a target-compatible DGD of +their own, or through the baseline-source ladder (rungs 2-3), which may use the incompatibility report as input +evidence (a changed baseline starts a new experiment, per `synthesize-user-workload`). Do not select a substitute, do not +rewrite the captured baseline, and do not park the run waiting for a new manifest. (A greenfield user without any +DGD is handled at the interview by the baseline-source ladder, never here.) Later iterations use the exact challenger-approved draft. The deployer creates: ```text @@ -87,7 +90,9 @@ semantics to hide a deployment failure. ## 4. Configure, Run, And Analyze The Benchmark Give the successful `DEPLOY_ROOT`, exact `user_workload.yaml` path and SHA256, and current performance question and -target operating region to `perf-analyzer`. For iteration 0, use a baseline-characterization question. For later +target operating region to `perf-analyzer`. For iteration 0, use a baseline-characterization question. When `deployment.origin` is not `user`, iteration 0 +is pure characterization: the baseline has no production history, so no result may be framed as an improvement or +regression against it beyond the same-series comparisons the benchmark rules already govern. For later iterations, use the question approved with the candidate. - Select or create the benchmark series that best answers the question. Reuse a plan only when it remains fit; write diff --git a/agent-docs/references/definitions.md b/agent-docs/references/definitions.md index 8d676d2efa81..cc7278f28ce8 100644 --- a/agent-docs/references/definitions.md +++ b/agent-docs/references/definitions.md @@ -46,7 +46,7 @@ Default Pareto axes are `output_tput_per_gpu` and `tokens_per_sec_per_user`. - `EXP_ROOT`: `runs//`, created by `user-interviewer` once for an optimization job. - `user_workload.yaml`: canonical workload contract synthesized from the user interview, with the baseline DGD path-and-hash record. -- `user_provided_dgd.yaml`: immutable baseline DGD supplied by the user and captured under `EXP_ROOT/inputs/`. +- `user_provided_dgd.yaml`: immutable baseline DGD supplied or explicitly confirmed by the user and captured under `EXP_ROOT/inputs/`. - `DEPLOY_ROOT`: `runs//artifacts/deploy-iter-/`, created for one candidate DGD. - `deployment_ledger.json`: deployment and smoke-test record. - `benchmark_summary.json`: parsed AIPerf metrics and comparison record. @@ -60,7 +60,7 @@ Default Pareto axes are `output_tput_per_gpu` and `tokens_per_sec_per_user`. ## Agent Roles - **User Interviewer**: turns the user's initial request and minimal follow-up answers into `user_workload.yaml`, - captures the user-provided baseline DGD, and hands both immutable inputs to `recipe-deployer`. + captures the user-provided or user-confirmed baseline DGD, and hands both immutable inputs to `recipe-deployer`. - **Recipe Deployer**: deploys the user-provided baseline DGD or a later challenger-approved DGD and verifies the endpoint. - **Performance Analyzer**: interprets AIPerf artifacts. diff --git a/agent-docs/rules/benchmarking/concurrency-grid.md b/agent-docs/rules/benchmarking/concurrency-grid.md index b7af7128f028..34baec152fe5 100644 --- a/agent-docs/rules/benchmarking/concurrency-grid.md +++ b/agent-docs/rules/benchmarking/concurrency-grid.md @@ -14,7 +14,10 @@ Perform a concurrency sweep during benchmarking only if you deem it is necessary Do not invent an unbounded sweep when the target and benchmark plan provide no safe maximum. Include `c=1` when the goal is to characterize the full latency/throughput frontier, but do not add it to a user-constrained set merely to -complete a curve. Additionally, after selecting a particular concurrency value, keep the selected number of requests to be AT MOST 4x the concurrency. For example, if `c=4`, the number of requests should be at most 4. +complete a curve. Additionally, after selecting a particular concurrency value, size the request count to AT MOST 4x the +concurrency (for example, at most 16 requests for `c=4`), and never below the concurrency itself - fewer requests +than slots cannot even fill the batch, and tiny counts cannot support the noise-floor and comparison rules in +`comparison-uncertainty.md`. Within that cap, the count must also keep the measurement inside the standard 30-minute window per `comparison-uncertainty.md`. Use a non-power-of-two point only when it is required by the user workload, needed to reproduce a baseline, selected by an AIPerf search method, or chosen as a bounded refinement around an SLO boundary or observed knee. Record the diff --git a/agent-docs/rules/execution/run-artifacts.md b/agent-docs/rules/execution/run-artifacts.md index 5ad2c9fb44e5..f724edbb0ffb 100644 --- a/agent-docs/rules/execution/run-artifacts.md +++ b/agent-docs/rules/execution/run-artifacts.md @@ -26,6 +26,7 @@ runs// |-- reasoning_transcript.md |-- inputs/ | |-- user_provided_dgd.yaml +| |-- baseline-evidence.md # ladder rungs 2-3 only | `-- benchmark-plans/ | `-- .json |-- analysis/ @@ -71,7 +72,12 @@ runs// - `reasoning_transcript.md`: time-stamped long-running document capturing the agent's reasoning, key decisions, actions, rationale, and status. Created and maintained by the top-level loop agent (the session running `optimize-loop.md`) per `agent-docs/rules/execution/logging.md`; specialized roles contribute through their own artifacts. -- `user_provided_dgd.yaml`: immutable baseline DGD supplied by the user and captured by `user-interviewer`. +- `user_provided_dgd.yaml`: immutable baseline DGD supplied or explicitly confirmed by the user (see the + baseline-source ladder) and captured by `user-interviewer`; provenance in the contract's `deployment.origin`. +- `baseline-evidence.md`: rungs 2-3 only; the proposal the user confirmed - nearest recipes considered, the + adaptation diff or authored draft's per-decision evidence table, and the user's confirmation. Written by + `user-interviewer` at capture time. `deployment.origin_source` points here for `agent-authored`; for + `recipe-confirmed` it holds the recipe path, and this file carries the confirmation record. - `benchmark-plans/.json`: immutable performance question, workload, measurement semantics, objectives, and required references for one benchmark series. - `hypothesis-backlog.jsonl`: append-only record of generated optimization proposals and their source evidence. diff --git a/agent-docs/rules/execution/user-workload.md b/agent-docs/rules/execution/user-workload.md index 1e98b1f88402..4cb4227605cf 100644 --- a/agent-docs/rules/execution/user-workload.md +++ b/agent-docs/rules/execution/user-workload.md @@ -53,6 +53,8 @@ kubernetes: deployment: dgd_path: runs//inputs/user_provided_dgd.yaml dgd_sha256: "" # SHA256 of the immutable canonical DGD copy + origin: "user" # user | recipe-confirmed | agent-authored (who produced the baseline the user confirmed) + origin_source: "" # recipe path (recipe-confirmed) or inputs/baseline-evidence.md (agent-authored); "" for user traffic: input_tokens: null # optional rough/median input sequence length when known diff --git a/agents/hypothesis-generator/AGENTS.md b/agents/hypothesis-generator/AGENTS.md index 78ba7c88eb01..3e7291856309 100644 --- a/agents/hypothesis-generator/AGENTS.md +++ b/agents/hypothesis-generator/AGENTS.md @@ -90,6 +90,13 @@ Require a successful smoke test and a benchmark audit whose status is `valid` or analysis is missing, invalid, or relies on a direct comparison across benchmark series, stop rather than manufacturing a proposal. +## Baseline Provenance + +Read `deployment.origin` from the workload contract. When it is `recipe-confirmed` or `agent-authored`, the +baseline itself is a hypothesis: every lever family starts genuinely untested (no production history is implied), +topology-first scrutiny per `tuning-hierarchy.md` applies with full force, and nothing inherited from the baseline +counts as `tested` without a same-series measurement. + ## Outputs When preparing a stop-request, also write the three Finalize artifacts BEFORE submission — diff --git a/agents/user-interviewer/AGENTS.md b/agents/user-interviewer/AGENTS.md index 2b58474de460..7edea6b3c6a4 100644 --- a/agents/user-interviewer/AGENTS.md +++ b/agents/user-interviewer/AGENTS.md @@ -8,6 +8,7 @@ intent: >- baseline DGD handoff for deployment, benchmarking, and optimization. skills: - synthesize-user-workload + - author-baseline-dgd "Required Readings: Docs": - agent-docs/references/definitions.md "Required Reading: Rules": @@ -21,10 +22,20 @@ You are the first specialized role for every new Dynamo recipe optimization run. before deployment, benchmarking, or hypothesis work begins. Invoke `synthesize-user-workload` with the exact initial message, attachments, and any caller-supplied experiment -identity. The user must provide the baseline DGD. If the user has none — a greenfield engagement — say plainly -that this workflow does not yet support greenfield: point them at `recipes/README.md` to pick a starting recipe for -their model and hardware, and invite them to return with it as their baseline DGD. Do not search the recipe catalog -yourself, select a substitute, or make the user author the workload contract by hand. If the user has not stated budgets, ask for them in the same interview — GPU-hours, +identity. The baseline comes from the baseline-source ladder, and the user's explicit confirmation is the +invariant at every rung: + +1. The user provides a DGD (`origin: user`). +2. No user DGD, but the catalog has an exact or close recipe for the model, hardware, and backend: propose it — + for a close match, with an explicit adaptation diff naming every changed field and its reason — and capture the + user-confirmed manifest (`origin: recipe-confirmed`). +3. Nothing close: invoke `author-baseline-dgd` to draft one from the interview facts and the sizing guides, relay + its draft and per-decision evidence table, and capture only what the user explicitly confirms + (`origin: agent-authored`). + +Selection and authoring happen ONLY here, at interview time, where a blocking question is legal; the optimization +loop itself never selects or substitutes. Never deploy or record an unconfirmed draft as the baseline; if the user +declines every rung, the engagement does not start. Do not make the user author the workload contract by hand. If the user has not stated budgets, ask for them in the same interview — GPU-hours, wall clock, and failed-deploy limit — propose sensible defaults, and record the answers in the workload contract. ## Role Boundary @@ -37,13 +48,20 @@ Do: - Ask the smallest grouped set of follow-up questions needed to resolve blocking ambiguity. - Create the experiment root when the caller has not already assigned one. - Write and validate exactly one canonical `/user_workload.yaml`. +- When no user DGD exists, run the baseline-source ladder: scan the recipe catalog for the model, hardware, and + backend; record the nearest candidates and why each fits or fails; propose per the rungs; relay + `author-baseline-dgd`'s draft and evidence table verbatim at rung 3; capture only what the user confirms, and + record `deployment.origin`/`origin_source`, writing the proposal, evidence table, and confirmation to + `/inputs/baseline-evidence.md`. - Create `/manifest.yaml` when establishing `EXP_ROOT` (session metadata per `run-artifacts.md`). - Record the captured DGD's exact path and SHA256 in the workload contract. - Return both exact paths and SHA256 values so `recipe-deployer` receives the immutable baseline handoff. Do not: -- Search for, select, generate, or modify a recipe or DGD. +- Select, generate, or modify a baseline WITHOUT the user's explicit confirmation, or outside the + baseline-source ladder. (Scanning the catalog to determine the ladder rung, proposing a recipe or adaptation + diff, and invoking `author-baseline-dgd` are ladder duties, not violations.) - Deploy resources, inspect secret values, run AIPerf, or propose optimizations. - Treat DGD configuration as unstated workload intent; record what the DGD proves and ask when that conflicts with or does not establish the user's serving requirements. @@ -53,7 +71,8 @@ Do not: ## Inputs - the user's first optimization message exactly as received -- the user-provided DGD as an attachment, local path, or pasted YAML +- the user-provided DGD as an attachment, local path, or pasted YAML, when one exists (otherwise the ladder + produces the baseline) - user attachments and referenced workload or trace paths - optional caller-supplied `EXP_ID` or `EXP_ROOT` - follow-up answers returned through the parent when the first pass is incomplete