Anatomy of a result package

The report page, tables, charts, files and metadata a job returns.

Reference

A complete analysis returns one zip file, <method>.<job_id>.zip, and the analysis service keeps a small metadata sidecar beside it. The zip is the job's working directory as it stood when the container exited, so it holds the inputs the method was given, the files it produced and the report it generated. This page lists what is inside, how the HTML report is organised, and which facts the report does and does not record. A reviewer checking an analysis should read this alongside the method's own page under The methods and their shared pipeline.

The package

Unzipping <method>.<job_id>.zip gives one folder, <method>.<job_id>/, containing:

File	What it is
`params.json`	The parameters as submitted, with the method `title` and the recordset's title and description
`records.jsonl`	The records given to the job, one JSON object per line, as fetched when the job was packaged
`filtered_records.jsonl`	The records that passed the method's filter stage
Method files	The converted input (for example a FASTA file) and the result files, which the method's page lists
`analysis_charts.html`	The charts fragment the method generated; an empty file when it produced none
`analysis_report.html`	The self-contained report
`analysis_report.pdf`	A PDF rendering of the report, when it could be produced
`stage_timings.json`	Start, end and duration in seconds of the validate, filter, convert and execute stages
`load_stats.json`	Job ID, start and end time, and total runtime in seconds
`resource_stats.json`	The CPU and memory samples the worker recorded while the container ran
`charting/`	A copy of the report template, stylesheet, logo and helper scripts used to build the report

A failed job's <method>.<job_id>.failed.zip has the same layout up to the stage that failed, plus error.json naming the stage script and holding its output (see Job lifecycle).

The HTML report

analysis_report.html is a single file with its stylesheet and logo embedded, so it opens offline and is what the eye icon in the Analysis panel previews. Its sections, in order:

Section	Content
Header and status bar	The method's internal name, the job ID, the completion time in UTC and the total duration
Recordset	The recordset's title and description as they were when the job was submitted
Parameters	Every key in `params.json` except `title`, `recordset_title` and `recordset_descr`, as a two-column grid; underscores shown as spaces, lists joined with commas, booleans as `true` or `false`. Keys beginning `labels_` with at least one value appear in a separate Labels row
Results	Two counts: input records (lines in `records.jsonl`) and after filtering (lines in `filtered_records.jsonl`)
Analysis	The method's charts, drawn as inline SVG; omitted when the method produced none
Timings	A proportional bar and a table of the validate, filter, convert, execute and package stages and their total
Outputs	The result files, each with the one-line description the method supplied

The Analysis section is the only part that differs between methods. The charts are built by the method from its own result tables; what each shows is described on the method's page, for example Sequence composition or Barcode gap.

The PDF

After writing the HTML, the method renders it to analysis_report.pdf with WeasyPrint. The PDF is a best-effort copy: if rendering fails, the job still completes and the HTML report is still present. The PDF exists only inside the zip; there is no separate PDF download.

The metadata sidecar

<method>.<job_id>.metadata.json sits next to the zip in the results container, not inside it. It is the worker's resource_stats.json with one more field, error:

Field	Meaning
`sampling_interval_seconds`, `sample_count`, `runtime_seconds`	How the container was sampled (every 10 seconds) and how long it ran
`cpu_percent`, `memory_mb`	The sampled series
`cpu_peak_percent`, `cpu_average_percent`, `memory_peak_mb`, `memory_average_mb`, `memory_limit_mb`	Summary figures
`error`	`null` for a completed job; for a failed job, the contents of `error.json` plus a `message` with the exit code

The scheduler reads the sidecar when it marks the job complete, stores it on the job record, and the status query returns it. The administrator's analysis dashboard charts runtime and load from these figures.

What the report records, and what it does not

The report is a record of what was asked and what came out. It records the parameters exactly as submitted, the input and filtered counts, the stage timings, the output file list and the completion time.

It does not record:

Whether a parameter was applied. The Parameters section is a copy of params.json. Options that a method accepts but ignores still appear there; see Known limitations of the methods for which ones.
Software names or versions. The programs each method runs, and the versions in the current images, are collected on Software, versions and citations.
Who submitted the job. The submitter is held on the job record in the analysis service, not in the package.
Resource usage. CPU and memory figures live in the sidecar and on the administrator's dashboard, not in the report.
The stage logs. What each stage printed goes to the worker's run log on the analysis host; the package keeps only the files the stages wrote.

Good to know: records.jsonl is the authoritative list of what the method saw. The count on the job in the Analysis panel is the workbench's count at submission, while the records themselves were fetched later, when the job was packaged.

Good to know: The export jobs (specimen-download and sequence-download) produce no report, no charts and no PDF. Their packages hold the requested data file and a load_stats.json whose values are fixed placeholders rather than measurements; ignore it. See Specimen and sequence exports.