CoClass, BIP and BK04 entries, and their model equivalents
Three Swedish reference systems answer three different questions. This page lists what each one contains, entry by entry, and shows where the same idea usually appears in a Revit or IFC model — so a team can tell scope from identity from product taxonomy before mapping anything.
CoClass
What kind of built asset, system or component is this?
CoClass is the Swedish classification system for the built environment, structured as a set of tables following the international construction-classification framework. Each table classifies a different kind of thing, and a CoClass designation is normally built from more than one table at once.
The code values themselves are published and maintained by Svensk Byggtjänst and are licensed. The tables below describe what each CoClass table classifies; go to the publisher for the current codes and revision.
| Entry | What it identifies | Model equivalent | Where it enters the chain |
|---|---|---|---|
| Construction complexesByggnadsverkskomplex | A group of construction entities forming one facility, such as a campus or a plant | Usually above the model: a project or site grouping in the common data environment, IfcSite at the edge of a federated model | Scope only — it frames which models a decision applies to |
| Construction entitiesByggnadsverk | A single building or civil structure — a school, a bridge, a tunnel | IfcBuilding; the model file or ACC model version | Scope and identity context; it does not by itself determine any element's system |
| Built spacesUtrymmen | Spaces by their nature and use, such as a wet room or a stairwell | Revit Rooms and Spaces; IfcSpace | Strong evidence for requirements — a wet room implies moisture requirements — but the requirement comes from regulation, not from the code |
| Functional systemsFunktionella system | What a part of the building is there to do: enclose, separate, carry, heat, ventilate | Revit Systems and assembly intent; IfcSystem, IfcBuildingSystem | Closest to LITHIC's system classification step — the nature of the thing, before any product exists |
| Constructive systemsKonstruktiva system | How that function is physically realised: a timber-framed external wall, a concrete sandwich wall | Revit wall/floor/roof types and their compound layer structure; IfcWallType, IfcSlabType | Feeds the recipe step: the build-up that material requirements are derived from |
| ComponentsKomponenter | The individual physical parts: a stud, a board, a door leaf, a window frame | Revit family instances and compound layers; IfcMember, IfcPlate, IfcDoor, IfcWindow | Where material requirements are stated and products are eventually selected against them |
| PropertiesEgenskaper | Measurable characteristics: fire resistance, U-value, sound reduction | Revit type and instance parameters; IFC property sets (Pset_*) | Candidate evidence for a requirement check — the value still has to be verified, not trusted because a parameter exists |
| ActivitiesAktiviteter | Work performed on or with the built asset | Not usually in the geometric model; schedules, method statements, procurement packages | Outside the current LITHIC chain; relevant to later procurement and logistics phases |
CoClass tables classify different things, so one object can legitimately carry several CoClass designations at once. Reading one of them as the object's whole identity is the most common misuse.
Svensk Byggtjänst — CoClassThe publisher of the classification, its tables and its current revision.
BIP
How are properties and designations written consistently?
BIP is a Swedish convention set for designations and properties used in BIM authoring. It does not say what an object is — it says how the information about it should be written so that different disciplines and different offices produce comparable data.
The BIP code and property lists are published and maintained at bipkoder.se and are versioned. The entries below describe the kinds of convention BIP covers, not its code values.
| Entry | What it identifies | Model equivalent | Where it enters the chain |
|---|---|---|---|
| Object designationsTypbeteckningar | A consistent, discipline-aware designation for an object type | Revit type name and the type mark parameter; IFC ObjectType | Evidence quality: consistent designations raise how much of a model can be classified without manual work |
| Property designationsEgenskapsbeteckningar | Agreed names for the properties carried on an object | Revit shared parameters; IFC property set and property names | Makes a property machine-readable. It does not make the value authoritative |
| Discipline setsDisciplinvisa uppsättningar | Which designations and properties each discipline is expected to deliver | Discipline models and their parameter schedules | Feeds information requirements: what must exist before a decision can be resolved |
| Value conventionsVärdeformat | How values are expressed — units, decimals, permitted enumerations | Parameter data types and unit settings | Directly affects quantity and cost work: incompatible units are refused, never converted by guesswork |
| File and model namingFil- och modellbenämning | How models, views and deliverables are named and versioned | ACC file naming, model version labels | Scope integrity: a decision is bound to an exact model version, so naming discipline is what makes the binding legible to people |
BIP is a convention, not a classification. A perfectly BIP-conformant model can still be unclassified and unpriceable — the conventions make evidence readable, they do not supply authority.
BIP — Building Information PropertiesPublisher of the designation and property conventions, with current versions.
BK04
Which building-material product group does this item belong to?
BK04 is a product grouping used in the Swedish building-materials trade: it organises what is sold, for catalogue, ordering and statistics purposes. It is supplier-side taxonomy, which is exactly why it sits at the bottom of a decision chain rather than the top.
The BK04 group codes are published by Byggmaterialhandlarna as part of the Vilma standard and are revised over time. The levels below describe the structure and how it meets a model; the codes themselves come from the publisher's current revision.
| Entry | What it identifies | Model equivalent | Where it enters the chain |
|---|---|---|---|
| Main groupHuvudgrupp | The broadest trade division, such as a family of building materials | No direct model equivalent; closest is the canonical category a LITHIC element resolves to | Product selection only. A trade division never establishes what an element requires |
| GroupGrupp | A narrower product family within the main group | Comparable in granularity to a compound-layer material in a Revit type | Helps find candidate products for a material requirement that already exists |
| Sub-groupUndergrupp | The finest published grouping before individual articles | Comparable to a specific layer specification — board type, insulation type, stud type | Candidate shortlist for a stated material requirement |
| ArticleArtikel | A supplier's actual sellable item | A manufacturer-specific family or type, where the model carries one | The product selection itself: bound to a requirement, a product version and a price-book line |
| Trade attributesHandelsuppgifter | Pack size, unit of sale, ordering and logistics data | Not in the model | Cost and procurement. Unit of sale must be reconciled with the governed quantity basis, never assumed equal to it |
The inversion to avoid: letting a product group define a requirement. A material class says what is required; a BK04 group says what a merchant sells. If the catalogue changes, the requirement must not.
Byggmaterialhandlarna — BK04 (Vilma)Publisher of the product grouping; use the applicable published revision.
Model hub: every element and its model entry
Look up a wall, doorset or slab: Revit and IFC entry, CoClass table, BK04 level, quantity basis and chain position.
LITHIC Sweden Pack: the four layers
Authority, construction knowledge, content and decision intelligence — and the contamination rule that keeps Core jurisdiction-neutral.
Why the three systems must stay separate
The failure mode: a well-named object nobody can price, or a priced product nobody can classify.