A Reproducible Additive Manufacturing Run Record: Inputs, Observations and Owners

Additive manufacturing teams often discover that a printed part is only as trustworthy as the record behind it. A qualified result is not merely a geometry that passed inspection; it is a documented chain of material inputs, machine activities, human decisions and observed deviations. This article sets out a practical operating method for capturing a reproducible step-by-step record of an additive run, using provenance concepts from the PROV Model Primer and dataset-description ideas from the Data Catalog Vocabulary (DCAT) Version 3. The goal is not to create administrative overhead, but to make a build repeatable, reviewable and transferable to another shift, site or auditor.

Framing the Run as Provenance, Not Just a Log

Every additive build can be described as a set of entities consumed and produced by activities that are carried out by responsible agents. A spool of powder, a build file, a machine setup and a finished component are entities. The laser powder bed fusion job, the post-print heat treatment and the inspection pass are activities. Operators, process engineers and quality reviewers are agents who bear responsibility for what they did. The PROV primer introduces these core distinctions so that a record can say not only that something happened, but who or what made it happen and from which prior things it was derived. When a shop treats a run record as provenance rather than a flat text log, it becomes possible to answer why a dimension drifted or why a surface anomaly appeared only in certain regions of the platform. This framing also supports later reuse: if a customer asks whether a bracket made last quarter can be remade with the same feedstock, the record shows the input lots and the parameter set rather than leaving the question to memory.

Declaring Inputs Before the Machine Starts

The first operational step is to fix the inputs in writing before the job is queued. For powder bed systems, this means recording alloy specification, particle-size distribution reference, lot number, supplier and storage conditions such as humidity exposure or sieve history. For resin or filament processes covered in other columns such as resin process control, the equivalent inputs are resin batch, exposure baseline and wash-cure configuration. The build file itself should be identified by hash or version so that the exact sliced geometry is unambiguous. Recycled powder ratios, if used, belong here as an explicit derived entity with a stated number of prior reuse cycles. DCAT 3 provides vocabulary for describing distributions and checksums of dataset-like resources; while originally aimed at web data catalogs, the idea that a resource carries a stable identifier and a digest is directly useful when the build program or inspection dataset is the resource being described. Writing inputs first prevents the common failure where a record is reconstructed after the fact and the true feedstock conditions are lost.

Running the Build with Timestamped Observations

During the run, the record must capture observations rather than only final pass/fail states. Melt-pool monitoring traces, recoater alerts, oxygen-level dips or a brief gas-flow interruption are all observations that may later explain a defect. Each observation should be tied to a time interval and, where possible, to a region of the build volume. Activity start and stop times, layer ranges and platform temperature readings give the temporal backbone that provenance models require. An exception such as a skipped layer check or a manual pause should be recorded with the name of the person who authorized it and the reason given at that moment. This is the difference between a log that says the part was made and a record that explains how the part came to have its specific history. Teams using metal processes will find that this observational discipline connects closely to the questions raised in metal print strength reporting, where orientation and local thermal history change the meaning of a test result.

Assigning an Owner to Each Stage

A record without ownership is a rumor. The practical method assigns one named owner per stage: preparation owner, machine-run owner, post-process owner and release owner. In provenance terms these are the agents and their roles; the primer distinguishes the person from the function they exercised, which matters when a supervisor temporarily covers a line or when a service bureau acts on behalf of a client. The owner is not blamed for every anomaly, but is accountable for having recorded it or having escalated it. When a deviation occurs, the owner writes the initial entry and a reviewer countersigns before the next stage begins. This creates a chain of responsibility that survives shift handovers. Internal process pages such as heat treatment documentation practice show why the post-print owner must record furnace loading, set points and actual soak conditions rather than assuming the previous operator already did so. Clear ownership also makes it possible to ask a precise question later: who decided to accept a recoater warning and continue, and on what evidence.

Recording Exceptions and Their Disposition

Exceptions are where most run records fail. A stopped build, a replaced filter or a substituted alloy lot all change the provenance of the output. The operating rule is simple: every interruption becomes an entity with a cause, a time, an owner and a disposition. If the build continued, the record states the assessment that allowed continuation. If the part was scrapped, the scrap reason is linked to the observation that triggered it. If a repair or re-print was performed, the new run is marked as a revision derived from the original attempt, so the history is not erased by the successful final part. Treating exceptions as first-class entries rather than footnotes means that a later reviewer can see the full path, including the abandoned branch. This approach also helps when several parts share a build plate: one anomalous region does not invalidate the whole record if each part’s local observations are separable and each disposition is documented for the specific serial rather than the whole job.

Packaging the Record for Review and Reuse

The final step closes the loop. The completed record should bundle inputs, activities, observations, exceptions and owners into a single retrievable object with a stable identity, so that a future engineer can fetch it alongside the part data rather than hunting through separate spreadsheets and machine screenshots. Describing that bundle with catalog-style metadata—title, creator, creation date, checksum of attached files and relation to prior versions—follows the resource-description pattern in DCAT 3 and keeps the record usable across systems. The value appears during audit or repeat production: the next build can start from the prior record, change only what is intended, and keep the rest constant. Rather than restating that documentation matters, the point is operational—without this packaging, each new run silently reinvents its assumptions, and the shop loses the ability to prove that two parts are truly comparable. For readers tracking process signals more broadly, the discipline complements the monitoring-context questions in other columns, because a signal is only interpretable when its surrounding record survives with it.