Aaron — ResEng charter review replies (How swimlane, scheduled exports, client scope, terminology)

aaron-reseng-charter-reply.md

How — double-click

How = three mechanisms:

1. Decouple ExpertWorkItem (Meridial work) from RLEvalTask (what ships)
2. CampaignConfigs per Campaign — SA drafts configuration before Meridial goes live; versioning handles scope changes
3. Importable primitives (RlRunner / RlGrader / ExportRunner) — FDEs import and configure anything that ought not be vibe-coded

flowchart LR
  subgraph SA["Solutions Architect"]
    A[Stress-test scoping form]
    B[Draft CampaignConfig vN]
  end

  subgraph FDE["FDE / delivery engineering"]
    C[Build campaign-unique glue]
    D[Client export mapping\nRLEvalTask → client schema]
    E[Execute on pinned config]
  end

  subgraph RE["Research Engineering"]
    F[Expand supported config keys]
    G[Ship versioned primitives]
  end

  A --> B
  B -->|published config| E
  B -->|gap found| F
  F --> G
  G -->|new template_pins| E
  C --> D
  D --> E

Loading

Swimlane read: SA publishes CampaignConfig before Meridial goes live. FDEs own what is genuinely bespoke — especially the export mapping from canonical RLEvalTask to client-specific archive layout (you would expect this to be config; in practice it is a moving target mid-campaign). ResEng expands what can be config and ships importable primitives. Delivery executes on pinned config + that bespoke layer.

---

Roadmap.Next — Scheduled Exports + client scope

Scheduled exports

Full detail: scheduled-exports.md (docs--rl-template-home, commit 6b4b369).

Summary:

Phase	Who schedules	Trigger
v0 (now)	Ops / delivery script	Cron or manual build_export; script-invoked ExportRunner per ADR-001
v1 (next)	CampaignOrchestrator	Weekly cadence + export_ready gate; rule AU-06 per ADR-005

Ledger contract unchanged either way: ExportRun + DeliveryLedgerEntry[]; Meridial::TaskDisposition.passed is not delivery truth.

Changing client scope

Example: Meta GDPVal — client moves from ~20 rubric criteria per task to 50–100.

Right now we treat that as an ops surprise. Experts open the mega-form, add rows, and hit the count — but operational reality is they split existing criteria instead of writing net-new discriminators. Headcount goes up; learning signal does not. No versioned spec records the change; in-flight tasks, export validators, and pass@k gates drift on mixed assumptions. Export mapping to Meta's archive layout gets hand-patched in the FDE repo.

But that means scope changes are invisible to the system — you cannot answer "which tasks were built under 20-criterion vs 100-criterion contract?" or grandfather cohorts cleanly.

Attempting to address this with:

• Immutable CampaignConfig rows — client CR → version + 1, change_summary, effective_from / grandfather_until (campaign schema)
• CampaignLifecycleState: change_request while migrations run
• Per in-flight item: MigrationDecision = migrate | requeue | grandfather | reject
• Post-v0: FR-T-06 — export blocked until required migrations complete
• Decomposed path (Amazon / next Meta): targeted ExpertWorkItem types (rubric_criteria_expansion_work_item_v1) instead of "add 80 rows to one form" — experts add criteria that separate gold vs foil model outputs (Kit sync Jun 16)

Export schema bounds (rubric_criteria_min / max) live on config. Client ZIP field naming stays FDE bespoke until we have stable enough handlers to promote into export_runner config.

---

Roadmap.Then — terminology

Agree synthesis is poisoned.

Procedurally generated? — closer for the combinatorial step (TaskArchetype × TaskOutcome expansion from DKS rules). Reads like game-dev and still sounds like "fake data" in ML contexts. Does not cover the digestion step (completed EWI → DKS diff).

Term	Fits
Procedural generation	Combinatorial expansion from explicit rules
Materialization	DKS state → concrete RLEvalTask rows (my lean)
Realization	Already used for Construct env builds (ADR-005) — keep paired, not overloaded
Assembly	Campaign-level ("benchmark assembly") — do not reuse for this step

Proposal: procedural materialization for the DKS → RLEvalTask step — rules expand the space; the engine emits rows. Rename archetype_outcome_synthesis → archetype_outcome_materialization when we touch the enum.

Lifecycle:

Scoping → CampaignConfig → Sourcing → ExpertWorkItems → DKS
  → RLEvalTask procedural materialization → DQA → Export

Yes, Roadmap.Then is later — Sprint 3 / decomposed_dks_synthesis. Meta GDPVal stays on legacy_single_form_passthrough until Amazon path proves the decomposed loop.