Contextual viewer assistant¶

For models that require your own credentials, open the chat key settings and paste a key from the provider's API console. Anthropic keys are recognized by the sk-ant- prefix; the viewer does not require a particular key version. Personal and service-account keys scoped to one workspace need only the key. For an unscoped key, also enter its Workspace ID from the Claude Console's Settings → Workspaces. Save commits both fields together. The provider checks the key's permissions, expiration, and workspace access when you send a message. See Anthropic authentication.

OpenAI project and service-account API keys use the existing API-key flow. They need access to the selected model and inference endpoint, and available API billing. The viewer currently supports API keys; ChatGPT account sign-in and ChatGPT plan usage require a separate OAuth integration. See OpenAI API authentication.

The current Anthropic choices are Claude Opus 5.5, Fable 5.1, Sonnet 5.5, and Haiku 4.5. The current OpenAI choices are GPT-6 Astra, GPT-6.1 Sol, and GPT-6 Luna; GPT-5.3 Codex remains an older specialized option. Saved Sonnet 5 and GPT-6 Sol selections migrate to Sonnet 5.5 and GPT-6.1 Sol respectively, keeping the same provider. Model access still depends on your API account. See the Claude model catalog and OpenAI model catalog.

Finding saved artifacts¶

Open Advanced Search → Libraries to search existing checks, saved reports, loaded BCF topics, documents, Flows, scripts, lists, lenses and saved profiles. Names and artifact types can be searched together; choose a family to narrow the results. Libraries remain reachable when no IFC model is loaded.

Opening uses the artifact's native tool. It selects the exact saved entry; checks, scripts and Flows do not run, lenses do not apply colors, and profiles open management without activation. Opening a check, list or lens asks before handing off to its editor. Running or unfinished script/Flow work refuses the handoff so that its current draft is retained. Changed, removed or replaced entries require a fresh search rather than silently opening another artifact.

The source labels distinguish loading, unavailable and currently available libraries. Scripts, Flows, lists and lenses report entries available in this session because their native startup readers do not expose a durable-read status. A failed startup read does not prove that storage contains no saved artifacts. BCF search covers topics in the currently loaded project.

Discussing viewer evidence¶

Open the Assistant from the Coordinate rail, or choose Discuss with AI in the header of an analysis panel: Clash (including duplicate scans), Data validation (IDS, information rules or the manual checklist, whichever side is shown), Lens, BCF, Compare, Changes, Change sets, Zones, Placement, Schedule, Linked records, Layers, Lists, Charts, Cost, Measurements, 2D drawing, Point clouds, Load report, Properties (the current selection), Flow (the graph; the run bar discusses the last run), Script and Document. Opened directly, the Assistant asks what to discuss and lists every source, grouped as Checks, Coordination, Quantities, Model and Automation, with its live status (for example "155 findings", "Not run yet", "Needs two models"): Discuss attaches the source. Run clash detection uses the native check and attaches its result. Run is disabled while a check runs or until an IFC model has delivered flat or GPU-instanced geometry. Open takes you to tools that need input such as an IDS file or a comparison pair. Not discussable at the end of the list names the panels that have no analysis result (Appearance, Model, Extensions, Session, Sources, Presentation, Environment and the Assistant itself) and why. Discuss something else (the arrows in the evidence header) returns to that list; switching asks before it clears an unsaved discussion. The Assistant opens in the existing panel workspace. Its header line names the source, its state (Current, Out of date or Saved) and how many rows are attached; Evidence details holds the full caveats and captured JSON. Pick a suggested question or type your own, choose a model below the composer, and press Enter to send (Shift+Enter adds a line). Sending is the action that contacts the selected provider; opening the panel does not send evidence.

The assistant explains a frozen snapshot of native results. Native verdicts remain authoritative. Comparison evidence lists changed entries first and adds the impact on loaded analyses and the latest cross-revision reconciliation as separate row sections, with their limitations; incompatible runs are sent as a refusal with reasons and no findings, and a reconciliation whose runs predate later model edits is sent as stale, without counts or findings. Every source keeps native totals in its summary, separate from the included sample, with units stated per row or column; values of different kinds, units or currencies are never added together, and unknown provenance stays unknown. Validation includes IDS and information-rule results; a rules result computed before an edit is out of date like an IDS one. Manual checklist answers are human verdicts, not native results. Switching the Data validation panel between IDS, information rules and manual checks cancels an active discussion attached to that panel's evidence and marks its snapshot out of date; refresh the attached evidence before continuing. Other evidence sources keep their active discussion. Flow discussion includes graph structure, excluding node parameters, inputs, outputs and execution status. The last run is a separate source: its native diagnostics (status, per-node status, lane errors, error and warning messages, incoming edges, tracking counts, output previews, run warnings and artifact metadata); node parameters appear only for nodes that failed in that run (an error or lane errors; skipped nodes only follow an upstream failure) and the nodes feeding them, with script source withheld and credential-like text such as bearer tokens, URL passwords and token query values redacted. Failing nodes and their inputs come first, so a large run's budget cuts healthy detail rather than the failure. Script evidence never includes the script source, and document, BCF, Flow and point-cloud evidence never include images, snapshots or artifact bytes. Selection evidence covers effective attributes, property sets and quantities of up to 100 selected elements, including unsaved edits. Material assignments use the native Properties reader, including its occurrence-before-type precedence and session-created associations. Layer thicknesses carry metre units. Assignment and member counts remain explicit when bounded; source-free associations without resolved data are marked unverified, with no assumed type or values. Generic material property sets include model/material provenance, live native edits and display units, with bounded groups, sets and values. Source-free material property reads remain unverified; empty rows do not establish absence. Typed IFC2X3 scalar material-property subtypes remain outside the native generic-set reader. Selection classifications include native occurrence and type associations with current edits. References and ancestor paths are sampled at the displayed bounds, with full known counts; codes use ItemReference in IFC2X3 and Identification otherwise. Unknown systems and unreadable fields remain unknown. Source-free membership edits or absent membership inputs produce an unavailable status and null total; retained source-origin markers do not prove current assignments. Unresolved paths also have null totals. The adapter register lists each source's rows, freshness and limits.

Clash evidence uses native detection type (status) and severity plus discipline candidates from the existing IFC-type selectors. Walls can match both architectural and structural selectors; pipes can match both MEP and fire protection. Multiple candidates stay ambiguous, and unmatched types stay unknown. These hints do not establish project responsibility or change human review decisions. Omitted findings remain unclassified. BCF draft topics keep assignees empty until one is chosen from the selected server project's user list. Draft batches are created from a reviewed clash grouping workspace or from checked clashes (see BCF drafts and publication); the AI grouping preview below does not create drafts itself.

Ask for a clash grouping proposal, for example with the Propose clash groups for coordination review suggestion. A valid answer appears as a Clash grouping proposal card instead of raw JSON (Show JSON reveals it), and Review clash groups appears beneath it; choose Preview groups. Select a finding row to show that clash in the model, or the crosshair beside a group name to show the whole group; both use the Clash panel's native focus and never change review status. Focus from the preview frames the overlap box rather than the computed contact lines, and is unavailable once the preview is out of date. The complete answer must use the typed JSON contract with group names, explanations and captured evidence citations. The preview keeps native detection type/severity and discipline candidates visible, distinguishes AI rationale, and accounts for every finding in the native report as proposed or unclassified. Unknown, repeated, ambiguous or incomplete references refuse preview: the answer appears as a refused proposal with the reason and Ask for a corrected proposal, which pre-fills a specific correction request. Because free models often repeat citations across groups, Review clash groups also offers Preview with repeats removed: the first group keeps a repeated finding, unknown citations and emptied groups are dropped, and the preview states every adjustment. The AI answer itself is unchanged. Findings omitted from the AI sample remain unclassified; a truncated native run still cannot establish all clashes in the model. Nothing changes until you apply the reviewed groups (below); To draft BCF topics, apply the groups and use Draft BCF topics in Clash's Groups view; drafting directly from the preview is not available yet. Save the conversation to retain the answer; the review itself stays in the panel session.

Human-created groups now use native conflict-safe content storage. In Clash's Groups view, Grouping workspace selects the active membership partition. Conflicting backup imports stay in separate workspaces until you select one. Edits remain visible while saving, and the shared storage notice distinguishes saved changes from quota failures and cross-tab conflicts. Retry does not overwrite another tab's newer partition; restore requires an explicit decision to discard unsaved grouping drafts. Existing legacy memberships and unreadable originals are preserved in recovery. Backup export/import includes grouping workspaces, and missing findings in a narrower rerun retain their saved membership. The selected workspace is a session preference; grouping contents persist after reload.

Editing, applying and undoing AI clash groups¶

The preview is an editable review. Rename a group with the pencil beside its name. Tick findings, then use Move selected to to put them in another group, in New group (split) (which needs a name and lands beside the group it came from), or in Unclassified; a group whose last finding moves away disappears. Merge … into folds one group into another, which keeps its own name and rationale. Groups created during review carry no AI rationale. The counts above the groups recompute after every edit, and findings sent back to unclassified stay listed so they can be placed again. Edits stay in the review until you apply them.

Apply to a grouping workspace writes the reviewed groups into Clash's native grouping. The default target is a new workspace named AI proposal <date and time> (editable), so human groups are never overwritten silently. Choosing Active workspace shows what changes first: groups added, existing groups kept, and every finding that would leave an existing group (with source and destination group, and groups that would be emptied and removed). Apply stays disabled until you tick the confirmation for those moves. Members are stored exactly like human-created ones (occurrence plus durable review key), and the applied workspace becomes the active one in Clash's Groups view. Grouping never changes review decisions, severities, detection types or BCF topics.

Apply is one storage transaction that writes the workspace at the revision the preview was planned against together with a durable receipt (content kind clashGroupApplications, included in library backup export/import). If the workspace changed in the meantime (another tab, an import, or a human edit) or holds unsaved grouping edits, nothing is written and the preview re-plans against the current workspace. A changed clash run refuses apply. Undo apply on the receipt restores the complete previous partition (or removes a workspace the apply created) and refuses when the workspace has changed since apply, so later grouping work is never overwritten. Receipts for the active workspace are listed under AI grouping receipts in Clash's Groups view and keep their undo after reload, subject to the same revision check.

After a new detection run, each receipt compares its groups with the current findings through the same resolver as human groups (exact occurrence first, durable review key as fallback) and lists per group how many members are unchanged, matched by identity (the same element pair reported as a different occurrence) or gone, plus new ungrouped findings that were not in the run at apply. Gone members keep their membership and return if a later run finds them; nothing is reassigned silently.

Classifying all findings¶

The discussion sample holds at most 100 findings. Classify all findings (in Review clash groups while clash evidence is current) sends the complete native report instead, one chunk of up to 100 findings at a time (smaller when the rows are long) with chunk-local citations E1…E100, using the same grouping contract and output guidance. Before starting it shows the number of findings, requests and the maximum output tokens against the run's budget: one root budget per run of 30 requests and 122,880 output tokens (about 3,000 findings). A run that would exceed it cannot start; a request the budget refuses during the run is not sent and its chunk counts as failed. A progress bar shows how many chunks are done, Cancel classification stops the run (nothing more is sent), and the per-chunk list says which chunks were accepted, refused or not run.

Chunk answers are validated strictly against that chunk's rows. Only if you tick the consent option before starting does a chunk that repeats or invents citations use the existing repeats-removed normalization, and each adjusted chunk is listed with what was removed. Accepted chunks merge by group name: names equal after trimming, collapsing spaces and ignoring case form one group, the first chunk's spelling and rationale win, and members follow chunk order. The merged groups open in the same editable review, cited as C2/E14 (chunk 2, row 14). Every native finding is counted once as grouped, unclassified, in a failed chunk or not run; findings that share one occurrence identity with another finding cannot be grouped and are reported. A cancelled or failed run is labelled partial, applies only accepted chunks, and its receipt records it as partial. If the clash run changes during classification its answers are discarded.

Answers render headings, lists and tables. Select a citation such as E12 to see the captured row it refers to; for a current clash row, Show this clash in the model focuses it. While a free model is thinking, the waiting line shows elapsed seconds; requests stop after two minutes, keep your question, and suggest trying another model.

Snapshots include at most 100 rows. Large values can be shortened or omitted; the panel reports the number of included rows and any projection limits. Open Evidence details and inspect the JSON to see exactly which evidence accompanies the question. The model is instructed to cite rows as [E1], distinguish inference from native findings, and acknowledge missing provenance. A citation does not establish that the explanation is correct.

The same captured-evidence view appears in discussions, report drafts and Flow patch reviews. It shows the source, what its rows represent, sample/omission notices and capture time. Expand the model metadata to inspect the names, IDs and supplied fingerprints loaded at capture; that list does not establish an analysis's evaluated scope. Historical evidence stays historical after a model is replaced. The complete escaped JSON remains available for inspection.

If the source or model changes, sending is disabled. Refresh evidence and start a new conversation captures the current source and clears the previous discussion. A native result that predates an edit must first be rerun in its source panel. Return to source opens that panel.

The scripting chat also uses the shared request service. Each explicit prompt starts a task with at most 16 requests and 40,960 output tokens; Continue and automatic preflight/patch repairs reuse that task, including after the panel is reopened. Each request asks for at most 9,000 output tokens, clamped to the route ceiling and the task’s remainder, with a two-minute overall deadline. Failed and cancelled requests spend a request; unreported nonempty output spends the reserved ceiling. Provider SDK retries and the development proxy fallback cannot add attempts outside this budget. Receipts contain provider-reported usage only, and hosted quota metadata remains separate.

Only a completed response can finalize script edits, run a script automatically or offer an installation. A truncated, cancelled, timed-out or failed response rolls back its incremental edits and retains partial response text for inspection. Continue can resume a truncated response; an exhausted task refuses without sending another request. Send an explicit new prompt to start a new task. Clearing the conversation ends the task and prevents a delayed automatic repair from returning to it. Native manual Run and script preflight remain available.

Model selection and API keys use the existing scripting assistant controls. A request has an output budget and time limit. Incomplete answers are marked. Cancel stops the active request. Failed or cancelled questions stay in the composer for retry and do not consume conversation history.

Placement, keyboard and answer language¶

Use the Assistant header's Assistant placement menu to choose a split beside the source, the side dock, or a floating panel. Contextual Discuss with AI uses that preference. When the source is hidden, Back to … reopens it. On narrow screens, the Assistant uses the existing panel sheet; returning to the source and reopening the Assistant preserves captured evidence and an unsent question. Moving between hosts also keeps the draft.

Source selection, saved conversations and citation details move keyboard focus into their labelled region. Escape closes the focused region and returns focus to its opener. It leaves an active answer running. Completion is announced through a restrained live region; focus moves to an answer only if its previous target has disappeared.

The Answer language selector changes the conversation's generation language independently of the viewer's UI language. New conversations capture both; saved conversations keep them. An active request keeps its captured language. Element names, property values, IFC names, IDs and quoted evidence retain their original spelling.

Open Customize sidebar, preview Coordinator review, and choose Apply to bring coordination tools forward with Clash and BCF in the existing split. The preview lists missing reserved tools rather than inventing panels. Restore my layout returns to the preceding rail and dock arrangement. Applying the preset preserves detached panels, saved widths and all available tools.

Budgets and usage¶

Each answer has an output ceiling of 4,096 tokens (lower if the selected route allows less) and a two-minute limit. Every attached evidence snapshot also gets one conversation budget: 16 requests and 40,960 output tokens, shared by first questions, retries and Ask for a corrected proposal follow-ups. When it is used up, sending is refused with a message and nothing reaches the provider; Refresh evidence or switching source starts a new budget. Failed and cancelled requests count as requests. Output tokens are charged as the provider reports them; when the provider reports nothing, the full ceiling is charged, except for a request that returned no text at all.

Below each completed answer a small footer shows the provider-reported token counts and the elapsed time, for example 1,234 → 456 tokens · 24 s (input → output). When the provider did not report usage it says Usage not reported instead; the viewer never estimates tokens. Anthropic keys always report usage, and so do OpenAI keys. Free models through the hosted proxy report usage only when their upstream provider includes it in the stream. The recent request history stays in memory for the browser session. Saving a conversation retains each completed turn's own receipt: request identity, model, route, times, outcome, reported counts and the output protocol when it was reported. Receipts never contain prompts, answers, schemas, endpoint URLs or keys. Older saved turns without a receipt keep that metadata unknown; reopening never restores the global session history.

With a free model selected, the composer footer shows how many free requests remain (Free requests left: 44 of 50), checked when the panel opens and after each answer. If the check fails it reads unknown and the failure is logged in the browser console.

Explanations preserve native results. Unsaved conversations stay in the current browser session; closing the panel preserves them. Choose Saved conversations (the history button in the Assistant header), enter a name and choose Save conversation to keep completed turns after reload. Storage failures retain an exportable draft and expose retry or conflict controls. Library backup export/import includes saved assistant conversations.

Opening a saved conversation displays archived evidence and disables sending. Refresh captures current native results and starts a new conversation. Backup imports preserve originals when identities conflict and do not grant archived evidence permission to continue. It does not run scripts, change model data, execute Flow graphs or create BCF issues.

Later values written by an older tab to an assistant library's legacy key are preserved in native raw recovery without replaying them over current committed turns. The normal library recovery/export controls retain those originals. Content-kind identity, codecs and immutable-report policies are shared with Documents, validation and comparison storage.

For Flow, ask for a graph patch. A valid answer appears as a Flow patch proposal card with Review Flow changes beneath it; choose Review changes. A complete typed patch must pass native node, parameter, wiring and cycle validation. Inspect before/after JSON, tracking warnings and additional graph capabilities; script code the patch writes is listed verbatim under Script code this change sets, because it runs on the next Run. Then mark the review checkbox and choose Apply graph changes. Applying changes the current editable graph without executing it. Save the graph in Flow to retain the edits after reload; saving the conversation saves its transcript and evidence separately. Pending graph reviews and their undo receipts stay in the current browser session. Undo graph changes restores the reviewed predecessor while the graph and model remain unchanged. Changed or extension-owned graphs refuse apply; later edits or model changes refuse undo. Native Run and its preflight remain separate. Patch review currently accepts at most 50 operations, 100 nodes and 200 edges within its bounded JSON contract.

Creating and debugging Flow graphs¶

The Assistant can be opened from Flow with no graph open; the source picker shows No graph open · describe a new one. Describe the graph you need. A valid answer appears as a New Flow graph proposal; choose Review new graph. Every node type, parameter, port and port type is checked against the viewer's native node registry, then the same document, wiring, capability and cycle checks as a patch apply. The review lists the nodes in execution order with their inputs, the capabilities the graph declares, the nodes that edit the model when run, any script code verbatim under Script code this change sets, nodes this viewer cannot run, and the tracking keys under which the graph will own the elements it creates. Create and open graph saves a new graph in the Flow library and opens it. It never replaces an existing graph and never runs it, and it is refused while an unsaved graph is open. Remove created graph is available until the graph is edited or has recorded owned elements.

After a Run, choose Discuss run with AI in the Flow run bar and ask why it failed. The captured evidence contains the last run's native diagnostics, so a debug proposal is a Flow patch with a diagnosis that cites the failing nodes. Review refuses a diagnosis that cites a node that did not fail in the captured run, or a patch that changes the behaviour of neither the failing nodes nor the nodes feeding them (moving or relabelling a node does not count). The review card shows the native error messages of the cited nodes next to the assistant's explanation. A later Run makes the evidence out of date.

When a patch changes a node that creates elements (for example Add element), the review lists each affected tracked node: removed or re-keyed nodes delete their owned elements on the next Run, a changed tracking mode or input branch updates them, and the number of elements currently owned on the active model is read from the graph's tracking record. Renaming the graph or a node without an explicit tracking key re-keys it. Applying such a patch needs a second confirmation, I understand which tracked elements this change updates or removes on the next Run, and is refused if the owned elements changed after review.

After a graph is created or a patch is applied, Preflight checks the open graph exactly as the Flow panel's Run would start it: an active model, secrets, capabilities, node availability, files and selectors. Nothing is executed. Run the graph from the Flow panel when preflight passes. Other reviewed actions are subsequent layers of the viewer AI implementation plan.

Reviewed report drafts¶

After a completed answer about any analysis source (every source except Flow, whose evidence is a graph definition rather than a result), expand Review report draft. Choose the Narrative language (it defaults to the viewer language and does not change it), then either use the existing answer or choose Draft report with AI, which asks the selected model for a narrative plus typed claims in that language. Enter a name and choose Prepare report draft. Inspect the narrative, the checked claims and the captured evidence, then tick the review checkbox before saving or exporting. Unknown row citations, incomplete answers, contradicted claims and changed live evidence block saving. A saved conversation can produce an explicitly historical report.

Checked claims¶

A report answer may end with one fenced report.claims JSON block. Each claim is one statement with the rows it cites and the native values it asserts, each with a field path into the cited row (or summary) and an optional unit. A row named in the statement itself (such as E1 below) counts as a citation even when citations omits it, and so does one a reviewer writes into an edited claim:

{"version":1,"kind":"report.claims","language":"de","claims":[
  {"text":"E1 überlappt um 20 mm.","citations":["E1"],
   "facts":[{"citation":"E1","field":"distance","value":-20,"unit":"mm"}]}]}

Each claim is checked against the captured evidence and labelled:

Supported by data: every cited value equals the captured value. A claimed unit is converted only to a unit of the same dimension that the evidence itself declares. A JSON number is compared exactly (0 m does not match a 20 mm overlap, and -0.1 m does not match -0.14 m); only a value written as a string with its decimals, such as "-0.10", may round to that many decimals.
Unverifiable: the claim cites no values, the field is absent or omitted, or the evidence records no comparable unit. Treat it as interpretation.
Contradicted: a cited row does not exist, or a value or unit dimension differs. Saving stays blocked until you choose Edit claim or Remove claim. An edited claim keeps only its uncontradicted facts, is checked again and is marked as edited by you; in the saved document its text block counts as edited AI text, not AI-generated text. Any edit withdraws approval.

A supported claim means that the cited values match. It does not establish the conclusion. A block that is declared but invalid is refused rather than ignored. An answer without claims is drafted as before, with citation checks only.

Narrative blocks, refresh and languages¶

Every text block the generator writes records the exact text it wrote, so the document can tell AI-generated, human-edited and human-written blocks apart. A duplicated block, or a document built from this one as a workflow template, belongs to you and never carries the old evidence. A saved AI report shows its language, revision and claim states above the blocks in Documents. Refresh evidence recaptures the same native source, finds each cited row again by its native identity (not its E number), re-checks every claim and lists:

each claim's state before and after the refresh, with the number of changed and missing values;
a warning when the loaded models are not the ones the report was first drafted against (compared by source fingerprint with the original capture, so it persists across later refreshes);
every block you edited whose regenerated text would differ.

A native result that predates a model edit is refused: rerun it in its panel, then refresh.

Apply refresh regenerates untouched AI blocks. Changed and missing values are flagged in the claim captions (was …), with a notice after each affected claim and a refresh summary under the coverage block. Row citations in the narrative, in claim text and in the referenced-evidence note follow their native rows: a renumbered row reads E2 (cited as E1), a row that is gone reads E1 (no longer in the evidence). A capture holds at most 100 rows, so when the new capture is a sample, a cited row it does not include reads E1 (outside the captured sample); its claim becomes unverifiable rather than contradicted. Your edited blocks are kept unless you tick Replace my edit with the regenerated text; a claim you rewrote before saving stays your text. Blocks you deleted stay deleted, and blocks you wrote stay where you put them. Narrative prose outside the typed claims is not re-checked.

Native report-owned headings, coverage/status captions, appendix labels and refresh notices use the chosen report language, independently of the viewer language. All thirteen offered Latin-script report languages have a complete catalogue. Native IFC field names, values, citations and captured diagnostics stay verbatim; generic PDF page/footer decorations and source-native table labels keep their existing exporter language. Saved/imported reports with an unsupported language refuse regeneration explicitly rather than silently switching to English. Catalogue coverage and export tests are not native-speaker approval.

Documents print with the standard PDF fonts, which cover Windows-1252 text: German, French, Italian, Spanish, Dutch, Portuguese and the Nordic languages print exactly. Polish and Czech letters outside that set keep their base letter (ł as l, ř as r), and the document adds a notice that lists each substitution by code point. The preview shows the same printable text as the PDF. A narrative that is mostly unprintable, such as Japanese, is refused with a request to choose a Latin-script language.

The document includes the provider model, capture time, narrative language, actual included/native row counts and omission notices. The narrative keeps the answer's structure as document headings, paragraphs and lists; a typed clash proposal becomes one section per group with its cited findings. A current Data validation capture adds the live native results table, captioned as live. A current Compare capture adds an immutable comparison snapshot. The appendix lists the models at capture, the native summary and every included row on one readable line (for clash rows: element types, detection type, severity, distance, discipline candidates and GlobalIds). AI prose does not change native verdicts or certify compliance. Values that resemble model bindings remain literal captured text.

Save reviewed document uses the existing Documents library. If storage refuses the write, its native recovery/export controls retain the draft. Open the saved document to edit it, export document JSON or generate PDF using the normal Documents controls. Every preparation creates a new document and preserves earlier human edits. New AI reports embed the final answer's actual generation receipt; document JSON export/import and native evidence refresh preserve it even after the source conversation is deleted. Legacy reports without a receipt remain unknown. Actual granted request limits and request digests are not recorded yet; receipt retention does not establish model quality or independent claim verification.

Load diagnostics¶

Open Load report and choose Discuss with AI to attach the native per-model load reports. Rows represent model reports, not a list of every affected element. Native counters, approximation settings, load path and supplied affected-entity identities are retained; the original load time remains in each report. A source without captured diagnostics is explicitly unavailable and never counted as clean. Diagnostics describe the original load and do not validate later edits.

The same conversation Save/Open and reviewed document controls apply. Model replacement or edits invalidate an active discussion; saved evidence remains historical. Large federations and long diagnostics use the common bounded evidence projection with explicit omission notices.

Evidence distinguishes an unavailable native report from an attached report with no rows. Run the native check and refresh evidence when no report is available. An empty result applies only to the native check and its captured scope; it does not establish that the models are free of issues. Older saved snapshots that lack availability metadata remain explicitly unknown.

Reviewed model changes¶

Ask for corrections, for example with Prepare corrections for the failing requirements on Data validation. A valid answer appears as a Model change proposal with Review model changes beneath it. Each change addresses an element by GlobalId and states the value it expects to replace. The review resolves every element in the loaded models and compares that expected value with the model's current value, including unsaved edits. It marks each row as Ready, Already set, Value changed, Element not found, Element in several models, Not editable or Unsupported value. Only ready rows can be approved, and each one can be excluded.

Changes are applied with the normal edit tools, so Edit mode must be on; the card offers to turn it on. Apply writes the approved rows as one undo step per model. If any model refuses, the whole batch is reverted. If the model changed while you reviewed, nothing is applied and the statuses update. Supported changes are property values (set or delete), existing quantity values, and the Name, Description, ObjectType and Tag attributes. GlobalIds and geometry are not changed here.

Each applied batch leaves a receipt with the before and after values. Receipts are kept in the native library (and in backups), listed under Changes → Reviewed changes, and label their row in the Changes history. Undo these changes reverts the batch, or Ctrl+Z does. Undo refuses rather than overwrite newer edits to the same values. After a reload the receipt remains, but the edit history it refers to does not, so undo reports that.

The same review is the primary action of the Data Connector (Review as changes), the Bulk Property Editor and the IDS correction dialog; see Reviewed table, bulk and IDS corrections. If an IDS or information-validation report exists when a batch is applied, the receipt records that report's passed and failed counts per specification, and notes when the report was older than the model at that moment. Re-run validation on the receipt runs the same check again on the edited model, publishes the new report as the validation panel does, and lists every specification whose counts changed (for example failed 1 → 0, passed 3 → 4). The rerun refuses when a different check is loaded, when the loaded IDS report validates a model the batch did not edit, or when its rule set is no longer open. A rerun that finishes after the batch was undone is not recorded.

Table mappings¶

In the Data Connector, Suggest mapping sends the table's headers, its first five rows (cells clipped to 80 characters) and the property and quantity set names carried by up to 20 elements the table names by GlobalId to the AI model selected for the Assistant, as one request through the shared request service (its own root budget, with a usage receipt like every request). The answer must be a typed table.mapping: one identity column matched by GlobalId, Tag or Name, and for each data column an exact property (with a text, real, integer or boolean value type), an existing quantity, or the Name, Description, ObjectType or Tag attribute, each with an optional unit (mm, cm, m, in, ft, mm2, cm2, m2, ft2, mm3, cm3, m3, l, ft3). Anything else is refused with the reason.

The suggestion opens as an editable Suggested table mapping card. Unknown columns, a column mapped twice, two columns writing the same value, a written identity column and a unit on a non-numeric column block review. The card converts the first five rows live and shows each element's current and new value, so a wrong unit or column shows before anything else. Review as changes converts every row into the reviewed change batch described above. An assistant answer of kind table.mapping is recognised as a Table mapping proposal, but the Assistant has no table evidence source yet, so such a mapping can only be reviewed against rows in the Data Connector.

Reviewed native Room commands¶

A room.command answer offers Review rooms for one explicitly identified loaded model and storey. Prepare room preview awaits the native Room geometry and creates a detached draft. Receiving an answer, preparing it and attaching its snapshot write no IFC rooms. The card shows the complete affected population, native contours, names, areas, heights and all creations, updates and deletions.

Pick requires an explicit storey-local point. Auto approves all captured untaken faces together; declining the action leaves every room unchanged. Footprint creates one native storey outline and refuses overlap. Update names explicit current room GlobalIds and Names and shows unsupported/skipped rooms. Edit uses the native drag, split, remove or prune operation, with explicit coordinates and tolerance. Length units are m or mm, the frame is storey-local IFC Z-up, and minimum area is always square metres. All native settings must be supplied; missing settings, unavailable geometry and incomplete populations are refused.

Approval belongs to that prepared graph and layout. Source replacement, edits, Undo, cancellation, another preparation or a changed native layout require a new preparation. Closing or replacing the review cancels its approval ownership; an already running remesh may finish without executing the Room action. Apply Room action uses the native recorder and one native Undo group. Its receipt joins Changes → Reviewed changes. Undo this Room action uses that actual batch; after reload the receipt records the action but cannot recreate session Undo history. A receipt storage failure reports that the native action already succeeded and leaves native Undo available.

Before any IfcSpace has been materialized, a layout edit is session state only. The card states that IFC export does not preserve this retained layout; native Undo/Redo preserves it during the current session. This route adds no manual polygon creation, new-file builder, mixed synchronous authoring batch or sandbox script bridge.

Attach this room snapshot to the next message explicitly shares the complete prepared native candidates, occupancy and current room identities/geometry in SI metres. The provider receives evidence, never a commit capability or native handle. A plain send collects no Room snapshot. A stale, altered or unowned attachment is refused before network dispatch. Preparing a storey that exceeds 128 candidates or current rooms, 4,096 candidate contour vertices or the complete attachment size limit refuses the review rather than approving a sample.

Room names and optional ObjectType retain the exact supplied IFC text, including leading/trailing spaces and empty values. Numeric inputs remain bounded and use their declared length units; minArea always uses square metres.

Reviewed model authoring¶

Ask the assistant to create, copy, array, delete, move, turn, align, trim, extend, type, join or place elements, for example with Prepare a model authoring proposal for review: on Load diagnostics. A valid answer appears as a Model authoring proposal with Review model authoring beneath it. The proposal declares its length unit (m or mm). All coordinates are storey-local, with Z up, and rotation angles are degrees counter-clockwise from above. The canonical stair Direction parameter is radians. The card repeats this, and a missing unit, another frame or an implausible length (such as a 200 m wall thickness) is refused before review. Existing elements are named by GlobalId with the class and name the proposal expects them to have; elements created earlier in the same proposal are named by a short reference.

element.rotate may supply an explicit storey-local pivot: [x,y] in proposal units. With a pivot, copy the complete current nativePlacement expected pin from selected or attached evidence; its origins are SI metres and its EXPRESS IDs and direction axes stay verbatim. Without a pivot, rotation retains the native origin behavior. Current named placement references, positional precedence and retypes follow the same effective placement reader used by native transform planning. Unavailable placement or angle is unknown and must not be guessed.

element.align supplies one native reference, an explicit target population, a native mode (left, centre, right, top, middle or bottom) and complete reference/target nativePlacement pins. Review requires Prepare native Align geometry before approval. The canonical native worker supplies current bounds in the owning storey workplane; proposal JSON cannot supply boxes. The ghost is a bounds prism, not the element solid. Source/view edits, model relocation, a new mesh generation or cancelled preparation require fresh preparation. Earlier geometry operations in that model must be applied before preparing Align; native type-detachment metadata can precede Align without changing bounds. Planar pins keep canonical native root fields; a rotated hosted placement uses a complete native spatial frame (layout: "spatial", placement ID, SI origin and verbatim direction axes). Carried children follow their host and have no separate ghost; they retain their own current pin and receipt. Native same-storey, reference, target, carrier and joined-element refusals remain authoritative. Apply uses the existing native writer and grouped Undo.

Bare slab openings use hosted.create with kind: "opening", an existing slab host or an earlier slab ref, and native params: Position: [x, y], Width, Depth, and optional CutDepth. Position is in the host's local XY frame; all lengths use the proposal's declared metres or millimetres. An existing slab requires the complete current nativeSlabOpeningExpected shape, placement and storey snapshot (selection evidence uses metres). Unreadable or unsupported native snapshots are unavailable and cannot be applied. Earlier slab references bind to their current native draft. The existing native opening writer sets the default cut depth to slab thickness plus 0.1 m. It does not check footprint fit or overlap: review states this boundary. On supported upright storey frames, the preview shows the native cutter bounds, not the boolean result. Other placement frames or earlier transforms have an explicitly unavailable preview. Apply uses the canonical native void writer and one grouped Undo. Slab door/window fillings remain unsupported.

Existing door/window fillings and wall-hosted openings can use hosted.edit with a complete current native expected binding and position, plus one or more exact fields Offset, Sill, OverallWidth and OverallHeight. The expected state names model-local host/opening/filling and location-point EXPRESS IDs, the location, offset, sill, and available overall size (or null). Lengths use the proposal units. Bare openings support movement; sizing requires the native filling geometry. Fit, overlap, source and schema refusals use the existing native editor. Review discloses that its geometry preview shows opening bounds rather than a filling solid or detailed cut mesh. After earlier geometry operations in the same model, this single-source hosted preview is unavailable and review states that limitation. Apply preserves occurrence identity and joins the edits into one Undo transaction.

Slabs, roofs, plates and spaces can use the existing polygon footprint: Profile: "polygon", OuterCurve: [[x,y], ...], optional position (defaults to zero), and thickness or height. Each outline has 3–256 vertices; the proposal also bounds aggregate outline work and refuses oversized batches without discarding vertices. Beams and members can replace rectangular width/height with a native Profile section; columns replace width/depth. Sections cover Rectangle, I, L, T, U, C, Circle, RectangleHollow and CircleHollow, with their exact native PascalCase dimension attributes in the declared batch units. Positive optional fillet radii are preserved in the exported section; the review discloses that the preview shows sharp corners. Native acceptance does not certify polygon topology or engineering suitability; self-intersecting outlines are outside the validity guarantee.

curtainWall.create creates the native aggregate from explicit PascalCase Start, End, Height, and optional UGrid/VGrid, member profiles, panel thickness, edge members and identity fields. All dimensions and explicit grid offsets use the declared m/mm unit; integer bay counts remain dimensionless. Review shows the complete member and panel population, bounded to 1500 panels per wall and 5000 parts per proposal. One native transaction writes, re-meshes and undoes every owned part. The existing command preview shows matching rectangular member sections and the native 0.024 m panel thickness; other native sections or thicknesses, unreadable/nonplanar frames and 2D parent placements have an explicit unavailable preview. Supported saved and current edited 3D translated/rotated XY storey frames retain their preview through the canonical current-frame reader; live changes to placement Z retain an explicit elevation/RTC preview limitation; native Apply always follows the current source placement. No curved system or engineering suitability is inferred.

stair.create and railing.create use the native PascalCase builder parameters and the declared length unit. Stairs create a root and one aggregated flight; railings use an explicit storey-local polyline. stair.resize accepts the native selected nativeStairExpected snapshot verbatim and a new dimension patch in the batch unit. stair.delete removes a uniquely owned single-flight pair, and railing.delete removes one railing. stair.replace/railing.replace replace only this family and create a new product record, with a fresh GlobalId by default or an explicitly supplied GlobalId. Native ownership, host, source and schema refusals remain authoritative. A proposal is bounded to 5000 native stair steps/railing posts in total. Review reuses command ghosts: solid stair steps omit a waist and square rail/post sections approximate the native round sections. Custom diameters, vertical rail segments and existing stair edit/removal bodies may have no preview; the card says so. Unsupported imported graphs, landings and multi-flight geometry are not inferred.

Existing walls, flat slabs/roofs/plates and straight beams/columns/members can be resized with element.resize: state the existing target, its full expected native dimensions and a size patch. Wall height/thickness, slab thickness, and linear length/rectangular cross-section use the same editor as the Model inspector and push/pull tool. A linear length can keep its start or end fixed. Wall/slab thickness updates only that occurrence’s material layers, leaving its shared type and other occurrences unchanged. element.profile replaces an existing centred linear section using its expected current Profile and the new native section fields. All dimension values use the batch’s declared units; the expected snapshot describes positive existing native dimensions, including elements smaller than new-size proposal limits. Missing current dimensions must be provided rather than guessed. Review shows the current and proposed fields and reports any geometry preview limitation before Apply. Native fit, ownership and source-layout refusals remain authoritative.

Reviewed Trim/Extend proposals can target native walls, beams and members. Select the elements and attach their current evidence so the provider can use nativeTrimExtendExpected verbatim. Explicit clicks and line boundaries use the proposal’s declared metres or millimetres; the native expected snapshot retains its source representation. Review shows the native planned end and length, source conflicts, and preview limits. Native joins, hosted refits and refusal to cut through a filling remain authoritative. A boundary created earlier in the proposal must also be approved. A boundary created or edited earlier in the proposal has no independent target ghost; review discloses this limitation while the whole native batch validates the current binding. Genuine same-model duplicate GUIDs refuse both target and boundary resolution. Targets and existing wall boundaries must have a native parent plan frame matching the declared storey coordinates. Translated or turned nested parents refuse before Apply; direct storey parents, identity nested plan frames and pure vertical offsets retain native support, including storeys with actual world translation or rotation. Slabs, roofs, plates and spaces can use the existing polygon footprint: Profile: "polygon", OuterCurve: [[x,y], ...], optional position (defaults to zero), and thickness or height. Each outline has 3–256 vertices; the proposal also bounds aggregate outline work and refuses oversized batches without discarding vertices. Beams and members can replace rectangular width/height with a native Profile section; columns replace width/depth. Sections cover Rectangle, I, L, T, U, C, Circle, RectangleHollow and CircleHollow, with their exact native PascalCase dimension attributes in the declared batch units. Positive optional fillet radii are preserved in the exported section; the review discloses that the preview shows sharp corners. Native acceptance does not certify polygon topology or engineering suitability; self-intersecting outlines are outside the validity guarantee.

Supported operations:

create walls, slabs, roofs, plates, columns, beams, members and spaces on a storey;
place a door, window or opening in a wall;
join two walls;
trim or extend native walls, beams and members to an explicit line or wall boundary;
assign an existing or new type, or detach an occurrence from its current type;
assign an existing or new material, or reviewed ordered material layers to a wall, slab, roof or plate;
add an explicitly supplied classification system and code to an existing element;
copy an element, optionally to another storey, with an explicit offset and turn;
make a linear or polar array of an element;
move an element horizontally;
turn an element about its own origin;
delete a single element.

Classification additions use exact Classification.Name and Reference.Identification (Reference.ItemReference for IFC2X3), with an optional Reference.Name. The user supplies the system and code; the assistant does not infer them. Native Add reuses a system with that current Name or creates one, preserves existing classifications, and writes one grouped Undo/Redo step. The review states that this metadata change has no geometry preview. Unknown fields, STEP tokens, incompatible reference spellings, stale target identities and changed sources are refused before writing.

Type detachment requires the current type’s exact GlobalId and Name. Rich selection evidence and explicit selection attachments include this binding as nativeType.expected, including unsaved type creation and renaming; untyped and unavailable bindings are explicit. It removes that occurrence from its type relationship, preserving the type object and its other occurrences; an empty relationship is removed. The review shows the type change and explicitly marks the resulting geometry preview unavailable. Apply uses the same native writer as the Model inspector, with one grouped Undo/Redo. Type detachment requires the current type’s exact GlobalId and Name. Both occurrence and type identities must be unique within their owning model. The native writer rechecks the binding on the intermediate batch state; an earlier assignment cannot authorize detaching a different type. Rich selection evidence and explicit selection attachments include this binding as nativeType.expected, including unsaved type creation and renaming; untyped and unavailable bindings are explicit. It removes that occurrence from its type relationship, preserving the type object and its other occurrences; an empty relationship is removed. The review shows the type change and explicitly marks the resulting geometry preview unavailable. Apply uses the same native writer as the Model inspector, with one grouped Undo/Redo.

Material-layer proposals use material.layers on an existing occurrence, with explicit scope: "element" or "type". Rich selection and explicit attachments supply nativeLayers: SI metre values, full assignment/layer/peer counts, and a complete expected snapshot when available. Copy every expected field, including the separate type layer population beneath any occurrence override; convert all layer thicknesses and wall dimensions if using batch millimetres. Existing materials use their source's modelId, native expressId and exact current Name; IfcMaterial has no GlobalId. New materials require an explicit {create:{Name}}, and empty layers use Material: null. Unknown provenance and truncated populations never authorize a write. Missing or wrong EXPRESS targets, unreadable required thickness and invalid material references in current layer populations are unavailable, never complete empty or invented thickness facts.

An occurrence wall assignment changes its native body thickness to the layer total, retaining the inspector's wall-layout and hosted-fit refusals. The native draft supplies the wall ghost when available; the card discloses unavailable or outer-body-only previews. Type assignments show the full current type peer population, and slab/roof/plate assignments preserve occurrence dimensions; these have no changed-body preview. Proposals are limited to 32 positive layers and a total of 5 m. Applying requires explicit approval and uses the inspector's same atomic constructor with grouped Undo/Redo. Reloading or editing source/overlay invalidates an old review. This route does not edit unassigned defaults or establish engineering suitability.

Copy proposals use element.copy with a target, a unique new ref and offset: [dx,dy,dz] in the declared unit. A turn needs angleDeg and an explicit pivot: [x,y]. Optional storey: {globalId, modelId?} selects a target storey in the same model; optional from: [x,y] pins the current source placement within 1 mm. Arrays use element.array, target, mode, count including the original, and refs naming every new root. Linear arrays take anchor and cursor, optional distance for spacing, and fit: true to distribute across a total span. Polar arrays take an anchor and optional angleDeg (360 by default); full turns avoid a coincident final copy. Each operation copies one root; multiple roots use multiple reviewed operations in the same native transaction. Native hosted openings, fillings and assembly parts travel with their root. At most 200 copy roots are proposed across a batch.

Copy an existing source before editing it in the same proposal, so the preview uses the same geometry as the copy. New copy references can feed later copies or type/material assignments; wall copies also support later hosted and join operations. Copy ghosts use available native source meshes and show the first 64 placements per array. A source without loaded meshes, or an earlier draft creation, has no copy ghost; hosted cut ghosts on copied draft walls are also unavailable; the card states this before applying. Reloading a source, replacing or editing its overlay (including native skip-history writes) or changing the federation invalidates an old copy preview, even when names and mutation versions match.

The review resolves every element, storey, type and material against the loaded models, including unsaved edits. It then runs the viewer's own builders on a draft that is never saved, so the model itself decides what it would refuse. Each row shows what the element is now and what it becomes. Its status is Ready, Value changed (the element's class, name, type, material, position or angle is not what the proposal expected), Element not found, Element in several models, Not editable, Unsupported value, Refused by the model (with the builder's reason), Already set or Needs another row. Excluding a new wall also excludes the door placed in it. Preview in 3D draws the new, copied, moved, turned and deleted elements as ghosts; nothing is written until you apply.

Edit mode must be on. Apply writes the approved rows with the Model workspace's own tools as one undo step per model and re-meshes what changed; if any model refuses, the whole batch is reverted. The receipt joins the reviewed changes under Changes → Reviewed changes, and Undo these changes or Ctrl+Z reverts it. Deleting a wall that hosts openings, deleting assemblies, vertical moves, storey changes, unsupported stair graphs and other unsupported operations are refused; use the Model workspace for them. The assistant is told to ask for missing dimensions instead of inventing them. Current evidence sources do not list storeys, so a creation needs the storey GlobalId from you. Native Split expected geometry and placement use the current named and positional IFC placement references, including ObjectPlacement, RelativePlacement, PlacementRelTo and axis directions. Positional edits take precedence for the same field. An old expected origin, basis or parent is refused after an edit; deleted leaves and cyclic parent chains make the placement unavailable. This preserves native layout restrictions and does not infer geometry from unreadable source data.

The operation matrix lists each operation's native path, preview, undo and export evidence.

Showing results in the model¶

Ask the Assistant to show something, for example with Show me the failing elements on Data validation, Show me the elements of the most severe clashes on Clash or Colour the changed elements by change type on Compare. A valid answer appears as a Scene action proposal card, and Show in the model beneath it lists what would happen. Nothing in the view changes until you choose Apply.

A proposal can select, isolate, hide, colour, frame, cut a section or place the camera. Elements are named by GlobalId (optionally restricted to one loaded model) or by an evidence citation such as E3. The review resolves each one against the loaded models and shows how many elements every action reaches and how many targets were not found, are ambiguous (the same GlobalId in several models without a model named), or cite evidence that is no longer current. Citations only resolve while the attached evidence is current; GlobalIds do not depend on it. Colour groups use a fixed palette (red, orange, yellow, green, teal, blue, purple, grey); an element named by two groups keeps the first colour, and the review says how many did. An isolation leaves elements you hid hidden, and the review counts them.

Section planes, section boxes and camera positions must state their units (m, cm, mm, ft or in) and are IFC world coordinates with Z up, the same frame BCF viewpoints use. They are converted through the georeferenced render frame of the loaded models and refused when they fall outside the loaded geometry (with a margin of 10% of its size, at least 1 m; a camera eye may stand up to three model diagonals away). A plane cuts away the side its normal points to; a box keeps what is inside it. A refused action is listed with its reason, and Apply applies the remaining ready actions. An action the 3D view cannot carry out at that moment (framing or a camera move while no viewport is mounted) is reported as not applied.

Applying first records the view you had: selection, isolation (including which tool owned it, such as a clash or validation focus), the elements it hides, colours, the section cut and the camera. Restore previous view stays offered below the conversation until you use it, even after later questions. Restore puts back only what the Assistant still controls: if you changed the selection, isolation, colours or section since, that part keeps your change and the restore message names it. Elements the Assistant hid are shown again unless you had hidden them before. The camera always returns to where it was, unless the 3D view is not ready, which the restore message says. If a model was added, removed, reloaded or replaced since, nothing is restored, even when the replacement has the same model ID. Returning to an earlier source does not revive its restore point. Renaming a loaded model or collapsing its tree keeps the restore point. Applying another proposal first restores the previous one, camera included; its card says so before you apply and reports what was restored.

When you discuss Properties, selected-element evidence includes occurrence properties and a separate inherited type definition with its model and type GlobalId. Both include unsaved edits and use the panel's display units. A same-named occurrence property takes precedence for that occurrence; the type definition remains visible separately. Each section includes at most 16 sets and 32 values per set for small selections, or 6 sets and 12 values for larger selections, with full counts recorded. Material assignments and generic material property sets use the same native reader as the Properties panel, including occurrence/type precedence and unsaved edits. Material layers state thickness in metres; property values use your display units. Groups, sets, values and collection members are bounded with full counts. Public typed edits retain their IFC data types before export. Non-plain session material assignments that the native overlay cannot decode are explicitly unverified; their property totals remain unknown. When source bytes are unavailable, missing material values and property totals are marked unknown; they are not evidence that no material properties exist. Selected documents include the native reference/information metadata and current session associations, including document location and revision. Source-free originals carry unverified source-origin markers; edited or missing membership inputs make the total unknown. Document samples and text are bounded independently. Classifications and relationships use the native effective readers described below.

For native editable walls, slabs, beams, columns and members, selected-element evidence also includes the current dimensions and supported Profile section in metres, independently of display units and Qto properties. The same native readers used by the model inspector supply the complete current values, including optional zero values and radii. Unsupported geometry or unavailable model length units remain unknown. These snapshots provide the expected current state for review; they do not grant permission to edit or establish engineering suitability.

Attaching the selection or the view¶

The composer has Attach selection and Attach view. Selecting elements or moving the camera attaches nothing by itself. Attach selection adds the selected elements' GlobalIds, models, IFC classes, current Names and available native dimensions/Profile sections (at most 100) to your next message only; the Assistant can then target them. Attach view captures the 3D view as an image for your next message only, and only for models that accept images; with a text-only model it explains why instead. An attached selection retains the population you explicitly captured. If its model is replaced or edited before sending, recapture it; refreshing another evidence source does not refresh that attachment. Attachments are cleared after sending and screenshots are not saved with the conversation, which records only that one was attached. Distances and geometry facts still come from native tools, not from the image.

Reviewed IDS, rule and report drafts¶

With Load report or Data validation attached, the assistant can draft checks: Draft IDS specifications for review:, Draft information rules (uniqueness, counts, comparisons) for review: and Outline a validation report with live result tables start such requests. A valid answer appears as an IDS draft, Information rules draft or Report outline card with its specification, rule or section count and how many requirements could not be checked. A review card appears beneath it. A malformed answer appears as a refused proposal with the parser's reason (for example a missing applicability, a unit on a non-measure property or a specification the current report does not contain) and Ask for a corrected proposal.

IDS drafts (ids.specifications) use the IDS 1.0 facets with their native field names: entity, attribute, property (with dataType), classification, material and partOf, each with simple values, enumerations, XSD patterns or numeric bounds and required, optional or prohibited cardinality. A property value may declare mm, cm, m, mm2, cm2, m2, mm3, cm3 or m3 together with IFCLENGTHMEASURE, IFCPOSITIVELENGTHMEASURE, IFCAREAMEASURE or IFCVOLUMEMEASURE; it is converted to the SI value IDS stores (2400 mm is written as 2.4). The review shows each conversion, for example Authored in mm, stored in SI: 2400 mm → 2.4 m, and labels a measure value with its SI unit (Required value (m)), so an edited value is in metres, square metres or cubic metres. Other units are refused, because the validator cannot convert them. The draft is written by the same IDS writer as Export as IDS and read back by the native IDS parser, so the card shows exactly what will be saved. Review IDS draft runs the native IDS audit (XSD shape, IFC classes, property sets and data types, restriction coherence) and lists its issues; audit errors block saving and export, and so does an audit that could not run. You can rename a specification, change the cardinality of the specification or of a requirement, and edit a required simple value. Every edit re-runs the audit.

Dry run on loaded models validates the draft with the Data validation panel's own IDS engine, once per loaded model, without publishing a report, recolouring the scene or saving anything. It needs at least one loaded model with parsed data. For each specification it shows the applicable, passed and failed counts summed over the models, any cardinality failure per model, specifications nothing in the loaded models applies to, and up to five failing elements with the requirement that failed; the crosshair selects and frames an element in the model. Save to IDS library is enabled only after a clean audit and a dry run of the exact current draft on unchanged models. An edit or a model change marks the dry run as out of date. Saving adds a new entry to the Data validation IDS library without switching to it: the active IDS and the result shown in Data validation, which the conversation may be about, stay as they are. Open in Data validation makes it the active IDS, where the normal Run Validation, results and BCF tools apply. As with choosing any other library entry, that clears the result shown, so use Save report there first if you need it. Export .ids downloads the audited draft. The viewer has no IDS editor; to edit further, export the file or convert it with Import IDS as rules.

Information rules drafts (rules.proposal) carry a native .rules.json rule set: per-element checks, plus unique, aggregate, compare and unit requirements, which IDS cannot express. The rule set is read by the native rule-set parser. Any field that parser would ignore is refused, as are targets, duplicate ids and duplicate names. Review information rules shows each rule's applicability and requirement and lets you rename it or change its severity. Dry run on loaded models runs the native rule engine over every loaded model, with the same counts and failing samples, plus failing uniqueness or aggregate sets. Save as rule set creates a new information rule set without activating it. Open in the rule editor makes it active and opens it in the Information validation editor, which likewise clears the shown result.

Report outlines (document.outline) consist of sections built from native document blocks: text, a validation table, a validation summary or a page break. A validation table is bound to the live validation report, optionally to one specification or rule by its id. It is never filled with values from the answer: the card shows how many rows it would print now, and the saved document prints the rows of whichever report is current when it is shown or printed. A table bound to a specification the current report lacks is refused. Report specification ids are positional (spec-1), so another run can give the same id to a different specification: a table bound to a specification is prepared only against the validation report the conversation was drafted from. After another validation run, or in a conversation that did not start from Data validation (including a reopened one), such a table shows that it was drafted from a different report and cannot be saved; discuss the current report and ask again. Tables over every check are not affected. A validation summary is the native report snapshot taken when the outline is prepared, and it needs a current report. Text stays literal (no model bindings), and the document states that it is an unverified AI draft. Save as new document adds it to the Documents library; Open in Documents opens it for native editing and PDF.

Unsupported requirements. A requirement no facet or rule can check (geometry such as clearances or opening direction, acoustic or daylight performance, judgement, documents) must be listed under unsupported with the reason, and the answer is told never to drop one. Each review card lists them under Not checkable natively. They are saved with the draft: in the IDS document description (and in the instructions of the specification they relate to), in the rule set's description (and the related rule's), or as a closing Not covered by this report section of the document. They remain manual checks; nothing marks them as passed.

Limits: a draft holds at most 50 specifications, 100 rules or 20 sections. Saving always creates a new library entry; revising an existing IDS, rule set or document in place is not offered. Dry runs follow the panel's per-model IDS behaviour, so an IDS cardinality is judged per model. The guidance names property sets and classes only from you or the evidence, and the native audit and dry run are what show whether they exist. Whether a free model drafts useful checks varies by model.

Filters, lists, lenses and charts¶

Ask the assistant to find elements or to build a list, lens or chart, for example with Build a list of walls with their area and fire rating or Chart element counts by IFC class on Load diagnostics. A valid answer appears as a Filter proposal, List proposal, Lens proposal or Chart proposal, with Review against the loaded models beneath it. Each proposal carries the native definition of its tool: Rules filter groups, a list definition, a lens, or a native chart. Chart proposals can count model elements, clash findings, BCF topics, schedule tasks, recorded IDS/information-rule results or revision-comparison rows. Analysis charts review the entire recorded analysis; a visible or basket scope is refused for those sources. Missing or known out-of-date analyses and invented columns are refused, while a completed analysis with zero rows is a valid empty chart. Numeric sums use the native column unit and show the measured-row denominator; timelines require a native date column. The review distinguishes recorded rows from elements, reports rows without a loaded-element link, and rechecks its source before saving. A rerun, topic edit, regrouping or schedule-cursor change withdraws the older review and computes new numbers. A class names its subclasses as well, as in the search field: IfcWall reaches IfcWallStandardCase. Numeric property and quantity comparisons, an equality with a number included, are SI (m, m², m³), whatever unit the file stores, and they read unsaved edits as lists and charts do. By default, filters, lists and lenses run over every loaded model. "This model" is a native model rule: the assistant names the model, and the review turns the name into the model's durable identity, the same value the Filter tab's model chips hold, so a saved filter still matches after a reload. A model name that is not exactly one loaded model is refused with the loaded names. A filter, list or lens can instead capture the selected or visible population when its review starts. That fixed population intersects its normal criteria; changing selection or visibility later does not widen it. Charts retain their own native dashboard scope (all, visible or basket). A request these rules cannot express, such as a relation between two elements or a distance, gets an explanation and the closest supported proposal, never a broader filter. The assistant receives a bounded digest of the class, property and quantity names the loaded models carry, counted locally per element. The index itself stays in the viewer. It is rebuilt in the background, in small steps, after a load, an unload or an edit. If the models cannot be read, the request still goes out without the digest, and the review card says why it cannot check the proposal.

The native Filter, List and Lens editors show the captured element and file counts. Capture selected or Capture visible replaces that population explicitly; Clear capture returns to the ordinary criteria over loaded files. Save and reopening retain the capture, including ordinary library persistence and Lens JSON export/import. The original source files and captured elements must still be available: missing, ambiguous or replaced files, deleted members and a new authored element reusing an old ID refuse instead of running a broader artifact. Reloading unchanged source files can resolve new runtime model IDs. Authored members also require their original authored record identity; recovery that loses it requires a fresh capture. A capture supports at most 20,000 elements from 1,024 files. Whole-library backups include these native libraries and their captures; imports preserve conflicting local edits as independent copies. A refused artifact save stays pending in this tab: keep the backup file and use Retry all libraries before closing it. Further imports and whole-library downloads are refused until that pending artifact import is saved; original-file recovery remains available. Native List and Lens IDs remain independent even when names and criteria match, and conflicting local edits are preserved as deterministic source-ID collision copies with matching collision names. Unchanged identity-and-content retries reuse those copies; renamed or edited local copies remain independent. Filters identify presets by their native trimmed, case-insensitive name and complete criteria or capture. An imported-looking name does not establish provenance: repeating a conflicting Filter import may allocate another copy because the native Filter format has no separate identity or import lineage.

Explicit classification system names are checked against the systems declared or referenced by the loaded models. An unknown name waits for your choice of an exact discovered name; an invented system cannot turn “classification missing” into a match for every element. Omitted or empty system names retain the native any-system meaning. Declared systems remain available even when no element has an assigned code. Native preview and discovery read current edits to classification definitions, references, associations and type relationships. Source-empty server transports cannot reconstruct edited source memberships; classification-dependent proposals explain that missing-source limit and require loading the original IFC.

Every property and quantity the proposal names is checked against the loaded models first. A name counts as present only when an element carries it exactly: same set name, same property name, same case. Otherwise the card asks you to pick from fields the models really carry, with the number of elements and models carrying each. Candidates are ranked by name similarity and then by how often they occur. A case-only or spacing-only difference is still offered as a pick, never applied silently. You can also ask the assistant again. Nothing runs until every name is resolved.

The proposal then runs through the tool's own engine against the loaded models. Filters use the shared filter evaluator, lists the Lists runner and unit resolver, lenses the Lens engine (first matching rule wins), and charts the chart dataset and aggregation. The card shows the matched elements per model and sample rows. Every sum states its unit and denominator, for example Qto_WallBaseQuantities.NetSideArea: 43.291 m², summed over 4 of 8 rows. 4 rows have no value and are not counted. For lenses it shows the legend and how many loaded elements stay uncoloured; an element with several materials is listed under each in the legend but counted once. For charts it shows the categories and how many elements have no value for the dimension; those are not counted again in a sum's denominator, which covers the charted rows. An empty result is shown as zero per model. When the models, their edits, or what a visible or basket chart counts change, the numbers are recomputed.

Save writes the artifact into its native library: saved filters, Lists, Lenses, or a dashboard. A chart joins the active dashboard only if its scope matches; otherwise it gets a new dashboard in the reviewed scope. Names never overwrite an existing entry (Walls (2)), and saving the same review twice is refused. Saved items are ordinary library entries you can edit or delete. These library types have no field for the assistant answer they came from, so that origin is not recorded. Open opens the saved item in the list builder, native lens or auto-color editor, native chart editor on its dashboard, or search Filter tab. Lens and chart editors load the current saved item, so later human edits remain visible. Their normal Save and Cancel controls apply. Deleting the opened saved item closes its editor; switching away from a chart’s owning dashboard closes that chart editor, so Save cannot recreate the deleted item or move it into another dashboard. Open in Filter without saving loads a filter proposal into the Filter tab. The Filter tab runs it there, and its own buttons select, isolate, export or turn the result into a list. Saving or opening never selects, isolates, hides or colours anything; a saved lens is applied from the Lens panel.

Linked-records assistance¶

Choose Discuss with AI in Linked records (or pick it in the Assistant) to ask about the loaded records, the last query results and any texts you attach. Under Assistant texts and saved reviews in the Linked records panel, paste a specification or attach the current records document. Attaching is your consent to include its passages in the evidence; each text becomes S1, S2 and so on, stays in this browser session and is cut into passages of at most 500 characters with exact character offsets. The evidence never contains endpoint addresses, hostname or local-HTTP grants, relay ids or credentials; it says only whether a grant exists.

Four typed answers appear as a native review card. Nothing runs, saves or changes the model until you act.

Query. The card shows the SPARQL, the expected columns and the lint result. Only SELECT and CONSTRUCT with named columns and an outer LIMIT of at most 5000 can run; SERVICE, FROM, updates and a column list that differs from the proposal are refused. Run query is enabled only while the Linked records panel holds an endpoint grant you exercised there (a load or Query selected). The card lists that endpoint, hostname, local-HTTP grant, relay and whether a credential is supplied, never the credential. The panel keeps the grant only while it stays open, so float it beside the Assistant (Sidebar options → Float current panel) before you load records; docking the Assistant into the same place closes it and withdraws the grant. Changing the source, hostname, relay, credential or mode in the panel, or closing it, also withdraws the grant and cancels a running query. Rows are resolved against the model revision in force at that moment; when the revision association or the loaded models change, the result is labelled Historical and is no longer resolved against the current models.
Mapping. Each IFC class or property to ontology term mapping shows its confidence, how many elements of that class the revision's model holds, whether the term is in the profile, an external IRI or unknown, and its quoted sources. A mapping can be approved only when its revision is associated with a loaded model, none of its terms is unknown (a profile key, or a well-formed external IRI that the card flags as outside the current profile) and every quoted source verifies. Save stores the approved mappings with the revision pin in the native library (reload, backup, import); the Linked records panel marks a saved mapping Historical once that revision context changes.
Projection. Each row is previewed by the existing projection service, which shows the target element, the old and new value, the unit and the conflict policy, or its refusal verbatim. Only approved rows are applied, with Edit mode on, as one undo step.
Requirements. Each extracted requirement carries the exact span it came from. The card checks every span against the passages the assistant was shown: Quote matches only when the text at those offsets equals the quote character for character, Quote differs (it shows what the source says there) or Not in captured text. Ambiguous, conditional or unsupported statements stay in the list with a reason instead of being dropped. Save keeps the requirements and each span's verification result.

The records in the Linked records panel stay independent of the IFC model: reviewing, saving a mapping or extracting requirements never rewrites them, and a record keeps its own source and revision even when it resolves to an element. See the linked-records assistance notes for the contract and its tests.

Review workspace¶

The Review panel (Coordinate group, command palette: Review) joins findings from every analysis into coordination cards, so one element pair that a clash run, a validation, a comparison and a BCF topic all mention reads as one item instead of four.

Cards. Findings share a card only when they name exactly the same set of elements and each element resolves to exactly one loaded model (model file name plus GlobalId). An element that exists in two loaded models, is missing, or that its own analysis could not identify is never merged: its finding keeps a card of its own, marked as not validated. A finding on one element of a pair is a separate card, linked as related.
Native statuses stay native. Each finding shows its analysis status verbatim (clash class, IDS outcome, change state, BCF status). Your own decision (Open, In progress, Resolved, Accepted, Dismissed, with a comment) is stored separately in your library, saved and backed up like other content, and never changes a clash, a validation result or a BCF topic.
Historical versus current. Saved evidence (the clash revision baseline, saved comparisons) is labelled Historical. A historical finding is only called No longer observed when a complete, current run of the same analysis looked again; a capped, stale, partial or differently scoped run leaves it not re-checked. Even then it is a candidate for you to confirm, never a resolution.
Saved grouping receipts. Reviewed clash-group applications appear as historical coordination records, preserving their applied or undone status, original workspace revision and saved group membership. Native continuity names unchanged, reidentified and gone members. Missing, ambiguous or stale run evidence remains unvalidated, and an unknown population stays unknown. Grouping a finding never proves that the clash was resolved. Open original selects its saved workspace when available and shows the exact application receipt in Clash, including an undone application. Switching workspaces ends that original-focus context.
Reconciled analysis runs. A compatible clash or validation run reconciliation from Compare contributes its native new, persisting, changed, resolved and not-evaluated findings. Resolved evidence remains historical and is only a candidate when the current re-examination is complete. Stale, partial, excluded or missing source evidence cannot confirm resolution.
Counts. Unique validated elements, current findings, historical findings, cards and BCF topics are counted separately and are never derived from each other.
Original evidence. Open original selects the live clash, topic or failed element in its native panel. A historical clash opens the saved baseline finding in Clash revision comparison, including its original model names, GlobalIds, status and saved time. If that baseline has been replaced or no longer contains the exact finding, Review reports that the original evidence is unavailable. For a reconciled analysis finding, Open original selects the captured run pair in Compare and focuses its exact row, including a persisting row normally omitted from the bounded list. Replaced, stale or unavailable originals refuse. Select in 3D selects the validated elements.
Actions. Draft BCF topics creates one draft topic per card (a clash card carries its live clash as the exact member); cards that already have a topic or only historical evidence are left out and listed. Nothing is published from here. Add to report creates a new document with literal text for the chosen cards, their decisions and the totals. Ask about this card attaches that one card to the assistant.

Saved IDS and information-validation reports also contribute bounded historical failed/warning element evidence: original GlobalIds, model names, check severity and native requirement details. Older count-only reports contribute no invented element rows. Historical absence stays not evaluated; it cannot confirm resolution. Open original reaches the exact saved failure row in Validation history and never installs old entity identifiers in the current scene. Reconciling runs across revisions uses each analysis' own comparison.

Task recipes and project preferences¶

Task recipes walks through native checks, evidence capture, questions and proposal review. Starting a recipe shows its step card; Do this step opens the native tool or attaches evidence and prefills a question. Sending a request, running a check, applying changes and publishing BCF topics remain separate native actions. Availability names the models, results, saved graphs or connections a step needs. Replacing an unsent question requires confirmation. Saved graph shortcuts wait until the current graph is saved and no run is active.

Saved recipes can be exported and imported as JSON together with the native Flow graphs they reference. Import assigns fresh graph identities so a missing graph never attaches to an unrelated existing graph with the same ID. Import reports refused graph imports and unsaved library writes; a partially imported recipe does not count as a complete import. Library backup waits for saved recipes and preferences to finish loading. The portable bundle carries prompts and parameters, not credentials or captured analysis results. Importing grants no network or publish authority; each run uses this host's native preflight and review.

Save workflow as Flow is available in Saved conversations after a completed discussion. Choose the action types to include and Draft workflow graph. The request shares that conversation's budget and captures the source's current native evidence. It generates a graph using the registered native nodes; unsupported contracts require clarification. Review all parameters, wiring, scripts, capabilities and tracking effects, then approve and choose Save reviewed workflow. Saving creates a new native graph and a reusable recipe for Ideas. Run remains a separate Flow action with the current host's permissions and preflight.

The graph retains the evidence source, user prompts, chosen action types and generation language in its description. It does not retain the discussion's captured result rows or assistant answers. Export from Flow, or export the recipe with its referenced graph, to move it to another browser. Graph and recipe storage failures are reported separately; each retains a session copy and offers a retry. Redrafting requires fresh approval, and cancelling or changing the Assistant's host cannot publish a late draft over a newer review.

Project preferences stores terminology, severity wording, expected property sets, naming guidance and report audience against the exact set of loaded-model fingerprints. Another revision or federation uses a different scope; switching scopes clears unsaved preference edits before saving in the new project. Preferences are advisory guidance in subsequent Assistant requests; they do not change native check verdicts. Credential-like text is refused.

Captured Lens and List JSON exports and browser storage use a versioned envelope. Older viewers cannot read that envelope, so they skip the saved Lens or refuse the List import instead of evaluating it over a wider population. Open these captures in a viewer that supports captured scope. Ordinary unscoped exports keep their existing format. Whole-library backup version 2 uses these same guarded codecs for its Lens and List libraries. Older viewers refuse that backup version rather than dropping the libraries or captured populations.

A Document can embed a captured List and re-run that exact population. Native Document version 13 preserves this behavior through file import, durable storage, and the existing Document backup route; older viewers refuse the newer document version. Documents saved in versions 1 through 12 remain readable in the newer viewer. Flavor Lens snapshots use the same guarded Lens envelope as native Lens JSON.

Selected relationship evidence records exact IFC relationship IDs, EXPRESS types, direction and model-local endpoints. Derived groups, openings and connections are not counted again as extra edges. The evidence samples at most 16 edges per element for small selections, or 6 for larger selections, and records the full known edge count. Duplicate selections identify their inherited lookup Express ID and merge direct edges once. Missing source membership has an unknown total; source-free edited graph rows are unverified evidence from the original model. The native Properties panel shows the same availability warning. Such original edges do not authorize current spatial authoring.

Dispatched generation receipts also record the actual output-token grant and parent deadline, a safe finish reason, and an explicitly declared producer prompt version (#7246). Versioned SHA256 digests identify finalized logical system/messages/schema and exact completed output text. They do not claim provider wire-byte identity or native artifact identity. Unknown legacy provenance stays unknown; saved receipt decoding reconstructs only these declared metadata fields and never retains raw prompts, replies, schemas, credentials or endpoints. Native viewer/headless JSON producers prepare one owned snapshot for both dispatch and digest under the parent deadline. Generic custom transports without this explicit boundary leave their opaque inputs untouched and mark the logical digest unavailable; metadata does not inspect getters or Proxy traps.

Reviewed element.replace proposals support the native wall, column, slab, beam, space, roof, plate, member, stair and railing replacement builders. Each row supplies the selected nativeReplacementExpected snapshot verbatim: the complete native root record, placement, storey, type memberships, material memberships and current mutation revision. A removed Stair flight also supplies its complete current record, placement and memberships. The existing native Split or Stair reader supplies a source shape pin when available, with its explicit metre units; unsupported old shape layouts keep an explicit unavailable marker and never acquire fabricated geometry. Root attributes, references and placement pins retain file units; only the new destination's parameters use the batch's metre/millimetre units. Source or intermediate-state changes and ambiguous native identities refuse approval. Native hosts with openings and unsupported aggregates refuse replacement; stairs retain the native uniquely owned single-flight restrictions. Existing stair.replace and railing.replace contracts remain available.

Replacement creates a new product identity and does not automatically transfer the old product's type, materials, property sets or hosted relationships. Shared old shape/style leaves may remain. The review shows the destination's existing command ghost only: the removed body and dependent geometry are omitted, and existing stair/profile approximation notices still apply. Native export is authoritative; one grouped Undo restores the original saved source graph. A cached or unreadable source does not authorize an invented replacement snapshot.

Reviewed element.split proposals name an existing target and supply its complete canonical native split snapshot (chain, placement parent/frame and storey ID). Missing snapshots must be obtained from the native model, never inferred. A wall/linear cut states a distance from its native axis start; a slab-like cut states two plan points. Only dimensions use the batch’s metre/millimetre units; native IDs and directions retain their meanings. Review draws a cut marker, with an explicit unavailable-preview notice for unsupported placement projection, and reports native hosted-opening assignments. It does not show the resulting solids or attest structural engineering intent. Native splitting retains the larger piece’s identity, creates one derived identity and preserves the canonical metadata policy. Source replacement, overlay revisions and ambiguous same-model GlobalIds refuse stale approval. Explicit selection batches contain one row per target and undo as one grouped change.

Native split and copy also carry effective property/quantity sets authored or edited in the current edit session, including edits to saved-source sets. Their values, types and units use the same mutation and STEP export path as the source; deleted or undone sets do not reappear. Canonical generated same-name metadata, including newly measured quantities, remains authoritative. Effective metadata cloning refuses an operation exceeding 10,000 projected writes across all sibling products; the native atomic operation rolls back instead of dropping metadata.

Selected-element evidence and explicit Attach selection include the same canonical native authoring snapshots: nativeSplitExpected, nativeHostedExpected, nativeTrimExtendExpected, and nativeStairExpected. nativeAuthoringUnits declares each snapshot’s representation. Their nativeAuthoringAvailability states distinguish available snapshots from missing targets, undeclared native units, unsupported native layouts, and projection limits. An unavailable snapshot never means that the element has no geometry. Native refusal details accompany Split and Hosted layouts.

Split and Hosted expected lengths use metres; Stair dimensions follow the native SI reader. Trim/Extend expected fields preserve their original mixed representation: wall placement coordinates use file units while wall geometry uses metres. Model-local EXPRESS IDs and direction vectors retain their native meanings. A proposal must use the complete expected snapshot and the operation’s own declared command units. Evidence projection removes a whole snapshot that exceeds its bounds instead of presenting a truncated expected state as usable. Both routes publish the current native Root GlobalId, including positional edits and their precedence over named edits. Non-Root names and deleted roots cannot supply a target GlobalId. Cached source-free Root identities remain known without making unavailable graph geometry readable. Both routes bind their captured native source and view; attachments also retain the native prepared lease. A later edit or source replacement refuses stale evidence before sending, and an in-flight source/view replacement cancels its owned request and rejects a late answer.

Reviewed loaded-model authoring can propose a grid and columns bound to its actual native intersections. Grid proposals state explicit model, storey, straight axis tags/endpoints, position and rotation; a batch creates at most200 grid axes and do not inherit the interactive tool's remembered settings. Lengths use the batch's declared metres or millimetres; grid Direction is radians. Grid axes are non-root IFC objects: their current express IDs and axis tags identify them within the pinned model, and they have no GlobalId.

Selected grid evidence and an explicitly attached selection can supply nativeGrid: full declared axis count, availability, and a current expected snapshot of axes and placement in SI metres. Unavailable evidence is unknown. A column on an existing grid must pin this snapshot and the two actual axis references. Its target name preserves the current native Name: null when absent, and the exact string (including an explicit empty string) when present. A column using an earlier proposed grid instead names that proposal and two unique axis tags; approving the column requires approving its grid too. Applying preserves IfcGridPlacement and IfcVirtualGridIntersection, rather than merely copying coordinates. Native crossing, ownership, source freshness and unit checks can refuse a proposal.

The grid preview draws native axis strips. The column preview draws its section at the native crossing; unsupported section headings or a workplane whose current placement differs from the readable saved frame have an unavailable preview. Apply still uses the native builder. These actions edit a loaded model through grouped native Undo/Redo; generating a separate IFC file is a different operation. No geometry or structural-engineering suitability is inferred from a proposal. Compact large-selection summaries omit complete Replacement pins, units and per-row availability to preserve the existing metadata budget. Their summary discloses nativeReplacementCapture: "unavailable-selection-budget". Select fewer elements or attach an explicit target for the complete native replacement expected state; a summary cannot authorize replacement.

Supplied analytical IFC graphs can be proposed with the separate structural.graph review card. It uses the existing native factories for analytical models, straight curve members, point connections, load groups, point and linear actions, and their three relationship routes. Supply every endpoint, restraint and load component explicitly; the assistant does not calculate a design, load, analysis result or compliance verdict.

Attach the current selection or open a single-element selection source to supply the complete native Structural snapshot. A multi-element source retains ordinary metadata and discloses nativeStructuralCapture: "unavailable-selection-budget" rather than repeating the complete graph for every row. If a complete single-element graph exceeds the remaining evidence envelope, that row retains its ordinary metadata and reports nativeStructural.status: "unavailable-selection-budget"; attach the explicit target for complete pins. Geometry inputs are metres in the source storey's local IFC Z-up frame. Load and stiffness fields remain literal model measures: the card requires explicit acknowledgement, displays declared-unit evidence and does not assume missing units or convert force/moment values. Changed source storey placement dependencies, unavailable/truncated evidence and stale sources refuse preparation or Apply. An analytical geometry preview is explicitly unavailable in this card; inspect the native record changes, choose operations and approve Apply. The resulting native edit group supports Undo/Redo and a saved receipt. Structural deletion is outside these creation/relation routes.

Explicit supplied cost graphs¶

Selection evidence can carry a complete current native Cost graph, its declared units, native IFC records and incoming shared references. An explicit selection attachment carries nativeCost.expected; rich selection evidence carries the same snapshot as nativeCost.expectedJsonParts, joined without separators and parsed as JSON. Compact large-selection evidence omits complete Cost pins and discloses nativeCostCapture: "unavailable-selection-budget"; select fewer elements or attach an explicit target to prepare a Cost graph. Ordinary element metadata retains its existing sampling budget. Unavailable or truncated evidence cannot authorize an edit. The snapshot is compared with the current loaded source before native preparation and again at Apply.

A separate cost.graph proposal supports the existing schedule, item, value, quantity, nesting, schedule assignment, object assignment, item-value attachment and safe-removal operations. Amounts, typed IFC measures, quantity values, native Unit references, Components and UnitBasis must be supplied explicitly. The route does not estimate prices, invent currency or convert amounts. Native names and parameter fields retain exact IFC PascalCase spelling. Existing references use captured native expressIds; references to earlier operations use {ref: "name"} and require those operations to be approved too.

Review the selected operations and inspect the complete native created, modified and deleted records, including changed shared references and cascades. Apply runs the same canonical SDK cost backend in one native edit group, preserving IFC export and Undo/Redo. Created GlobalIds are assigned at Apply. Non-root values and quantities have no GlobalId: their receipts retain the actual model-bound expressId instead. Receipts use the existing reviewed-change library and can be backed up; edit history remains session state, so a receipt after reload does not recreate Undo history. A failed receipt save is reported separately from the applied native edit.

The route requires Edit mode and native edit permission. It refuses unavailable sources, ambiguous rooted identities, stale snapshots, unsupported native schema/units/SELECTs, cycles, unsafe shared-reference removal and unapproved dependencies. It is non-geometric and does not create a viewport ghost. The bounded route does not establish human evaluation, fixture approval or coordinator-study acceptance.

Review Room AutoAll across current storeys¶

A version 1 room.command may explicitly request command.action: "autoAll" for its supplied modelId. The supplied storey Root anchors that model; native preparation enumerates every current storey in that model. It does not include other federated models. The existing explicit m/mm and storey-local Room settings apply to each storey, with lengths normalized once to native metres.

Prepare publishes complete per-storey coverage: ready, no walls, occupied, no eligible faces, or unavailable. A successful native remesh does not prove complete wall coverage: live contained walls with missing or unusable geometry make that storey unavailable. A genuinely wall-free storey remains no walls. Existing room counts include unsupported native room shapes. Unavailable coverage is shown as incomplete, with no approvable partial changes; it never announces an empty plan. Approval refuses unknown/unavailable coverage rather than applying only the known storeys. A successful nonempty action uses one native graph transaction and one Undo group. Empty/no-wall/fully occupied preparation has no IFC write or new Undo group. Source, direct mutation revision, native layout, geometry and model/storey frame changes invalidate held approvals. Cancellation releases preparation without applying it.

Room contours stay in each owning storey's local frame; the combined AutoAll card lists each owner and complete contours instead of overlaying different storeys into one plan. Selection and explicit selection attachments publish only current storey identities and the requirement for native preparation, never guessed candidates. Compact large selections omit the repeated storey population and disclose nativeRoomAutoAllCapture: "unavailable-selection-budget"; use a rich smaller selection or an explicit attachment for complete current storey identities. Explicit prepared Room attachments carry the actual complete snapshot. Native solver/exporter diagnostics and unsupported current frames retain their existing boundaries.

New native IFC scaffold¶

With Models and new IFC files, an empty viewer can discuss the native new-file capability without claiming loaded-model facts. Supply the project Name, Schema (IFC4 or IFC4X3), LengthUnit (METRE or MILLIMETRE), and each storey's Name and Elevation. Elevations use those file units. Optional Description, Author, Organization and Currency remain supplied values; currency is omitted when absent. FOOT and unsupported schemas refuse.

A reviewed ifc.create answer creates only a standalone project scaffold. Prepare new IFC file calls the existing native builder and parses its actual output before displaying the exact bytes, units, names and generated identities. The native Site and Building names remain Site and Building. No product geometry or design requirements are inferred. Download reviewed IFC publishes those prepared bytes through the native download action. Replacing the answer invalidates the old review.

Request viewer load (replace session) dispatches the native File request to the existing primary load owner. It refuses a busy, edited, shared or changed workspace. The request does not confirm loading: follow native Activity and Load reports for the actual outcome. File publication and session replacement have no model-edit Undo. Browser loading acceptance and human evaluation remain separate from native scaffold evidence.

Comparison’s Impact on other analyses rows offer Open original for the current native clash, failed IDS element/specification, list aggregate or BCF topic. Changed-element chips select the exact compared base or head model in 3D; opening a BCF topic does not guess a model from its component GUIDs. A list opens its recorded aggregate without claiming its unstamped result is current. Links require source ownership recorded by the native comparison producer. Imported/manual comparisons, replaced model sources, direct overlay edits, stale or replaced findings and removed elements keep readable facts but cannot acquire navigation authority by mounting the panel; refresh the comparison and analysis when a link is unavailable.

Reassign an existing product to another storey¶

A reviewed element.reassignStorey proposal changes a product's storey while preserving its identity and world position. It names the existing target, source storey and destination storey with the same explicit owning modelId. Complete hosted opening/filling and aggregate/nested dependencies travel with the root. Distinct named membership relationships retain their metadata and remain distinct at the destination. Detached children, ambiguous identities/ownership, shared or unreadable placements and dependency cycles refuse. Sites, buildings, storeys and grids cannot be moved by this operation.

Rich selected-element evidence and Attach selection supply matching nativeStoreyReassignments candidates. Each candidate pins both storeys in expected.sourceStorey and expected.destinationStorey as { expressId, GlobalId } records, counts the complete product population, and carries bounded expectedJsonParts. Join every part and parse the resulting JSON for the operation's complete expected value; those native fields remain unchanged even when the batch uses millimetres. A model with more than 20 storeys, a projected/partial pin, or a complete minimal one-operation batch with a one-character title exceeding the existing text limit supplies no usable candidate. Changing either storey GlobalId invalidates the reviewed pin; incomplete older pins are refused. Missing state must be obtained from current evidence rather than guessed. Existing target names use an empty string when absent; the native expected attributes preserve the exact absent or empty Name.

Review shows the source/destination identities and complete dependency count. World geometry stays fixed, so the card discloses the absence of a displaced geometry preview. Apply revalidates the loaded source, overlay revision and native state, records grouped Undo and refreshes the affected products using canonical remeshing. Export/reparse retains their GlobalIds and EXPRESS IDs. The proposal does not establish structural-engineering suitability.

Complete storey reassignment pins are bounded to 200,000 submitted values and 12 nesting levels. The 5,000-product bound applies to the moved dependency closure; a complete source relationship may contain more unchanged members. Selection capture shares one effective Root/relationship inventory across destination candidates.

Complete optional Storey, Structural and Cost pins share the request envelope. After ordinary facts and all guidance are reserved, generation admits each unchanged whole pin only when the complete serialized messages and system text fit the existing 90,000-character limit. A refused pin reports unavailable-transport-budget; its complete expected state is omitted, while ordinary identities, citations and metadata remain. Captured source attachments stay unchanged for stale-state validation; the saved user turn records the projected text actually sent. This transport boundary does not reduce direct native planner or writer capabilities, and a pin larger than 12,000 characters remains usable when the full request fits. Oversized conversation history or ordinary context can still refuse the request.