Field Guide
IADS in an Army RFP: Reading the Requirement, Pricing the Work
The Stack
One Clause, Four Layers
A solicitation rarely makes a fuss about IADS. It appears inside the technical data language, next to the MIL-STD-40051 citation, and reads like a note about which viewer the customer happens to use. Underneath it are four layers a bid has to account for:
- The content standard — the cited 40051 part and revision, which fixes the work-package model you author against.
- The DTDs — AMCOM publishes them per revision through its Publication Services site at Redstone. Validating against the wrong version is a delivery failure that looks like success locally.
- The FOSI — the formatting layer, published alongside the DTDs, that decides how the tagged content actually renders. The most-skipped item on this list.
- The package and the viewer — a built IETM dataset that opens and behaves correctly in IADS, which is frequently what acceptance really examines.
Add the program's production business rules — AMCOM publishes those too — and you have the same shape as an S1000D BREX: the standard narrowed to what this customer will accept.
The Two Silent Costs
Formatting and Access
The FOSIis the first silent cost. Content can be flawlessly valid and still render wrong, and rendering is what a reviewer sees first — so a team that meets the formatting layer late spends the end of the program fighting output instead of finishing content. Get the applicable FOSI early, run real work packages through it in the first weeks, and treat the result as a gate. It is the Army's version of a lesson this site keeps repeating about rendering pipelines: the transform is where valid content becomes an acceptable document.
The second is access. Getting a team set up can involve a System Access Request routed through the weapon system program office or the IADS helpdesk, over NIPR. That is not difficulty — it is a queue, and it runs on the calendar rather than on effort. A team that starts it after kickoff loses precisely the early weeks when building and testing in the target viewer is cheapest. Start it during capture. And since data packages are typically opened from a location that must remain available, sort out where the dataset lives and who can reach it before it becomes a delivery question.
Before You Price
Eight Questions to Answer
Which MIL-STD-40051 part and revision does the solicitation cite — and which AMCOM DTD version goes with it?
The DTDs are versioned and published per revision. Authoring against the wrong one produces content that validates locally and fails at delivery. Pin the pairing in writing before pricing.
Which FOSI (or stylesheet set) applies, and are we expected to use the government's or supply our own?
The FOSI controls how content renders. It is the single most-skipped line in TM bids, and it decides whether your output looks like the customer's other manuals or like an argument you're about to lose.
Are the program's Production Business Rules invoked, and have we read them?
AMCOM publishes business rules alongside the DTDs and FOSIs. They narrow the standard to what this customer accepts — the same role a BREX plays on an S1000D program, and just as consequential.
What exactly is the deliverable: source XML, a built .iads package, or both — and on what media or system?
A working IETM package is a different artifact from conformant source. If a package is owed, its build, test, and delivery mechanics are labor that belongs in the estimate.
Who on our team already has IADS access, and how long will it take to get the rest?
Access can require a System Access Request over NIPR, routed through the weapon system program office or the IADS helpdesk. That is calendar time, not effort — and it starts before authoring, not after.
How will the government verify the deliverable — validation report, viewer walkthrough, or both?
If acceptance includes behavior in the viewer, then viewer testing is a scheduled activity with its own rework loop. Bids that price only authoring and validation have priced half the job.
Does any legacy content come with the award, and in what condition?
Inherited manuals arrive at whatever revision and quality the last contractor left. Conversion and remediation are a separate cost line, sampled before it is quoted.
Who fixes rejected work packages, on whose clock, and how many cycles are assumed?
The reject loop is the line item optimistic bids omit entirely — and the one that decides whether a TM program makes money.
These sit inside the wider discipline of our TM contract review checklist and the TMCR that usually carries the detail — and if the program is heading toward a government-owned repository, the exchange questions stack on top. Answer them at capture and the IADS clause becomes a line item. Answer them at delivery review and it becomes a finding.
Two companions worth reading alongside this: why IADS is in every Army contract — the consolidation decision behind the clause, and why the software itself carries no license cost — and authoring for IADS, for the team who will actually produce the content.
FAQ
Questions We Hear
How does IADS usually appear in a solicitation?
Rarely as a headline requirement — more often as a clause inside the technical data or CDRL language: manuals shall be delivered as IETMs viewable in IADS, or words to that effect, sitting alongside the MIL-STD-40051 citation. It reads like a single sentence about a viewer. In practice it is a stack: conformant XML authored to the cited 40051 part and revision, against the AMCOM DTDs, formatted by the applicable FOSI, satisfying the program's production business rules, and packaged so it opens and behaves correctly in the viewer.
What is a FOSI, and why does it matter so much here?
A Formatting Output Specification Instance — the stylesheet layer that tells a formatter how the tagged content should look. AMCOM's Publication Services at Redstone publishes DTDs and FOSIs together for MIL-STD-40051, precisely because structure and appearance are both governed. It matters because content can be perfectly valid and still render wrong, and because 'wrong' is what a reviewer sees first. Teams that discover the FOSI question late spend the end of the program fighting output rather than finishing content.
Why does IADS access need to be in the schedule?
Because it can involve a System Access Request routed through the weapon system program office or the IADS helpdesk, over NIPR — an administrative path with its own queue. The risk is not difficulty, it's sequencing: a team that starts the request after kickoff spends early weeks unable to build or test in the target viewer, which is exactly when viewer problems are cheapest to fix. Start the access conversation during capture, not after award.
Is there a license cost for IADS itself?
No. The official FAQ states that IADS 'has always and will always be provided for free' — what is charged for is training, support, and data conversion services. Two implications for a bid: drop any phantom license line, and don't let free software imply free adoption. The costs on this deliverable are conversion, authoring, formatting against the right FOSI, access lead time, and the viewer-testing loop — all of them labor, none of them licensing.
What does a realistic IADS-aware bid include that a naive one doesn't?
Four things. Access lead time as a schedule item with an owner. A viewer-testing loop budgeted alongside authoring and validation, not folded into it. Formatting iteration against the actual FOSI, early, on real work packages. And an explicit assumption about reject cycles — how many, fixed by whom, on whose clock. None of these are exotic; they are simply the difference between pricing the deliverable and pricing the document.
Get In Touch
Bidding an IADS Deliverable?
Send us the technical data language before pricing locks. We'll map the DTD and FOSI pairing, the access path, and the viewer-testing loop — the three things that decide whether the estimate survives.