Explainer
What Is a BREX Data Module?
The Problem
A Specification Bigger Than Any Project
S1000D is written to serve everything from fighter jets to ferries across half-century lifecycles — so nearly everything in it is optional, configurable, or multi-valued. Which elements a project uses, which codes are legal, how identifiers are built, where applicability may be used: the spec offers menus, and a program must order. The orders are called business rules, and every S1000D program makes them — the only question is whether deliberately, once, in writing, or accidentally, per author, forever.
The BREX data module— Business Rules EXchange — is where the deliberate version lives: the project's decisions recorded as data. Every ordinary module declares which BREX governs it, the spec ships a default BREX as the floor, and validation checks content against the rules — so “valid” stops meaning merely schema-legal and starts meaning compliant with this program.
The Payoff
Decisions With an Enforcement Arm
The BREX narrows the specification to the project's dialect: elements forbidden, values pinned to approved lists, contexts where something is required. Rules needing richer cross-element logic are implemented alongside it with Schematron-style checks — the pairing is the point. Together they turn the business-rules binder from persuasion into machinery: an authoring tool can enforce the rules at the cursor, a CSDB at check-in, an acceptance process at delivery. It is the aerospace-grade version of the argument we make about all enterprise content — a template is not a content model — with the model given a contractual teeth-fitting.
The operational advice is timing. Write the BREX early, with the program's content architects and whoever owns the customer relationship, because many rules encode what the contract demands — it sits near the top of our program start checklist for a reason. Written late, the BREX becomes an audit of a thousand modules against decisions nobody had made when they were authored — mechanically discovering, all at once, every divergence the missing rules permitted. Every program gets a BREX eventually. The good ones get it first.
FAQ
Questions We Hear
What does BREX stand for, and what is it?
Business Rules EXchange: a special data module type in which an S1000D project records its business rules — the decisions about how the specification will be applied — in machine-readable form. Every ordinary data module declares which BREX it is governed by, and validation tools check content against those rules, not just against the schema. The specification itself ships a default BREX; projects layer their own on top of it.
Why does S1000D need a rules layer at all?
Because the specification is deliberately bigger than any one project. It serves air, land, and sea programs across decades, so nearly everything is optional, configurable, or multi-valued — which elements to use, which codes are permitted, how identifiers are built. A project that doesn't decide gets every author deciding individually, and the library diverges module by module. Business rules are those decisions; the BREX is what makes them enforceable rather than aspirational.
What kinds of rules live in a BREX?
Constraints on what content may contain: elements or attributes the project forbids, values restricted to approved lists, contexts where something is required or disallowed. In effect the BREX narrows the specification down to the project's dialect. Rules that need cross-element logic beyond what BREX expresses are typically implemented alongside it with Schematron-style checking — the pairing matters more than the boundary between them.
When should the BREX be written, and by whom?
Early — ideally before volume authoring starts, as part of the business-rules decisions the program makes once and lives with for decades. The authors are the program's content architects together with whoever owns the contractual relationship, because many rules encode what the customer requires. Writing the BREX after a thousand modules exist means discovering, mechanically and all at once, every decision nobody made.
Get In Touch
Rules in a Binder, or in a BREX?
We author BREX modules and the business-rules decisions behind them — early on new programs, and forensically on libraries that grew up without one.