Sustainment Tail Test

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.

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:

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.