Rescue work
The extra, often unrecorded help a second team needs from the original team to get a transferred capability working. Classifying it shows what the capability really depends on.
Rescue work is the unplanned help that flows to a team trying to reproduce someone else's result: a quick call, a patched dataset, a configuration nobody documented, a fix only the founders know. Because it is informal, it is usually invisible, and a transfer that looks successful may be quietly depending on it.
In a second-team test, the useful thing to do is measure it: log every request for help and classify it rather than hiding it. Some rescue work reveals missing documentation. Some reveals a tacit skill that must be taught. Some reveals that the capability is bound to specific people or special conditions and will not travel.
Reading the trend
The total matters less than the direction. If rescue work declines over time, that is support decay: the capability is genuinely transferring. If it stays flat, adding more teams only multiplies the dependency on the same experts. Good replication lowers it.
Read more in The second team is the real innovation test.
Related terms
Support decay
The fall in exceptional help a transferred capability needs from its original team over time — the real measure of whether an AI pilot has become an organizational capability.
Second-team test
A test of whether a different competent team can reproduce a pilot's useful result without inheriting the first team's exceptional conditions or constant expert help.
Replication
Reproducing a successful result in a new setting by a different team. It is not copying: it means carrying over the capability and learning, so the second attempt costs less in learning.