Results and provenance¶
GPTNT keeps source records separate from derived analysis and submission artefacts. That boundary allows completion, collation, and validation to use the same recorded execution facts.
flowchart LR
PS["Player step and observation"] --> PR["Per-player Parquet v3"]
PR --> F["Record footer"]
F --> CL["Local completion ledger"]
PR --> DB["DuckDB: steps and summaries"]
F --> DB
DB --> IP["Interactive experiments.parquet"]
SL["Reduced suites.lock"] --> IB["Interactive submission bundle"]
IP --> IB
SM["Static run_meta.json"] --> SB["Static submission bundle"]
MX["Static metrics.json"] --> SB
Player records own the execution detail¶
Each player service writes one Parquet file for its role in an execution. Step rows hold actions,
model messages, observations, usage, bomb state, parsing errors, and relative dispatch time. The
footer holds the shared ExperimentInstance, final bomb state, role, crash state, and provenance.
The recorder writes a sibling .tmp file and renames it only after Parquet writing finishes.
Orphaned .parquet.tmp files therefore indicate interrupted writes rather than completed records.
Completion comes from terminal evidence¶
The local completion ledger groups player-record footers by attempt_name. An execution is valid
only when it has no hard crash and its outcome is solved, timeout, or strikeout. A generic
detonation or incomplete state does not count as a valid completed outcome.
The W&B ledger supplies the same status contract for cross-machine aggregation. local and wandb
can differ in where they read state, but both use the shared terminal-outcome rule to decide which
attempts are safe to skip.
DuckDB is an analysis projection¶
build-db reads Parquet rows directly into experiment_step and derives one
experiment_summary row from the grouped footers. The summary combines runtime identity, frozen
suite and mission data, protocols, capabilities, outcome, crash state, and provenance. The
database has no independent provenance or completion authority.
Static output binds identity before prediction¶
A dataset-backed static run writes run_meta.json before its first prediction. The file binds the
player capabilities, run date, benchmark provenance, requested dataset revision, and resolved
dataset commit. Predictions are per-instance files. metrics.json is the task-dependent aggregate.
Submission reduces rather than replaces¶
Interactive bundle construction selects summary and usage data from DuckDB and writes
experiments.parquet. It does not include the full trajectories. The bundle also contains a reduced
suite lock, which lets validation reconstruct the recorded suite without reading live suite files.
A static bundle copies metrics.json and describes it with the stored static metadata.
Keep source Parquet through validation
DuckDB and experiments.parquet are derived representations. Keep the original player-record
Parquet until every intended bundle validates, so you can rebuild after a collation, selection,
or schema problem.