The Words This Industry Uses

Each CDRL line item points at a data item description and sets the delivery terms. Collectively they are the answer to what a program actually owes in data, which is a question surprisingly few programs can answer quickly.

For publications teams the CDRL is where scope hides. A single line can oblige a format, a review cycle, a delivery medium, and an acceptance process, and the cumulative weight of those obligations is rarely priced as carefully as the writing itself.

Which category attaches to a deliverable decides whether the government can hand it to your competitor. Unlimited rights means exactly that; limited rights protects data developed exclusively at private expense; government purpose rights sits between them and historically converts to unlimited after five years.

The timing trap is that markings are a pre-award discipline. Missing the window to assert and mark proprietary data can forfeit the protection permanently, and no amount of careful delivery afterwards recovers it.

A CDRL line says what is owed and when. The DID it references says what the thing has to contain. Together with the cited standard and the statement of work, they form the citation chain that defines a deliverable.

When those sources disagree, and they do, the contract's order of precedence clause decides which wins. Knowing that clause exists, and what it says, is worth more than any amount of familiarity with the individual documents.

Every DoD technical document carries one of six statements. They are access control rather than classification: a document can be entirely unclassified and still be restricted to specific audiences.

They matter operationally because they govern what your delivery system must be able to prove. A platform that cannot scope access per person and evidence who received which revision cannot honor the marking, whatever the cover page says.

A FOSI separates presentation from content in the SGML world, in roughly the role a stylesheet plays elsewhere. Defense programs still encounter them because defense libraries still contain SGML.

Practically, a FOSI is often the reason a deliverable that validates correctly still looks wrong. Format conformance and content conformance are separate tests, and programs that assume one implies the other find out late.

IADS is software rather than a specification, which is the single most common misunderstanding about it. MIL-STD-40051 defines how Army technical manual content is structured; IADS is the government-provided environment that authors and displays it.

It matters commercially because the Army consolidated on it, retiring other electronic maintenance viewers, so a contract naming IADS is naming the standing destination rather than expressing a preference. Content that validates cleanly can still fail acceptance by behaving badly in the viewer, which is why testing in it belongs in the schedule from the first module.

An IETM is not a PDF on a tablet. The distinction is that its content is data rather than pages, so the system can filter by configuration, follow a fault isolation path, resolve a reference, and record what was shown.

A legacy class scale from Class I, meaning electronically indexed page images, up through Class V, meaning integrated diagnostics, still circulates and contracts still cite it. It is worth knowing what a class citation means, and worth more to ask what the deliverable is actually expected to do.

IETP and IETM describe the same kind of thing: technical information delivered interactively rather than as pages. Which term a document uses tells you more about its lineage than about the deliverable.

What actually differs between two IETPs is not the acronym but the business rules: which functionality is required, which viewer it must run in, and what the acceptance criteria are. Those are contract facts worth pinning down early, because the word itself will not settle them.

The ITAR's definition of technical data covers information required for the design, production, operation, repair and maintenance of defense articles, which describes the contents of a technical publications library almost exactly.

The consequence people underestimate is that providing controlled technical data to a foreign person can constitute an export without anything crossing a border. That makes per-person access control, and the evidence that it worked, the whole compliance story.

LSA was standardized by MIL-STD-1388-1A (the process) and MIL-STD-1388-2B (the record, or LSAR, keyed by LSA control numbers). Both were canceled in the 1990s; the data role passed to GEIA-STD-0007, and the S-Series carries the discipline in S3000L.

Its task analysis is the source of a manual's procedures and its provisioning data the source of its parts lists, so publications that drift from the analysis are wrong in ways only a maintainer notices.

Where an Army program runs S1000D rather than 40051, MIL-STD-3031 supplies the business rules layer: the decisions the specification leaves open, already made at service level.

The alignment lag is the detail that surprises people. A service rules standard points at a specific S1000D issue, and that issue is usually several behind the newest. It is the reason a new S1000D release does not reach most programs for years.

3048 does for Air Force Technical Orders what MIL-STD-3031 does for the Army: it settles the choices S1000D deliberately leaves open, at service level rather than program level.

Like its Army counterpart it aligns to an older S1000D issue, and like its Army counterpart that alignment moves on the standard's own revision cycle rather than the specification's.

38784 does not define a manual's technical content; the detail specification cited for each manual type does that. It defines the presentation layer those manuals share: style, format, the handling of changes, and the conventions readers rely on across documents.

Its warning, caution and note conventions are worth knowing precisely, because they differ from the ANSI Z535.6 conventions that govern commercial product manuals. A team writing for both markets is running two rule sets that share a vocabulary.

40051 is the Army's governing standard for technical manual content: work packages, required structure, and the rules a manual must satisfy to be acceptable. Part 1 covers interactive electronic delivery and Part 2 covers page-based manuals.

It is free to download from ASSIST, the Defense Logistics Agency's repository of record. Contracts still routinely cite superseded revisions, so the revision named in your TMCR matters more than the current one, and checking which is which is a five minute job that prevents a very expensive misunderstanding.

The RPSTL is the military counterpart of a civil illustrated parts catalog: what the item is made of, how the pieces relate, and what is needed to service them.

It is a recurring conversion trap. Parts data usually lives apart from narrative content, maintained on its own schedule by a different team, and gets remembered at integration rather than at planning. Legacy RPSTL files frequently need converting before they will work in a target viewer.

A TDP is what the government buys when it wants the ability to have something made or maintained by someone other than the original manufacturer. Its completeness determines whether that ability is real.

The modern version increasingly centers on the model rather than the drawing, which shifts the authoritative record upstream and makes the relationship between engineering data and publications considerably more direct.

A TMCR is where the general becomes specific. It names the standards, the revisions, the parts that apply, what is tailored out, and what the program must deliver and verify. Two contracts citing the same standard can demand very different things once their TMCRs are read.

It is the single most under-read document in a technical publications bid. Pricing a proposal from the standard's name rather than the TMCR's tailoring is the most reliable way to discover the real scope after the price is fixed.

A CCMS stores content at the component level: a topic, a warning, a procedure, a table. Each is managed on its own, with its own version history and its own record of every publication that uses it.

That last part is what distinguishes it from a document repository. When a component changes, the system knows what it affects. An S1000D CSDB is a CCMS specialized for that specification, where the components are data modules and the rules come from the BREX.

CGM stores illustrations as vectors rather than pixels, so they scale without degrading. WebCGM added the interactive layer that made it indispensable to IETMs: regions of an illustration can be hotspots that navigate somewhere.

That hotspot data is the reason flattening a CGM library to raster for convenience is destructive. It discards the interactivity a program is usually contracted to deliver.

A conventional CMS manages whole items: a page, a post, a file. That is exactly right for a website and wrong for a technical library, where the same procedure has to appear in six deliverables and stay identical in all of them.

The common failure is asking a marketing CMS and its media library to do a document management job. They were built for different problems, and the seams show at about the point the library reaches a few thousand controlled documents.

A content model says what a piece of content is made of and in what order: a procedure has preliminary requirements, then steps, and a step may carry a warning. It is enforceable.

This is the distinction from a template. A template describes how something should look and relies on people to comply. A content model refuses content that does not conform, which is why 'we have a template' and 'we have a content model' describe very different levels of control.

A DAM is built for assets: find the right image, know its rights and formats, deliver it at the needed size. It is genuinely good at that.

It is not built to be the authority on which revision of a controlled procedure is in force, which is the job it gets asked to do when a marketing system is the only repository an organization has.

The digital thread is the ambition that data flows rather than being retyped: a design change propagates into analysis, into support planning, and eventually into the manual a technician reads.

Publications are where the thread either arrives or breaks. A program can have excellent model-based engineering upstream and still hand a maintainer a PDF that nobody can trace back to anything.

DITA organizes content as topics rather than documents, with maps defining which topics make up a deliverable and in what order. Conditional processing lets one source serve many variants.

Its distinguishing feature is specialization: a disciplined way to derive your own element types from the standard ones without breaking compatibility with generic tooling. DITA is adopted by choice, where S1000D is usually arrived at by contract, and that difference governs almost everything downstream including who decides when to migrate.

A DMS treats the document as the unit and concerns itself with control: which version is current, who approved it, who may see it, and what the record says about distribution.

It is a different job from a CCMS, which manages the pieces content is made from. Regulated organizations frequently need both, and confusing the two produces either a library nobody can prove anything about or a component system nobody can release from.

A DTD declares the vocabulary and structure a conformant document must follow. It is not namespace-aware and has no concept of data types, so it can require that a value be present but not that it be a date.

It persists because contracts cite it. A 40051 program means DTDs in practice, whatever the tooling would prefer.

In an MBD approach the model carries the dimensions, tolerances and annotations that a drawing used to carry, and it becomes the record other activities work from rather than a picture generated alongside one.

For publications this changes where content comes from. When the model is authoritative, illustrations and procedures can derive from it rather than being redrawn, and the relationship between engineering change and documentation change becomes direct instead of manual.

A schema checks shape. Schematron checks meaning: if this module is procedural, a warning must precede the step it concerns; if this code is used, that attribute is mandatory.

In S1000D terms this is the natural home of business-rule checking layered on top of the delivered schemas, which is exactly the role the BREX plays.

SGML was a framework for defining markup languages rather than a language itself, and defense and aerospace produced decades of technical manuals under standards built on it.

Those libraries still exist and still have to be read, revised and eventually converted. They are also the best-behaved legacy content there is, because they were validated against a grammar when they were written.

Single-sourcing is the practice the whole structured content apparatus exists to enable: one authored source, many renditions, nothing re-keyed and nothing left to drift.

The promise is only as real as the machinery behind it. Content copied between deliverables to save time reintroduces exactly the divergence the approach was adopted to prevent, and it does so invisibly.

SVG is vector graphics expressed as XML, which means illustrations can be inspected, validated and transformed with the same tools as the content around them.

S1000D Issue 6 introduced an SVG profile for technical illustration, which is the clearest signal of direction: new work increasingly starts in SVG while substantial CGM libraries remain in service.

Topic-based authoring means writing pieces that make sense on their own, rather than chapters that depend on what came before them. It is the precondition for reuse: content that assumes context cannot be moved.

The discipline is editorial rather than technical. Tools can enforce that a topic exists; only a writer can ensure it does not begin with the word 'therefore'.

XML makes structure explicit and checkable. A heading is tagged as a heading, a warning as a warning, and a machine can verify that a document contains what it is required to contain.

That is why technical publications standards are built on it. When a manual outlives the software that wrote it, which in defense is routine, a vendor-neutral validated format is the only thing that survives the transition.

XSD fixed what DTDs could not do. It is typed, so an attribute can be declared a date, an integer within bounds, or a string matching a pattern, and validation catches errors a DTD would pass.

Grammar, types and rules are three separate layers of enforcement. A schema says what may appear; something like Schematron says what your project actually permits.