The file-based coordination workflow in Catenda Hub begins within the active topic board. Users can easily access topic-sharing settings via the new item action menu in the top right of the topic board interface under the dropdown option Exchange topics. Within this panel, project coordinators can execute automated exchanges using the Import BCF and Export topics features.

Standard BCF files (typically exported with the .bcf or .bcfzip extension) are standard compressed archive containers.2 By modifying the file extension of an exported BCF package to .zip, coordinators can unpack the package on their local system to inspect its raw XML and graphic files using any standard compression tool.2

When extracted, a standard BCF 3.0 archive contains several root-level metadata files and individual topic directories 2:

A mandatory XML file verifying that the package conforms to the BCF 3.0 schema version.1

An optional XML file mapping the package's topic records back to a specific Common Data Environment (CDE) project name and project UUID.1

A configuration file that outlines the allowed list of topic types, statuses, and labels defined for the topic board.1

A registry file listing any supplemental documents or attachments referenced within the coordination archive.1

For every active coordination topic, the ZIP container includes a dedicated subdirectory named using the topic's Globally Unique Identifier (GUID) in lowercase letters inside <Topic-GUID> placeholders.

Within each folder, the coordination data is split into 2:

1.5.1 markup.bcf

The primary XML document defining the topic's structural metadata (such as title, description, creation author, and conversation history).

1.5.2 snapshot.png (or a GUID-based PNG file Snapshot_<Viewpoint-GUID>.png)

A static image snapshot capturing the visual context of the topic.

1.5.3 viewpoint.bcfv (or a GUID-based BCFV file Viewpoint_<Viewpoint-GUID>.bcfv)

An XML file conforming to the visinfo.xsd schema, capturing the exact camera parameters, isolated components, color overrides, and sectional cuts.

When exchanging topics across diverse platforms, differences in user interface labels can create the illusion of custom fields or missing features.

For example, what other BCF collaboration tools term Phase is mapped to the standard <Stage> element inside the markup.bcf schema.

Inside Catenda Hub, this same open standard parameter is natively integrated into the active workspace as the Milestones feature.

This direct mapping ensures that project milestones are successfully translated into project phases when files are exchanged with other model-checking software.

In modern CDE workflows, a clear distinction must be made between features designed for human interaction within a cloud-based web browser and parameters serialized into a flat BCF file.

This divide manifests in two distinct ways: standard fields that exist in BCF schemas but behave differently in the Web UI, and highly interactive CDE features that have no open-standard representation within BCF XML.

Every coordination topic in Catenda Hub is natively tracked using a machine-friendly, randomly generated and globally unique GUID.

2.1.1 Import Behavior

When a BCF file is imported, Catenda's server automatically checks the project for existing topic GUIDs.

If a topic with that GUID already exists, Catenda updates the existing topic.

If it is a new GUID, the server creates a new topic and assigns it a sequential, human-friendly running topic number—visible in the UI as the Topic Number (e.g., #725 or #782) in the table.

This running number is what other standards refer to as the <ServerAssignedId>.

2.1.2 Index Mapping

The BCF standard defines the <Index> attribute to maintain the order of topics on a board.

In Catenda Hub, this Index maps directly to the active Topic Number shown in the table.

Users can filter by this Topic Number in the table to quickly single out specific topics.

2.1.3 Export Behavior

When you export topics to a BCF package, the server-assigned ID / running topic number is entirely omitted from the XML files.1 The BCF package contains only the standardized GUIDs to ensure clean, vendor-neutral exchanges.

The running topic number remains purely a UI navigation and filtering tool inside Catenda Hub.

2.2.1 The Priority Field (<Priority>)

The BCF standard defines <Priority> as a core attribute for ranking topics.

While BCF files containing priority designations can be read by Catenda Hub's database, the Priority field is not currently mapped to an active dropdown or entry element in the default web interface.1 If a priority field is included in an imported BCF, Catenda Hub will maintain standard schema compliance by adding an empty <Priorities/> tag to the exported extensions.xml file, though individual topic-level priority tags are omitted to align with the board's active layout.

2.2.2 The Line Markup Field (<Lines>)

The buildingSMART BCF standard supports a <Lines> element inside the visinfo.xsd schema (nested under the viewpoint's <VisualizationInfo> node) to store 3D annotation lines or redline markings alongside viewpoints.

While some platforms use these lines to draw markups or point locations directly inside the 3D scene, these 3D lines are not currently displayed in the Catenda Hub Web UI, and any line data contained in imported BCF packages is omitted on import and export.

2.2.3 The Viewpoint Bitmap Overlay Field (<Bitmaps>)

The buildingSMART BCF standard supports a <Bitmaps> collection nested under the viewpoint's <VisualizationInfo> node.

This allows flat 2D graphics or immersive 360-degree photos to be placed at specific coordinate points in the 3D scene, defined by a 3D world coordinate point , a normal vector, and an up-vector.

A visual analysis of standard model views confirms that no active bitmaps are rendered inside the scene, which aligns with why the corresponding viewpoint files contain empty <Bitmaps/> tags.

Currently, bitmaps are not viewable in the Catenda Hub Web UI, and any active bitmap data is omitted from standard file exports. However, this data can be accessed with API access to support custom external integrations.

The buildingSMART BCF standard reserves the <BimSnippet> element to associate external data payloads (such as small IFC files representing a provision for voids) directly to a topic.2

2.3.1 The Queries Feature

In Catenda Hub, this corresponds conceptually to the native Queries feature.

Queries allow coordinators to selectively load specific sections of building geometry (e.g., rectangular 2D area cuts, spatial space bounds, or specific storey boundaries) without loading the entire federated model.

2.3.2 Omitted on Export

While queries can be created and saved in the Web UI, they are omitted on BCF export.1 Catenda does not serialize queries as BimSnippets; instead, it preserves visual consistency by referencing the main IFC file and using standard object visibility exception lists inside the .bcfv viewpoint file.

2.3.3 API Access

Regular customers cannot retrieve or edit queries via the REST API.

However, programmatic creation of new queries can be accessed with API access inside the Catenda 3D viewer SDK (software-to-software customers only).

Catenda BCF exports do not physically package massive, multi-gigabyte IFC files inside the lightweight ZIP container. Instead, a topic’s <DocumentReference> or <Header> file entry points directly back to a file registered in the Catenda Document/Model Library.1

2.4.1 Version History and Filenames

Within Catenda Hub, a registered model or drawing is represented in the Web UI by its master Document Name, which corresponds to the standard BCF <Filename> tag.1 Under this master document container, the library maintains a live version history comprising multiple revisions (e.g., #1.1, #1.2, #1.3), with each revision carrying its own unique creation date and its own distinct physical filename.

Standard BCF <Header> tags (like <Date>) are used to serialize the specific timestamp of the active model revision referenced at the moment of export.

2.4.2 File References

For the BCF file reference (Header/Files/File/Reference), there is a native web UI element where you can select a document in the table and use the Copy link action to copy the direct URL of the file.1 This URL corresponds directly to the file reference link written to the BCF header.

Topic relationships have multiple visual and functional representations in Catenda:

2.5.1 In-Description Markdown Links

Users can reference other topics inside the topic description or comments by writing # (e.g., #).

This action generates an interactive, clickable in-text hyperlink that allows team members to quickly jump between related topics.

2.5.2 Right Collapsible Menu Relations

To the right of the topic banner, opening the information panel reveals the Related items section, where coordinators can formally add, edit, and remove topic-to-topic links separate from the description text.

2.5.3 BCF Export Behavior

While the in-text markdown links in the description are preserved as plain text comments, it is the formal relations list managed in the Right collapsible menu that is serialized and exported into the BCF <RelatedTopic> GUID nodes, ensuring standard-compliant relational mapping between tools.

Catenda Hub offers advanced features for 2D/3D coordination that are fully operational in the web browser and mobile apps but are completely excluded from exported BCF packages due to standard schema boundaries:

2.6.1 The Storey Configurator and 2D Viewer selector

The IfcSpatialStructureElement attribute in the BCF Header maps a topic to a configured storey level (e.g., "First Floor").

In Catenda Hub, this level configuration is utilized across the Storey Configurator page (to map IFC levels and align 2D drawings like PDF layouts) and the 2D Viewer panel (to filter views by building levels and select specific storeys).

2.6.2 Proprietary 2D Topic Location Markers

Within the 2D viewer, users can place a colored pin (marker) representing a topic directly onto the active storey's floor plan.

While these location markers are vital for web and field workflows (e.g., Catenda Site), standard BCF 3.0 has no native representation for 2D sheet space coordinates.

Consequently, while the static storey name is registered, the interactive 2D plan pins are entirely omitted on BCF export and remain live database features preserved on the CDE server.

The BCF standard defines the IsExternal parameter under the <Header>/<Files>/<File> node that operates entirely behind the scenes in Catenda Hub and is not exposed as an editable field in the user interface:

2.7.1 IsExternal

A boolean flag (always exported as true by Catenda Hub).

In BCF schemas, this defines whether the referenced IFC model file is embedded directly inside the physical BCF zip archive (false) or resides externally (true).

Catenda Hub keeps this as true to avoid bloating BCF files with heavy physical geometry.

Catenda Hub is built on a foundation of open standards and supports the complete serialization of BCF v3.0 files.

The table below outlines how each standard BCF 3.0 field is handled by Catenda Hub, detailing its corresponding web user interface representation, its BCF serialization behavior, and its round-trip behavior.

The BCF 3.0 standard allows multiple viewpoints and snapshots to be linked directly to individual comments.2 Within the BCF ZIP container, each topic is stored in a dedicated folder named with the topic’s lowercase <Topic-GUID> placeholder.2

This folder contains the core files required for visual and narrative coordination:

The XML file storing the topic's descriptive data, conversation thread, and relationships.

The static image rendering of the topic.

The schema-compliant XML containing the 3D coordinate vector dataset.

The visual relationship is established by the viewpoint, which presents a perspective of the model layout.2 In the viewpoint file Viewpoint_<Viewpoint-GUID>.bcfv, the standard visibility state is represented by setting <Visibility DefaultVisibility="true"> with optional <Selection/> and <Coloring/> nodes, allowing the camera position to carry the full visual context.1

The camera coordinates from this extracted viewpoint are parsed using the following standard mathematical structures 1:

4.3.1 Perspective Camera Geometry

The perspective camera position is defined in three-dimensional space by a camera viewpoint coordinate vector

The direction of the camera lens is defined by the unit vector

The vertical orientation of the camera is maintained by the camera up-vector

The perspective lens properties are defined by standard viewing metrics:

In addition to camera coordinates, the viewpoint file contains:

4.3.2 <Selection>

Lists any specific IFC elements that are actively highlighted or selected for the topic.

4.3.3 <Visibility DefaultVisibility="true">

Sets the baseline rendering state for model files.

4.3.4 <ViewSetupHints SpacesVisible="false" SpaceBoundariesVisible="false" OpeningsVisible="false"/>

Standardizes the visibility of spatial boundaries and openings to prevent geometric clutter.

To understand how BCF 3.0 represents complex visual states, we analyze how the schema handles advanced topic packages containing the primary markup, snapshot images, and highly detailed visualization datasets.

For advanced coordination, the BCF viewpoint schema captures highly complex visual coordinate states. When a coordinator slices open a ceiling to reveal interior partitions, isolates HVAC components, makes outer structural envelopes transparent, or highlights specific equipment in a vibrant color, the visualization parameters are encoded directly in the viewpoint XML according to the buildingSMART specification.

4.4.1 Highlighted & Selected Components

In BCF 3.0, the elements that should be highlighted or selected are nested under the /VisualizationInfo/Components/Selection node.

The XML structure identifies selected objects using their globally unique Industry Foundation Classes identifiers (IFC GUIDs).

Selected target elements are registered under the <Selection> node:

When loaded inside Catenda Hub, the 3D viewer automatically highlights the listed components to focus the reviewer's attention.

4.4.2 Visibility Exceptions & Hidden Objects

To prevent surrounding geometries (such as solid walls and slabs) from obstructing the view of the problem, the viewpoint uses a default visibility toggle combined with exception overrides:

4.4.3 Transparent Objects and Alpha-Channel Overrides

A major capability of the BCF 3.0 schema is the ability to apply custom colors and transparency levels to model elements via the <Coloring> node to aid spatial tracking.7 In this viewpoint, highlighting is managed via the <Coloring> node, applying the solid green color hex 49ff00 to the following targeted elements:

Transparency is driven by the viewer's active display mode, rendering background components translucent to provide a context-rich backdrop without blocking the view of the highlighted elements.

4.4.4 Slicing with Clipping Planes

To slice open the roof and reveal the layout, the viewpoint uses clipping planes.2 In the .bcfv schema, sectioning cuts are stored under /VisualizationInfo/ClippingPlanes.

Each active plane is defined by two vectors:

<Location>

A coordinate point P defining where the cutting plane sits in 3D space.

<Direction>

A normal direction vector n defining the cut angle and indicating which side of the model to crop out.

For any point on the clipping surface, the plane equation is expressed as:

Expanding this into 3D Cartesian coordinates gives:

The viewpoint Viewpoint_<Viewpoint-GUID>.bcfv defines two active clipping planes to expose the interior space:

Clipping Plane 1:

Clipping Plane 2:

Upon import, the 3D engines in both Catenda Hub and other BCF-compliant viewers apply this exact mathematical slice to render the same cut section of the building.

To ensure seamless data exchange across platforms, it is important to distinguish standard BCF 3.0 fields from proprietary metadata.

This proprietary data is divided into two categories: non-standard fields injected by competitors, and server-side extensions used by CDEs like Catenda Hub.

Some coordination platforms and design applications insert proprietary XML schemas directly into BCF zip structures.

These additions are designed to support native features like pushpin locations or platform-specific topic tracking.

Because these files do not conform to the schema defined in markup.xsd, they are either stripped or ignored during standard BCF 3.0 validation.

Catenda Hub offers several advanced features as a cloud-based Common Data Environment (CDE).

These features are managed server-side alongside the standard BCF metadata schema to optimize coordination and information management.