On this page
9 Practical example
9.1 A simple maritime procedure in Markdoc
Here is how a bunkering procedure might look as Markdoc content in Manifest, using custom tags:
--- title: Bunkering Operations Procedure regulatoryBasis: MARPOL Annex I, Regulation 18 revision: 3.1 lastReviewed: 2025-11-15 --- # Bunkering operations procedureAll tank levels must be monitored continuously. Soundings shall be taken at intervals not exceeding **15 minutes** and recorded in the .warningAll bunkering operations must comply with the vessel's SOPEP and the port facility's requirements. The Chief Engineer is responsible for overall bunkering safety.
Every element in this document carries structural meaning. The frontmatter (between --- markers) provides metadata that the system indexes and validates. The {% callout%} tags create typed notices whose categories are schema-enforced. The {% table %} tag creates a structured data table whose columns can be validated. The {% partial %} tag pulls in shared content from a single source. The $flagState and $vesselSupplementSection variables are replaced with vessel-specific values at render time.
9.2 The same block in multiple documents
That pre-bunkering checklist block exists as an independent content unit in Manifest. The assembly for the Bunkering Operations Procedure references it. But the same block might also appear in:
- The vessel's Safety Management Manual under Section 7 (Shipboard Operations)
- A Pre-Arrival Checklist assembled for port calls where bunkering is scheduled
- A Training Manual for new engineering officers
Each assembly references the same block. Each can pin to the same or different versions. Each can override the title to fit its context. When the checklist is updated (say, a new check item is added to comply with an updated regulation) every assembly sees the change at its next publication, with full traceability.
9.3 How version control works for regulatory updates
Consider a scenario. MARPOL Annex I is amended to add a new requirement for bunkering in sensitive sea areas. The workflow in a structured system looks like this:
- The regulatory change is recorded in the system, linked to the specific MARPOL Annex I node in the regulatory tree.
- The system identifies all content blocks with
regulatoryBasiscontaining "MARPOL Annex I," including the bunkering procedure above. - The compliance manager receives a list of affected blocks with direct links to each one.
- The bunkering procedure block is updated with the new requirement, creating version 3.2.
- Each vessel's assembly is reviewed. Vessels operating in sensitive sea areas update their assemblies to reference v3.2. Others retain v3.1 until their next scheduled review.
- New editions are published for affected vessels, with the previous editions preserved as the auditable record of what was in effect before the change.
No one searched through folders of PDFs. No one wondered whether a procedure was affected. No one copy-pasted updated text into twenty different Word documents. The structure of the system (documents as data, content as trees, assemblies as versioned references) made the process traceable, complete, and efficient.