JSG 0852 or S1000D: How to Choose the Right Standard for Your Project

Every few weeks someone in program office asks me the same question, usually with a slightly worried look: "Should we go for JSG 0852 or S1000D for our Level 4 IETM?" And almost every time, the worry is misplaced. They think they're choosing between "old" and "new," or "Indian" and "international," or "cheap" and "premium." That framing is exactly how projects end up with the wrong standard, a blown budget, and a deliverable nobody can actually open.

So let's clear the fog. If you're staring at a tender or scoping a new IETM and you have to commit to a standard, here's how to think about it without getting sold a story.

First, a word on that confusing "Level 4" label

Before anything else, sort out the vocabulary, because half the arguments I hear are really just two people using the same word to mean different things.

In common Indian defence parlance, when someone says Level 4 (or Level IV), they usually mean an IETM built to JSG 0852, the Indian standard. When someone says Class / Issue 4 or Class / Issue 4.2, they're almost always talking about S1000D. Same number, different worlds. The "Level" scale (roughly 1 to 5) traces back to the old US MIL-PRF-87268 family that JSG 0852 grew out of, where Level 4 means the content lives in a database and gets assembled dynamically rather than sitting as flat linked pages.

S1000D doesn't really talk in "Levels" at all; it talks in data modules, issues, and classes.

The practical takeaway: both standards can deliver a fully interactive, database-driven manual that a technician can search, filter, and navigate in a few clicks. At the top end they look similar to the end user. Under the hood, they are built completely differently. That difference is the whole decision.

What JSG 0852 actually is?

JSG 0852 is the Joint Services Guide issued by the Indian Ministry of Defence's Directorate of Standardization. It's been around and in use for roughly two decades, and it gets revised regularly (you'll see 0852:2001, then 2015, then 2019 referenced on various projects). It was written for the Indian defence context, and it usually rides alongside JSS 0251, which governs how the underlying technical document is structured before it ever becomes an IETM.

Technically, a JSG 0852 Level 4 IETM is a database-driven system, typically a SQL/MySQL backend feeding an HTML-based viewer, with the usual interactive machinery: hyperlinking, hotspots, drawing-to-table links, search, user tracking, and an authoring mode for updates. You build the content, it goes into the database, and the viewer renders it.

Its real strengths are unglamorous, but they matter. It's affordable. The tooling is standard web and database technology, so you don't need a small fortune in licenses. Your people can maintain it with basic HTML and SQL skills rather than a niche specialization. Deployment is quick. And crucially, the data sits on your own servers, inside the country, which is not a small thing when the customer is the armed forces.

What S1000D actually is? (and it's not the villain)

S1000D gets a lot of unfair press in India, usually from people trying to sell you the alternative. So let me be straight about it: S1000D is a genuinely powerful specification, and for the right project it's the correct choice.

It's an international specification born in European aerospace and now maintained jointly by industry bodies across Europe and North America. Instead of "a manual,"

S1000D thinks in data modules — small, self-contained chunks of technical information, each tagged in XML and stored in a Common Source Database (CSDB). From that single source you can publish an IETM (S1000D people call it an IETP), a PDF, or a subset tailored to a particular user, all from the same content.

That architecture is the point. If you have a large platform — an aircraft, a warship, a system that will be maintained for thirty years and touched by dozens of suppliers — the ability to reuse a single data module across multiple publications, control it centrally, and swap it out cleanly when the design changes is worth a great deal. This is why aerospace has used it for decades and why it shows up in big multi-national programs. When interoperability, long-lifecycle configuration control, and export or partner-sharing genuinely matter, S1000D earns its keep.

The catch nobody puts in the brochure

Here's where projects go sideways. S1000D is only S1000D if it's produced and managed through a real CSDB. The XML is necessary but nowhere near sufficient.

A proper CSDB suite — the kind used by the big aerospace houses — runs into crores of rupees, and the servers are often maintained abroad. Because that's expensive and inconvenient, a fair number of Indian projects quietly cut the corner: a vendor produces XML files that superficially resemble S1000D, hands them over, and everyone calls it S1000D. The client accepts it because, quite often, neither the client nor the vendor owns a genuine CSDB to test it against. What you've actually bought in that case is an XML-flavored IETM — roughly a Level 3 experience wearing an expensive label.

And if your end user — the shipyard, the naval unit, the OEM — doesn't own a CSDB, then even a perfectly authentic S1000D package can't be plugged into anything. You've paid a premium for portability into an ecosystem that doesn't exist on your side.

The cost gap is real too. As a rough field figure, an S1000D deliverable can run around four times the price of the equivalent Indian-standard IETM — think in the neighborhood of ₹10 lakh versus ₹2.5 lakh for a thousand-odd pages. Sometimes that four-times premium buys you something essential. Often it buys you a logo.

So how do you actually choose?

Forget which one sounds more impressive. Walk through these questions honestly and the answer usually picks itself.

1. What does the tender say? If the RFQ or contract just says "IETM" or "Level 4," it means the Indian standard — build to JSG 0852. If it explicitly says "S1000D" (usually with a class like 4.2), then that's a hard requirement, not a suggestion. Read the scope carefully before you assume.

2. Does the end user own a CSDB? This is the single most decisive question for S1000D. If the receiving organization doesn't have a genuine CSDB studio to import and manage data modules, S1000D gives you almost nothing that JSG 0852 wouldn't, at several times the cost. In India, only a handful of organizations actually run one.

3. Where is the data allowed to live? If the contract or the customer needs everything kept on Indian soil and off foreign clouds, that alone can rule out a foreign-hosted CSDB workflow and point you to JSG 0852.

4. How many suppliers and how long a lifecycle? A single system, one supplier, standalone deployment — JSG 0852 is the sensible fit. A large platform assembled from dozens of OEMs, maintained for decades, where everyone must share and reuse content in a common structure — that's the scenario S1000D was designed for, provided the whole chain is genuinely equipped for it.

5. Is there a real interoperability or export need? If your manuals have to slot into an international partner's system or a global sustainment program, S1000D's standardization is a genuine asset. If they don't, that asset is just overhead.

6. What's your budget and in-house skill? Constrained budget, limited XML/CSDB expertise, need to update content in-house without hiring specialists — JSG 0852 wins comfortably.

Conclusion

For the large majority of Indian defence and PSU projects — the OEM supplying a subsystem, the shipyard hosting manuals from a hundred vendors, the equipment maker meeting a mandatory IETM deliverable — JSG 0852 at Level 4 is the practical, defensible, cost-sensible choice. It does the job, keeps the data at home, and doesn't demand an ecosystem you don't have.

Go with S1000D when the requirement is explicit, the platform is genuinely large and long-lived, multiple partners must share a common source, and — this part is non-negotiable — there's a real CSDB on the receiving end to make the standard mean something.

The worst outcome isn't picking the "lesser" standard. It's paying four times over for an S1000D badge stuck on XML that nobody can use as intended. Ask the six questions above, match the standard to the project instead of to the marketing, and you'll rarely get this wrong.

If you're scoping an IETM right now and aren't sure which way your tender points, it's worth reading the scope line by line before committing a single rupee to tooling — the standard is usually hiding in the fine print.

You can always contact https://ilxs.in for guidance on executing an IETM project.