Create a concise exchange brief that turns a design-data request into researchable route requirements and later acceptance checks.

Write an Interoperability Brief That Leads to Testable Acceptance

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.
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, profile or conformance scope, test case, pairwise comparison, observation, or human review.
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.

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.
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.

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.