Part 1 established the practical boundary: Gen 2 PRT files contain recoverable geometry, but a successful parse is not the same thing as a recovered solid.
This part is the field guide: the rules that kept the investigation honest.
Do
Preserve the original
Work from copies. Record the input filename, byte size, hash, parser version, and output status. A conversion pipeline should never make the only source harder to audit.
Validate structure before meaning
For every record candidate:
- validate the marker;
- read and check the record size;
- check the subtype;
- verify the fields against other files;
- compare the resulting geometry with an independent artifact when possible.
A plausible number is not a decoded field.
Separate the layers
Keep these claims distinct:
PRT serialization
→ CADKEY loaded/API representation
→ native DXF export
→ normalized web presentationThe SDK documents API calls. The PRT parser documents serialized records. The native exporter shows what CADKEY does after loading. None of those layers automatically proves the others are identical.
Use the native exporter as an oracle
When CADKEY can load a sample, compare its DXF against parser output by entity type, coordinates, layers, and winding—not count alone. A count match is a lead. Vertex-level correspondence is evidence.
Keep uncertainty visible
The current high-confidence boundary includes:
- entity headers and little-endian geometry;
- Type 2 3D lines;
- Type 1 construction arcs;
02 02COEDGE vertices;02 05cubic coefficient records;- plane-aware profile/construction separation.
The current low-confidence boundary includes FACE ownership, raw NURBS controls, ACIS cross-IDs, and design units.
Don’t
Do not scan with a loose marker regex
Binary payloads contain byte sequences that resemble headers. A marker is real only after its size, subtype, and surrounding record structure validate it.
Do not interpret offsets from the wrong base
The common entity header starts at marker + 20. Several early FACE and plane theories came from reading valid bytes from the wrong offset. The resulting numbers looked meaningful and were still wrong.
Do not call every curve a NURBS surface
The verified radial entity layout and the verified 02 05 cubic coefficient layout are not raw NURBS surface evaluation. The topology-derived --nurbs DXF is an approximation for inspection, not recovered control-point data.
Do not call a screenshot proof
A CADKEY screenshot proves that the application displayed something. It does not prove which bytes created it. A DXF proves more, but it is still a post-load export. Keep raw bytes, parser results, and native exports together.
Do not call a wireframe a solid
A useful DXF may contain curves, faces, blocks, or annotations without preserving a watertight solid or design history. Report what is present and what needs engineering review.
The result
The investigation became productive when it stopped trying to explain every byte at once. It focused on the smallest reliable deliverable, tested it across the corpus, and kept unresolved ownership questions separate from recovered geometry.
That is the rule for the rest of the work: recover what can be verified, label what is derived, and leave unknowns unknown.