CADKEY PRT Recovery, Part 3: The Smallest Useful Pipeline

Part 1 established what can be decoded. Part 2 documented the rules. This is the practical end state: a conversion workflow that produces something an engineer can inspect.

The pipeline

PRT
  → parser or controlled CADKEY export
  → DXF
  → structural checks
  → conversion report

The original PRT stays in the package. Every output is associated with its source, size, hash, method, and status.

Why the native path still matters

CADKEY’s DXF exporter runs against the loaded CADKEY database and runtime. It is not a standalone reader for raw PRT bytes. That makes it useful as an application-level oracle, but it also means the proprietary runtime belongs in a private, controlled environment—not in the public repository or a customer’s browser.

The parser is valuable for deterministic inspection and for files where the recoverable geometry boundary is understood. Native export is valuable when the original application can load the part. These are complementary paths, not interchangeable claims.

What the report says

A useful batch result is not just a folder of DXFs:

  • original filename and source hash;
  • conversion method;
  • output filename and byte size;
  • discovered entity types and counts;
  • warnings and unsupported content;
  • review status.

The report should make it obvious which files converted cleanly, which are useful approximations, and which need a human with CAD experience.

What failed before this

Screen-level automation was the wrong abstraction. VNC and simulated keystrokes helped inspect CADKEY, but focus, registration dialogs, display state, and window timing made them unreliable for unattended work.

The durable lessons were:

  • use a private runtime directory;
  • keep vendor binaries and credentials out of source control;
  • prefer native window/control messages over coordinates when automation is necessary;
  • validate the output file instead of trusting a successful menu action;
  • preserve the manual path as a fallback for exceptions.

What this does not promise

The current recovery service is strongest at producing inspectable DXF and a clear report. It does not promise that every PRT becomes:

  • a watertight modern solid;
  • a STEP model;
  • a parametric feature tree;
  • a dimensionally complete manufacturing package.

Those are separate deliverables requiring separate validation.

The useful answer

For an archive owner, the first question is usually not “can every byte be decoded?” It is:

Which files are recoverable, what survived, and what needs attention?

A preserved source, inspectable DXF, and honest report answer that question without pretending the unknowns are solved.

Part 4: Why web previews need their own boundary →