By Rovaryn Digital · May 5, 2026 · 8 min read
The scramble before the deposition
A CRC gets a call on a Tuesday afternoon: an attorney wants the transferable skills analysis by Friday, and the file is a stack of a claimant's old job titles with no DOT codes attached. The counselor starts pulling numbers from memory — a forklift job here, a shift-lead role there — and realizes halfway through that two of the "matches" she's about to write down don't actually share a skill set with the claimant's prior work, they just sound similar. If this gets to cross-examination, "it sounded similar" will not hold up.
That scramble is what happens when a TSA gets treated as a title-matching exercise instead of what it actually is: a structured comparison of worker traits against occupational requirements, built from defined data points rather than impressions. By the end of this article you'll be able to explain, precisely, what a transferable skills analysis is, what it has to contain to be defensible, and how it differs from the labor market survey or wage-earning-capacity report that often follows it.
What Is a Transferable Skills Analysis, Exactly?
A transferable skills analysis is a method for identifying occupations a person can reasonably perform given the skills, aptitudes, and work traits demonstrated in their documented work history, filtered against any physical, cognitive, or other limitations that now apply. It is not a resume review and it is not a guess about what someone "could probably do." It is a comparison of two structured data sets: what the person's past jobs required, and what a candidate occupation requires — run through a filter of the person's current capacity.
The output of a TSA is typically a short list of specific occupations, each tied to an occupational code, each with a stated rationale for why the skills transfer (or a stated reason a nearby occupation was excluded). That list is what feeds into whatever comes next — a labor market survey to test whether those occupations exist in a reachable geography, or a wage-earning-capacity calculation to compare pre-injury and post-injury earnings.
Practitioners doing this work daily know the real difficulty isn't the concept — it's the discipline of doing the comparison the same defensible way every time, instead of pattern-matching from memory the way our overwhelmed CRC did on that Tuesday afternoon. A worked TSA example makes this concrete faster than a definition alone.
Where a TSA Comes From: DOT Worker-Function Scales and SVP Levels
The vocabulary a TSA runs on comes from the U.S. Department of Labor's Dictionary of Occupational Titles (DOT) system, which rates every occupation on standardized public-domain scales. Two of those scales carry almost all of the weight in a TSA:
Worker-function ratings — each DOT occupation is rated on three scales: how it engages with Data, how it engages with People, and how it engages with Things. A job rated high on the Data scale and low on the Things scale has a different transferability profile than one rated the reverse, regardless of what the job title happens to be. This is the mechanism that lets a practitioner compare a machinist to a quality inspector on functional terms rather than surface-level title similarity.
Specific Vocational Preparation (SVP) — a numeric scale describing how much time it typically takes a person to learn to perform a given job at an average level, ranging from short demonstration-only tasks up through occupations requiring extended training. SVP level is one of the primary gatekeepers in a TSA: an occupation with a substantially higher SVP than the person's documented work history generally is not a transferable match, because the skill wasn't actually demonstrated, only some part of it.
Both scales are public-domain classification tools, not proprietary to any vendor or software. Understanding them is a prerequisite to reading — or writing — a TSA that will survive scrutiny. A full breakdown of how SVP levels work and why they gate transferability is worth the separate read if this is new territory.
What Goes Into a TSA: The Inputs a Practitioner Needs
A defensible TSA starts from documented facts, not inference. At minimum, a practitioner needs:
- The claimant's or client's full work history, with enough detail to assign a DOT occupation code to each prior job — job title alone is not enough; the counselor needs to know what the person actually did.
- Worker-function and SVP ratings for each of those prior jobs, pulled from the DOT classification, not estimated.
- Documented functional limitations — physical, cognitive, or both — usually sourced from medical records, a functional capacity evaluation, or a treating physician's restrictions.
- A defined labor market or jurisdiction relevant to the case, since "transferable" only means something in relation to a place the person could actually work.
Because the DOT itself has not been actively updated by the Department of Labor for years, most current practice crosswalks DOT occupations forward into the ONET-SOC taxonomy to confirm an occupation still has a modern labor-market footprint. The ONET database currently covers roughly 900 occupation profiles spanning more than 55,000 job titles (National Center for ONET Development, USDOL/ETA, 2025; ONET content used here under CC BY 4.0, O*NET is a trademark of USDOL/ETA), which gives practitioners a large, standardized set to cross-reference against older DOT codes. The mechanics of that crosswalk — and where it commonly trips people up — deserve their own explanation, covered here.
How a TSA Maps Work History to Alternative Occupations
The actual analysis runs in a sequence, and skipping steps is where TSAs go wrong under cross-examination.
First, every prior job in the work history gets coded — DOT code, worker-function ratings, SVP level, physical demand level. This is the foundation; if it's wrong, everything built on top of it is wrong too.
Second, the documented limitations get applied as a filter. A person with a lifting restriction is not a physical match to their old heavy-exertion job anymore, regardless of the skills they built there — the transferability question shifts to whether those skills (not the physical demands) carry over to a lighter occupation.
Third, candidate occupations get generated by comparing worker-function and SVP profiles across the DOT/O*NET-SOC universe, looking for occupations that share enough of the functional profile that a worker could step into them without starting vocational training over from zero. This is where SVP does its filtering work: an occupation requiring, say, several years of specific vocational preparation is not a realistic transfer target for someone whose relevant experience only demonstrates a few months' worth.
Fourth, each surviving candidate occupation gets a stated rationale — which specific skills transfer, and from which specific prior job. "This person could do X" is not a rationale. "This person's 12 years coding and testing embedded firmware demonstrate the Data-function skills required by occupation Y at a comparable SVP level" is.
That fourth step is the one practitioners most often shortcut when working under deadline pressure — and it's the one an attorney or hearing officer is most likely to ask about directly. A structured worksheet that forces the rationale field before it lets a counselor move to the next candidate occupation closes that gap; see the step-by-step TSA methodology for the full sequence.
What a TSA Is Not
A TSA answers "what could this person do." It does not answer whether those jobs exist in reachable numbers nearby (that's a labor market survey), what they'd pay relative to the person's prior earnings (that's a wage-earning-capacity calculation), or whether the person is medically cleared to pursue them (that's a matter for the treating physician or an independent medical evaluation, not the counselor). A TSA is also not a legal or clinical opinion on its own — it is an estimating and case-organizing tool built from the practitioner's professional judgment applied to structured data. The credentialed counselor's judgment and signature are what turn a data comparison into a vocational opinion; software can organize the comparison, but it cannot sign it.
It's also worth being explicit that requirements for what a TSA must contain, and when one is required, vary by jurisdiction and by referral source — a state workers' compensation board, the Social Security Administration, and a long-term disability carrier can each have different conventions. Confirm the applicable standard with the relevant body or referral source before finalizing a report, rather than assuming one jurisdiction's practice applies everywhere.
Building One Without Starting From a Blank Page
Every element above — work-history coding, limitation filtering, candidate generation, rationale documentation — has to happen in a repeatable order for a TSA to hold up under scrutiny, whether that scrutiny is a claims adjuster, a hearing officer, or opposing counsel. Doing that from a blank page, case after case, is exactly the kind of manual, error-prone work that eats a counselor's billable hours and invites the copy-paste mistakes that show up later in a deposition.
A structured worksheet fixes the sequence in place before the analysis starts, so the rationale field isn't optional and the DOT-to-O*NET crosswalk isn't reconstructed from memory each time. If you want to see the fields laid out before building your own, the TSA worksheet and the broader transferable skills analysis resource hub are the next stop — or download the TSA Worksheet Pack directly and start your next case with the structure already in place.