The Problem with Ad-Hoc Templates
A structural and architectural engineering practice working across dozens of simultaneous projects cannot afford to start each one from scratch. Without a shared production standard, every project develops its own line weight conventions, its own view template naming, its own annotation symbols, its own shared parameter schema. The consequence is not just inconsistency in deliverables — it is compounding friction: a consultant joining project three cannot read project seven’s model, schedules built for one project cannot be reused on another, and every project startup involves hours of manual configuration that add no engineering value.
The GPA BIM Template for Architecture is the practice’s answer to this. It defines, in a single production-ready Revit template file, everything a new architectural project needs to be started correctly: graphic standards, view configurations, annotation families, sheet organisation, shared parameters, and the loaded family content that supports day-one modelling.
Container Architecture
The most important structural decision in the template’s design is the separation of content into independently versioned container files rather than embedding everything in a single monolithic template.
Three container projects hold distinct categories of Revit content:
Component Families container — all loadable annotation and component families used across GPA projects, loaded into a dedicated .rvt project that serves as the family library. New families are added, tested, and approved here before being propagated to the production template. This prevents untested content from entering live projects.
System Families container — wall types, floor types, ceiling types, roof types, and all other system families (which cannot be saved as standalone .rfa files in Revit) are maintained in a separate project from which they are transferred to the template via Revit’s Transfer Project Standards function. Isolating system families this way means their versioning can be tracked independently of annotation and line style changes.
Line Styles container — line weights, line patterns, and line styles are held in a third file. These are the most frequently revised elements of a graphic standard — responding to feedback from plot testing, print quality reviews, and changes in deliverable scale — and separating them avoids contaminating system family or component family versions with what are essentially graphic calibration changes.
The production template is assembled by transferring approved content from all three containers. This architecture means that a change to a single line style does not require re-publishing the entire family library, and a new wall type does not trigger a line style review cycle.
Shared Parameter Schema
A single shared parameter file (GPA_SharedParameters_r01.txt) defines every project parameter used across the template — the GUIDs, parameter names, data types, and parameter groups that GPA’s scheduling and data workflows depend on.
Centralising parameters in one file guarantees that the same parameter appearing in an architectural model, a structural model, and a Dynamo script refers to the same database field — not to three parameters that happen to share a name but carry different GUIDs. This is the layer of data infrastructure that makes cross-discipline scheduling and quantity takeoff possible without manual reconciliation.
The shared parameter file is version-controlled alongside the template. When a new parameter is required — for a new regulatory requirement, a new quantity field, or a new BIM data protocol — it is added to the shared parameter file first, the addition is reviewed, and only then propagated to the template and to any Dynamo scripts that reference it.
Sample Project
The _progetto campione (sample project) is a fully modelled reference project distributed alongside the template. It demonstrates correct usage of every template element: how view templates are applied, how sheets are organised and named, how levels and grids are structured, how annotation is placed, and how the architectural and structural models are linked.
Three sample sheet sets — floor plans, elevations and sections, reflected ceiling plans — are published as PDFs and included in the library, providing a visual reference for the expected output quality and graphic standard at standard drawing scales. These serve both as training material for new team members and as a benchmark for QA review on live projects.
The sample project includes both an architectural (ARC) and a structural (STR) model linked together, demonstrating the correct federated model setup for a typical GPA project.
Guidelines Publication
The template is accompanied by a written guidelines document produced in InDesign and distributed as PDF. The guidelines explain not just what the standard is, but why each decision was made — which drawing scales each view template is calibrated for, what the rationale is for the parameter schema, how the sheet numbering system works and how it maps to the project’s BIM execution plan.
Written rationale matters in a production environment because templates are followed more consistently when the reasoning behind them is understood. A team member who knows why a line weight is set to a particular value will preserve it under pressure; one who sees it as an arbitrary number will override it the moment it seems inconvenient.
Versioning
The template has been maintained through multiple iterations — tracked across Revit versions (2021 through 2024) and internal revision cycles — with archived versions retained for backwards compatibility with projects started on earlier Revit releases.
Active development is tracked in a revision folder where work-in-progress iterations are held separately from the production release. This prevents experimental changes from reaching live projects until they have been validated against a test project and signed off. The production template carries a version number in its filename; when a new version is released, all project teams are notified and onboarded to the change.
The template is one of the less visible pieces of infrastructure at GPA — it is the foundation that every architectural project is built on, and its quality determines the consistency and professionalism of every drawing that leaves the office.