AXF takes the concept of an an object store to the physical level as a fully self-describing, self-contained encapsulation format for complex file collections. AXF provides a standardized way of storing files or file collections of any type and size, along with limitless encapsulated metadata of any size and type, on any type of storage technology or device (including flash media, spinning disk, data tape, cloud and others). AXF is independent of the host operating system and file system as well as from the application that originally created the AXF Object.

AXF can be described as a container that encapsulates any number of related files (of any type and size) into a fully self-describing and constrained object package. It supports the inclusion of any amount of open or proprietary, structured or unstructured metadata encapsulated as part of the object, providing its self-descriptive characteristics. AXF extends this self-descriptive nature to the storage media that contain AXF Objects, allowing access using any AXF-aware system ensuring long-term accessibility and protection regardless of whether the original application which created the object is available.

AXF is also used in the cloud-based transport, storage and preservation of file-based assets and asset collections. It provides a standardized, protected, and authenticated container for complex collections as a single data package that can be transported, stored, restored, verified and distributed.

AXF is based on a file and storage medium-agnostic architecture which abstracts the underlying file system, operating system and storage technology. AXF Objects contain any type, any number and any size of files as part of its payload, accompanied by any amount and type of structured or unstructured metadata, checksum and provenance information, full indexing structures, and other data within a single self-describing, encapsulated package. The AXF Object includes an embedded file system, which helps abstract complexities and limitations of underlying storage technology, file systems and operating systems. AXF Object can exist on any data tape, disk, flash, optical media, or other storage technology and can be used for network transport of data.

As a self-contained and self-describing format, AXF supports large-scale archive systems as well as simple standalone applications, facilitating encapsulation or wrapping, long-term protection and content transport between systems conform to the AXF standard from different vendors.

AXF is an IT-centric implementation, supporting any type of file encapsulation including database files, binary executables, documents and image files. It supports the Open Archive Information Systems(OAIS) model as well as preservationist features such as provenance for both media and objects, unique identifiers (UUID, UMID, ISCI, etc.) support, geo-location tagging, error detection down to the file and structure level and data-validity spot checking.

Each AXF Object is a fully self-contained, encapsulated collection of files, metadata and any other ancillary information which adds relevancy or value to its contents. AXF is designed to handle a single file encapsulation or many millions of files of any type and size. 

AXF Objects are equivalent regardless of whether they are created on data tape, disk, flash, or optical media with or without file systems. This makes the creation and handling of AXF Objects on differing media deterministic once the standard has been implemented.

To aide in resiliency and performance across any storage device, technology or medium, each data structure and element contained within an AXF Object must be aligned on pre-defined chunk boundaries. These can be independent of the storage technology or medium, and can be different for each AXF Object contained on that medium if the medium itself supports this. Chunk size is typically a integer multiple or sub-multiple of blocks on block-based media which also aides in the recoverability of AXF Objects in case where indices have been damaged or corrupted.

During each AXF Object creation, copy or movement operation, the application is responsible for ensuring the data is aligned on the block boundary basis defined for the destination storage technology or media. AXF Objects can be specifically tuned to the underlying storage to optimize performance and storage efficiency even down to the level of tuning on an AXF-object-by AXF-object basis, depending on the average, minimum and maximum file sizes contained within the file payload.

The Binary Structure Container is a simple binary envelop which wraps/contains payload information. For AXF structural elements, this payload is simple XML but in the case of Generic Metadata Containers, it can be anything from binary to text. The Binary Structure Container allows the application to comprehend its contents allowing it to be stored, validated, tracked and reliably recovered regardless of its nature or origin.

For linear media, AXF includes an ISO/ANSI standard VOL1 volume label. This is included for compatibility purposes with other applications to ensure they do not erroneously handle AXF formatted media and to signal applications that do understand AXF they can immediately access the objects contained on the medium.

The AXF Medium Identifier structure contains the AXF volume signature, a UUID and label for the media as well as information about the storage medium itself. The implementation of the Medium Identifier differs slightly depending on whether the storage medium is linear or nonlinear, and whether it includes a file system or not, but the overall structures are fully compatible.

This structure adds the self–describing media characteristics to AXF so systems that support the format can immediately understand everything necessary about the media to be able to index, read and recover its contained AXF Objects.

The AXF Object Index is an optional structure that assists in the rapid recoverability of AXF–formatted media by foreign systems. Information contained in this structure is sufficient to recover and rapidly reconstruct the entire catalog of AXF Objects on the storage medium – think of it as an advanced File Allocation Table (FAT).

This Object Index can be periodically written at various points on the storage media providing enhanced, rapid indexing and recoverability. In a case where the application has not maintained these optional AXF Object Index structures, the contents of each AXF Object can still be reconstructed by simply processing each AXF Object Footer structure adding to the multilevel enhanced resiliency of the format.

Following the AXF Object header is any number of optional AXF Generic Metadata packages. These are self-contained, open metadata containers for applications to include AXF Object-specific metadata. This metadata can be structured or unstructured, open or vendor specific, binary or XML, and provides a flexible and dynamic space in which to enrich the depth of the AXF Object and permanently link it to the encapsulated file payload of the object.

There are no constraints or standards governing the type of metadata, the number of packages, or their contents. In the case where there is no metadata to store along with the AXF Object, this structure is simply omitted. Metadata (XML, binary or other) can also be stored in the file payload of the AXF Object as well but their context may make processing difficult for third-party applications during subsequent restore or replication operations.

Next is a File Payload Start structure which marks the start of the file payload of the AXF Object. This is a simple, empty structure which can be easily located by even the most simple AXF applications.

The File Payload consists of zero or more File Data + File Padding + File Footer triplets. This is the actual byte data of the files to be stored within the AXF Object container. File Padding is used to ensure the chunk alignment of all AXF Object files and structure elements. This is a fundamental requirement of the AXF standard. The File Footer structure contains the exact size of the preceding file along with file-level checksums, original path information, etc. which can be processed by the application on-the-fly during operations to ensure data integrity.

Next is a File Payload Stop structure which marks the end of the file payload of the AXF Object. This is a simple, empty structure which can be easily located by even the most simple AXF applications.

The final portion of an AXF Object is the AXF Object Footer which is essentially a repeat of the information contained in the Object Header with some additional information captured during the creation of the AXF Object itself such as file checksums, block positions, file permissions, etc. The Object Footer is fundamental to the resiliency of AXF and allows efficient re-indexing of AXF media by foreign systems when the content of the media is not previously known (i.e. the self-describing nature of AXF Objects).

Each AXF Object component described above is itself encapsulated in a Binary Structure Container envelope which provides structure identification, index structure checksums, classification information, media/mime types, etc.