Why the template matters more than most firms acknowledge
A sealed field review report is a regulated document. Under Ontario Building Code section 1.2.2.2, a field review is the mechanism by which a designer of record confirms that general conformity with the designed intent has been, and continues to be, achieved during construction. The document that records that review carries a professional seal, and the seal carries personal liability for the P.Eng or OAA member who signs it.
This is why the template matters. The template is the default structure every review starts from. If the template is missing a section, the engineer has to remember to add it on every visit - which means some visits will omit it. If the template has ambiguous prompts ("observations" with no further guidance), the resulting reports will be inconsistent across engineers within the same firm. If the template has placeholder language that nobody edits, the report goes out with generic boilerplate where site-specific content should be.
After reviewing hundreds of field review reports across multiple Ontario structural and building-science practices, the pattern is clear: firms with strong templates produce consistent, defensible reports with relatively little effort per visit. Firms with weak templates spend 30 to 60 minutes per report manually adding structure that should have been there already - and the reports vary visibly in quality from one engineer to the next.
This piece catalogues what a sealed field review template needs to contain, what is typically missing from off-the-shelf templates, and the tradeoffs firms face when customizing.
Required elements: what cannot be omitted
A template for OBC 1.2.2.2 field reviews has a small number of elements that are genuinely required. Not required by preference, but required by either regulation, case law, or the structure of the professional obligation. Every sealed review must contain these, without exception.
The header block
The header identifies the document. It is the metadata layer that makes the report findable, citable, and auditable. Required fields:
- Project name and address. The street address is load-bearing for any later dispute - it establishes the physical location the engineer visited.
- Project number. The firm's internal tracking reference. A report without a project number is almost impossible to retrieve from file storage years later, when it matters most.
- Report number and revision. Field reviews are typically numbered sequentially within a project (FR 1, FR 2, FR 3...). Revision numbers apply when a report is re-issued to correct an error or address a dispute. A report without a revision field cannot properly document its own supersession.
- Date of review and date of issue. These are two different dates. The review date is when the engineer was physically on site. The issue date is when the report was signed and distributed. They usually differ by one to seven days and the distinction matters in disputes about when the engineer knew something.
- Reviewer name and firm. The licensed professional conducting the review, and the firm under whose Certificate of Authorization the review is performed.
- Firm name and Certificate of Authorization number. PEO Regulation 941 requires that engineering work performed for the public be performed by a holder of a C of A. The number belongs on every sealed report.
The scope of review
A defensible field review report states what was reviewed and what was not. This is sometimes called the "area reviewed" or "scope" block. It is required because a field review is a sampling exercise - the professional selects representative elements and evaluates them - and the record of what was sampled is the only evidence of what the engineer actually inspected.
A good scope block names the building area, the floor or grid lines, the work type (structural concrete, structural steel, waterproofing, etc.), the stage of construction, and any elements explicitly not reviewed during this visit. A weak scope block is a single line like "site visit to review construction progress" - which is a placeholder, not a scope.
Observations
Observations are the body of the report. Each observation is a numbered finding that names what was observed, where, when, and against what standard. The template must support observations as a structured list - not as a single text field - because each observation needs its own metadata (observation number, location, classification, recommendation, and any photo references).
A template that provides a single "notes" field where the engineer types paragraph-form observations will produce reports that are hard to search, hard to cross-reference, and hard to carry forward into subsequent visits. A template that forces each observation into a structured cell produces reports that can be machine-read, audited, and compared across revisions.
Photo evidence
Every observation that references a physical condition should be paired with a photograph. The template needs an embedded photo slot per observation (or a referenced photo log) and a captioning mechanism. A template that allows photos to be attached as an appendix - disconnected from the observations they illustrate - produces reports where the reader cannot tell which photo supports which finding, and the engineer may forget to embed a photo at all.
Photo references should be inline in the observation text itself ("(Refer to Photo #3)", "(Photos #1 and #2)"), not deferred to a separate index. This is both a defensibility point and a readability point.
The sign-off block
The sign-off block is the artifact that makes the document a sealed report rather than a draft. It contains:
- The licensed professional's name, designation, and PEO or OAA license number
- A space for the professional seal (physical embossed or digital equivalent)
- A space for signature
- The date of seal application (which may differ from the report date if the seal is applied later)
A template that treats the sign-off as an afterthought - a footer line with "Signed: _______" - leaves the engineer to construct the block manually on every report, which produces inconsistency.
The boilerplate closing
Most firms include a standard closing paragraph ("We trust that this report accurately reflects the conditions observed at the time of our visit. Should any questions arise..."). This is not legally required but it is practice-standard, and it sets expectations about the scope of the engineer's professional opinion. The template should include this paragraph as a non-editable or protected element so engineers do not accidentally remove or rewrite it.
Commonly missing elements: what engineers add back by hand
The above are the required elements. Most off-the-shelf Word templates downloaded from an association site, a generic engineering-document library, or adapted from a competitor's report contain most of them. What they miss is the structural supporting elements - the ones that elevate a compliant report to a defensible one.
The revision history block
A field review report can be re-issued. When it is, the replaced version should not simply disappear - it should be marked superseded, and the new revision should document what changed and why. Most templates have no revision history block. Firms that re-issue reports regularly (which is every firm doing restoration work) end up adding it manually every time, inconsistently, and the resulting chain of revisions is hard to follow six months later.
The distribution list
Who received this report? A template should explicitly list distribution recipients - typically the general contractor, the project manager, the architect, the owner or owner's representative, and sometimes municipal building officials. The distribution list is how the engineer demonstrates that the findings were communicated to the parties who needed to act on them. A template without a distribution block forces engineers to include recipients as an email attachment rather than as part of the report itself, which breaks the documentary record.
The people-present-on-site block
Field reviews are usually witnessed. The contractor superintendent, the project manager, the waterproofing foreman, other subtrades - they were on site when the engineer was. Naming them in the report does two things: it establishes the evidentiary record of who could corroborate the engineer's observations, and it forces the engineer to actually engage with the people doing the work rather than treating the site as an empty stage. Most templates omit this block entirely.
The regulatory citation cascade
A defensible observation cites the specific code section, CSA standard clause, or project specification that the engineer is measuring against. Most templates have no prompt for this. The engineer either remembers to include the citation or does not. A template that prompts explicitly - "Standard or specification referenced:" as a field per observation - produces reports with consistent regulatory literacy. A template that leaves it to memory produces reports where half the observations have citations and half do not.
The photo caption requirement
Photos without captions are visual noise. A defensible report captions every photo with what is shown, where it was taken, and which observation it supports. Most templates embed photos with no caption field. Engineers add captions manually, inconsistently, or not at all.
What firms customize, and the tradeoffs
Firms do eventually build templates that address the gaps above. Customization typically falls into three buckets, each with a tradeoff.
House voice. Firms develop signature language - how they phrase observations, how they structure recommendations, how they close the report. Customizing the template to encode the house voice produces consistent reports across engineers but reduces flexibility. A junior engineer who inherits the template cannot easily adapt it for a new project type that needs a different voice.
Client-specific overlays. Some firms maintain multiple templates per client, matching each client's preferred report layout. This is common when the client is a large property management company or a municipal authority with its own submission standards. The tradeoff is template sprawl - ten clients produce ten templates, and keeping them all synchronized when a regulation changes is an operational burden.
Discipline-specific variants. The template for a structural field review is not identical to the template for a mechanical one, nor a building-envelope one. The required header and sign-off blocks are the same, but the observation vocabulary, photo subjects, and regulatory citations differ. Firms that do work across disciplines need per-discipline templates. The tradeoff is development cost - each variant requires its own tuning and its own maintenance.
Where Fermito fits
Fermito produces sealed field review reports from voice field notes, using per-discipline prompt vocabulary for structural, mechanical, electrical, plumbing, and architectural work under OBC 1.2.2.2. The generated output is a DOCX file that is template-aligned by design: the header block, scope, structured observations with inline photo references, distribution list, and sign-off block are all present because the prompt and the export pipeline encode them.
For firms that already have a house template, Fermito's output can be tuned to match that format during onboarding - the firm's preferred section headings, phrasing, and layout. For firms that do not have a house template, or that are starting from a generic Word document, the Fermito default is a structurally defensible template that passes the criteria in this article.
Free Word templates for all five disciplines are being released at fermito.com/resources/templates as each one passes review. The structural template is first. Use them as they are, fork them into a firm-specific format, or use them as a checklist against whatever you have today.