Core Concepts

QTO works by attaching structured tag data to Revit elements, then computing quantities from the model geometry and producing BoQ deliverables in formats your downstream tools can consume. Three ideas are worth knowing before you run anything: where the data lives, how tagging cascades from types to instances, and where the catalog of price-list items comes from.

The QTO data model

Extensible Storage (ES) — the authoritative store

Each QTO-tagged element carries an Extensible Storage (ES) entity holding the full tag payload. ES is the authoritative source of truth. If you ever see a discrepancy between ES and the Shared Parameter mirror (described below), ES wins.

Shared Parameters (SP) — mirror for external auditors

The add-in also mirrors a subset of the tag data to Shared Parameters bound to each element. Why mirror? Shared Parameters are visible in Revit's native UI, in schedules, and in IFC export. A third-party auditor who does not have the QTO add-in installed can still read the tag information.

Why dual storage

Dual storage is a deliberate cost: more transactions, more storage, more synchronization risk. It is paid for two specific reasons.

• For third-party validators: in public procurement, model handover must be auditable by reviewers who do not run our add-in. SP visibility makes this possible.
• For downstream interop: SP-backed values flow through IFC export and into validators, viewers, and other Revit-aware tools without requiring our add-in to be present.

Element tagging states

State	Meaning
Untagged	Element has no QTO data.
Type-tagged	Element inherits the tag from its type definition (most common state for series-produced elements).
Element-tagged	Element has an explicit tag overriding the type — used for one-offs.
Mixed	Type-tagged elements can be selectively element-overridden.

Type-based propagation

When you tag a type, every instance of that type inherits the tag automatically.

• Adding a new instance of an already-tagged type? It inherits the tag without further action.
• Changing a type's tag? All non-overridden instances update.
• This is why the typical workflow is: tag types first, override individual instances second.

The catalog library

QTO matches Revit elements against entries in a catalog — a database of price-list items (called listini in Italian usage, Bordereau in French, Leistungsverzeichnis in German).

The catalog library is stored locally as a SQLite database. The schema is additive-only — schema migrations are numbered SQL scripts; existing catalogs always remain readable across add-in upgrades.

Future versions of the add-in (V1+) introduce AI-assisted catalog matching (QTOAI) and a shared remote catalog service.

Supported classification standards

QTO is designed for multi-jurisdiction work. The catalog library accepts entries classified under any of the major international standards alongside national price-lists.

Standard	Authority	Scope	Typical use
MasterFormat / UniFormat / OmniClass	CSI (US)	Work results and elemental classification	North American specifications and BoQ
Uniclass 2015	NBS (UK)	Faceted, all-sectors	UK / ISO 19650 workflows
GAEB DA XML	GAEB (DE)	Tender and award data	DACH-region procurement
BC3 / FIEBDC-3	Spanish industry	Decomposed prices	Spanish market
BPU + CCTP	French standard	Unit prices + technical specs	French public procurement
IfcCostItem / bSDD	buildingSMART	OpenBIM cost mapping	Cross-vendor IFC-native workflows
Italian regional prezzari (XPWE)	ACCA / regional bodies	National	First delivery format in Beta

Beta ships with XPWE for PriMus as the only delivery format (Pay tier). V3 opens the international Pay surface (IFC, GAEB, BC3). See the Changelog → for what is live in each release.

The QTO config file

QTO writes a configuration file next to your .rvt named AEC_QTO_Config_<project>.json. It captures project-level setup state (selected catalogs, mappings, phases, work categories).

See also

Last updated 2026-05-19 • Applies to v0.9+