Selection and Observability

Structured evidence, score summaries, final candidates, live monitoring, and audit traces.

1. Structured run artifacts

PathProducerPurpose
task_logs/lhr_stage_performance.csvLNR Stage capture and adjudicationCandidate rows, metric evidence, validity, selection eligibility, artifact identity, Gate fields, and worker/ESTRA context.
task_logs/lhr_events.jsonlLNR state-machine storeAppend-only run, Stage, ESTRA, resume, and merge events.
task_logs/resource/resource_events.jsonlUnified resource storeAdmission, lease, queue, review, advisory, arbiter, strict-gate, timebox, and execution events.
task_logs/state.jsonParallelRunner/finalizerFinal status and elapsed/resume-budget accounting.
workers/w*/logs/evaluator_events.jsonlGate-owned evaluator managerArtifact SHA, backend/status, metric, validity, readiness, selection eligibility, and policy trace.
workers/w*/logs/scienceflow_time_trace.csvOrchestrator trace callbackLLM timing, model, token, cache, and cost analysis.
workers/w*/logs/interaction.logAgent interaction loggerHuman-readable agent and tool activity.
workers/w*/snapshots/SnapshotStoreValidated source and artifact state, with content-addressed storage for large objects when enabled.

2. Evaluator and Gate evidence

The evaluator produces a normalized MetricEvent. The Gate policy then decides whether that evidence is acceptable for Stage creation. The event trace preserves both fact generation and policy decision so later analysis can distinguish evaluator failure, policy rejection, duplicate candidate suppression, and a successful Stage transaction.

Evidence groupRepresentative fields
Identitycandidate_id, stage_id, worker_id, artifact_path, artifact_sha, artifact_kind
Metricmetric_name, metric_value, lower_is_better, metric_validity
Readinessvalidation_ok, candidate_ready, selection_eligible
Evaluatorevaluator_backend, evaluator_status, runtime and output-tail metadata
GatePolicy name/version, parameters, trigger, accepted/retry/reject result, reason code
Gate-time metric validity and post-commit Stage audit validity are separate fields. A later audit may lower selection confidence without rewriting the historical Gate decision.

3. Score summary and effective Stage facts

solver/lnr/stage/score_summary.py normalizes metric direction and computes raw best, valid best, worker summaries, and selection context for ESTRA, resource review, and finalization. Selection uses effective Stage facts: the append-only ledger preserves the research narrative, while snapshot source events can update validity, eligibility, and reason codes used by current decisions.

4. Global merge outputs

solver/lnr/global_merge/ builds a candidate evidence pack from validated worker stages, exposes those candidates to a merge workspace, asks the live owner agent to construct the required final artifacts, and evaluates every finals/final_* directory through the configured evaluator. Structured fallback can promote ranked valid candidates when the agent does not produce enough finals.

merge/
├── global_merge_workspace/
├── submission_snapshots/
├── finals/
│   ├── final_00/
│   ├── final_01/
│   └── final_02/
└── global_merge_manifest.json

The default configuration requests three finals and allows at most three. The manifest records the required, produced, and valid counts plus fallback sources and evaluator results.

Runs using final_artifact_mode: best_stage instead write merge/best_stage_manifest.json and materialize the selected Stage under merge/finals/final_00/.

5. Monitor surfaces

SurfaceUse
scienceflow monitor --manifest ...Live multi-task Rich dashboard assembled from Stage, resource, ESTRA, trace, process, and final-state files.
scienceflow monitor --log-dir ...Single-task compatibility view from a monitor-state path.
scienceflow monitor-trace -m ... -o ...Self-refreshing HTML trend view with optional JSON cache.
scienceflow resource-summary <root>Run-level aggregation of resource events as a table or JSON.

The monitor distinguishes unique Stages from candidate rows. Stage totals are deduplicated by worker and Stage id, while readiness and eligibility counts retain candidate-row semantics. Resource kill_req records a requested/approved review outcome; kill_exec records an actual process termination.

6. Operational interpretation