No off-the-shelf PACP MSCC defect code mapping to a custom training taxonomy exists, so you have to build one. Say an acquisition brings in sewer inspection data coded under NASSCO’s PACP or WRc’s MSCC, and your corrosion detector was trained on your own label set. The crosswalk between the two needs sound engineering judgement, not a lookup. Anchor it to the published coding standard, have inspection experts from both organisations agree it, version it like code, and give it a named owner who signs off every ambiguous entry. Without that, a validation run on the acquired data tests your mapping as much as your model.
Is there a standard PACP MSCC defect code mapping to a custom label set?
No. NASSCO says it has no formal guidance on which codes or grades to use when aligning PACP ratings with WRc coding. A custom taxonomy that one company built for its own model has even less chance of being covered by any published crosswalk.
The two standards share a lineage but are not identical. NASSCO adopted the PACP codes for North America in 2002. They were based on the MSCC system WRc developed in 1980, and the first PACP version was similar to MSCC Version 4.0. NASSCO still lists notable differences: similar observations have different names, PACP added codes for rehabilitated pipes, point repairs and corrosion deterioration mechanisms, and some observations that used to sit in the Remarks field became coded fields. NASSCO’s own conclusion is that conversion is possible for most practical engineering and asset-management uses, because PACP Group codes share an engineering basis and a 1 to 5 severity grade with WRc’s root codes. But the systems are not identical, so any conversion needs sound engineering judgement and a deliberate code-mapping strategy.
Comparisons in the field show the same thing from another side. A 2023 study in Water ran four sewer condition assessment protocols over the same 182 pipe segments and got different results. The main causes were different defect weights and different evaluation methods. So the same pipe can grade differently under different protocols because of how defects are weighted.
Innovyze’s InfoAsset Manager applies one coding standard per database by default, with an override per network. The documentation warns that if you switch the standard on existing data, the data stays in place but is no longer valid, because the codes differ between standards.
Why anchor to the published standard rather than either team’s labels?
The published standard gives both sides a shared fixed reference to check a disagreement against. Each team’s labels are a local interpretation of it, or a replacement for it. Many cities created their own defect catalogues before PACP, or adapted catalogues from other countries. PACP then let them drop those for a standard catalogue that logs observations consistently from pipe to pipe and from one inspection to the next. A custom ML taxonomy repeats that history: it is one more local catalogue.
If you map the acquired operator’s codes straight onto your training labels, every judgement call ends up in a table that only the people who built it understand. A two-step route works better. First, map each side to a published code: PACP, MSCC, or EN 13508-2:2003+A1:2011, the European visual inspection coding standard. Then derive the label crosswalk from those two mappings. When a later reviewer asks why a code landed where it did, the answer points to a definition in the standard, not to someone’s memory.
Also check whether the acquired data really conforms to the standard it claims to use. In InfoAsset Manager, the standard’s choice lists are read-only by default but can be unlocked and extended. Edited lists no longer conform to the standard, which can lead to wrong condition scores. So data labelled “PACP” may carry user-defined additions. Inventory them before you assume conformance.
Building the mapping from PACP or MSCC codes to your training taxonomy
The procedure below assumes you have the acquired operator’s exported code list, your own label definitions, and access to inspectors from both organisations. The steps run in order, because each one depends on the one before.
- Inventory both code sets as they are actually used. List every code and modifier that appears in the acquired export, flag any that are not in the published standard, and record which standard version the data was coded under.
- Map the acquired codes to the published standard. The work is in local additions and in codes from earlier versions, which need their own mapping strategy.
- Map your training labels to the published standard. Write down which standard codes each label was meant to cover, including any that were folded in quietly.
- Classify every pair by relationship type. SSSOM, a published standard for sharing mappings, separates exact matches from cases where one concept is broader or narrower than the other, or only closely related. MSeg, a CVPR 2020 composite dataset, uses four relationship types: direct correspondence, merge, split (one-to-many) and union of split classes.
- Send every non-exact entry to adjudication. Exact one-to-one entries go straight into the crosswalk. Anything with several candidates or no candidate goes to the named owner and the domain experts, and the decision and its reasoning are recorded before any data is relabelled.
- Record provenance and version on every row. SSSOM records who authored a mapping, who published it and who reviewed it. It also records the source vocabulary versions and the version of the mapping set itself.
- Quality-check the relabelled data. NASSCO’s recommended long-term route for converting between observation bases includes Quality Assurance protocols, possibly built by a paid third party. MSeg’s relabelling embedded sentinel tasks with unambiguous ground truth in at least 10% of each batch, and an expert annotator labelled the cases that still failed its consistency criteria.
Why use a format like SSSOM instead of a spreadsheet with two columns? Its authors describe most existing mappings as single-use conversion tables that are incomplete or inaccurate in ways nobody can see, with too little metadata to reuse. A defect crosswalk that will be read again during every re-validation needs to be better than that.
PACP codes with no one-to-one equivalent: split, merge or leave unmapped?
A code with no clean partner can be merged, split or left unmapped. The right choice depends on whether your model needs the distinction that would be lost. MSeg’s authors put the core trade-off plainly. Merging is easy, can be done in code and needs no new labelling, but it throws away labelling effort and gives a coarser taxonomy. Splitting gives finer classes, but every instance of the class has to be relabelled. In practice, MSeg merged its component datasets’ 316 classes into 194, split 31 classes and relabelled 221,323 masks.
| Situation | Handling | Cost | Risk if chosen wrongly |
|---|---|---|---|
| One standard code matches one training label exactly | Direct crosswalk entry | None beyond review | Low, if both definitions were checked against the standard |
| Several standard codes fall under one coarser training label, and the model never needs to tell them apart | Merge | Programmatic; no relabelling | Lost granularity that cannot be recovered later without relabelling |
| One coarse label covers several standard codes the model must distinguish | Split, with relabelling of every affected instance | Labour-intensive | Inconsistent relabelling if quality control is weak |
| A standard code has no training label (new material, new feature type) | Leave unmapped; exclude it from training and validation metrics until a label is defined | Some data set aside | A forced mapping corrupts an existing class silently |
For a corrosion detector, the hole versus missing-wall distinction is a case where merging loses what matters. In PACP, the hole codes (HSV, HVV) and the surface damage missing wall code (SMW) both describe missing pipe material. A hole comes from structural break or fracture. SMW comes from corrosion degrading the pipe until a hole forms, and the two need different repairs. If your custom taxonomy has one “missing material” label, the merged class mixes the defect your model is meant to find with one it should not attribute to corrosion. Recovering corrosion as its own class would then mean splitting and relabelling.
Leaving a code unmapped is a legitimate result, not a failure. Forcing a code into the nearest-looking label to reach full coverage is how mapping errors get into training data unnoticed.
Who should own ambiguous or unmapped defect codes?
The owner should be whoever is accountable for the integrity of the combined model’s training labels. In an acquisition, that should be a joint function in the acquiring organisation: a data-engineering lead who owns the artefact, plus sewer-inspection experts from both former organisations who adjudicate the entries. NASSCO’s advice on aligning PACP and WRc points the same way. It suggests using PACP-certified staff who have worked with both systems, so the alignment matches the organisation’s operational goals.
SSSOM’s roles give that arrangement a usable structure. Authors establish the mappings, a creator owns and publishes the mapping set, and one or more reviewers check it. Put names in those fields. A committee nobody is accountable to will still leave ambiguous codes unresolved, only more slowly. The owner does not need to be an inspection expert. What matters is that one person can say “this entry is final for version N” and is answerable when an entry turns out to be wrong.
Keeping the crosswalk valid as PACP and your taxonomy change
PACP keeps changing, so name the PACP version a crosswalk covers. NASSCO describes PACP as changing its codes and grades over the years since 2002. For example, Version 7 (May 2015) changed some grades, removed the Buckling codes, added Deformed Flexible and Deformed Brick codes, and revised descriptors and modifiers, leaving over 220 code options. NASSCO also says that converting from earlier PACP versions to Version 7 needs a code-mapping strategy of its own.
NASSCO expected PACP Version 8.0 in 2023. Its planned additions included surface damage codes for pipes other than concrete (asbestos cement), pressure pipe codes and valve codes, with multi-sensor inspection codes being addressed. A corrosion model being extended across pipe materials is exactly where new material-specific codes will appear without an entry in an old crosswalk.
Treat the mapping as a versioned artefact. Keep it in version control next to the label definitions, stamp it with the standard version and taxonomy version it covers, and re-validate it whenever either one changes. SSSOM’s version fields exist for this reason: a missing mapping can then be traced to an outdated mapping set rather than looking like a deliberate gap.
How the mapping affects validating the detector on differently labelled data
On data from the acquired network, validation metrics are only as trustworthy as the mapping that translated its labels. Northcutt and colleagues estimated an average of at least 3.3% label errors across the test sets of ten widely used benchmark datasets, including at least 6% of the ImageNet validation set. Errors like these can change which model looks better. On ImageNet with corrected labels, ResNet-18 outperforms ResNet-50 if the share of originally mislabelled test examples increases by just 6%. A wrong crosswalk entry is a systematic label error, not a random one. It lands on whole defect classes.
MSeg shows both what goes wrong and how to handle it. Its “naive merge” baseline, which matched classes only when their names were the same, did worse than the reconciled taxonomy, and so did a version that skipped the relabelling of split classes. For evaluation, MSeg mapped its unified classes to each test dataset’s taxonomy through a binary matrix, set by hand before training or evaluation. For sewer inspection, that means freezing the crosswalk before you compute any metric on the acquired data. Revising it after seeing which classes scored badly contaminates the evaluation.
Sewer-ML holds 1.3 million images annotated by professional inspectors from three Danish utilities over nine years. In a 2023 preprint, models pre-trained on Sewer-ML were evaluated on a new 50,000-image dataset from Carencro, Louisiana, annotated for five defect classes. Comparing across datasets like that only means something once someone has decided how each label on one side relates to the classes on the other.
With the mapping in place, the next work is the cross-material validation itself. That means a held-out set stratified by pipe material and coating type with reconciled labels, plus a per-stratum domain-shift report before sign-off. Those are separate pieces of work, and the mapping has to come first. A weak crosswalk eventually shows up in the detector itself. Building and deploying that detector for inspection imagery is covered under computer vision R&D.
What the crosswalk cannot settle for you
A careful mapping removes one source of doubt from a cross-material result. It does not tell you whether a drop on, say, the acquired network’s non-concrete pipes comes from material shift, from different inspection practice, or from a mapping entry that was adjudicated wrongly. To tell those apart, read the per-class results next to the crosswalk’s adjudication log. A class whose accuracy fell, and whose mapping was a merge or a split, is the first place to look. Retraining comes after that.
