A manufacturing traveler needs more than a done flag

A job can be finished at one workstation and still be nowhere near a finished part. That sounds obvious on a factory floor, but a database with one status column can quietly erase the distinction.

A recent hybrid manufacturing example makes the problem concrete. On August 24, ORNL described work with A.J. Tuck that combines polymer printing, electroforming and hot isostatic pressing. The first phase produced five cylindrical HIP cans; more complex geometry belongs to an ongoing second phase. It is a bounded demonstration, not evidence that any arbitrary part is qualified. ORNL announcement

The associated technology description follows a polymer mandrel through shell deposition, mandrel removal, powder filling and HIP consolidation. Those are distinct material states, even when everyone refers to the same job number. ORNL process description

Separate position in the route from disposition

Imagine building a digital manufacturing traveler: a record that accompanies an item through its operations. I would model two independent questions:

• Where is the item in this route?
• What decision has been made about the evidence for that operation?

A shell can exist while its measurements are still awaiting review. Calling both conditions done encourages downstream software to treat physical completion as permission to continue. A stage describes what happened; a disposition records what the responsible process allows next.

Here is a proposed data-model example, not an ORNL system, implementation or acceptance rule. All identifiers are fictional.

{
  "traveler_id": "demo-001",
  "design_revision": "D3",
  "route_revision": "R2",
  "stage": "shell_formed",
  "record_version": 7,
  "latest_event": {
    "event_id": "demo-event-017",
    "from": "mandrel_printed",
    "to": "shell_formed",
    "criterion_revision": "demo-criteria-C4",
    "evidence_refs": [
      "demo:bath-log/17",
      "demo:measurement-map/17"
    ],
    "disposition": "pending_review"
  }
}

The references identify records; their presence does not prove that the records contain adequate measurements. Likewise, the criterion revision points to a separately controlled requirement. It is deliberately not a tolerance invented by the application developer.

Make transitions explicit

For a small prototype, I would start with a route table containing allowed stage pairs and the required evidence categories. A proposed transition would name the route revision, current record version and event identifier.

The service would reject a stale version instead of overwriting another operator's update. Repeated delivery of the same event identifier would return the existing event; reuse with different content would be a conflict. Recording the event and updating the current projection would occur in one transaction. These are proposed software rules, not reported features of the research project.

Physical work and digital recording can also disagree. If an operator reports that an operation occurred while required evidence is missing, the system should retain that observation and flag the discrepancy. Silently refusing to record it would produce a cleaner database and a less truthful traveler.

Preserve context when something changes

A.J. Tuck's general process overview describes bath analysis, mechanical testing, and records connecting parts to tanks and operating dates. That illustrates why a filename alone can be weak context for a manufacturing result. A.J. Tuck process overview

In the proposed model, a design revision would not overwrite the identity attached to earlier events. Rework would create another event rather than edit the history into apparent first-pass success. A material split or merge would require explicit parent-child links before the example could support it. The compact JSON above does not implement those cases.

Useful tests follow directly: a stale update cannot advance the projection; a duplicate event cannot advance it twice; pending review is not release; and a new design revision cannot silently inherit an earlier decision.

The payoff is modest but important: the application can explain which state it knows about and which decision remains open. It still cannot declare a component fit for service. That boundary belongs in the data model, not just in a disclaimer.