Community Profiles & Evidence

A contributor handoff checklist for sharing a profile or project with printer, material, slicer, test, privacy, and verification context.

reviewed Community 3 min read

Share a 3D-Printing Profile with Enough Context to Reproduce the Result

A shared profile is a handoff, not just a file. The recipient needs to know which machine, material, slicer, and test gave the settings meaning. A project, preset bundle, backup, metadata-bearing 3MF, or plain G-code preserves a different amount of context; an import message does not prove that the target printer or physical result is equivalent.

Choose the smallest useful artifact

Use the object that matches the reader’s purpose:

  • Preset or process bundle: reusable settings when the recipient will choose their own machine and material context.
  • Project: model, modifiers, selected configuration, and print settings when the recipient needs to inspect how the slice was made.
  • Packaged sliced job: only when the recipient’s workflow supports that format and its metadata scope is understood.
  • Plain G-code: a toolpath artifact, not a complete profile. It may omit the printer, material, process, inheritance, and test context needed to reproduce the slice.

Keep host or machine exports separate from shareable process settings. An export can contain an IP address, API key, account identifier, local path, or other endpoint data. Inspect the package and remove secrets before attaching it to a post, issue, or repository.

Write an identity card

Record the context next to the artifact, not only in a filename such as final:

profile_id: "human-readable name plus revision"
status: "starting-point / physically-verified / superseded / unknown"
slicer: {name: "name", release: "exact version", channel: "stable/beta/unknown"}
printer: {model: "exact model", variant: "variant", firmware: "release or unknown"}
nozzle: {diameter_mm: 0.4, material: "actual type", wear: "new/used/unknown"}
plate: "surface and selected plate profile"
material: {vendor: "name", product: "grade/color", dry_state: "recorded/unknown"}
presets: {machine: "name", material: "name", process: "name"}
changes: ["field or relationship changed"]
test: {object: "name", date: "date", result: "observed result or not tested"}
output: {format: "file/package", post_processing: "none or described"}
rollback: "previous profile identifier or snapshot"

This is a communication aid, not a universal interchange schema. Write unknown, not checked, or not applicable rather than filling gaps with the latest firmware, a similar printer, or a generic filament label.

Label the result honestly

Use starting point when the values came from a preset, manufacturer guidance, another maker, or a software-only check. Use physically verified only for the named printer, material product, nozzle, plate, slicer release, geometry, and test conditions that were actually checked. A successful first layer validates that checkpoint, not every speed, support, dimensional, or long-term claim. If a revision is replaced, mark it superseded and keep the old identifier as a rollback reference.

Give the recipient a safe next step

Ask the recipient to confirm identity and effective inherited values, inspect the preview and final output, run a small first-layer or calibration check on the actual setup, and then print a representative part. If the context does not match, the useful answer is an adaptation plan—not a promise that the shared file is ready to run.

Trace the context

Sources & provenance

Sources are shown with the quality tier recorded by the author. A source tier describes the source, not a guarantee that every claim on this page was tested.

  1. Import & Exportspecialist
  2. Saving projects as 3MFprimary
  3. How to import and export custom profiles in PrusaSlicerprimary
  4. SDK backupsspecialist
  5. Immutable releasesprimary