An interoperability brief is a short record of what the exchange must accomplish and how the result will be judged. It gives a route researcher, supplier, or receiving team a question that is precise enough to investigate without pretending that the route is already proven.
The brief is an editorial planning tool, not a standard-mandated form or a replacement for a contract, project specification, or detailed acceptance procedure. Its value is that it keeps requirements, evidence, and unknowns together.
Include the decision fields
Use one row for each field and fill in “unknown” when the answer is not yet available.
| Brief field | What to record |
|---|---|
| Participants | Source owner, receiving owner, and the team that decides acceptance. |
| Source scope | Product and release, model state, configuration, units, coordinates, and dependencies. |
| Destination scope | Product and release, intended workspace, model view or schema, and required operation. |
| Direction and mechanism | One-way delivery, reference, translation, update, return, or repeated exchange; native, neutral, package, or service route under consideration. |
| Change authority | Who owns each required layer, who may propose or apply changes, and who approves or accepts the resulting state? |
| Continuity expectation | Whether the result is viewed, edited, referenced, updated, or sent back. |
| Required information layers | Geometry/topology/mesh, structure/identity, editability/intent, engineering semantics, spatial context, visual data, manufacturing/quality data, and any domain-specific layer. |
| Permitted loss | What may be flattened, approximated, omitted, or rebuilt, and what may not change. |
| Dependencies | Linked files, asset paths, references, identifiers, fonts, textures, access, and version assumptions. |
| Evidence requested | Documentation and scope, test case, pairwise comparison, observation, or human review; for equivalence work, name the assessed data, criteria, inspection requirements, and retained result. |
| Acceptance | Checks, tolerances or decision rules, sample coverage, acceptance owner, and response to an unresolved result. |
| Retention and retrieval | Whether the package must remain usable later, what must be retrievable, and who will verify that it can be recovered. |
The last row matters when a handoff must outlive the immediate project. LOTAR separates data preparation, ingest, archival storage, retrieval, governance, and preservation planning from data domains such as explicit geometry, assembly structure, and PMI. That does not make every exchange a LOTAR package; it does show why long-lived continuity needs more than a file that opens today.
CCSDS 653.0-M-1 gives a complementary long-term-use model: record the representation information needed to understand the data, including structure, semantics, and software dependencies, along with relevant reference, provenance, context, fixity, access-rights, package, and future-use information. Adapt those fields to the actual retention objective rather than treating them as a universal CAD checklist. LOTAR’s 2025 notice separately describes general 3D-CAD archiving principles and “as-designed” product-structure validation and metadata as distinct scopes. A June 2026 LOTAR notice described Part 021 archival-package metadata as being in external ballot; because that is a development-status source and does not enumerate final fields, do not present it as a current mandatory requirement without checking the final publication.
As checked on 2026-10-12, the NSAI listing identifies prEN 9300-021 with a public-review window ending on 2026-08-20, and DIN Media lists DIN EN 9300-021:2026-08 as a draft. The ended review period and draft listing do not establish its outcome, final EN approval or publication, or the final metadata fields. Use Part 021 as a status question to recheck, not as a current mandatory field set.
When the exchange is also a transfer of permanent electronic records, name the governing records authority and transfer context separately from CAD requirements. NARA’s metadata reference consolidates federal regulations, bulletins, and transfer-request guidance; it does not define CAD-specific fields for every exchange. It also distinguishes the post-accession Lifecycle Data Requirements Guide from agency obligations: agencies do not need to comply with that guide.
NARA’s digital-design format plans identify significant properties and may supply test criteria for formats and transformations represented in its holdings. Their scope reflects NARA’s holdings, risk assessment, processing capabilities, and tools, so identify the properties and criteria applicable to the receiving task rather than treating the plans as universal.
An exchange’s file-construction details may also matter. The published ISO 10303-21:2016 implementation-method scope names external-reference sections, compressed exchange structures, digital signatures, and UTF-8 encoding. Treat these as questions about the selected implementation and receiver—for example, whether references resolve after packaging or signatures are actually checked—not as a guarantee that a particular CAD route writes or verifies them.
Turn an ambiguous request into a brief
Ambiguous request:
Please send the model in a format our team can use.
Bounded brief:
Objective: The receiving team must review the assembly, identify the affected
components, and produce a supplier package. Feature-history editing is not a
requirement for this delivery.
Source: [product, release, assembly configuration, units and coordinates]
Destination: [product, release, supplier-preparation workflow]
Direction: One-way delivery; no return edit is assumed.
Change authority: [who may propose, apply, approve, or accept changes for each required layer]
Required layers: assembly structure and component identity; usable geometry;
the annotations and documents needed for the supplier decision.
Permitted loss: source feature history may be unavailable if the required
supplier review remains possible. Component identity and required annotations
may not be silently flattened.
Dependencies: include all referenced components and state how their paths and
versions are identified.
Evidence requested: route documentation plus a representative assembly
comparison and a human review of the required annotations.
Acceptance owner: receiving engineering lead.
Retention: preserve the accepted package, its requirement record, and the
information needed to retrieve and interpret it at the next release review.
Unknowns: destination handling of [specific annotation or reference] remains
open until the route test is complete.
The example does not recommend a format. It defines what a format or route must demonstrate.
Separate evidence from the requirement
Do not write “the format preserves everything” in the requirement field. Write the requirement as an outcome and the evidence field as a question:
Requirement: the destination must identify every released assembly component.
Evidence: compare the source structure with the received structure for the
selected configuration and record missing, merged, or renamed components.
The CAx-IF testing description is a useful pattern: test-case specifications define functionality, model creation, and criteria; native and exchange files are checked; a target imports the exchange file; and native and target statistics are compared. A project may use a different method, but it should preserve the same discipline of naming the source, target, scope, comparison, and acceptance decision.
Standards scope can help name the questions without answering them. The public abstract for ISO 10303-242:2025 includes product structure and configuration context, change and version tracking, documentation references, long-term archiving and retrieval, and verification and validation. A brief can therefore ask whether those layers matter to the project, but the abstract is not a conformance result for a file, implementation, or route.
For an annotated model or assembly comparison, keep the assessed product data and configuration, criteria and inspection requirements, and recorded result as separate brief items. ISO’s public module summaries describe those information scopes but provide no project-specific thresholds or transfer result. If characteristic master data also travels between systems, identify the dictionary or data specification and implementation profile, and ask separately about message syntax, semantic encoding, data-specification conformance, accuracy, and provenance.
Certification evidence follows the same principle. buildingSMART describes IFC certification as tied to specific exchange requirements satisfied by a Model View Definition, with export/import cases and automatic and manual verification. In a brief, identify the model view and test scope instead of treating “certified” as a universal answer.
Make unknowns visible
Use a status that distinguishes facts from questions:
| Item | Status | Owner and next action |
|---|---|---|
| Destination release | Confirmed / unknown | Destination owner confirms the release before route testing. |
| Required annotation set | Required / unclear | Receiving owner names the annotations needed for acceptance. |
| External references | Included / unresolved | Source owner supplies a dependency manifest and the receiver tests resolution. |
| Continued editing | Required / not required / undecided | Project owner chooses a continuity model before evaluating “editable.” |
| Round-trip behavior | Required / not required / undecided | Define the return path and comparison before exchanging the first file. |
| Long-term retrieval | Required / not required / undecided | Retention owner defines package, metadata, and retrieval checks when applicable. |
| Archival metadata standard/status | Confirmed / proposed / unknown | Confirm the applicable standard and current publication status before relying on a metadata field set. |
An unknown is not a failure, but it is a reason to avoid a broad compatibility conclusion. Resolve it through the appropriate route evidence or keep the acceptance boundary narrow.
Hand the brief to the next decision
The brief should be short enough to share and specific enough to test. Use it to ask route-specific questions about formats, profiles, translators, versions, and source/destination behavior. After a route is selected, turn the “Evidence requested” and “Acceptance” fields into the detailed checks owned by the project’s validation process.
Do not turn the brief into a generic archive manual, a product-pair matrix, or a promise that every layer is preserved. Keep the route and the evidence bounded to the task. Define a CAD Data Handoff Before You Export provides the framing; Choose the Right Handoff Expectation: Delivery, Continued Work, Reference, Update, or Round Trip helps define continuity.
Key points
- Record source, destination, direction, objective, layers, permitted loss, dependencies, evidence, and acceptance.
- Keep requirements separate from the evidence that will test them.
- Make release, profile, configuration, and unknown applicability visible.
- Add retention and retrieval requirements when the handoff must remain useful later.
- A good brief makes route research and acceptance possible without claiming that either has already succeeded.