ifc-control

Bounded IFC control semantics: permits, project orders, action requests, and performance history.

Status	Implemented
Latest release	0.3.0 (2026-09-29)
Registries	crates.io ifc-control
Via the facade	openbim-ifc feature control
API documentation	rustdoc · docs.rs
Source	crates/ifc-control/

Overview

Bounded IFC control semantics: permits, project orders, action requests, and performance history.

This crate owns the IfcControl subtypes that govern work rather than describe physical form. It stages them into a transaction and validates what the schema states; it does not implement approval workflow, authorization, or policy decisions, which are the concern of whatever system issues the permit.

Controls relate to the work they govern through IfcRelAssignsToControl. The crate owning the relating control writes that relationship, so this crate stages it for its own four controls and refuses any other.

Records are laid out by attribute name from one release's table (#198). IfcRoot.OwnerHistory is required in IFC2X3 and optional from IFC4 on, so the writers that leave it unset refuse IFC2X3 with ControlError::AuthoringRequired; the *_with_owner_history variants bind the model's declared release and take a caller-supplied IfcOwnerHistory (#202).

IfcCostItem, IfcCostSchedule, IfcWorkCalendar and IfcWorkControl are IfcControl subtypes too, but they belong to ifc-cost and ifc-schedule: the crates split by domain, not by supertype, so those entities do not move here.

Depends on

• ifc-model
• ifc-schema

Changes

Latest release, 0.3.0 (2026-09-29):

Changed (breaking)

• ControlDraft and ControlAssignmentDraft are #[non_exhaustive] (#214). Struct literals no longer compile outside the crate: build them with ControlDraft::new() and ControlAssignmentDraft::new(global_id, control, related_objects) plus field-named setters (.name("Permit")). Fields stay public.

Changed

• Depends on ifc-schema with its default features named explicitly (every bundled release), now that the workspace dependency turns them off for the facade's per-release features (#112).
• A model whose header declares IFC4X1 or IFC4X2 is refused with the existing unsupported-schema error. ifc-schema now bundles both releases, but no layout here is verified against them, so they are never read as IFC4 or IFC4X3.

Full history: crates/ifc-control/CHANGELOG.md