IFC IDS Requirements Receipt

Locate model elements that fail selected literal IDS1.0 requirements before routing them to model review. Supply a small authorized IFC4 STEP model and its IDS document; one bounded receipt localizes failed checks by STEP id, optional GlobalId, class, specification and requirement index. It reports exact applicability and conjunctive pass/fail counts without exposing attribute or property values.

This experimental receipt does not inspect geometry, repair a model, infer requirements or certify IFC/IDS, structural, regulatory or physical conformance. Existing native/web/API validators are strong substitutes; customer demand and savings from managed access remain unvalidated.

Input

Run the always-uncharged bundled synthetic pair with:

{"demo": true}

For real input, send one JSON object with processingPermission: true, nonempty ifcText and idsXml strings. Both documents are inline; no paths, URLs, archives, cloud credentials or other fetch instructions are accepted. demo and processingPermission are actual booleans, default false. Demo requires documents to be absent, even empty/null, and permission false or absent. Unknown keys, NUL, malformed Unicode, coercion and mixed modes are refused before native work.

Only IFC4 STEP physical files with a normal header/end envelope are admitted. IFC2X3, IFC4X3 and IFC XML are outside the profile. Native unsuccessful parser status, exceptions or diagnostics yield a fixed uninspected refusal, without native logs or exception text. This does not certify all IFC syntax: the native parser can silently accept trailing text.

Finite IDS profile

Use namespace http://standards.buildingsmart.org/IDS. The root contains optional info followed by specifications, with 1–16 specifications. Each specification has ifcVersion="IFC4", a 1–128-character name, optional bounded identifier, one exact entity applicability and supported literal requirements.

Exact classes are IFCWALL, IFCDOOR, IFCWINDOW, IFCSLAB, IFCBEAM and IFCCOLUMN. Subtypes are not implicitly included. Applicability supports required 1/unbounded (default), optional 0/unbounded or prohibited 0/0. Prohibited applicability has no requirements; other applicability has 1–16 conjunctive requirements.

Attribute requirements support only direct Name, Description and Tag, with optional nonempty literal value and required/optional/prohibited cardinality (default required). Property requirements support exact property-set/base-name literals, mandatory IFCLABEL or IFCTEXT datatype, required cardinality only and an optional nonempty literal value. Only single-value properties without unit interpretation are admitted. Normal type inheritance and occurrence overrides are resolved; duplicate/ambiguous sets or matching definitions and non-scalar representations refuse processing rather than collapse into a pass.

Literal strings are case-sensitive. Required zero matches fail existence; optional zero matches are explicitly not_applicable; prohibited zero matches pass the selected absence check. Each element passes only if every declared requirement passes. A failed selected requirement is a complete semantic result, not a native runtime failure.

DTD/entities/external resources, regex/XSD restrictions, alternate namespaces, classification/material/partOf, predefinedType, entity requirements and additional applicability facets are refused. schemaLocation and allowed URI metadata are inert; user XML never enters a native generic loader. Ordering, duplicate singletons, attributes and literal shapes are checked. This is structural profile admission, not full IDS document validation.

Pinned IfcTester0.9.0 mishandles optional direct attributes whose actual value is None. This version uses the documented narrow compatibility rule: admitted optional Name/Description/Tag with None passes; empty strings and present values continue through native facets. Required and prohibited attributes are unchanged. The receipt discloses this rule. Package versions and the native writer build string are distinct provenance; an experimental native build label is not a maturity claim.

Full report and failures

After successful delivery, the default dataset contains one full receipt object and the default key-value store's REPORT JSON contains the identical object. Use the Output tab's Complete REPORT JSON link or GET /v2/key-value-stores/{defaultKeyValueStoreId}/records/REPORT with appropriate Apify authorization. Dataset tables are summaries; retrieve the full JSON for all specifications, elements and checks. Specification and requirement indexes are zero-based; elements are ordered by ascending STEP id.

Statuses are complete, refused or failed. Outcomes are review_findings, no_findings_in_completed_checks or not_inspected. No outcome means compliant, valid, ready or safe. Refused/failed receipts use fixed sanitized reason codes. Native crash, timeout or invalid/oversized output produces a fixed failed receipt when the parent survives; platform termination may prevent any stored receipt.

Recover and retain this run's evidence

1. Use your authorized Apify caller to start asynchronously. Save the returned run id and a caller-generated request key in your own records before proceeding; retain defaultKeyValueStoreId and defaultDatasetId from the run response.
2. Check GET /v2/actor-runs/RUN_ID with that saved ID (run API). If a wait or retrieval times out, check the same run again. A failed or timed-out run can still have stored output; inspect it before deciding what to do.
3. Retrieve the authoritative full receipt with GET /v2/key-value-stores/STORE_ID/records/REPORT, using that run's defaultKeyValueStoreId as STORE_ID (record API). Its equal dataset item is available at GET /v2/datasets/DATASET_ID/items?format=json, using defaultDatasetId (dataset items API). Check REPORT during failure recovery even if dataset delivery failed.
4. Export the full typed JSON, parse it and verify the input binding and decision-required evidence before acting or cleaning up. Keep profile, catalogVersion and input.ifcSha256/input.idsSha256 with all specification, element and requirement results. complete can include failed selected requirements; it does not establish general IFC/IDS compliance.

Do not silently POST again after a failed retrieval. If the initial start response was lost and no run ID is known, reconcile your authorized run history against your recorded request and input before considering a paid restart. A missing response does not prove no run started; this workflow promises no universal start idempotency.

A table or optional dataset field projection can support a limited notification, but it is not the full report. Retain the run/storage IDs, the identity and version/profile fields above, and relevant coverage; retrieve omitted detail from this same run before making a detailed decision.

Selective cleanup

After the run is terminal, no restart is planned and your exported evidence has been parsed and verified, you may remove authorized copies you no longer need. Use your saved exact storage IDs, never a latest-run shortcut or an assumed shared store. See Apify's record deletion and dataset deletion references for platform operations, which were not exercised in this Actor's QA: deleting INPUT leaves REPORT; deleting REPORT does not delete the dataset. Input records, REPORT records, dataset items and external copies are separate. Removing one does not erase logs, exports, saved task input, source files or customer copies, or guarantee provider-wide erasure.

Bounds and charging

Bound	Maximum
IFC / IDS UTF-8 input	1 MiB (1,048,576) / 64 KiB (65,536) bytes
Model instances / evaluations	5,000 / 2,048
Specifications / requirements each	16 / 16
XML depth / element count	16 / 2,048
Literal attribute value / property-set or property name	256 / 128 characters
Serialized UTF-8 report	1 MiB
Native child address space / CPU	1 GiB / soft10, hard12 seconds
Child wall / adapter / candidate platform timeout	15 / 55 / 60 seconds
Candidate platform memory	512 MiB

These are chosen design bounds, not measured scalability guarantees. A fresh child installs Linux resource limits before native imports, uses an explicit secret-free environment and one OpenBLAS/OMP thread, and suppresses native stdout, stderr and tracebacks. The parent bounds pipes, kills/reaps at deadline and does not retry. This is process/resource isolation, not a security sandbox.

The current price is $0.05 per useful report. Useful means non-demo and complete with both documents admitted and at least one specification fully evaluated. Selected requirement failures and zero-match existence/absence/not-applicable results can be useful. All demos, unsupported/invalid/over-limit and crash cases are uncharged. Equal REPORT and dataset copies precede one eligible report-produced event. Storage, deadline or charge failures fail the run without application replay; dataset redirects are disabled and SDK charge idempotency remains in place.

Authorized input and output may persist in normal Apify storage. No automatic deletion, original-input redaction, erasure or nonretention is promised. Reports include bounded caller specification labels/identifiers and localization ids; they omit source attribute/property values and arbitrary native reason strings.

IfcOpenShell and IfcTester are LGPL-3.0-or-later dependencies. See the official versioned source and license and the LGPL terms. The image also retains THIRD_PARTY_NOTICES.md with dependency notices.