---
name: sustainment-tail-test
description: Use this skill when a field-built or team-built defense system has to survive its builders rotating out, before a team integrates a system or before any builder leaves. Given a repository, a build record, or an exported build chat, it drafts the missing build-record pieces only from what the material contains, runs the Sustainment Tail Test's seven questions, checks the Supplier Contract Pattern's rights lines for every bought component, and concludes pass or fail with a cold-rebuild plan. Triggers on requests like "our lead builder has orders," "will this survive a PCS," "run the Sustainment Tail Test," "draft the build record from this repo," "turn this group chat into a build record," "who owns this after we rotate," or "can anyone rebuild this without us."
---

# Sustainment Tail Test
This skill is Labor as Code™ for the sustainment method in *You Are Not
the Warfighter*. Labor as Code is a skill that
encapsulates a person's knowledge, judgment, taste, and skill in
durable, inspectable, versioned form. The know-how is the habit of
asking, while a system still works, what happens to it on the date
every current builder is gone, and of writing that answer down as a set
of organizations and dates rather than a set of people.

The method spans three chapters. "Plan Sustainment Before the People Who Built the System Rotate Out" teaches the Sustainment Tail Test,
works it on the tanker-planning tool's first life at a regional air
operations center, and follows the Larkspur Brigade drone cell from a
group chat to a sustainment package.
"Buy Components, Interfaces, and Rights From Industry"
teaches the Supplier Contract Pattern, whose rights lines are how a
team answers the test for the parts it buys. "AI Lets Warfighters Build More, but It Doesn’t Know the Fight" shows an AI drafting the build record before a
builder leaves. The test is *Bare Metal Software*'s disappearance test
("Sovereignty Means You Have Tested How to Keep Running Without a Vendor") with a rotation as
the disappearance. Read the chapters for the argument and the worked
cases. This skill runs the test on the user's own system and never
borrows the cases' dates, costs, or facts as the user's.

**The skill drafts from what exists; it never guesses.** Every fact in
the build record cites the file, commit, document, or message it came
from. Where the material is silent, the entry reads "missing," with the
question a builder must answer. A plausible part number, firmware
version, or expiry date supplied from general knowledge is worse than a
gap, because the next team will trust it.

**The skill never names an owner, and it can't do the cold rebuild.**
Owners come from the commander and the organizations that agree to
hold the system. The cold rebuild is done by a person who never met the
builders. The skill can say which answers still name a person, which
fail the test, and exactly what the cold rebuild must prove.

## Before running

1. **Apply the book's security rule first.** Use only unclassified,
   publicly releasable material, in an AI tool the user's organization
   has approved for it. Build material is where controlled content
   hides. If the repository or chat
   contains anything marked CUI, FOUO, controlled technical
   information, or classified; operational detail (locations,
   schedules, frequencies, tactics, countermeasure specifics); a
   supplier's proprietary data the contract doesn't let the government
   share; or personal information about service members, stop and tell
   the user which files or messages hold it. Ask for a releasable
   export. Nothing controlled goes into the AI Workforce™ running this
   skill: not its files, not its memory, and not through an MCP
   connection to a system on a DoD network that the connection's own
   authorization doesn't cover.
2. **Never copy a secret.** Credentials, keys, tokens, account numbers,
   and purchase card data never enter the build record. Record that an
   account or key exists, what it's for, and where the record says it's
   held. Flag any secret found in the material as a finding for the
   team to rotate.
3. **Get the system and the dates.** Which system, in which
   configuration, and every date the user knows: each builder's
   departure or orders date, each authorization's expiry, each
   contract's end. The test runs twice, before a team integrates a
   system and again before any builder leaves. Ask which run this is.
4. **Get the material.** The repository, an existing build record, an
   exported build chat, test cards, parts lists, firmware notes, and
   the contracts or statements of work for bought components if the
   user can share releasable versions. Record what was provided and
   what wasn't.

## Step 1: Inventory the material

List every source provided (repositories, documents, chat exports with
their date ranges, parts lists, contracts), who controls each today, and
where it lives. A group chat or a personal laptop is a source the skill
can read and a place the test says a build record must never live. Say
so once.

A chat export holds decisions in the order people argued about them.
When two messages disagree about a fact (a firmware version, a part, a
setting), cite both, mark the item "conflict: builder to confirm," and
don't pick the later one on the assumption that it won.

## Step 2: Draft the build record

Draft under these headings, which are what question 2 says must
survive the builders:

1. **Specification.** What the system must do, the rules it follows,
   and the tests that prove it.
2. **Interface documentation.** Every interface between components and
   to other systems, with its documentation and where it came from.
3. **Source and build steps,** from a clean machine to a working build,
   with toolchain versions.
4. **Bill of materials with firmware versions:** each component, with
   maker, origin, lot, firmware version, and signing where recorded.
5. **Design files.** Frame, enclosure, and part files, with print or
   fabrication settings where recorded.
6. **Test cards.** Each test, its conditions, and its pass result.
7. **Known failure modes.** Each one, what triggers it, and the fix.
8. **Accounts, licenses, and authorizations with expiry dates,**
   including the ATO or other authorization.

Rules for every entry:

- Quote or cite the source for each fact.
- Write "missing" for anything the material doesn't state, followed by
  the question a builder must answer: "Missing: which firmware version
  is flashed on the flight controllers now? Ask the builder before the
  orders date."
- Write "conflict: builder to confirm" where sources disagree.
- Don't name an owner for any item, and don't decide anything passes.

Put the "missing" and "conflict" items in one list at the end. It goes
to the builder before the builder leaves.

## Step 3: Run the seven questions

Answer each question from the material and the user's answers only.
Record, for each, whether the answer names an organization, a person,
or no one.

1. **Who maintains it after every current builder has rotated?**
2. **What survives them, and where is it held?** The build record from
   Step 2, and its location. A registry, depot, or repository passes on
   location. A group chat or a personal laptop fails.
3. **Can someone who never met the builders rebuild, repair, and
   re-certify it from what survives?** The cold rebuild. It passes only
   when it has been done once and succeeded; "never tried" fails. Step 5
   plans it.
4. **Who owns the accounts, licenses, and authorizations, and when does
   each expire?** List every expiry with its date. Any expiry that falls
   after the last builder's departure with no organization assigned is
   a dated failure; put it on the calendar in the output.
5. **What does a year of sustainment cost, and which money pays for
   it?** Use only figures the user supplies. The skill doesn't pick a
   fund or rule on purpose-statute questions; mark the line "for the
   resource manager to confirm."
6. **Is it registered where a sister unit can find it?** A registry
   entry passes. A file on one ship's workstation or one unit's drive
   fails.
7. **What is its retirement date or trigger?**

Score each question:

| Question | Answer | Owner type (organization, person, no one) | Source |
| --- | --- | --- | --- |

An answer that names a person fails, however capable the person is,
because the person is what the test assumes will leave. Mark each such
row with the person's departure date if known: that's the date the
system fails.

## Step 4: Check the Supplier Contract Pattern's rights lines

A system's tail includes the parts the team didn't build. A team that
can rebuild its own frame from depot files but can't open a supplier's
controller has passed half the test. For each bought component or
service, check the contract material the user supplied against the
pattern's seven lines:

1. **Components**, screened for origin (FY2020 NDAA sec. 848, the
   American Security Drone Act, 10 U.S.C. § 4872 magnets, and the Blue
   List for drone components).
2. **Interface documentation**: major interfaces designated, defined,
   and delivered with the documentation a third party needs to
   integrate components, with machine-readable interface syntax.
3. **Data rights**: government purpose rights in interface data; the
   operation, maintenance, installation, and training data the statute
   already gives; source code and toolchain for software; negotiated
   terms for commercial items, whose default license gives far less.
4. **Repair rights**: repair data, diagnostic software, tools, and
   warranty terms that allow organic repair, on fair and reasonable
   terms.
5. **Test data**: the supplier's results with their conditions and
   Distance to the Fight, and the right to run and share the team's own
   tests.
6. **Provenance**: a bill of materials with origin for covered
   components, and firmware versions and signing.
7. **A support agreement**: reach-back engineering, response times, a
   sustainment price after the builders rotate, and escrow if the
   supplier exits.

Mark each line "present (cite the clause)," "absent," or "not in the
material." Then say which absent lines the test depends on: usually
data rights and source for software, repair rights and diagnostic
software for hardware, and the support agreement for anything the team
won't maintain itself.

Two rules shape how the gaps are written. **Price rights; never seize
them:** a gap becomes a priced line item to negotiate in the next
option or buy, and the pattern applies to new entrants exactly as to
legacy primes. And **the law won't fill the gap later:** right to repair
is Army policy pursued through contracts since April 30, 2025, and
Congress dropped it from the FY2026 NDAA in December 2025, so repair
rights not bought at the start won't be handed over by statute. The
contracting officer and counsel decide every clause. The skill lists
gaps; it drafts no contract language as final.

## Step 5: Write the cold-rebuild plan

The cold rebuild is the question teams skip, and the only one that
proves the record complete. Write a one-page plan:

1. **Who.** A person who never met the builders, from the organization
   that will hold the system. The skill names the role, not the person.
2. **From what.** Only the build record and what it points to, in the
   place it will live after the builders leave. No calls to the
   builders during the run.
3. **What they must do.** Rebuild from a clean start, repair a known
   failure mode from the record, and re-certify: run the test cards and
   get the recorded result.
4. **What counts as success.** The same result as the builders' test
   card, within the tolerance the card states. Where the card states
   none, that's a "missing" item.
5. **What gets recorded.** Every question the rebuilder had to ask, and
   every step they had to guess. Each is a gap the record, and the
   skill, couldn't see.
6. **When.** Before the first builder's orders date, with time for a
   second attempt.

## Step 6: Conclude pass or fail

State one verdict with the reasoning, citing specific rows above.

- **Pass.** All seven answers name an organization as owner, and the
  user's material shows a cold rebuild that was done and succeeded.
  Name the next run date: before the next builder leaves.
- **Fail.** Any answer names a person or no one, or the cold rebuild
  hasn't been done or didn't succeed. That's the usual first-run
  result. List every failing question, the date each failure becomes
  real (a departure, an expiry, a contract end), and the smallest
  action that fixes each, ordered by date. The cold rebuild goes on the
  list even when every other answer passes.

Where the fix for question 1 is a choice about who holds the system,
present the live options side by side,
without picking the owner. The book's options are: a service software
factory, depot, or government lab takes it; a sustainment line goes
into the next budget; a vendor team is hired on purpose under the
Supplier Contract Pattern's support agreement; or the system retires on
a stated date. For each, give what it needs, which rights gaps from
Step 4 it depends on, and what would make it the right call. Name who
decides: the commander, or the portfolio acquisition executive for a system
in a portfolio, better on purpose now than by default after the system
stops.

Where the material is too thin to answer most questions, say so, and
make the "missing" list and the cold-rebuild plan the output. Handed to
the builder before the orders date, that list is still the cheapest
insurance the team can buy.

## Checks before calling the work done

- **Every fact in the build record cites its source.** Spot-check three
  against the material. Delete any version, part number, date, or
  setting the skill supplied.
- **No secret was copied** into the record or the output.
- **No owner was named by the skill,** and no answer that names a person
  was scored as a pass.
- **The cold rebuild is either documented as done or scheduled,** with a
  date before the first departure.
- **Every rights gap is written as a line to price,** for the
  contracting officer and counsel, not as a clause to impose.
- **The conclusion is pass or fail,** with dated actions or labeled
  options for who holds the system.

## What this skill does not do

It doesn't decide who holds the system, which money pays for it, or
what a contract says; the commander, the resource manager, the
contracting officer, and counsel do. It doesn't do the cold rebuild. It
doesn't fill a gap in a build record with a guess, however plausible.
And it doesn't treat a system that works today as sustained. The
book's tanker tool failed all seven questions while it was working
well; the failure was a set of dates nobody put on a calendar.

## Used in *Acquired Alpha*

A program office that buys a system from a seller instead of building it can run this test on the purchase, with the seller's escrow, build record, and rights lines as the material. In *Acquired Alpha* it is the check that the Sustainment Tail has a named owner before signing and again at the end of a prototype. The skill's own conclusion does not change.