Validation & the world

A scene is what you traced over one sheet. The world is the coordinated building, solved from every scene you have committed. Validation is the gate between them: you never write to the world directly, you validate a scene and commit it.

This page is the rules reference. It lists every check the product runs, the exact message each one produces, and what commit and withdraw actually do.

Validate a scene

1. Open the scene in the scene editor.
2. Click Validate in the head bar.
3. If anything fires, the Validate dropdown opens: "{n} validation issues", one row per finding. Click a row to be taken to it — the view flies to the geometry the finding names and lights it up, the same as opening it from the RFIs panel.
4. Fix it on the drawing. The scene re-validates quietly as your edits settle.
5. When the scene is clean the flash reads "Scene is valid and consistent with the world — ready to push" and Push to Tekla becomes clickable.

Button state	Tooltip
Never validated	Validate this scene, then check it against the committed scenes
Running	Validating…
Findings open	{n} validation issues — click to view
Clean	Scene is valid and consistent with the world
Push, disabled	Push to Tekla — validate clean first
Push, enabled	Push to Tekla — write the building into the open model

Every finding is also filed as an RFI for the whole project, so you can work the list from the RFIs panel instead of sheet by sheet. Re-validating an unfixed drawing reopens the same RFI with a rewritten message rather than adding a duplicate.

There is no severity model

There are no warnings and no errors — only findings, and every finding blocks commit. Nothing can be dismissed, snoozed, waived or overridden, and there is no "commit anyway", no force flag and no partial commit. A finding leaves the list one way: the drawing stops producing it. Every open RFI row says so: "Fix in the scene to clear".

Fix the sheet first, then the set

One click of Validate runs two passes in a fixed order.

Pass	Question	When it runs
Scene	Is this sheet self-consistent and complete enough to build from?	Always.
World	Does it agree with every committed scene?	Only if the scene pass fired nothing at all.

Inside the world pass there is a second stage: the grid-chain and cross-sheet rules run first, and the building is only assembled — and the placement and clash rules only run — if those fired nothing.

What this means in practice: you cannot see your cross-sheet problems until your own sheet is clean. Clear the scene findings, validate again, and the cross-sheet findings appear then. A world finding is therefore never noise from an unfinished sheet; it is always a genuine disagreement with something already committed.

The response tells you how far it got, as ran: scene or world.

The scene pass — 14 rules

Checked against this sheet alone. Two of these short-circuit: if grid_missing or elevation_no_grid fires, it is returned on its own and every other scene finding is suppressed. Fix it and validate again to see the rest.

Rule	What it checks	Message	Example
grid_missing	The scene has at least one grid line. Short-circuits.	This scene has no grid lines, so nothing on it can be located.	(fixed text)
elevation_no_grid	An elevation names at least one grid line to run along. Short-circuits.	This elevation names no grid line, so nothing on it has a place in the building.	(fixed text)
scene_uncalibrated	The scene has a scale, so distances mean feet.	This scene has no scale yet — run Calibrate, or enter a bay dimension.	(fixed text)
grid_unlabeled_line	Every grid line has a label. One finding per unlabeled line.	A grid line has no label, so no dimension or member can name it.	(fixed text)
member_duplicate_station	One column per station.	{n} columns stand at {labels} — a station takes one. Delete all but the one that is right.	2 columns stand at 2 x B — a station takes one. Delete all but the one that is right.
elevation_unpinned_level	Every member end on an elevation has a height.	The {kind}'s{ end} sits at no elevation — pin the level it is on, or give it the height the sheet states.	The column's start end sits at no elevation — pin the level it is on, or give it the height the sheet states.
member_off_grid	A member end is located, by grid intersection or sheet position.	A {kind}{ end} is not placed — it has neither a grid intersection nor a position on the sheet.	A beam start end is not placed — it has neither a grid intersection nor a position on the sheet.
member_invalid_intersection	The two lines a member is anchored to actually cross.	The {kind} at {labels} is anchored to two parallel grid lines, which never cross.	The beam at 2 x 3 is anchored to two parallel grid lines, which never cross.
grid_elevation_conflict	The two lines through a point agree on its elevation.	The {kind} at {labels} sits where {A} is at {za} ft and {B} is at {zb} ft — two elevations for one point.	The column at 2 x B sits where 2 is at 100 ft and B is at 98.5 ft — two elevations for one point.
member_missing_profile	Every member has a section.	The {kind} at {stations} has no profile — nothing says what section to build.	The beam at 2 x B to 3 x B has no profile — nothing says what section to build.
member_missing_grade	Every member has a steel grade.	{location} has no steel grade, and the general notes have not been read for one.	The column at 2 x B has no steel grade, and the general notes have not been read for one.
grid_line_island	Every grid line is tied by dimensions to the rest of its grid.	Grid lines {groups} have no dimension between them, so they cannot be placed relative to each other.	Grid lines (A, B, C) and (F, G, H) have no dimension between them, so they cannot be placed relative to each other.
grid_chain_conflict	Dimensions along a run agree with each other.	{from} to {to} is dimensioned {dist} ft[ here], but the other dimensions make it {implied} ft.	B to C is dimensioned 25 ft, but the other dimensions make it 30 ft.
grid_order_conflict	Dimensioned order matches drawn order.	The dimensions put {labels} in a different order than the drawing does.	The dimensions put B, C in a different order than the drawing does.

Reading the templates:

• The end word is start end or end end for a two-ended member. For a one-ended member member_off_grid leaves it out entirely (A column is not placed …), while elevation_unpinned_level falls back to end (The column's end sits at no elevation …).
• The location phrase in member_missing_profile and member_missing_grade is The {kind} at {A x B} for one anchored end, The {kind} at {A x B} to {C x D} for two, and An off-grid {kind} when neither end is anchored — for example "An off-grid brace has no profile — nothing says what section to build."
• The word here appears in grid_chain_conflict only when the contradicting dimension came from a different scene than the rest.

Why some of these never fire when you'd expect them to

grid_order_conflict needs three or more placed lines in one family on one sheet. Two lines are in some order either way, so it cannot contradict anything.

member_missing_grade is suppressed across the whole project once the general-notes extraction has finished (status is done) and produced at least one grade fact. Which shape that fact covers is a question for commit, not for validation — if the rule fired on every member of every properly-noted job, and nothing is dismissible, commit would be unreachable. See the design spec.

A rule called elevation_end_malformed used to exist and has been deliberately removed.

Six rules show as a raw slug with no Fix line

The short chip label and the Fix: hint under each finding come from a table that does not cover every live rule. These six render with their rule id and no hint: member_duplicate_station, elevation_no_grid, elevation_unpinned_level, world_column_section_conflict, elevation_grid_unplaceable, elevation_runs_along_its_own_family. The message itself is always there and is the part that tells you what to do.

The world pass — 8 rules

Cross-sheet only, and only reached from a silent scene pass.

Rule	What it checks	Message	Example
world_grid_line_island	This sheet's grid ties by dimension to the grid the world already knows.	Grid lines {groups} have no dimension between them, so they cannot be placed relative to each other.	Grid lines (A, B, C) and (F, G, H) have no dimension between them, so they cannot be placed relative to each other.
world_grid_chain_conflict	This sheet's dimensions agree with the committed ones.	{from} to {to} is dimensioned {dist} ft[ here], but the other dimensions make it {implied} ft.	B to C is dimensioned 25 ft here, but the other dimensions make it 30 ft.
world_station_conflict	Two sheets give one piece of steel one profile and one grade.	One piece of steel is given two {field}s: {value} on {scenes} and {value} on {scenes}.	One piece of steel is given two profiles: W14X61 on Level 3 Framing and W14X90 on Level 1 Framing.
world_grid_elevation_conflict	Two sheets of one level agree where a grid line sits.	Grid line {label} is at two elevations on this level: {z} ft on {scenes} and {z} ft on {scenes}.	Grid line B is at two elevations on this level: 98.5 ft on Level 2 East and 100 ft on Level 2 West.
world_column_section_conflict	A plan's sighting and an elevation's span agree about a column.	The column at {labels}, {z} ft, is sighted on a plan and spanned by an elevation with two {field}s: {value} on {scenes} and {value} on {scenes}.	The column at 2 x B, 13.5 ft, is sighted on a plan and spanned by an elevation with two profiles: W14X61 on Elevation B and W14X90 on Level 2 Framing.
elevation_grid_unplaceable	A committed plan fixes where this elevation's grid line is.	This elevation runs along grid {label}, which the model cannot place — no committed plan fixes where that line is, so the frame it stands for has nowhere to go.	with label = CO-A
elevation_runs_along_its_own_family	The elevation runs along a line it does not cross.	This elevation runs along grid {label}, which is parallel to the lines it draws — a frame crosses those lines, so it cannot also lie along one of them. Name a grid from the other direction, or this sheet is not the view it says it is.	with label = CO-A
member_clash	Two members do not occupy the same steel.	{member A} and {member B} overlap by {inches} inches on {level}. Each sheet is self-consistent; together they put steel in one place.	the beam from 2 x B to 3 x B and the column at 2 x B overlap by 6.5 inches on Level 2. Each sheet is self-consistent; together they put steel in one place.

elevation_grid_unplaceable, elevation_runs_along_its_own_family and member_clash are the second stage — they only run once the first five are silent.

The bracketed here in world_grid_chain_conflict works exactly as it does in the scene pass: it is printed only when the contradicting dimension came from a different scene. In the world pass that is very nearly always, because the contradiction is normally between two sheets.

In member_clash, a member reads as the {kind} at {A x B} when it has one station and the {kind} from {A x B} to {C x D} when it has two, falling back to a {kind} when it has no world identity; the level falls back to the literal words this level.

What is compared, and what deliberately is not

Only profile and grade are compared across sheets. Rotation never is — it is filled by a vision model, and two sheets can differ by detector noise alone.

world_grid_elevation_conflict is scoped within one level on purpose. Comparing level 1's A against level 3's A would flag every two-storey building.

member_clash is scoped to the scene you are validating. It reports the steel this sheet brings into the model, not every standing interference in the building.

A member's body is the box its section sweeps along its work line, so a beam takes up its depth vertically and its flange width across the sheet — two beams side by side in a bay are separated by the flange, not by the depth. A member that ends inside another is framing into it, which is a connection and not a clash: a beam stops at the face of the girder that carries it, so its last coordinate sits inside the girder rather than on its centreline. A column is sized by the circle that contains it, because a plan does not state which way its flanges face.

An elevation that names several grids is checked once per frame, and each finding names the frame it is about. All of them must be clean: one drawing standing for seven frames is one statement.

The tolerances

Check	Tolerance	Meaning
Grid chain closure	1 inch	A run of dimensions that closes to within an inch is agreeing with itself.
Cross-scene level elevation	0.02 ft (about ¼ inch)	Two sheets stating a level's elevation this close are agreeing.
Parallel lines	1.5° (scene pass and grid chain) / 2.9° (world pass, grid plan, run-along picker)	Two lines within the tolerance are the same family, and never cross.
Elevation of a point on the grid	float noise only	Two lines through one point must give the same height. An eighth of an inch apart is a real contradiction, not a tolerance.
Clash overlap	0.02 ft (about ¼ inch)	Bodies must overlap by more than this to be reported, so steel that merely touches is not a finding.
Framed connection	the member's own half-section, plus 1.8 inches	An end this close to the inside of what carries it is a connection. The margin is for drawing and extraction slop; the rest scales with the supporting member.

Push a sheet to Tekla

1. Validate until the sheet is clean.
2. Click Push to Tekla.
3. Read what this push would do, and click Write it.
4. On success the flash reads "Sheet checked", or, when grades were filled from the notes, "Sheet checked; 14 members graded from the notes" — followed by what the Tekla write did.

What this push would do

Nothing is written until you have seen what would be. Push to Tekla validates the sheet, works out what should change in the model, and shows you the answer before the model is touched:

Line	What it counts
Created	Steel the model does not hold yet
Changed	Steel that exists and would be re-stated. up to — anything you edited by hand, locked or issued is left alone
Removed	Steel of ours that no drawing calls for any more. Locked and issued steel stays
grid lines and levels written	The grid and the elevation ladder

Where the sheet sits, and seeing it before it is written

At the top of the dialog Fablnx says where this sheet lands in the building, and draws it there:

Drawn in Tekla on A, B, 1, 2 — 4 crossings, agreeing to 1/16", at Level 2. Dashed lines are proposed; nothing is written until you write it.

While the dialog is open the whole proposal appears in the Tekla model as dashed, translucent lines: every member on its work line, a small cross where each end lands, and the grid at the level this sheet sits on. A column would otherwise be invisible from above — its work line is a single point in a plan view — so the crosses are what make it read.

Nothing is written by any of this. They are not objects: they cannot be selected, numbered, reported on or deleted, and closing the dialog takes them away. When you press Write it they become real steel — and the steel is coloured, so you can see what landed and what did not:

Colour in Tekla	What it is
Dashed and see-through	Proposed. Nothing is in the model yet.
Green	Written by this push.
Purple	Yours — a member you corrected by hand, which the push left alone.

Read the line before you write. The labels are the grid lines this sheet and your model both name; the crossings are how many places the two grids can be compared at; and agreeing to is how far apart they still are at those places. A small figure means the drawing and the model are describing the same building. A large one means they disagree about the shape of the grid — which is worth finding before forty members are written to it.

If they share no crossing at all, the dialog says so and draws nothing:

This sheet's grid and the model's share no crossing, so there is nothing to place it against and nothing is drawn in Tekla. The push still writes it — at the drawings' own origin, which is what an empty model should take.

That is normal for the first push into a brand-new model: there is nothing there yet to line up with, so your drawings decide where the building is. On a model that already holds steel it is worth asking why — usually the grid labels differ between the sheet and the model.

Hover a line and that steel lights up in the Tekla model — nothing moves, no camera, no change to what you had selected, so glancing at a row costs you nothing. Show these beside a line selects it properly, so you can look at what is about to change rather than counting on the number.

The highlight is Tekla's own temporary colouring: it clears itself when you move off the row, and Clear temporary states in Tekla clears it too.

With nothing to do it says so: Nothing. The model already matches this sheet.

Under the counts, any member on this sheet that could not be placed is named rather than silently skipped — 3 members on this sheet could not be placed and will not be written — because a sheet routinely carries steel it has not finished describing.

Under that, the order the push is carried out in: grid lines and levels first, then everything created, then everything changed, then everything removed.

Cancel writes nothing. Write it does the push.

Watching a push go

While it runs, the dialog says what is happening and counts the seconds:

What it says	What is going on
Waiting for Tekla to finish what this window last asked it	Something else Fablnx asked Tekla for — a model read, a report — is still going. Yours is next.
Writing into Tekla — a push waits for any macro of yours to finish rather than landing inside one	It is in Tekla's hands.

The Fablnx window stays alive throughout. It used to freeze for as long as the push took, which mattered most exactly when it took longest: a push that is waiting patiently for your numbering macro to finish looked identical to one that had crashed.

The seconds are the honest answer to is it stuck. Fablnx does not show a member-by-member bar, because it cannot: what is going in is Tekla's business until the push answers, and a bar that guessed would be worse than a clock that does not.

What a push will not write over

Three things stop steel being written, all of them decided in Tekla at the moment of the write rather than guessed here:

• A member you corrected by hand is left exactly as it is — this is the hold, and it is why Changed is an upper bound.
• A part Tekla has locked, or that has been issued, is left exactly as it is and named in the result. Fablnx checks this itself rather than relying on Tekla to refuse the write.
• A model Tekla is still busy with. If a macro is running when you press Write it, the push waits for it to finish, and says so rather than writing into the middle of it. Nothing is half written. It will wait a couple of minutes; the dialog keeps counting while it does, and no longer gives up on a push that is simply being patient.

What a push removes, and what it will not

A push takes steel out as well as putting it in, and the rule is the sheet's own: a drawing is an area it looked at, and inside that area it is the authority on what is there. "At CO-8 there is no column" is as much a statement as "at CO-7 there is a W12X40" — and both are only statements where the sheet looked.

So a sheet removes a member when all of this is true:

• a column stands at one of the sheet's own grid crossings, is wholly inside the storey the sheet draws, and the sheet shows nothing there;
• a beam has both ends at crossings the sheet covers, lies on the sheet's own level, and the sheet draws nothing between those two points.

Everything else it leaves alone, and each of these is deliberate:

It leaves alone	Why
Steel away from its grid	Not a place this drawing speaks about. This is what keeps another job's steel — the stair job's, the next area's — safe from your push
A beam running off the edge of the grid	It frames into a bay this sheet never looked at. The sheet can see one end and has no idea what carries the other, so it is not the sheet's to take away
A column rising past the storey the sheet draws	It serves a floor above, drawn on a plan this one has never seen
A beam at a level this sheet does not draw — a mezzanine inside the same storey	Same reason. It belongs to the plan that draws that level
A member you corrected in Tekla	The hold
Steel you modelled yourself	Never Fablnx's, never touched

The last four are reported, not silently skipped: a push that disagrees with the model and says nothing would read as agreement.

Why a piece did not reach the model

The line under a finished push counts what happened — Model updated — 12 created, 3 updated, 2 not written. Where anything was not written, a panel opens listing each one in a sentence: "B-12 records no bolt grade, so its bolts are not placed", "the connection between B-12 and C-4 came back STATUS_WARNING and wants a look". Every one of them names a member and what to do about it, which a number never could.

Ends awaiting a connection design are counted apart from these, because they are not a problem. The work goes modelling, then connection design, then applying that design; between the first and the second, a beam is in the model standing on its work points with nothing detailed at its ends yet. A sheet you have just pushed for the first time reads Model updated — 67 updated, 130 ends awaiting a connection design, and that is the sheet being right. Settle those typicals in Connections and the count falls as you go.

It does not matter whether we put it there

A push does not ask "did I write this?" — nothing records who wrote a given object, and a member re-detected on a re-run carries a different id than the one in the model. It asks what the drawing says about the place. That is why a sheet whose grid could not be solved removes nothing at all: it cannot say where it is, so it cannot say what is not there.

Which phase a push lands in

New steel is written into the phase the model is currently in — the phase Tekla itself shows as current, not phase 1 and not a phase Fablnx chose. That includes the connection detailing hung off each member.

If Tekla will not say which phase the model is in, the push writes nothing and says so. Steel in the wrong phase disappears from every view, filter and report a job is set up with, which looks exactly like a push that did nothing at all.

"Changed" is an upper bound, and there is no undo

Whether a member has been corrected by hand is decided against the model at the moment of writing, so the preview can only honestly say up to — 42 changed would be a promise it cannot keep when 17 of them turn out to be held.

And the preview is a preview, not a safety net: Tekla has no way to undo a push as one step, and there is no model backup Fablnx can trigger for you first — both were measured against Tekla's own interface, not assumed. What you agree to here is written for real, and everything it wrote carries Fablnx's stamp, so what you have selected in Tekla can always say whose it is. If a push takes long enough that you alt-tab away, the browser tab title says ✔ Pushed to Tekla when it lands, and clears itself when you look back.

Pushing the same sheet again changes nothing: the write is a reconciliation, so it inserts, updates and deletes to match rather than appending. There is no withdraw — nothing joins the building, so nothing leaves it. Delete a scene and its steel goes out of the model on the next push.

The server does not trust a clean pass from your screen. On every push it:

1. Fills grades from the general notes onto members of this scene whose grade is NULL — only nulls. A grade written next to the member, or corrected by hand, is the more specific statement and the notes never overrule it.
2. Re-runs the full validation, both passes.
3. Refuses whole if anything fires: nothing is written to the model. One thing does persist even on a refusal — grades filled from the general notes are written before the re-check and are kept. The flash reads "Push refused — this sheet has open questions" and the findings panel opens.

Grades are frozen at the push

Resolution happens at commit and the grade becomes the member row's own value. Editing the general notes later does not silently restate what a committed scene already says. Re-commit the scene if you want it re-read.

A grade the notes have no answer for stays null, and member_missing_grade will ask about it. No answer is a real answer, not a failure.

Editing a committed scene withdraws it, silently

Every accepted edit to a committed scene clears its committed state on the spot. There is no confirmation, no warning and no dialog — the in-world badge simply drops on your first change, in the header and in the scene list. The scene stops feeding the world until you validate and commit it again.

This holds however the edit arrives: your own change, the same project open in another window, or a detection step writing to the sheet. The editor compensates by re-validating quietly as the edits settle, so the badge tells you the truth without a refresh.

Taking steel back out

There is no withdraw. Nothing joins the building — every sheet you have traced is part of it — so nothing has to leave.

To take steel out, take it off the drawing and push that sheet again. Erase the column at CO-8 and the next push of that sheet erases it from Tekla, because the sheet now says there is nothing at CO-8 — see what a push removes.

Deleting the scene does not do it. That removes the statement rather than changing it: with no drawing looking at that bay, nothing says the steel should not be there, and it stays. Delete the scene when the sheet was traced in error; edit and push when the steel is.

What the world derives

Open the coordinated 3D model or the World summary in the Structure panel to see the solved building.

Derived	How
Grid positions	Lines are clustered into families of parallel lines across all committed scenes, then laid out from the dimensions only — sheet coordinates are never used for distance. Order within a family comes from the label convention, and each family's direction is turned to agree with the drawn order, so the building does not come out mirrored. Lines are drawn overshooting the outermost crossing line by 4 ft.
Which sheets drew a line	Every world grid line carries the scenes that drew it, so "where else is B?" is answered without another query.
Named vs. unnamed lines	A line the drawings name is drawn differently from one shown but not named (labelled from its geometry, like CO-10+14'-11"). One sheet naming it is enough to make it named.
Beam and brace locations	Both ends must be anchored to a grid intersection. Each end's height comes from the grid elevation of that point. There is no top-of-steel drop; the ends state the height.
Beams stated twice	Two sheets drawing one floor state one beam, not two. The rows merge and both sheets are named as its source.
Column heights	A plan sights a column (one end, no height). An elevation states a span (two ends), placed as drawn. Sightings at one station stack into lifts: each lift runs from the plan that drew it up to the next plan that drew the same station, carrying the lower plan's profile. Touching lifts of the same profile and grade are coalesced into one piece rather than spliced at every floor line. A sighting an elevation's span already covers is absorbed into that span.
Grades	Not derived here. Resolved at commit and written onto the member row.

levels in the world is every level the project defines, not only the ones a scene sits on.

Why something could not be placed

The World summary lists what the model could not place, under the heading Can't place yet, each row reading kind, station and level with the reason under it. There are exactly nine reasons:

Reason, verbatim	What it means
it is not on a grid intersection	A column end is not anchored.
its grid intersection could not be placed	The column's two labels do not resolve to a crossing point.
one of its ends sits at no elevation the sheet states	An elevation-stated span has no height at an end.
the sheet puts both its ends at one elevation, so it has no height	A stated span of zero height.
one of its ends is not on a grid intersection	A beam or brace with fewer than two anchored ends.
the grid it is anchored to could not be placed	A beam or brace whose end labels do not resolve to a point.
its two grid lines give it two different elevations	A beam or brace end hits the elevation conflict case.
the two plans put it at one elevation, so it has no height	Two stacked sightings at the same height.
it appears on only one plan, so nothing says how tall it is	A column with exactly one sighting.

Grid lines the world could not place are listed separately, by label: "{labels} have no dimension path — dimension them to the rest of the grid and recommit."

Two things are deliberately not reported here:

• The topmost sighting of a column is never flagged. Every building has a highest plan, and there is nothing above it to read a height from. Only a station with exactly one sighting in total is reported — and, in the current build, only while nothing else in the model has already been listed as unplaced; once anything else is stuck, single-sighting columns stop being reported.
• A column on two levels with two different sections is a splice, not a conflict. A station carries its level, so two levels are two stations, and a section change between them is a correct, buildable drawing. Only two sheets disagreeing at the same level is a real contradiction.

What is deliberately not checked

A member the plan shows and the elevation does not is never flagged. Leaving things off for clarity is normal draughting — real sheets say so in the title block, "STEEL ACCESS NOT SHOWN FOR CLARITY". Since nothing here can be dismissed, a rule that fired on correct drawings would make commit unreachable.

Where to go next

• Run Validate and Push to Tekla from the scene editor head bar. The dropdown footer reads "Fix in the scene — issues are tracked in the RFIs panel." and carries a Revalidate button.
• Findings are tracked project-wide in the RFIs panel.
• Committed scenes drive the coordinated 3D model and the World summary in the Structure panel.
• If a button is disabled or a commit will not go through, see Troubleshooting.