The assembly pattern: how Manifest builds documents from blocks

6.1 Atomic content blocks

Manifest does not store documents as monolithic files. Instead, every document is an assembly, a tree of references pointing to independent content blocks. Each block is a self-contained unit (a section of a procedure, a data table, a diagram, a regulatory reference) that does not know which document it belongs to. It exists independently in the content repository, with its own version history, its own metadata, and its own lifecycle.

This is analogous to how a modern vessel is constructed from modules. The engine room module, the bridge module, and the accommodation module are designed and built independently. They are assembled into a complete vessel according to a structural plan. The same engine room design might appear in multiple sister vessels. If the engine room design is updated, each vessel can choose when to incorporate the update.

6.2 Assembly as a tree with materialized paths

The assembly itself is a tree structure, echoing the AST concept at the document level. A DP Operations Manual might be assembled like this:

DP Operations Manual (Assembly Root)
├── 1. Introduction and Vessel Description [block-id: dp-intro-v3]
├── 2. DP System Description [block-id: dp-system-desc-v2]
│   ├── 2.1 Power Generation [block-id: power-gen-v4]
│   ├── 2.2 Thruster Configuration [block-id: thrusters-v2]
│   └── 2.3 Position Reference Systems [block-id: pos-ref-v3]
├── 3. Operational Procedures [block-id: dp-ops-v5]
│   ├── 3.1 Critical Activity Mode [block-id: cam-procedures-v2]
│   └── 3.2 Task Appropriate Mode [block-id: tam-procedures-v3]
└── 4. Emergency Procedures [block-id: dp-emergency-v4]

Each entry in this tree has a materialized path (a string encoding its position, like /dp-manual/section-2/subsection-2.1). This path enables efficient queries. Find all blocks under Section 2. Retrieve the full ancestry of any block. Reorder sections without rewriting content.

6.3 Version pinning and title overrides

When an assembly references a content block, it can pin to a specific version. The DP Operations Manual for Vessel A might reference power-gen-v3 while Vessel B's manual references power-gen-v4 because Vessel B has undergone an engine room refit. Both assemblies point to the same content block family, but each locks to the version appropriate for its context.

Assemblies can also override a block's title. The same emergency procedures block might appear as "Emergency Procedures" in the DP Operations Manual and as "DP Emergency Response" in the vessel's overarching Emergency Response Plan. The content is identical; only the assembly decides how it is presented.

6.4 Edition management

When an assembly is finalized for publication, it becomes an edition, a frozen snapshot of the complete document at a point in time. Previous editions are preserved, creating an audit trail. If a regulatory audit asks "What version of your emergency procedures was in effect on 15 March 2025?", the system answers instantly by retrieving the edition that was active on that date.

This approach is precisely what maritime documentation demands. Traceable, versioned, auditable records with clear provenance, achieved not through manual record-keeping but through the architecture of the system itself.