Measure tab: surface runs + profiling/verification measurements (visibility, selection, report separation)

[itsab1989]

Summary

Feedback from Knut: the Measure tab hides the run/measurement model from the user. You can't see how many runs a profile has, whether starting will create or overwrite a run, or which measurement kind (profiling vs verification) you're about to write — and there's no high-level "what happens when I create and measure a chart?" help. We need a coherent strategy for surfacing and managing this, in both the UI and the file layout.

How it works today (for reference)

The Measure tab is file-driven, not project-driven: you load a specific .ti2 and the output is written next to it as <chart-stem>.ti3 (tab_measure.py, ti3 = self._ti1_path.with_suffix(".ti3")).

• New vs overwrite: measuring never creates a new run — it always overwrites the loaded chart's run. New runs come only from the Create Chart tab (chart generation "add new run", or refinement Project.new_run(preconditioning_from=…)). The only current cue that a measurement already exists is the "reuse existing .ti3 / resume" checkbox appearing.
• Kinds of measurement, already distinct on disk:
  • Profiling → <stem>.ti3
  • Verification → <stem>-verify.ti3 + CHROMIQ_VERIFICATION "true" keyword (via the "Profile verification" checkbox; the app refuses to build a profile from it).
  • Calibration → separate cal/ folder.
• Report coupling: the Measurement Report trends from saved reports/report_*.json, rebuilt from each run's profiling <stem>.ti3. Verification files aren't auto-included — but nothing filters on the CHROMIQ_VERIFICATION keyword, so a verification measurement that ever gets "reported" could be trended alongside profiling runs. Latent mixing risk.

What's missing

1. No display of how many runs a profile has, or which run is active, in the Measure tab.
2. No indication of whether Start will create or overwrite, and which run.
3. No way to pick/overwrite a specific run from Measure (only by loading that run's .ti2).
4. Profiling vs verification (and vs calibration) isn't shown in the UI — only inferable from the checkbox and filenames.
5. Verification is one fixed slot per run (-verify); re-verifying overwrites, no history, only implicitly tied to a run.
6. No high-level help card describing the whole create → print → measure → build → report flow and which folders are created when.

Proposed strategy (for discussion)

• Run + kind status strip in the Measure header once a chart is loaded: e.g. "Profile Canon-Pro300 · run 3 of 4 · profiling", and Start-button wording: "Start will overwrite run 3's profiling measurement" vs "…create run 3's verification measurement."
• Run selector in Measure (dropdown of the project's runs + "＋ New run"), making Measure project-aware — so a fresh run or a specific overwrite can be chosen from here, not only from Create Chart.
• Formalize the three measurement kinds on Run (profiling / verification / calibration) with explicit path accessors, and have the Measurement Report exclude anything carrying CHROMIQ_VERIFICATION — closing the latent mixing risk with the marker that's already written.
• Decide the verification data model: keep one-slot-per-run (simple) or allow timestamped verifications per run (e.g. reads/verify_YYYYMMDD.ti3) if a verification history is wanted.
• User-facing process help card: "What happens when I create and measure a chart?" — the whole flow and folder lifecycle, from the material in docs/dev_folder_layout.md.

Priority

Low → high risk order: (1) status strip + create/overwrite wording (surfaces existing data, no behaviour change) → (2) report honoring the verification keyword → (3) run selector / new-run-from-Measure → (4) verification history → (5) help card. None urgent.

Raised from Knut's testing feedback, 2026-07-22.

[soul-traveller]

Questions: how can I also distinguish between a profiling measurement run or a verification measurement run? How are these distinguished and stored in the folders? An how to see which I have selected to measure or overwrite?

Additional thoughts:
It is important to track this so that the measurement report show the correct measurements and user don’t mix them up.

A strategy needs to be developed how these things are handled in a user friendly way, both in the user interface and file management.

Simplest strategy is that user must fully and manually keep track of profile measurement runs and verification runs, preferably as separate profiles where profile name distinguishes, and not mixing them in one single profile. Maybe also good practice because verification runs don’t need as large charts. The question is if this is the most user friendly, although flexible? And the chosen strategy will affect help text, recommendations and guidance in windows where user must choose type of run, overwriting data or creating new profile, or new measurements etc,

Reanalyse for showing alternative strategies and to find simplest user friendly method that allows indentification of discussed things, and suggest best way to go.

[itsab1989]

Re: distinguishing profiling vs verification, and the "separate profiles" idea

Good questions — and the good news is that most of the mechanism you're asking for already exists on disk; it's just not surfaced in the UI or first-classed in the model. Answering your three questions directly, then evaluating the separate-profiles strategy.

1 + 2. How are they distinguished and stored today?

They're already separate on disk:

• Profiling → <stem>.ti3
• Verification → <stem>-verify.ti3, plus a CHROMIQ_VERIFICATION "true" keyword written into the file (ti3_analysis.mark_verification_ti3, triggered by the Profile verification checkbox). The app already refuses to build a profile from a file carrying that marker.
• Calibration → its own cal/ folder entirely.

So the three kinds never collide as files. The weakness is that verification is a second-class citizen in the model: Run has accessors for measurement_ti3, merged_ti3, preconditioning_ti3, calibrated_icc… but no verification_ti3. The verify file is produced by an inline rename, not through a Run property — which is exactly why nothing in the UI can display it.

3. How do you see which you're about to measure / overwrite?

Right now: you can't, beyond the filename and the checkbox. Measure is file-driven, not run-aware — no run count, no create-vs-overwrite indicator, no kind indicator. That's items 1–4 in the issue body.

On the "keep verifications as separate profiles" idea

It's a reasonable instinct, and your point that verify charts can be smaller is correct. But I'd argue it's the wrong default, because it's the option that most severs the one link that matters:

A verification is fundamentally an audit of one specific built profile — "how good is this profile?" It is not a run of its own; it's a property of a run.

Splitting it into a separate profile means:

• you lose the profile ↔ verification traceability (which profile was this verify printed through?),
• the Measurement Report's whole value is a per-printer run history, and a separate verify-profile can't ride along with the run it validates,
• naming discipline becomes the only thing keeping it straight — which is the mixing risk you're worried about, not a fix for it.

So the cleaner direction is the opposite: keep the verification inside the run, next to the profile it validates, and make the tool show it. Separate profiles stays a valid power-user workflow, but we shouldn't design around it.

The report-mixing risk (real, but narrow)

For the record: the report trends from saved report_*.json, and its rebuild loop keys off the profiling filename, so verify files are skipped there. The only leak is if a user manually runs the Measurement Report on a -verify.ti3 and saves it — build_report never checks the CHROMIQ_VERIFICATION keyword. One is_verification guard closes it completely, using the marker that's already written.

Recommended strategy (lowest risk first)

#	Strategy	Risk	What it gives
B ⭐	Surface + first-class what already exists: add Run.verification_ti3; a run + kind status strip in the Measure header ("run 3 of 4 · profiling" / "· verification"); Start-button wording ("will overwrite run 3's profiling" vs "create run 3's verification"); and make the report exclude any ti3 carrying CHROMIQ_VERIFICATION.	Low — no data-model change	identification ✅ · visible selection ✅ · no mixing ✅
C	Run-aware Measure: run dropdown + "＋ New run" so create-vs-overwrite is a choice, not a filename side-effect	Medium	explicit run selection / overwrite
D	Verification history per run (timestamped verify/verify_YYYY-MM-DD.ti3) instead of one overwriting slot	Higher	only if a verify history is wanted — likely skip for v1
E	"What happens when I create and measure a chart?" help card from docs/dev_folder_layout.md	Low	the high-level mental model

Proposal: ship B + E first (surfaces everything, closes the mixing risk, teaches the model), keep C as a follow-up, treat D as optional. Don't design around separate-profiles.

One deeper tension worth naming now

Your "smaller verify chart" point exposes a genuine gap: today -verify keys off the loaded chart's stem, so it cleanly tags only the same profiling chart re-measured through the profile. A dedicated smaller verify chart is a different .ti2 and would land in its own folder. The clean long-term fix (part of C/D) is to let a Run own multiple measurement kinds — a big profiling chart and an optional smaller verification chart printed through that run's profile — rather than the current "one chart == one run" coupling. Worth naming now so the model evolves the right way, even if we don't build it yet.

[itsab1989]

The same thing in plain words (for anyone skimming)

The two kinds of measurement:

• Profiling measurement — the normal one. Print the chart with colour management off, measure it, and ChromIQ learns your printer and builds a profile. This is 99% of what people do.
• Verification measurement — the "did it work?" check. Take your finished profile, print a chart through it (colour management on this time), measure that, and see how close the colours came out. It's a report card for a profile you already built.

The idea on the table: keep every verification as its own separate profile, so the two never share a folder.

Why the opposite is better. One sentence explains it:

A verification isn't a thing of its own — it's a grade for one specific profile you already made.

Like an exam: the profile is the student, the verification is that student's test score. File the score in a different drawer from the student and you've lost the one thing that made it useful — whose score it is. "Separate profiles" tears the report card away from the student it belongs to. So the better move is to keep the verification right next to the profile it grades, and just make ChromIQ show it's there. (Smaller verify charts still work fine when they live together.)

The good news: the "the report will mix them up" fear is already mostly handled. On disk they're already kept apart — profiling files are chart.ti3, verification files are chart-verify.ti3 and carry a hidden "I am a verification" stamp, and the trend already ignores the verification files. The only hole: if someone manually adds a verification file to the report and saves it, the report doesn't yet check that stamp. That's a one-line safety net — a small gap, not a broken design.

What to build, in order:

1. Show it, don't hide it (easy, safe — first) — a line at the top of Measure: "run 3 of 4 · profiling" / "· verification", and a Start button that says "this will overwrite run 3's profiling measurement" — no surprises. Plus teach the report to respect the hidden stamp so nothing can sneak in.
2. A plain-English help card (easy) — "What actually happens when I create and measure a chart?" — the big-picture map that's missing.
3. (later, more work) — a run dropdown + "new run" button in Measure, so you choose the run instead of relying on which file you opened.
4. (optional) — keep a history of verifications instead of overwriting the last one.

Suggestion: do #1 and #2 next — they solve the real problems (I can see it; it won't mix up) with the least risk, and everything underneath is already built correctly.

[soul-traveller]

What about the likely case that a normal measurement run is made to create a printer icc profile, then a smaller verification run is made monthly on that icc profile, and a measurement report created every time for those verification runs, and possibly other verification runs for same printer in a separate profile folder, or verification runs belonging to other measurement runs for the same profile folder. How can this be accomplished? And does your suggested solution allow this?

Separate «verification runs» subfolder in a measurement run folder to keep order?

[soul-traveller]

I prefer 3 and 4, as this was my starting point that is missing, and the measurement report was designed to make a report of many verification runs, which the file and UI strategy should support.

[itsab1989]

Re: monthly verification history (options 3 + 4)

You're right, and this changes my earlier recommendation. Let me own that first, then give the design that actually fits your workflow.

Where my earlier advice was wrong

I proposed "surface the runs, and make the report exclude verification measurements." That treats a verification as a throwaway pass/fail check. But your workflow is the opposite:

build a profile once → run a smaller verification chart monthly through it → a report every time → the report trends those verifications over time.

So the verifications aren't noise to hide — they're the very thing the report is meant to trend (a profile's drift, month over month). You said it exactly: "the measurement report was designed to make a report of many verification runs." Options 3 (run selector / new-run-from-Measure) and 4 (verification history) are the right target.

Why this isn't possible today (checked in code)

1. Verification is a single, overwriting slot. mark_verification_ti3 writes <stem>-verify.ti3 in the run folder; a second monthly verify overwrites the first (ti3_analysis.py). There is no history.
2. The report mixes everything. list_project_reports globs runs/*/reports/report_*.json and trends them all by date, with no profiling/verification distinction (measurement_report.py). A verification report saved into runN/reports/ lands in the same trend as the profile builds. build_report never looks at the CHROMIQ_VERIFICATION stamp.
3. Measure is file-driven. It writes next to the loaded .ti2, so it can't "start a new monthly verification of profile P" — it just overwrites whatever chart is loaded.

So: monthly history → impossible; per-profile verification trend → not a concept; mixing → real.

Proposed design (answers your questions)

A first-class verification run that lives with the profile it grades — your subfolder instinct, formalised. Yes to the verify/ subfolder.

runs/run1/                      # profiling run → builds profile P
  <name>.ti3   <name>.icc
  verify/                       # this profile's verification HISTORY
    2026-07-15_1030/
      <verifychart>.ti2/.ti3    # its own (smaller) chart + measurement, CHROMIQ_VERIFICATION
      report_2026-07-15.json
    2026-08-14_0915/
    …

• Each monthly verification = its own dated folder, tied to the run whose profile it validates. History preserved; smaller charts are natural (each folder carries its own).
• "verification runs belonging to other measurement runs in the same profile folder" → each profiling run (run1, run2 from refinement) keeps its own verify/ history. Solved by construction.
• "other verification runs for the same printer in a separate profile folder" → still works: the Measurement Report can already aggregate several sources, so you can combine across projects — but the natural, tidy home is per-run.

The report gains a "verification history" view: point it at a profile → it gathers that run's verify/*/ measurements and trends them chronologically (the drift report you designed it for). Meanwhile the existing profiling-quality trend excludes anything carrying CHROMIQ_VERIFICATION — closing the mixing risk with the marker that's already written. Two clean stories instead of one muddled one.

Measure becomes project-aware (option 3): a run/profile selector + a "New verification" action, so a monthly verify creates a new dated folder instead of overwriting.

Does this allow your scenario? Yes, end to end: profile once → monthly small verify → each a dated folder under run1/verify/ → report trends them → repeat; other runs/profiles get their own histories; cross-profile aggregation stays possible.

Effort & suggested phasing

This is the big item on this issue — it needs a folder-schema bump + migration (fold the legacy single -verify.ti3 into the first dated folder), Measure becoming project-aware, and a report mode. I'd build it in order:

• (a) verify/ history storage + the report excludes verification from the profiling trend — closes mixing and lets verifications accrue.
• (b) the verification-history report view — trend verify/*/ by date.
• (c) the Measure run selector / "New verification" UI + a plain-English help card.

No code yet — this is the design. If it looks right, I'll start at (a).

[soul-traveller]

Comments and questions:

1. I prefer calling the sub-folder "verification", because it is an action, not a verb to verify.
2. If Verification folder holds dated folders, for monthly or even weekly verification runs (whatever desired), where are the smaller chart files stored that is used for all the verification runs (one definition of chart for all verification runs belonging to that profile run. Other runs for that same profile may have a different verification chart defined, but that does not matter for the measurement report, as it handles all the metrics the same way and are comparable), as the profile measurement run and profiled icc uses a much larger chart not usable for regular verification runs? How do we then specify: a) Which run we are editing a chart for, or doing a profiling measurement run for. b) For selected run being edited, if we are defining the profiling chart, or the verification chart. Then we can have control over the charts defined for a run, all the verifications performed and the belonging reports, for both profiling runs and for verification runs. So, the Create Chart tab also needs to specify the run that the chart belongs to, as the measure tab also must specify in similar way, if the measurement is for a profiling measurement run, or a verification run (and which verification run), so that correct chart can be shown for measurment. The Print Chart tab must then also show the preview to be printed as specified in Create Chart tab, but can be specified separately in the Print Chart tab also. This way one may specify both charts in Create Chart in one go, then go to the Print Chart tab and specify which chart to print. And, the one selected for printing in Print Chart tab will automatically be selected in Measure tab when activating the Measure tab.
3. When the verification folder contains dated folders for verifications, will the report still show the profile name added, and then the verification date? And if the report is using verification run files, that the measurement report clearly shows in the title, for example "Measurement Report - Verification of Profile". And if the report uses Profiling measurement runs, the title could show "Measurement Report - Profiling of Printer"

Reanalyse with regard to these topics and give another suggestion of solution with the deails on how the folder structure will look like, how the measurement report will show the selected profile measurements in the Scope section, and a list of workflow steps when doing a profiling measurement run and when doing a verification run, from creation of charts, where they are located, printing, measuring, building profile, quality checking the profile, where all files then are placed at each step (the file strategy must keep the main run folder tidy and containing all the helper files in subfolders relating to the activity: for example helper files for measurment in sub-folder "measurment", helper files for verification in the "verification" sub-folder, helper files for building profile under sub-folder for "profile", and helper files for Check and refine under a sub-folder "check", and helper files for refinement of measurements are placed in the folder belonging to the measurements, sub-folder "measurement" for profiling measurement run refinement and sub-folder "verfification/dated folder name" for verification measurement run refinement). Analyse if this is a tidy and logical structure, or suggest better strategy to keep all the 50 types of files tidy for all the various activities. Ti1, ti2, main ti3, json file, tif files and main icc/icm should probably be kept cleanly together (for verification runs, maybe a common location in parallell to the dated verification folder?, and for profiling measurement runs, as today in the run folder)

[soul-traveller]

Also look at the possibility to add in the Preferences Reports tab a new frame "Additional header logo in report", then a field to select a logo image that will be added on the top-left header margin (automatically sized to fit the same hight as the ChromIQ logo on the right side of the header margin). The default is per today a dummy image to make the report nice, but can later be made to hold a default image from a company that sponsors the app.

[itsab1989]

Reanalysis: full profiling + verification architecture

Great questions — they push this from "add a subfolder" to "make the whole Create → Print → Measure → Build → Check pipeline run- and kind-aware." Here's the worked design: folder layout, where every file lands, the Create/Print/Measure flow, the report Scope + titling, and an honest analysis of the activity-subfolder idea against ArgyllCMS's constraints.

1. Naming

Agreed — verification/ (the activity), not verify/.

2. The one constraint that shapes everything: ArgyllCMS stem+cwd coupling

Before the layout, the rule that #127 was built around and that any new structure must respect: Argyll's tools are stem- and cwd-coupled. chartread reads <stem>.ti2 and writes <stem>.ti3 in its working dir; colprof reads <stem>.ti3 and writes <stem>.icc; printtarg writes next to the .ti1. So the coupled chart chain must physically sit together — you can't scatter .ti2/.ti3/.icc into measurement/, profile/, etc. without running each tool in its subfolder and moving/renaming its output. That's the reason #127 keeps the chain at the run root and only puts ChromIQ's own paperwork (never the coupled chain) into reports/ exports/ cache/.

I'll lean on this below rather than fight it.

3. Proposed folder structure

runs/run1/                              # ONE profile build
  <name>.ti1 .ti2 .cht .ps .channels.json .strips.json   # profiling chart chain (root — Argyll-coupled)
  <name>_NN.tif                         # printable profiling pages
  <name>.ti3                            # profiling measurement
  <name>.icc                            # the built profile
  preconditioning.* merged.* calibrated.icc              # role-named build artefacts (root — coupled)
  reads/                                # profiling refinement/averaging snapshots
  reports/                              # profiling quality checks + Refine lists + profiling report_*.json
  exports/  cache/                      # hand-off files / disposable intermediates
  meta.json
  verification/                         # NEW — this profile's verification activity
    <name>-verify.ti1 .ti2 .cht .channels.json  <name>-verify_NN.tif   # the ONE verify chart (defined once)
    2026-07-15_1030/                    # one dated folder per verification run
      <name>-verify.ti3                 # the measurement (carries CHROMIQ_VERIFICATION)
      reads/                            # this verification's own refinement snapshots
      reports/  cache/                  # this verification's report_*.json + intermediates
    2026-08-14_0915/
      …

Why this shape

• The verify chart is defined ONCE for the run and lives at verification/ root — exactly your "one definition for all verification runs of this profile run." A different profiling run may define a different verify chart; the report doesn't care (metrics are comparable).
• Each verification run is a dated folder holding only its measurement + report → true history, nothing overwritten.
• Mixing is solved by structure, not by filtering. Profiling reports live in runs/*/reports/; verification reports live in runs/runN/verification/<date>/reports/. The profiling trend globs the former, the verification trend globs the latter — they can't cross. (We still keep the CHROMIQ_VERIFICATION stamp as a belt-and-suspenders.)
• Coupling: to measure a dated verification, ChromIQ runs the reader with cwd = verification/<date>/ and the shared .ti2 referenced there (the engine writes the .ti3 straight to the dated folder; the stock-chartread fallback gets a throwaway copy of the small .ti2 in that folder). So each dated folder ends up self-contained without breaking stem+cwd coupling.

4. Analysis of the activity-subfolder idea (measurement/ profile/ check/)

Honest take: logical in the abstract, but it fights Argyll coupling for the profiling chain — measurement/<stem>.ti3 and profile/<stem>.icc would force every tool to run in a subfolder and move outputs, which is exactly the fragility #127 removed. And a "report" isn't owned by one activity — it's produced by both quality-check and verification, so a strict activity split gets ambiguous.

So I'd not re-home the profiling chain into measurement//profile/. Instead:

• Profiling activity keeps Cleaner project folder structure: group run-folder clutter into subfolders (reports/, exports/, cache/) — de-risked plan with migration + golden-manifest E2E tests #127's proven layout (coupled chain at root + reports//exports//cache/). It's already tidy — the root holds the ~8 real deliverables; everything disposable is bucketed.
• verification/ is the one genuinely-separate activity that earns its own area — different chart, different cadence, own report history, and it doesn't fight coupling (its tools run inside the dated folder). This gives you the tidy activity grouping where it actually matters, without a risky whole-tree reorg.

Net: adopt verification/; leave the profiling side as #127. If the root still feels busy later, the smaller follow-up is renaming reports/→checks/ etc., not moving the coupled chain.

5. Run- and kind-aware Create → Print → Measure

The pipeline gains two selectors that travel together — run and chart kind (Profiling / Verification):

• Create Chart: pick the run (or "＋ New run") and the kind. Profiling writes the chart chain to the run root; Verification writes it to runs/runN/verification/. You can define both charts for a run in one visit.
• Print Chart: shows the preview of the selected run+kind chart (overridable), so you print the profiling chart (CM off) or the verify chart (CM on).
• Measure: inherits the run+kind that Print last selected. Kind = Profiling → writes the run's <stem>.ti3. Kind = Verification → creates a new verification/<date>/ and writes there (never overwrites a prior date). A run/kind status strip makes this explicit ("run 1 · verification · new").

This is your "3 + 4" made concrete, extended up the pipeline so the right chart is always the one shown/printed/measured.

6. Measurement Report — Scope + titling

• Two report intents, detected from the source folder: sources under verification/*/ → a Verification report; sources at run roots → a Profiling report. (The CHROMIQ_VERIFICATION stamp confirms it.)
• Title: "Measurement Report — Verification of " vs "Measurement Report — Profiling of ".
• Scope section shows the profile name plus, for a verification report, the date span and count of the verification runs being trended (e.g. "Profile Canon-Pro300 · 6 verifications · 2026‑02 → 2026‑07"); for a profiling report, the run(s) as today. The trend x-axis is the verification date — the drift chart you designed it for.

7. Workflow step lists (where every file lands)

Profiling run

1. Create Chart — run = run1, kind = Profiling → runs/run1/<name>.ti1/.ti2/.cht/.ps/.channels.json/_NN.tif.
2. Print Chart — print the profiling chart, colour management OFF.
3. Measure — kind = Profiling → runs/run1/<name>.ti3 (refinement snapshots in reads/).
4. Build Profile — runs/run1/<name>.icc (merged/calibrated role-named at root).
5. Check & Refine — quality check + refine list + report_*.json in runs/run1/reports/.

Verification run

1. Create Chart — run = run1, kind = Verification (once) → runs/run1/verification/<name>-verify.ti1/.ti2/….
2. Print Chart — print the verify chart, colour management ON (through the profile).
3. Measure — kind = Verification (new) → runs/run1/verification/2026-08-14_0915/<name>-verify.ti3 (+ reads/ there).
4. (No Build Profile.)
5. Report — runs/run1/verification/2026-08-14_0915/reports/report_*.json; the Verification report trends verification/*/ by date.

8. Effort / phasing

This is a schema bump (v3) + migration (fold the legacy single <stem>-verify.ti3 into a first dated folder) + Create/Print/Measure run+kind awareness + report modes. Phase it:

• (a) verification/ history storage + measure-writes-dated + report reads the two areas separately (closes mixing, enables accrual).
• (b) Verification report view: Scope + titling + date-trend.
• (c) Run+kind selectors across Create/Print/Measure + help card.

9. The header-logo request (your 18:13 comment)

That one is unrelated to this run/verification architecture — it's a self-contained report-appearance feature (Preferences → Reports: pick a top-left header logo, auto-sized to the ChromIQ wordmark's height, default a neutral placeholder, sponsor-ready). I'd split it into its own issue so it can ship independently of this larger folder/pipeline work. Happy to open it and spec it there.

---

No code yet — this is the design. If the structure in §3 and the Create/Print/Measure model in §5 look right, I'll start at phase (a).

[soul-traveller]

Comments:

1. since other folders , like exports, use plural s, we can also use "verifications", instead of "verification".

Proposed folder structure

1. Your section "Why this shape", Coupling: You say " the stock-chartread fallback gets a throwaway copy of the small .ti2 in that folder)" Cannot this be automatically deleted for the "stock-chartread", so that in all cases the same is placed in the verifications/date folder (only ti3)? Also, the measurement report assumes the ti3 is next to the ti2 file. Thus, the measurement report must accept that the ti2 can exist next to the ti3 file or one level up, for the case when checking if ti2 file exists.

Analysis of the activity-subfolder idea (measurement/ profile/ check/)

1. Regarding Analysis of the activity-subfolder: You said "measurement/.ti3 and profile/.icc would force every tool to run in a subfolder and move outputs". I said the helper files should be saved in the sub-folders, like measurement or profile. This does not apply for .icc, .ti3, .ti2, .ti1. Also, the measurement sub-folder may not be applicable, since there is already a "reads" subfolder, with similar intention.

2. If a verification report contains input from several runs in the belonging profile name, then the verification report is by default placed in the reports folder that is common for all runs. This applies also for measurement reports that contain several profiling measurement runs in the belonging profile name. Thus, as with the title in the report, the report name also needs to be distinguishing the two: Thus I propose two file names start with the exact same name as the title in the document, "Measurement Report - Profiling of Printer - (then file name as before)" and "Measurement Report - Verification of Profile - (then file name as before)".
   If a verification report contains input from only one measurement run in the belonging profile name, and more than one (two or more) verification runs for that measurement run, then the verification report is by default placed in the reports folder "Profile Name/runs/runN/verifications/reports".

If a verification report contains input from only one measurement run in the belonging profile name, and only one verification run for that measurement run, then the verification report is by default placed in the reports folder "Profile Name/runs/runN/verifications/"date_time"/reports".

If measurement report contain ONE profiling measurement run in the belonging profile name, then the report is by default placed in the reports folder "Profile Name/runs/runN/"reports".

The measurement report must handle all these cases for write (and possibly read) of the related report files.

Agreed that Verification Chart files are placed in folder "Profile Name/runs/runN/verifications/".

Your "Profiling activity keeps" is agreed.

Run- and kind-aware Create → Print → Measure
You said:
"- Create Chart: pick the run (or "＋ New run") and the kind. Profiling writes the chart chain to the run root; Verification writes it to runs/runN/verification/. You can define both charts for a run in one visit.

• Print Chart: shows the preview of the selected run+kind chart (overridable), so you print the profiling chart (CM off) or the verify chart (CM on).
• Measure: inherits the run+kind that Print last selected. Kind = Profiling → writes the run's .ti3. Kind = Verification → creates a new verification// and writes there (never overwrites a prior date). A run/kind status strip makes this explicit ("run 1 · verification · new")."

I modify this to:

• Create Chart: pick "Profile run:" option ("Overwrite existing run" or "New run") and the "Run type:" option ("Profiling" or "Verification"). Profiling writes the chart chain to the run root; Verification writes it to runs/runN/verifications/. You can define both charts for a run in one visit.

**Note!
I changed the method of how selecting a run is done. IF it is easier that "Profile run:" always is a list of current runs in opened Profile Name in Create Chart, then that might be easier IF the pull-donw list content is made user friendly. This might look like:
Run 1 (overwrite)
Run 2 (overwrite)
New run

This allows user to understand that selecting exiting runs will overwrite. If your analysis prefers this method from using separate selection boxes (more complicated), then replace this method in the below description. My reservation against this is that one cannot select the verification run using the same method, unless introducing a new field anyway. Thus, to be consistent in how runs are selected, I propose using the below described method, where selection-lists appear when required.
**

If "Profile run" = "Overwrite existing run", then a selection-list must appear where user can select which of the existing profiling runs to overwrite.
If "Profile run" = "Overwrite existing run" and "Run type:"=Profiling, then existing files in the selected runs/runN/ is overwritten.
If "Profile run" = "New run" and "Run type:"=Profiling, then new runs/runN/ folder is created where files are created.

If profile run "Overwrite existing run" and "Run type:"=Verification, then a selection-list is NOT required in the Create Chart tab. This is only needed in Measure tab.
If "Profile run" = "Overwrite existing run" and "Run type:"=Verification, then existing files in the selected runs/runN/verifications is overwritten.
If "Profile run" = "New run" and "Run type:"=Verification, then new runs/runN/verifications folder is created where files are created for the chart.

User must be asked if he wants to delete previous files to start fresh for this run or continue to overwrite existing files. Note that some files risk not being overwritten, depending what activity is being done. But, when measuring fresh, the old related measure files (ti3 or others, like reads/ files?) should be moved to a "Old files"(or similar) folder before writing new files. The same goes for building new icc or making quality check. If only modifying ti3 with a re-measurement of strips, then the old ti3 can be copies to "Old" folder for retaining old version.
If "Run type:"= Profiling, then the chart files for the runs/runN/ are modified/created according to "Profile run" selected.
If "Run type:"= Verification, then the chart files for the runs/runN/verifications are modified/created according to "Profile run" selected.

• Print Chart: shows the preview of the selected "Profile run" + "Run type" chart (overridable), so you print the profiling chart (CM off) or the verify chart (CM on). This difference must be mentioned in help text and user receive guidance as usual in this window.
  The "Profile run" + "Run type" can be manually selected, but is by default inherited from setting in Create Chart when clicking the Print Chart tab (this includes any selection list where a run and/or verification is selected).

• Measure: "Profile run" + "Run type" can be manually selected, but is by default inherited from setting in Print Chart tab when clicking the Measure tab (this includes any selection list where "Run type" profiling or verification is selected). Selection list only appears when "Profile run" = "Overwrite existing run". However, if a user wants to overwrite an existing profiling run AND an existing verification run, then the user must manually change between "Run type" = Profiling and "Run type" = Verification.

If "Profile run" = "Overwrite existing run", then a selection-list must appear where user can select which of the existing profiling runs to overwrite. This setting is inherited from the Print Chart tab as default.
If "Profile run" = "Overwrite existing run" and "Run type:"=Profiling, then existing files in the selected runs/runN/ is overwritten.
If "Profile run" = "New run" and "Run type:"=Profiling, then new runs/runN/ folder is created (if not created in earlier Create Chart or Print Chart tabs) where files are created. The app must track if the new runs/runN/ folder has been created, so that it does not falsely create this again.

If "Profile run" = "Overwrite existing run" AND "Run type" = Verification, another selection-list must appear where user can select which of the existing verification runs to overwrite. This cannot be inherited from Crate Chart or Print Chart tab, but default selection shall be the last verification run made. So, for the Measure tab, two selection lists may be visible at the same time.
If "Profile run" = "New run" and "Run type:"=Verification, then creates a new runs/runN/verifications<date_time>/ folder is created where files are created for the verification measurement (never overwrites a prior date).

A "Profile run"/"Run type" status strip makes this explicit ("run 1 · verification · new")."

Analyse use of these fields in Create Chart tab, Print Chart tab and Measure tab to map all the cases that must be covered, so that moving from one tab to the other is as seamless and simple as possible. What is the best solution? Should maybe these fields be interlinked for all of the three tabs, so that they always are the same, no matter where user changes any of the fields?
Identify any weeknesses or holes that must be handled.

In Build Profile tab, the "Profile run" is not editable, but as shown in Measure tab. The "Run type" is always set to Profiling (not editable), as it is not possible to build a profile with "Run type" = Verification.
Same for Check & Refine tab.

The "Verify a Profile" tool
The "Verify a Profile" tool is made to select a ti3 file belonging to a verification run to verify a profile. Here the selected profile run icc file is used, but the ti3 file should come from any of the verification runs for that selected profile run. This needs to be explained well in help text and on-screen guidance of the tool window.
Also, if a profile run has been selected in any of the 3 first tabs (Create Chart, Print Chart, Measure. They are always the same, right?) then the runs/runN/ folder should be the default location for browsing file dialog. Else, the Loaded Profile Name folder is default location for browsing file dialog. If also that is not selected, then the default ChromIQ folder is made default for browsing file dialog.
The default browsing location for the ti3 file will also be runs/runN/verification/<date_time> folder as selected in any of the 3 first tabs (Create Chart, Print Chart, Measure). If verification run has not been selected, then the default browsing location should be runs/runN/verification. If profile run has not been selected, then fall back to default browsing location runs/runN. If Profile Name has not been loaded, then the default ChromIQ folder is made default for browsing file dialog.
Also, output from the "Verify a Profile" tool should by default be to the folder where the selected ti3 lives. This should mostly be in runs/runN/verification/<date_time> folder, but could also be selected independently from other location.

Finally, we are using the term verification run for a process performed after profiling, then chart printed using that profile, then measure... The measuring step is obviously the first step of this process, the next step is to make the Measurement Report and then also use the "Verify a Profile" tool. The name "Verify a Profile" for this tool may be a bit confusing, if one does not understand the steps involved in a verification run. Make this process clear in help cards, help texts in various tabs and in "Verify a Profile" tool, so that the user understands the steps associated with a verification run.

Measurement Report — Scope + titling
You said:
"Title: "Measurement Report — Verification of " vs "Measurement Report — Profiling of "."

I prefer:
"Measurement Report - Profiling of Printer - (then file name as before)" and "Measurement Report - Verification of Profile - (then file name as before)". The reason is that one is a profiling of a printer, the other verification of a profile. Your suggestion does not distinguish between the two and gives the impression that both are for the printer name used in the profile name.

You said:
"Scope section shows the profile name plus, for a verification report, the date span and count of the verification runs being trended (e.g. "Profile Canon-Pro300 · 6 verifications · 2026‑02 → 2026‑07"); for a profiling report, the run(s) as today. The trend x-axis is the verification date — the drift chart you designed it for."

Today the "Report Scope" section lists for a profiling run: the profile name, instrument, runs. Example "Canon-Pro300-Glossy, Instrument: X-Rite i1 Pro · 5 runs", and then allows many such runs to be listed as part of the report.
For a verification run the section shall show: the profile name, instrument, verification runs

The combined date range for the selected profile runs / verification runs are shown in a separate paragraph called "Date range:", and shall not be placed in the list below the text "The following profile(s) measurement runs are included:"

Workflow step lists (where every file lands)
Replace the terms you used for run = run1, kind = Profiling etc, in the listed workflows, as defined with above mentioned field names:
Example: "Profile run" = "Overwrite existing run" (then select run in selection-list) and "Run type:"= Profiling
Make sure steps, field names, options and folders are understood as discussed above. Else ok. Help descriptions should include these steps so understand the difference between the two processes, including in the high level overview of steps in the discussed new help card.

Make sure all these comments are understood and the action proposal is updated with the correct details and shown again for review. Many details are required here to avoid gaps and illogical behaviour. Make sure your analysis covers all user-eventualities and combinations of settings, and that all combinations have a defined action/method with logical associated folder strategy, and list all these combinations for review.

[itsab1989]

Updated design — full run/kind model, all combinations mapped

Incorporating every correction. Structured so each open question has one defined answer, with a complete combination matrix and a holes list at the end.

Accepted corrections

• Folder is verifications/ (plural, like exports/).
• Helpers already live in subfolders (reads/, reports/, exports/, cache/) — so I'm dropping the measurement//profile/ idea: reads/ already is the "measurement helpers" folder, colprof intermediates already go to cache/. The coupled chain (.ti1/.ti2/.ti3/.icc) stays at the run root. Profiling layout = Cleaner project folder structure: group run-folder clutter into subfolders (reports/, exports/, cache/) — de-risked plan with migration + golden-manifest E2E tests #127, unchanged. Agreed.
• Verify chart files live in runs/runN/verifications/. Agreed.

The stock-chartread .ti2 copy → deleted, and the report looks one level up

Yes: for the stock-chartread fallback we drop a throwaway copy of the small verify .ti2 into the dated folder, run the read, then delete it — so in all cases a dated folder contains only the .ti3 (+ its reads/, reports/). (The engine writes the .ti3 straight there, no copy at all.) Consequently the report's "is there a .ti2 next to this .ti3?" reference lookup must also check one level up (verifications/<name>-verify.ti2). Small, well-defined change.

Folder structure

<Profile Name>/
  project.json
  reports/                                   # NEW: reports spanning several runs (project-wide)
  exports/                                    # Tools exports (project-wide, as today)
  cal/  …
  runs/run1/
    <name>.ti1 .ti2 .ti3 .icc .cht .ps .channels.json .strips.json  <name>_NN.tif   # profiling chain (root)
    preconditioning.* merged.* calibrated.icc
    reads/  reports/  exports/  cache/        # #127, unchanged
    old/                                      # NEW (optional): "start fresh" archive of prior files
    meta.json
    verifications/                            # NEW
      <name>-verify.ti1 .ti2 .cht .channels.json  <name>-verify_NN.tif   # the ONE verify chart for run1
      reports/                                # verification reports spanning several dates of run1
      2026-07-15_1030/
        <name>-verify.ti3                     # the measurement only (CHROMIQ_VERIFICATION)
        reads/  reports/  cache/
      2026-08-14_0915/  …

Report placement = lowest common ancestor of its inputs

This captures your four cases with one rule — a report is written at the deepest folder that contains all its input measurements:

Report inputs	Saved in
1 profiling run	runs/runN/reports/
≥2 profiling runs (same profile)	<Profile>/reports/ (project-wide)
1 verification date (of 1 run)	runs/runN/verifications/<date>/reports/
≥2 verification dates of 1 run	runs/runN/verifications/reports/
verifications across ≥2 runs	<Profile>/reports/ (project-wide)

New: a project-level reports/ folder for cross-run reports. The trend-data JSONs keep their machine name (report_*.json) so gathering still works, plus a "kind": "profiling"|"verification" field; the exported PDF gets the human name = the title (below). Because profiling and verification reports live in physically separate folders, the two trends can never cross.

Report titles + filenames (your wording)

• Profiling: Measurement Report - Profiling of Printer - <name>.<ext>
• Verification: Measurement Report - Verification of Profile - <name>.<ext>

(The exported PDF filename equals the document title.)

Report Scope section

• Profiling: Canon-Pro300-Glossy, Instrument: X-Rite i1 Pro · 5 runs (as today), list of included runs.
• Verification: Canon-Pro300-Glossy, Instrument: X-Rite i1 Pro · 5 verification runs.
• The combined Date range: goes in its own paragraph, not inside the "The following … runs are included:" list. Trend x-axis = the (verification) date.

Run + kind fields — one shared context (my recommendation on your interlink question)

You asked whether the fields should be interlinked across the three tabs. Yes — make them one shared "active target" the app owns, that all of Create/Print/Measure bind to. Changing it anywhere updates everywhere. This beats forward-only inheritance (Create→Print→Measure), which breaks if the user skips a tab (e.g. jumps straight to Measure) — a real hole. The shared target holds:

• Profile run = Overwrite run N | New run
• Run type = Profiling | Verification
• Verification date = Overwrite <date> | New — only meaningful for Measure + the Verify tool

Each tab shows the subset it needs; a selection-list appears only when Overwrite is chosen. Your single-dropdown idea (Run 1 (overwrite) / Run 2 (overwrite) / New run) is the friendlier control for Profile run — I'd adopt it there; Run type stays a two-way toggle; the Verification date is a second dropdown that appears only in Measure/Verify when Run type = Verification + Overwrite. A status strip echoes it everywhere: "run 1 · verification · new".

The complete combination matrix

Create Chart (defines a chart; no date — the verify chart is one-per-run)

Profile run	Run type	Result
Overwrite run N	Profiling	writes/overwrites runs/runN/<name>.* (chain + pages)
Overwrite run N	Verification	writes/overwrites runs/runN/verifications/<name>-verify.*
New run	Profiling	creates runs/runN+1/, writes <name>.*
New run	Verification	⚠ see Hole 1 — redirect to defining a verify chart for an existing profiled run

Print Chart (inherits the shared target; overridable)

Run type	Prints	Colour management
Profiling	runs/runN/<name>_NN.tif	OFF
Verification	runs/runN/verifications/<name>-verify_NN.tif	ON (through the profile)

Measure

Profile run	Run type	Verification date	Writes
Overwrite run N	Profiling	—	runs/runN/<name>.ti3 (fresh → archive old to old/)
Overwrite run N	Verification	New	runs/runN/verifications/<newdate>/<name>-verify.ti3
Overwrite run N	Verification	Overwrite <date>	re-measure runs/runN/verifications/<date>/<name>-verify.ti3
New run	Profiling	—	creates runs/runN+1/ (if not already), writes <name>.ti3
New run	Verification	—	⚠ Hole 1

Measure is the only tab that can show two lists at once (which run to overwrite and which verification date); the verification-date list defaults to the latest date.

Build Profile / Check & Refine — Profile run shown (read-only, mirrors the shared target); Run type locked to Profiling (can't build/refine from a verification). Agreed.

"Verify a Profile" tool

• Uses the selected run's .icc + a .ti3 from any of that run's verification dates.
• Browse defaults (cascade):
  • profile .icc: runs/runN/ (if a run is active) → loaded-project folder → ~/ChromIQ/.
  • verification .ti3: runs/runN/verifications/<date>/ (if a date is active) → runs/runN/verifications/ → runs/runN/ → loaded-project → ~/ChromIQ/.
  • output: the folder the chosen .ti3 lives in (usually verifications/<date>/), overridable.
• Naming/clarity: "Verify a Profile" is only the last step of a verification run (print-through-profile → measure → report → this tool). Add a help card that lays out the whole verification-run flow, and cross-reference it from the Measure/Report/tool help so the name isn't confusing.

Overwrite safety ("start fresh" vs "overwrite")

On any overwrite that would replace existing data, prompt "Start fresh" vs "Overwrite in place." Start fresh moves the activity's prior outputs into runs/runN/old/<timestamp>/ before writing — measure → .ti3 + reads/; build → .icc; check → its reports. A strip re-measure copies the old .ti3 into old/ first. Nothing is silently destroyed.

Holes / weaknesses to resolve (flagged for decision)

1. Verification needs a built profile. "New run + Verification" is semantically empty (nothing to verify yet). → Constrain Run type = Verification to existing, profiled runs; "New" then applies to the verification date, not a new run. (This is the main correction to your matrix.)
2. No verify chart defined yet → measuring a verification prompts "define a verification chart first" (Create Chart · Verification).
3. Overwriting a profiling run that already has verifications → those verifications graded the old profile; warn and offer to archive them to old/ (they no longer match the rebuilt profile).
4. Migration: fold a legacy single <stem>-verify.ti3 into verifications/<its date>/ on load (schema v3 + migration).
5. Cross-project verification report save location is ambiguous → default next to the primary picked source, or prompt.
6. Report gathering now reads two disjoint areas (runs/*/reports/ for profiling, runs/runN/verifications/*/… for verification) — the gather + _source_key dedup logic must branch on kind.
7. No profile loaded → all run/kind fields disabled with a hint.
8. Delete/rename a run must cascade to its verifications/.
9. Instrument mixing across verification dates → the existing Scope instrument-warning already covers it; keep it.

Scope note

This has grown from "#130: surface runs" into a run/chart/verification/report re-architecture (schema v3 + migration, three run-aware tabs, a shared target model, report placement/titling, the Verify-tool cascade, an old/ archive). I'd split it into tracked sub-issues and build in the phase order I gave earlier (a: verifications/ storage + report separation → b: verification report view/titles/scope → c: the shared run/kind selectors + Verify-tool cascade + help cards → d: overwrite/old/ safety). The report header-logo request is unrelated and should be its own issue.

Please review the matrix and Hole 1 in particular — that's the one place I've deviated from your description, and I think it removes an illogical combination.

[soul-traveller]

Make sure to use the terms "Profile run" and "Run type" names/labels, not run and kind, in the json files and other places. Be consistent all places.

Hole 1: If New run + verification is selected without a built profile existing, one could give a warning message that the a profiling measurement run must first be completed an a profile created. Then verification run can be started. Then notify that the Run type is set to Profiling and to change to start Verification run when the profile is completed. There is no need to create the verifications/<date_time> folder before a verification measurement run can actually be performed.

I think this is similar behaviour to Hole 2.

Hole 2. good
Hole 3. good
Hole 4. OK
Hole 5. good

Hole 6: what does this mean? "Report gathering now reads two disjoint areas (runs//reports/ for profiling, runs/runN/verifications//… for verification) — the gather + _source_key dedup logic must branch on kind."

For verifications there are four reports locations, depending on where the measurements included come from
profile_name/reports
runs/*/reports/
runs/runN/verifications/reports
runs/runN/verifications/<date_time>/reports

When the measurement report tool is gathering information to build the report I guess there is only two locations:
runs/*/reports/
runs/runN/verifications/<date_time>/reports
The included measurements and their location dictates where the reports must be read from, and the measurement report tool must do this correctly. Have I understood correctly?

Hole 7. good
Hole 8. good
Hole 9. good

If Sebastian is good with all this, I am satisfied.

[soul-traveller]

I would also like to propose to add two parameters in the preferences window, Reports tab:
Two Free-Text fields to define the front part of the Measurement Report titles + filenames.

Frame: "Default measurement report title and file name":
Profiling measurement runs: "Measurement Report - Profiling of Printer" + " - .pdf"
Verification measurement runs: "Measurement Report - Verification of Profile" + " - .pdf"

The last part

• " - .pdf"
  is not part of the input text fields and can be omitted, but if informative they can be non editable text. However, is currently date_time stamp, not a name of profile or similar. Thus it would be more correct to specify
• " - <date_time>.pdf"

The title on the first page of the generated pdf and on the file name generated will then take its text from these two fields, depending on type of measurement report from selected included ti3 files. The exported PDF filename equals the document title.

[itsab1989]

Converged — confirmations + the last refinements

Agreed on nearly everything. Locking the four open points, plus your new preference fields.

Terminology (locked)

User-facing labels are "Profile run" and "Run type" everywhere (tabs, help, status strip). In JSON/metadata the keys are the snake_case equivalents — profile_run and run_type (values "profiling" / "verification") — so code and files stay consistent with the labels. No more "run"/"kind".

Hole 1 — adopting your softer handling

Instead of hard-blocking, when the user picks New run + Run type = Verification with no profile yet:

• show a message: "A verification checks a finished profile. First complete a profiling run and build its profile; then start a verification run."
• auto-set Run type back to Profiling and note that they can switch to Verification once the profile exists,
• and don't create any verifications/<date_time>/ folder until a verification is actually measured.

Same spirit as Hole 2 (nothing is pre-created; the folder appears only when a measurement is taken). Good call.

Hole 6 — you understood it correctly; here's the clean split

The confusion is that "report" means two different things. Separating them removes it:

• Per-measurement report point (report_*.json) — one per measurement, holding that measurement's metrics. It's the trend data point, and it lives next to its own measurement:
  • profiling measurement → runs/runN/reports/
  • verification measurement → runs/runN/verifications/<date_time>/reports/
    So there are exactly two kinds of source locations — exactly your two. ✔
• Combined report document (the exported PDF, trending many points) — written to the lowest-common-ancestor of the included measurements (the 4-way table from before: run root / project / verifications/ / verifications/<date>/).

So: gathering READS the per-measurement points from the two measurement locations; the PDF is WRITTEN to the LCA. The included measurements dictate both — read from where they live, write to their common ancestor. A profiling report only ever gathers profiling points; a verification report only verification points (separate folders + the run_type/CHROMIQ_VERIFICATION marker) — they can't mix. Your understanding is right.

New: configurable report title/filename prefixes (your 01:32)

Two free-text fields in Preferences → Reports, in a frame "Default measurement report title and file name":

• Profiling: Measurement Report - Profiling of Printer
• Verification: Measurement Report - Verification of Profile

The trailing part is - <date_time>.pdf, shown as non-editable info (you're right — today <name> is the %Y-%m-%d_%H-%M-%S stamp, so it should read <date_time>, not <name>). The chosen field (by report type) becomes both the first-page title and the PDF filename → "<prefix> - <date_time>.pdf". This supersedes hard-coding the titles.

Note there are now two Reports-tab preference additions — these title prefixes and your earlier header-logo request. I'd group both under a small "Report appearance" slice (own issue), independent of the big folder/run-model work, so they can ship early and quickly.

Status

I think this is fully converged and gap-free. Over to Sebastian for the go-ahead. When approved, I'll split #130 into tracked sub-issues and build in phases:

• (a) verifications/ storage + profile_run/run_type metadata + report read/write separation (closes mixing, enables accrual).
• (b) Verification report view: titles, Scope (… · N verification runs, Date range: paragraph), date-trend.
• (c) Shared Profile-run/Run-type target across Create/Print/Measure + the Verify-tool browse cascade + help cards (incl. the "what is a verification run" flow).
• (d) Overwrite safety (old/ archive).
• Separate, early: Report-appearance prefs (title prefixes + header logo).

[soul-traveller]

One more field for the report naming:
I forgot something: The title in the PDF shall NOT have the " - <date_time>" as part of the title. This is only in the file name. Inside the report there is already a date specified and shall not be part of the title.

I want to add add a new field in Preferences → Reports, in a frame "Default measurement report title and file name":
"Add profile name in title and file name:", options: True or False. Default is True.
Then the title and file name of the report will add the profile name from the root folder run files for the profile, same as the Profile Name field in Create Chart tab.

The naming structure shall then be:
File name: - <profile_name> - <date_time>.pdf
Report title: - <profile_name>

Where "" is the two free-text fields in Preferences → Reports, in a frame "Default measurement report title and file name", which depend on if the report is for profiling or for verification.