Case study
M-1003 Vendor Compliance Strategy and ASCTD Phase 2
Pivotal Rail Products LLC — Freight rail: railcar test equipment
At a glance
- Client
- Pivotal Rail Products LLC
- Industry
- Freight rail test equipment
- Engagement
- Software-side M-1003 vendor compliance + Gen 2 platform
- Year
- 2026
- Status
- Ongoing, in active development
The challenge
The 2026 reissue of AAR M-1003 (the Association of American Railroads' quality-assurance specification) raised the bar for certified railroad repair facilities. Traceable electronic records, software integrity, calibration management, software supply-chain visibility, and vendor accountability all moved from good practice to audit criteria. An ASCTD sits in the middle of two of the most sensitive areas an M-1003 audit examines: the traceability of measuring and testing equipment, and the integrity of electronic quality records.
Most ASCTD platforms in the field were designed long before any of this mattered, with no cryptographic software delivery, no traceable firmware history, and no controlled release management. Pivotal Rail had already moved its ASCTD onto a maintained, AAR-certified software baseline with OEG as its software organization. Phase 2 sets a harder target: make the platform audit-defensible, on the existing installed hardware base.
What we're building
OEG is the sole software-development organization for the ASCTD. The core of Phase 2 is not a feature set; it is a vendor compliance posture. OEG is working with Pivotal Rail to define a realistic and defensible division of compliance responsibility between the three parties an audited ASCTD touches: the certified railroad repair facility, the ASCTD manufacturer, and the software-development organization.
On the software side, OEG is building the evidence that posture depends on. Releases are cryptographically signed and verified by SHA-256 digest, delivered to customers through secure download portals, and traced back to the exact source they were built from. The team is taking a deliberate, practical approach to software provenance: digest-pinned build containers, source-to-release traceability, generated software bills of materials (SBOMs), archived rebuild bundles, and a controlled AWS CI/CD pipeline.
This posture rides on a Generation 2 software platform OEG is delivering in the same phase. The embedded software is being restructured into a clean two-layer architecture separating low-level hardware control from application and web-service logic, a unified task-engine framework runs every major test procedure, and the Yocto Linux platform and operator tooling are being modernized.
Outcome
Phase 2 is in active development through 2026. It is establishing the ASCTD as an audit-defensible platform: controlled release management, traceable firmware lineage, cryptographically verified delivery, audit-ready electronic records, and a documented division of compliance responsibility, all on the hardware customers already own.
Related
