Compare Profile Revisions Without Losing the Test Context

A profile revision is more than a changed temperature or speed. A slicer release can resolve inheritance differently, a printer or nozzle can change the applicable machine limits, a project can contain object-level overrides, and post-processing can change the final output after preview. Compare the context and effective result before deciding that one revision is better.

Freeze both sides first

Save the original artifacts and record, for revision A and revision B:

• profile identifier, revision, lifecycle state, source, and date;
• slicer name, exact release or channel, machine/material/process presets, inheritance, overrides, and compatibility warnings;
• printer model and variant, firmware, nozzle diameter and material, extruder/tool, plate, and material vendor/product and dry state;
• layer height, line widths, temperatures, cooling, flow, maximum volumetric speed, retraction, pressure or linear advance, supports, speeds, acceleration, and machine G-code; and
• project or model, output format, post-processing script, final file or package, test object, procedure, observed result, and remaining unknowns.

A visible field may not be the effective field. Follow inherited, calculated, per-object, per-extruder, and material overrides in the selected slicer. If a value is absent from the exported artifact, record it as omitted rather than assuming the old value carried forward.

Use a change matrix

comparison:
  from: "profile-id revision"
  to: "profile-id revision"
  reason: "calibration / hardware / release / correction / unknown"
identity_changes:
  printer: "same or described change"
  firmware: "same or described change"
  nozzle_plate_material: "same or described change"
software_changes:
  slicer_release: "old -> new"
  preset_inheritance: "old -> new"
  post_processing: "old -> new"
effective_value_changes:
  - field: "field name"
    before: "value or unknown"
    after: "value or unknown"
    owner: "machine/material/process/project/firmware"
    reason: "why it changed or unknown"
output_changes: ["format, package members, final G-code, or omitted fields"]
test_changes: ["object, procedure, date, result, environment"]
status: "starting-point / physically-verified / superseded / unknown"
rollback: "previous revision or snapshot"

The owner matters. A flow field in a material preset, a maximum volumetric limit in a filament profile, a line width in a process profile, and a pressure command in firmware are related to the print but are not interchangeable controls. A numerical difference is not automatically a meaningful behavioral difference, and a matching number is not proof of matching behavior.

Interpret the result conservatively

First ask whether the revisions were tested on the same physical context. If not, treat the comparison as a software or documentation comparison, not a controlled A/B result. If the test object, geometry, dry state, plate condition, or maintenance state changed, report that confounder. If several variables changed together, describe the new package and avoid attributing the result to one field.

Validate in increasing-cost order: reopen both profiles, compare effective values and warnings, inspect previews and final outputs, run a small first-layer or control-specific check, then print a representative object. Keep the earlier revision as rollback even when the newer one looks cleaner. A passed software profile check proves only that the defined software checks passed; it does not prove physical print quality.

When the change is a correction rather than an experiment, link the correction record instead of rewriting the old result. Use correct and supersede a community profile to make the reason, impact, replacement, and history visible.