Most audit trail systems answer one question: what was sent?
SMC is designed to answer a harder one: what did the machine actually execute?
That distinction matters more than it might seem.
The Gap Between “Sent” and “Executed”
In a standard file transfer workflow — even a secure one — the audit trail usually stops at delivery. A file was authenticated. It was encrypted in transit. It arrived at the controller. The transfer is logged.
That is where most systems lose visibility. DNC software, manual transfers, even encrypted delivery — they all end at the same place: we sent it.
But delivery is not execution. A file can be delivered correctly and then be overwritten by a different version already on the controller, modified by someone with local access before the job runs, or adjusted at the machine for feeds, speeds, or tool stations. Those scenarios are not unusual — they happen on shop floors every day. And they are almost never captured by transfer logs.
From an audit perspective, this creates a gap between transfer assurance and execution assurance. For defense manufacturing — where G-code encodes the geometry, dimensions, and process details of controlled parts — that gap matters.
What Transfer Proof Does
Before a G-code program is transmitted to a CNC controller, SMC injects structured audit markers directly into the program. These markers travel with the file and become part of what the controller processes. They include file identity, transfer session, integrity reference, and traceability checkpoints at key points through the program.
On supported controllers, SMC captures execution echo and correlates it with the transferred program — providing evidence not just that the file was delivered, but that the machine ran it.
That shifts the audit record from a delivery event to execution-level traceability.
When the Machinist Changes Something
This is the part most systems ignore entirely.
A machinist tweaks a feed rate at the controller. Adjusts a tool offset. Changes an approach angle because the setup requires it. That happens. It’s normal manufacturing.
The problem is when it happens invisibly.
If a program stored on the machine is modified, SMC can receive it back, compare it line by line against the original released version, and generate a documented comparison report. The supervisor reviews exactly what changed, approves or rejects it, and if approved, the change is reconciled back into the controlled source.
Every step is documented. Every decision has a name and a timestamp.
SMC does not assume shop-floor edits never happen. It makes sure they never happen invisibly.
Why This Matters at Assessment Time
CMMC assessments focus on whether you can demonstrate control over CUI — including how technical data is transferred, used, and changed within your environment.
The relevant question isn’t just “did you send the right file?” It’s “can you demonstrate that the program executed on the machine was the approved version — or, if it was changed on the floor, that the change was detected, documented, reviewed, and reconciled?”
Most shops can’t answer that today. Transfer Proof produces that answer automatically, inside the normal manufacturing workflow. The machinist runs the job. The record builds itself.
The Bottom Line
Logging what you sent to a machine is the baseline. Any reasonable transfer system should do that.
Providing evidence of what the machine actually executed — and detecting, documenting, and governing any machine-side changes — is a different level of control.
That is what makes a CNC compliance record defensible.
Transfer Proof™ is how SMC closes that gap.
If you want to see how Transfer Proof fits your controller environment, see how CNC shops are reducing scope at /cnc-scope-reduction/.