# Odin local results, history, and exports: decision questionnaire

**Purpose:** Set the product and data contract needed to resolve [Define local results, history, and export behavior](https://git.bongbetic.com/xavierk/odin/issues/12).

**From:** Odin product owner, **To:** Odin product owner, **How your answers will be used:** Record the agreed decisions on the ticket and carry them into Odin's build-ready specification.

## Context

Odin is a local Linux benchmark and diagnostic suite. A standard run may produce a headline median only when all seven required performance domains are valid. Quick and incomplete runs still produce useful measurements and health evidence. Results must distinguish measurement conditions, missing coverage, and health uncertainty so users can revisit runs and compare compatible systems or upgrades. No hosted account or leaderboard is planned.

## How to answer

Allow about 20–30 minutes. No deadline is assumed. Replace each `>` with your answer. Partial answers and “I don't know” are useful; mark uncertain points. Suggested defaults are starting positions, not decisions until you accept or change them.

## Result record

### Should Odin retain every raw trial and sample statistic after a run?

Suggested default: Yes. Keep native units, timestamps, sample counts, ranges, validity outcomes, and summary calculations so results can be audited.

>

### Should incomplete, cancelled, invalid, and safety-stopped runs remain in history?

Suggested default: Yes. Preserve partial measurements, reasons, health evidence, and cleanup status without presenting them as completed scores.

>

### How much environment detail should every result preserve?

Suggested default: Enough to interpret and compare it later: workload and tool versions, protocol and scoring versions, calibration release, selected profile, execution mode, software mode, kernel and relevant settings, driver, device, filesystem, permissions, and observed thermal or power context.

>

### Should Odin preserve the evidence behind each health finding and advice item?

Suggested default: Yes. Keep source, observation time, collection scope, severity, confidence, unknown or stale status, and the evidence linked to each recommendation.

>

### Should a stored result carry explicit schema and calculation versions?

Suggested default: Yes. Keep original records immutable; future readers may migrate a copy or derive a new view without silently changing historical scores.

>

## Local history

### Where should Odin save results by default?

Suggested default: A per-user local data directory, with a clear option to choose or open the location. Avoid writing results into the benchmarked filesystem path by surprise.

>

### How long should Odin keep runs by default?

Suggested default: Until the user deletes them. Show storage usage and offer explicit cleanup; never erase failed-run evidence automatically.

>

### What should happen if saving a run fails or Odin exits during saving?

Suggested default: Keep the last committed history intact; recover or flag any incomplete record, and tell the user whether the current run was saved.

>

### Which history actions must the terminal interface support in v1?

Suggested default: List and filter runs, inspect full detail and evidence, compare two compatible runs, export a run, and delete a selected run with confirmation.

>

### What should Odin show when two runs are not directly comparable?

Suggested default: Show the results side by side with precise incompatibility reasons; do not calculate a combined change or imply that score differences share one cause.

>

### Should users be able to annotate a run after it finishes?

Suggested default: Allow a separate user note, such as “before kernel upgrade,” without altering the original measurement record.

>

## Export and privacy

### Which export form must v1 provide?

Suggested default: A portable, versioned machine-readable record containing raw measurements, summaries, coverage, provenance, health evidence, and advice. A human-readable report can be an additional format.

>

### What identifying data should the default export include?

Suggested default: Redact hostnames, usernames, home paths, serial numbers, and stable hardware identifiers. Keep non-identifying hardware and software characteristics needed to interpret results.

>

### Should users be able to request a full-fidelity export with identifiers?

Suggested default: Yes, through an explicit, clearly labelled choice with a preview of sensitive fields.

>

### Should Odin import exported results into local history in v1?

Suggested default: Yes, if schema and integrity checks pass; mark imported records and preserve their original identities. If this exceeds v1 scope, name the minimum portable export contract needed for future import.

>

### How should Odin handle an export that cannot fit the requested privacy policy?

Suggested default: Explain the conflicting field and require a different export choice; never silently leak identifiers or discard comparison-critical data.

>

## Anything else?

What requirement, edge case, or concern did these questions miss?

>