Set of findings

[STE1200]

Hi,
we are building tooling to read Revit files without a Revit installation, and rvt-rs — especially your reconnaissance document — has been our starting point and by far the most useful public resource. Thank you for putting it out there!
Over the past days we did our own reverse-engineering pass, mainly on a Revit 2014 manufacturer family (.rfa) plus a 2026 project file, with hard oracles (gzip trailers, manufacturer type catalogs, exact f64 bit patterns). We ended up with a set of findings that we believe close several of your open items, and one that corrects a layer your docs mark as complete. Before filing issues, I wanted to check with you directly — you haven't had third-party contributions yet, and I'd rather ask how you want this than flood your tracker.
What we have, in decreasing order of impact:
Decompression bug (silent corruption). Revit streams are checksum-paged: every full 65249-byte stored page = 64896 bytes of payload + 353 bytes of checksum. The tails must be stripped before inflating; the bitstream itself is standard RFC 1951. Without the strip, inflate terminates cleanly but drifts after the first page boundary — on our file, Formats/Latest silently loses ~48% of the schema. Verified against per-chunk gzip trailers (209/209 members, two files) and independently consistent with ahzs645/reviter's constants. This affects rvt-rs on any stream beyond ~190 KB.
Global/ElemTable body decoded: it is an ownership tree (2014: 28-byte records, owner as trailing u32; 2026: 40-byte/u64 variant). Your docs list the body as "partial".
Element record framing: ElementHeader records are locatable via a marker; the element id sits at a fixed offset before it, the element's class tag at a fixed offset after it. That makes ~63% of records immediately class-resolvable — likely useful for your CLASS-xx decoder issues.
Formats/Latest full parse on 2014 (3619 classes, no abort), with two small grammar fixes, plus evidence on how the real serialization tag is assigned. This one overlaps partly with your Q4 addendum.
Parameter store wire format (two record shapes, BuiltInParameter ids for extrusion/revolution, shared-parameter name resolution via PartAtom GUIDs) — and a practical trap: Revit computes feet as mm/25.4/12, which differs from mm/304.8 by 1 ulp, so bit-pattern searches must try both.
End-to-end geometry: sketch curve records → closed loops → extrusion/sweep/revolve parameters → solids. We rebuilt 85 of 86 extrusions of a real family in a CAD kernel from the raw streams.
Everything is clean-room black-box work on publicly available files — no decompilation, no NDA material — so Apache-2.0 contribution is no problem. Per your CONTRIBUTING.md we'd file each item as an issue with evidence, confidence and repro steps, and we can follow up with dated addenda for the reconnaissance doc plus Rust example probes and tests with synthetic fixtures. For item 1 we could also prepare a PR for the container layer if you'd take it.
Would that flow work for you, or do you prefer a different route? Happy to share the full write-ups directly as well.
Best regards, Steffen

[DrunkOnJava]

Hi Steffen,

First, apologies for the delayed reply—I only just saw your message. Thank you for reaching out, and for the extraordinarily thoughtful work behind it. This is the first substantive outside contribution to rvt-rs, and it means a great deal to hear that the reconnaissance document has been useful to another team building in this space.

Everything you described is highly relevant, especially the checksum-page decompression finding and its potential for silent corruption on larger streams. I would be very glad to dig into all six findings with you.

Please do not feel that you need to turn everything into polished issues, probes, tests, and documentation before sharing it. If you send the full write-ups, existing scripts, reproducible artifacts, sample provenance, or even rough research notes that you already have and are able to share, I’m happy to take on the repository-side work: independently reproducing the results, organizing and opening the tracking issues, implementing fixes, writing regression tests and probes, and updating the reconnaissance documentation. I’ll make sure the issues and resulting work clearly credit you and your team for the discoveries.

If you would enjoy preparing the focused container-layer pull request for the decompression issue, I would be excited to review it—but that is entirely optional. I’m equally happy to implement it here based on your evidence. I’ll begin investigating the decompression finding now using the details you’ve already shared. Whenever it’s convenient—now or later—please feel free to send anything else you already have, even rough notes, and I’ll incorporate it into the work from there.

I would also really value your perspective as an actual user of this work. I started rvt-rs because this part of the AEC ecosystem seemed underserved, but I don’t want to assume that the library’s current API, tooling, documentation, or priorities match real-world workflows. If you’re willing, I’d love to understand what your team is building, which Revit releases and file types matter most, where rvt-rs created friction, and which features, outputs, integrations, or compatibility improvements would make it more useful. I’m actively looking for that feedback and would be glad to put engineering effort into the improvements your workflow genuinely needs. If your team has any representative files it is fully authorized and comfortable sharing—publicly as fixtures, privately for research, or only through locally run probes—that corpus and its known expected results would be extraordinarily valuable, with absolutely no expectation to share confidential or customer material.

Your clean-room, public-file approach is aligned with the project’s Apache-2.0 contribution requirements. We can keep the technical record public in this discussion and linked issues, unless anything is security-sensitive or cannot be redistributed.

Thank you again—not only for the findings, but for approaching the project with such care. I’m excited to learn more about your work and to help turn these discoveries into improvements for the wider community.

Best,
Griffin

[STE1200]

Hi Griffin, Nice to hear from you! I'll start sending you the details tomorrow, and I can already tell you that I'm an architect who gets annoyed from time to time that suppliers of building equipment sometimes only offer Revit families — and we don't use Revit. On the other hand, I did some research on design automation 20 years ago and know the current AEC software landscape quite well. I've also been using AI since 2019 (first image generation, now LLMs), and in June something changed: Claude Fable was the first LLM that could understand geometry (by now also Opus 5 / Sonnet 5, to some extent). So I thought it was worth a try to see whether they could decode Revit files if I gave them matching IFCs. They could — but the crucial input (those CRCs) came from Kimi K3. In the end I was able to extract the geometry I needed into Rhino. New times ahead ;-) Talk to you soon, Steffen

…

DrunkOnJava ***@***.***> hat am 29.08.2026 20:54 MESZ geschrieben: Hi Steffen, First, apologies for the delayed reply—I only just saw your message. Thank you for reaching out, and for the extraordinarily thoughtful work behind it. This is the first substantive outside contribution to rvt-rs, and it means a great deal to hear that the reconnaissance document has been useful to another team building in this space. Everything you described is highly relevant, especially the checksum-page decompression finding and its potential for silent corruption on larger streams. I would be very glad to dig into all six findings with you. Please do not feel that you need to turn everything into polished issues, probes, tests, and documentation before sharing it. If you send the full write-ups, existing scripts, reproducible artifacts, sample provenance, or even rough research notes that you already have and are able to share, I’m happy to take on the repository-side work: independently reproducing the results, organizing and opening the tracking issues, implementing fixes, writing regression tests and probes, and updating the reconnaissance documentation. I’ll make sure the issues and resulting work clearly credit you and your team for the discoveries. If you would enjoy preparing the focused container-layer pull request for the decompression issue, I would be excited to review it—but that is entirely optional. I’m equally happy to implement it here based on your evidence. I’ll begin investigating the decompression finding now using the details you’ve already shared. Whenever it’s convenient—now or later—please feel free to send anything else you already have, even rough notes, and I’ll incorporate it into the work from there. I would also really value your perspective as an actual user of this work. I started rvt-rs because this part of the AEC ecosystem seemed underserved, but I don’t want to assume that the library’s current API, tooling, documentation, or priorities match real-world workflows. If you’re willing, I’d love to understand what your team is building, which Revit releases and file types matter most, where rvt-rs created friction, and which features, outputs, integrations, or compatibility improvements would make it more useful. I’m actively looking for that feedback and would be glad to put engineering effort into the improvements your workflow genuinely needs. Your clean-room, public-file approach is aligned with the project’s Apache-2.0 contribution requirements. We can keep the technical record public in this discussion and linked issues, unless anything is security-sensitive or cannot be redistributed. Thank you again—not only for the findings, but for approaching the project with such care. I’m excited to learn more about your work and to help turn these discoveries into improvements for the wider community. Best, Griffin — Reply to this email directly, view it on GitHub #112?email_source=notifications&email_token=CMFEVHVL4LFQUAXOGXHLJV35MMRHVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTCMJSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18201112, or unsubscribe https://github.com/notifications/unsubscribe-auth/CMFEVHUDFXZUNBMOCB7PLS35MMRHVAVCNFSNUABJKJSXA33TNF2G64TZHMYTEMJVGE4TAMBSGQ5UI2LTMN2XG43JN5XDWMJQGY3DANBRHGQXMAQ. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/CMFEVHSZHSC4TSKHZHWTFBT5MMRHVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTCMJSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM and Android https://github.com/notifications/mobile/android/CMFEVHTUA7VCP2TSM2LYPP35MMRHVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTCMJSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[STE1200]

slik_rvt_scripts_260902.zip
260902_DIGEST_findings_for_rvt_rs.md

Hi Griffin,

you asked for our raw material rather than polished issues — here it is. Attached/below is a consolidated English digest of all six findings (F1–F6), with byte offsets, evidence, per-claim confidence marks, and — deliberately — a "Retractions" section: two claims we made while our own dump was still silently corrupted, plus one broken heuristic of ours, so nobody chases those ghosts. Our Python reference scripts (decompressor, schema parser, parameter reader, form-geometry decoders) are included; consider them Apache-2.0, use them freely as evidence or test references. The two 2014 sample files are manufacturer-published (Stertil BIM library); we won't redistribute them, but the digest carries their SHA-256 hashes for provenance, and they are publicly downloadable.

On the container-layer PR: please go ahead and implement it on your side — you'll be faster in your own codebase, and honestly our team's Rust is not our strong suit. What we can genuinely contribute is verification: we'll run your stream-evidence harness over our 2014 corpus and post the JSON reports, and we can re-run our full geometry pipeline against any fix candidate — our gzip-trailer and catalog-value oracles make regressions visible within seconds.

Releases that matter to us. Both ends, unfortunately: manufacturer libraries lag years behind (2014–2020 .rfa is the norm, which is why the 2014 layouts in our digest matter), while consultant .rvt files are current (2021–2026).

Where rvt-rs created friction.

The decompression issue (now #151) — silent, and it poisoned weeks of our early analysis.
The schema tooling stopping early on 2014 files, and the tag semantics (digest F4).
The biggest gap for us: there is no element-level API yet — "give me all elements with resolved class names, their owner tree, their parameters, and (for families) their form geometry". Our digest F2, F3, F5, F6 are essentially the raw material for exactly that layer.
The reconnaissance docs are excellent for researchers; a short "how do I get X out of a file today" page would help users.
What would make rvt-rs most useful to us, in order: (1) the paged decompression fix with per-chunk trailer verification where available; (2) element enumeration + class resolution (header/body directories); (3) parameter access including BuiltInParameter ids; (4) family form geometry (sketch loops, extrusion/sweep/revolve semantics including the void flag) exportable as plain curves/solids — we take it to Rhino from there, so IFC export is less critical for us than clean geometry primitives.

We'll keep everything in this discussion public; nothing in the digest is sensitive. Looking forward to seeing what you build from it — and we'll happily test every step against our corpus.

Best, Steffen

[jakobhirn-bit]

Hi,

Notes from a parallel effort, with answers to a few of your open issues

We have been reverse engineering the same format from the other side for a
while, in JavaScript rather than Rust, and we read a different set of things than
you do. We are preparing to
open source our side of it, and we would rather line up with what you are
building than run a parallel effort.

Caveat before the details: our corpus is Revit 2024, 2025 and 2026, and most of
the byte work was done on 2026 files plus the public Autodesk sample projects.
Yours is 2024_Core_Interior. Where that matters we say so, and you should treat
every claim as something to re-measure on your fixtures rather than adopt.

---

First: thank you for F1, it was a live bug in our reader

@STE1200, your checksum-page finding cost us an evening and was worth every
minute of it. We had a note in our own tree reading "raw deflate with a
non-standard trailer", which was a description of the symptom and not an
explanation. 65249 is not an arbitrary number once you go looking for a period
in the stream, and we never went looking.

Measured on our corpus, the same stream inflated raw against page-stripped:

file	members raw	stripped	bytes raw	stripped	inflate failures raw
rac basic sample 2026	1141	1156	106,317,774	107,689,125	15
Snowdon Towers 2024	4497	4604	431,870,248	442,153,012	107
sample 2025	1892	1920	180,835,116	182,662,101	28

Zero failures after the strip in all three. That is the self-check that confirms
the page arithmetic, and it is why we trust the numbers.

Why we never saw it: we split the stream at the gzip magics and inflate each
member on its own, so a member sitting inside one page comes out undamaged, and
almost all of them do. Only members crossing a page boundary are hit, 5 of 1156
in the small file. The damage therefore scales with page count, which is to say
with file size. 283 pages cost us 15 members, 461 pages cost 28, and 1389 pages
cost 107 members and 10.3 MB.

That matters to us beyond the missing bytes. Our wall reconstruction is exact on
the small sample and collapses on large models, 0 of 1128 wall areas within 5
percent on Snowdon. We had put that down to our own geometry being overfitted to
one reference model, which it partly is. It is now also a live candidate that
some of those elements were simply in members we never saw. Re-measuring, and we
will report the number either way, including if it turns out to change nothing.

The sentence we will be quoting internally for a while is yours: "Ran without
error is not evidence of correctness here." Complete Huffman codes cannot fail,
so the decoder runs on and hands you plausible garbage. Wherever we frame a
compressed stream ourselves we now want an independent probe rather than the
absence of an exception.

Two things in your digest we did not have

F2, ElemTable as an ownership tree. This is the one we should have found and
did not. We use Global/ElemTable only as an arbiter to decide which record
framing a file uses. Our assignment of geometry to family instances is a cluster
heuristic that we have rebuilt three times and still do not trust, and owner
chains running curve to sketch to form to subfamily to root are exactly what
that heuristic is a poor substitute for.

F6, the curve records. We read sketch lines from the record bounding box,
which works because a line's box is the line. It also means we cannot see an arc
at all: a box cannot distinguish a chord from the arc over it. Your marker with
explicit line, arc and conic layouts is a capability we simply lack. The style
byte at header+43 separating boundary lines from sweep path and revolve axis is
also a cleaner answer than our inference from how many sketches sit under a
form, and the two agree, which is reassuring for both.

Our own caveat applies in both directions: your offsets are from a 2014 family,
ours from 2024 to 2026. Neither of us should adopt the other's numbers without
re-measuring.

---

#238, the wall join decision does have a carrier: the record bounding box

You write that "Revit's per-pair join decision (allow/disallow join, butt vs
mitre) has no identified carrier in the element records". We think it does, and
it is the box you already parse.

The bounding box in a wall record is join resolved, but only upward. It is the
union of

1. the raw rectangle, axis x type width, and
2. the corner extensions at the ends where this wall wins the join.

The loser's cutback is not in the box. That asymmetry is the signal. A wall whose
box reaches past its own raw rectangle at an end won that corner; a wall whose
box stops at the raw rectangle either lost it or has no join there.

Amounts, measured:

• The winner extends by half the width of the neighbour, not its own. On the
  Autodesk sample, wall 234869 (0.663 wide) extends by 0.197, which is half of
  0.394, the width of 430064. Oblique: ½·w_n / sin θ.
• The loser is cut back by the same ½·w_n and ends on the winner's face, so the
  corner is volume neutral overall. The common approximation "cut both by half
  the neighbour width" loses w_n · h · B per corner.
• The box extension at the winner's end is the outer corner point of its own
  band: ext = ½w_n/sin θ + ½w_self·|cot θ|. Checked on the sample pair
  493697/493790 at θ = 37 degrees: measured 1.371, formula 1.372.
• Mitre is the case where both walls show the extension in their boxes.
  They split the corner diagonally and neither axis length changes. Pair
  493612/493697 is exactly this case and it is readable from the bytes.
• T joint, an end meeting the run of a neighbour: the abutting wall always
  loses, −½w_n/sin θ, and the through wall is untouched.
• Collinear, θ near 0: no overlap, no change at either end.

That gives you the disqualifying predicate you asked for. Your 31 over trimmed
ends that were "accidentally exact untrimmed" should be the winners, and the box
says so. Where there is no box evidence, for example a wall with an approximated
axis or a join switched off, we leave the corner at zero and label the result
approximate rather than guess.

Measured on a purpose built test file with Revit API ground truth and on
rac_basic_sample_project_2026. Not yet checked on a 2024 file.

#223, +0x46 and +0x4a are flags, not a schema class join

In our corpus the u32 at +0x46 is a flag word, and we have attributed its low two
bytes:

• Byte +0x46, bit 0x10 = driven. Set on everything whose extent does not come
  from its own sketch but from outside: host stubs inherited from the family
  template, beam stubs, height driven columns. Where it is set, the stored
  bounding box is the template state, not the placed object. Measured across 17
  family templates: 0x28 on all 20 freely modelled forms, 0x38 and 0x39 on the
  four driven ones.
• Byte +0x47, bits 0x06 = solid. Set means solid, cleared means void. Measured
  on purpose built pairs, box 0x0f against void 0x09, and on the template
  families, 0x4f against 0x49.

+0x4a we have not attributed.

If that holds on your records, the correlation with class you are seeing is
probably not a schema class id but the fact that different classes have very
different proportions of driven and void bodies. That would be worth ruling out
before you invest in the join, since a join claimed on a correlation would be
wrong in a way that is hard to see later.

Honest scope: we measured these on form records inside family definitions in 2026
files, you are looking at project partition element records in 2024. Same field
offset, possibly not the same field.

#228, the reference lists

We see the same structure and read it as several lists rather than one. Two
observations that may save you a pass:

• The leading entries are constants that repeat across all records of the same
  kind, not element references. Curtain grid lines, for instance, carry
  [195, 86961, <wall id>, <own id>], so the owner sits at a fixed position and
  is confirmed by a second list holding [34702, <wall id>]. Cross checking two
  lists against each other is cheap and catches misframing.
• The type reference is not always in the same list. On stairs we had to take
  it from the fifth list rather than the second, and a rule that assumed one
  position produced silently wrong types. Worth validating per class instead of
  globally.

#88, compound layer thicknesses are fully decoded

The layer list is [0xffffffff][0x65 0x11][count u32], then per layer

[f64 width][u64 materialId | -1][i64 -1][u32 f1][u32 f2][i32 -1][u32 index]

40 bytes each, with a leading 0x01 from the second layer onward. The index field
counts up, which makes the parse self validating. Membranes have width 0 and
f = (100, 999). The f-values are the MaterialFunctionAssignment codes.

One trap that cost us a release: the f64 sitting at the block entry is layer one
only. Total thickness is the sum, and a single layer read there looks plausible
on single layer types and is silently wrong on everything else.

Verified against the Autodesk sample: "Exterior - Brick on Mtl. Stud" comes out
as 90 + 76 + 0 + 19 + 152 + 0 + 13 = 350.0 mm.

#95, curtain walls: the grid is in the file

Grid lines are their own records under CurtainGridsWall (-2000321), class 1028,
and the bounding box is the line: two of the three extents are zero. The
owning wall is in the reference list as described above. We checked ids and
endpoints one to one against CurtainGridLine.FullCurve from the Revit API.

Two things follow that are worth more than the grid itself:

• Revit stores the lines already trimmed to the wall profile. A gable curtain
  wall therefore describes its own outline: we fitted the ridge from the trimmed
  line ends to (-87.5 / 8913) mm, the wall's profile sketch says (-87 / 8913) and
  the wall bounding box ends at 8913. No roof intersection needed.
• The panel is the grid cell minus the mullion bodies that actually touch it.
  Not half a mullion by rule. Where a grid line carries no mullion the panels meet
  flush, and we have a wall in the sample where exactly that happens. Watch the
  edge case where a border cell is narrower than the mullion and disappears
  entirely.

That reproduces all 48 panels of the sample project, 40 of them within 1 percent
of the Revit area. The three that miss are double leaf glass doors, where our
ground truth probe measured one leaf.

#90 and #92, two results that save time

Room area and volume are not persisted. We checked three ways: no numeric
parameter on the room, no struct offset, no geometry cache stream, and the only
square metre strings in the file belong to colour scheme legends. If you need
space boundaries you have to construct them. We flood fill inside the room box
against wall bands, and the one thing that made it work was clipping wall axes to
the wall bounding box first, because untrimmed axes cut into neighbouring rooms.

Ceilings are nearly free. On a large public sample, 50 of 67 ceilings match
within 1 percent with the trivial rule, area equals the large face of the box and
volume equals the box. Before writing a decoder, measure how far the box already
gets you per category. It is a poor source in general and an exact one here.

---

The record envelope, since it is your stated blocker

For files written by Revit 2024 and newer:

+0x00  u64   element id
+0x08  i32   record length
+0x0c  u16   marker           <- constant per Revit version, table below
+0x0e  u32   n                <- number of parameter declaration entries
+0x12  n x 22 bytes           <- which parameters are set on this element
       i64   BuiltInCategory  (negative, the public enum)
       u16   class number     (file local, NOT stable across files)
       6 x f64  bounding box
       reference lists

Scanning for the marker at +0x0c and validating against the length field finds
the records without an index. On a 19 MB project that yields about 81000 records.

The category is the documented BuiltInCategory enum, so typing records does not
need a per class decoder. The class number is per file, so a class table built
from fixtures will not survive a different file. That one bit us.

The n x 22 block declares which parameters are set, not their values. It is
useful on its own: it tells you what a type carries before you can read any value.
On stairs it was the only way to tell the construction mode, because the values
themselves still held template leftovers.

Marker to Revit version

Read from BasicFileInfo and correlated across 253 files:

2010 0x364   2013 0x48f   2017 0x4c2   2019 0x4ed   2020 0x4f8
2021 0x513   2022 0x53c   2023 0x576   2024 0x59f   2025 0x5c7   2026 0x5e5

Your 2014 family reads 0x49D, which drops cleanly between our 2013 and 2017
entries. Two unrelated corpora, same progression, so the table looks safe to
lean on.

The break is between 2023 and 2024. From 2024 on you get the layout above. 2023
and older use a four byte framing with the length repeated as a trailer; we can
find those records but we have not decoded their interior and we stopped, because
the current three versions cover what our users bring us. If you have 2016 to
2023 working, that is the one place where you are ahead of us and we would take
the help.

Parameter values

Value blocks are framed as [owner u64][56 x 0xff][3 x 0x00] with two channels:

1. String sections, [count]([defId i64][len u32][UTF-16])*. A negative defId
   is the public BuiltInParameter enum, on 2026 too, so those resolve with no
   lookup table. Positive ids point at shared or project parameter definition
   elements. There is a numeric variant of the same shape,
   [count]([defId i64][f64])*, ascending by defId.
2. Anchor entries, [0xffffffff][slot u16][payload]. Payload type is slot
   specific with no table, but learnable: take instances that chain, require
   consensus across them, reject self validating shapes that fail. One trap, a
   slot appearing several times in one block is a struct array, not a repeated
   parameter, and treating it as a parameter floods the result with noise.

Slot ids are constant only inside one Revit version. 2024 and 2026 disagree.
Lengths are internal units, decimal feet.

Sketches and solids, for #156

The kind of a solid is not in a class number. It follows from how many sketches
sit under the form and how they lie: one profile is an extrusion, profile plus an
axis in the same plane is a revolve, two profiles is a blend and behaves as a
prismatoid h/3·(A1 + A2 + √(A1·A2)), profile plus a path perpendicular to it is
a sweep. Checked against the Revit API, all agreeing to better than 0.01 percent.
Swept blend we could not test because the API refused to build one for us.

A sketch line is a record whose bounding box is the line, same as the curtain grid
lines. Beware that a sketch record carries a box even when its lines are empty,
and that box is the family envelope, not the profile. We built a rule on it once,
it linked a lot of instances and produced values between 30 percent and 1261
percent wrong.

One more negative result

Family geometry of loaded families is usually not in the file as resolvable
forms. In one project with 1034 family instances, exactly one had a form. On the
Autodesk sample, 1 of 168 family clusters has forms at all. It is not a parser
gap, and a pipeline that assumes doors and windows carry bodies will keep looking
for something that is not there. The opening dimensions, on the other hand, are
available from the family type table, width by height plus sill from the value
block, which is the honest source for cutting an opening rather than the
instance box. That is the substance of your #227.

---

Where we are

We are a small BIM consultancy in Austria. We built this because we needed to
read Revit data without Revit, and it runs entirely in the browser, so the file
never leaves the machine. Categories, parameters, type layers, schedules and a
partial geometry reconstruction work on 2024 through 2026.

You can throw a file at it yourself here: https://hirn.consulting/rvtreader
Drag and drop an .rvt or .rfa, nothing is uploaded, the parsing happens in your
tab. The 3D tab is where the geometry reconstruction shows its current state,
warts included. If it misreads one of your fixtures we would genuinely like to
know.

The geometry side is work in progress and we will not oversell it. Walls are
exact on the Autodesk sample and fall over on large real models, 0 of 1128 wall
areas within 5 percent on one public sample. Part of that is a single reference
model being a trap, and part of it may turn out to be F1, which we are measuring
now. Whatever the split, that is where our effort currently goes.

Tell us what shape of contribution is useful: a spec document, a reference
implementation, or test vectors with expected output. We are also happy to write
any of the above up in the individual issues instead of one long post, if that
fits your evidence first process better. And we would like to be corrected where
your fixtures disagree with ours.

This is just the start of it, let's crack the matrix together and end information
oligarchy.

[STE1200]

Hi Jakob, hi Griffin,

Jakob, thank you for sharing your work with us - this is exactly the cross-check we hoped for. We took your claims and measured them on three files before replying: our Revit 2026 project (house.rvt, public, flowbim.ee, with its IFC), the Autodesk rac_basic_sample_project.rvt (the 2017 build, not your 2026 one) and the public BIMcollab example (STR model, Revit 2015, with its IFC export).

1. Your version marker is the Formats/Latest tag of the class ElementHeader. Our 2014 marker 0x49D is that tag in the 2014 schema. Predicted and measured: 2026 → 0x5E5, 2017 → 0x4C2, both exactly your table values, and 2015 → 0x4B1, which your table does not have yet. So a reader never needs the table: it can read the marker off the schema of the file at hand. Our 2014 schema grammar (digest F4) parses all four schemas completely (3619 / 3725 / 3879 / 4690 classes, no abort).

2. Your "file-local class number" is that same schema — it just sits at +0x4A, not right after the category. The u16 directly after the category is the low half of m_familyId (mostly 0xFFFF, which is why it looked unstable). The ElementHeader class in the schema lists its fields — m_categroryId, m_familyId, m_ownerViewId, m_designOptionId, m_unplacedOwnerId, m_miscId, m_viewRules, m_abFlags4Bytes, m_classDef, m_pBBox, m_parents — and laid on the bytes, m_classDef is the u16 at +0x4A (2024+, n = 0) and at marker+38 before 2024. It resolves through the file's own Formats/Latest on 100 % of category records in all three files (35,814 / 30,093 / 21,306), and all 59 IFC walls of house.rvt resolve to SWall. Your +0x46 is m_abFlags4Bytes, so Element record +0x46: the flag word is unread (+0x4a is the schema class, RE-76) #223 has both answers: +0x46 is the flag word (Jakob), +0x4A is the schema class reference (Griffin). The number is per-file because the tag is per-schema; the name is stable.

3. Your 2024+ record envelope holds, with a precision, and pre-2024 is the same envelope with 4-byte ids. Scanning the u16 marker at +0x0C and validating with the length field chains 99.5 % of 132,551 records in the 2026 file. The length counts the body AFTER the 16-byte head [u64 id][i32 len][u16 marker][u16 n_lo] — we first read it as including the head and got 0 %. Category is at +0x12 + 22·n as you describe; 27 % of records carry a real BuiltInCategory, 73 % carry −1. Before 2024: [u32 id][u32 len][u16 marker][u16 n], length counts the body after the 12-byte head, chaining 99.5 % (2017) and 98.8 % (2015); the header interior has the same field order with u32 ids, the flag word at marker+34, m_classDef at marker+38, the bounding box at marker+52 (2024+: +0x58). We did not confirm the "length repeated as trailer" — the u32 before the next record equals len in about 40 % of cases and len±4 in most others.

4. Your wall-join box asymmetry (RE-26 follow-up: 31 over-trimmed wall ends on 16 walls — join decision has no identified carrier #238): confirmed on all three files, with IFC ground truth on one. Per wall end we measured where the record box ends inside the neighbour's thickness band (0 = near face, 0.5 = axis, 1 = far face). At T-joints the abutting wall's box ends on the through wall's axis in 14/19 (2026), 39/49 (2017) and 36/36 (2015) cases. At L-corners the pattern is (axis, far face) for butt joins — 26, 18, 31 corners — and (far face, far face) for mitres: 3, 2 and 33. The two mitres in the Autodesk sample are 493612/493697 (your pair) and 628523/849032. In the 2026 file we also have a second box per wall that is the cut body: at the abutting/losing end it stops at the neighbour's near face while the record box reaches the axis, so "the loser's cutback is not in the box" is visible directly. The BIMcollab file makes that a ground-truth statement: record box minus IFC body along the axis is 0 at 155 ends and exactly +50.0 mm = half the 100 mm neighbour at 70 ends; lateral extents agree on 113 of 114 walls. Lateral growth of the box is 0.00 mm on all 59 walls of house.rvt. Not tested: oblique joins (none in these files).

5. Flags. The flag word is at your offset in all three files (m_abFlags4Bytes), values on walls 0x1929 (2026) and 0x0928 / 0x0100002A / 0x0108104B (2017). On project walls bits 0x06 of the second byte are never set, and walls are solid, so the solid/void reading is specific to form records as you said. One caveat for readers: on records with n > 0 the offsets shift by 22·n (526 such records in the 2026 file, walls with base/top offsets among them).

What we can offer for 2016–2023: the interior above is measured on 2015 and 2017 project files and on a 2014 family; the body directory, sketch curve records (line 8×f64, arc 12×f64, conic 13×f64), extrusion/sweep/revolve parameters and the void flag are in digest F2–F6. If you have a 2019–2023 file you are allowed to share, we will run the same probes and report tag, envelope and join numbers. Scripts are Python, Apache-2.0, on request.

Griffin — three things from the above for rvt-rs: read the record marker off Formats/Latest instead of a version table; resolve m_classDef (marker+38 / +0x4A) through the same schema to get class names without a per-class decoder; and Jakob's page-strip numbers on three large projects are the third-party confirmation of #151.

Best, Steffen

[DrunkOnJava]

Hi Jakob,

The connector references RE-134 located and left undecoded, near +1,060 from a duct's or pipe's connector-manager anchor, are decoded now (#550, RE-138), and they reproduce Revit's own connections. Measured on GitHub's runners on the MIT RE1 Mechanical and Plumbing models against Revit's IfcRelConnectsPorts.

The lists. After the anchor a join is a counted list of two references: [u32 2][u64 the duct or pipe, u32 connector index, u32 1][u64 the element joined, u32 connector index, u32 1]. A join is written in two blocks, the earlier at 1,021 to 1,130 bytes from the anchor and the later at 1,217 to 1,362. The later block carries the curve's own connector index as Revit numbers it; the earlier block carries it inverted (0 for the connector Revit calls 1). The index of the element joined is Revit's in both. Read that way, the lists give 50 of the 53 connections of Revit's export that involve a duct or pipe on Mechanical (94.3 per cent) and 102 of 108 on Plumbing (94.4 per cent).

The export. rvt-rs now writes an IfcDistributionPort per connector, an IfcRelConnectsPortToElement per port and an IfcRelConnectsPorts per join whose two elements are exported as distribution elements: 53 of 59 on Mechanical and 112 of 118 on Plumbing, every port tied to the element its name gives, and IfcOpenShell's IFC4 validation of both files finds nothing. A port on equipment written as a building element proxy is a schema error in IFC4, so there is none.

What is missing. Flow direction: Revit names a port InPort or OutPort and gives it SINK or SOURCE, and the same connector index is In on some pipes and Out on others, so it is the system's flow, which these lists do not carry. We name ports Port__ with the direction undefined. And fitting to fitting and fitting to equipment connections, which are 14 of Mechanical's 73 and 8 of Plumbing's 126, are not read: we have only looked at the lists of ducts and pipes. If your reader has found where a system's flow direction is stored, or a fitting's connector list, we would like to know.

Credit for the connector entries that led here is in the report, the changelog and the PR.

Best,
Griffin

[DrunkOnJava]

Hi Jakob, hi Steffen,

Thank you both, and sorry for the silence on this thread. Jakob's notes and Steffen's cross-measurement on three more files are the kind of independent check this project needs. Several of them landed on issues we had marked as having no identified carrier, and three are now merged, each credited to you in the issue, the report and the changelog.

Merged since your posts, measured on our fixtures (Core Interior 2024, the four MIT RE1 models 2025, Autodesk Snowdon Towers 2024 locally):

• F1, the page strip on Formats/Latest (Formats/Latest is inflated without the page strip; the schema drifts after ~140 KB in every file and parsing stops at 64 KB to hide it #410): it was inflated without the strip, which your numbers predicted. With the strip, the stream's own gzip CRC32 and length trailer verify on all 23 files we hold (and fail without it), and the 2024 schema reads 4,126 classes instead of 395.
• The class at +0x4A (Element record +0x46: the flag word is unread (+0x4a is the schema class, RE-76) #223, RE-76): it is the class's definition ordinal in the file's own Formats/Latest. Every element we export on Core Interior, RE1 Architecture and Snowdon Towers resolves (SWall, ArcWall, Floor, RoomElem, FamilyInstance and so on), and each carries it as RevitClass.
• Parameters (M4-07: Recover common parameters #35, RE-77): your value blocks, [owner u64][56 x 0xFF][3 x 0x00], with BuiltInParameter-keyed UTF-16 strings inside. We read three type parameters from them. On Snowdon Towers, Type Mark agrees with the model's VIM export on 1,257 of 1,276 elements (the other 19 are empty there), Description on 70 of 70, and Fire Rating with Revit's IFC4 export on 696 of 696. Instance parameters and numeric values are not read yet.

Still open:

1. RE-26 follow-up: 31 over-trimmed wall ends on 16 walls — join decision has no identified carrier #238, the box-asymmetry rule. An interim measurement on Snowdon: the box equals Revit's wall end at 853 of 1,860 ends, extends past it at 674 and falls short at 333. It is not a simple rule yet; we are normalising by the neighbour's band next.
2. The record marker as the ElementHeader tag, so a reader needs no version table, and the pre-2024 envelope Steffen measured on 2015 and 2017. This is the most promising route to element records outside 2024 and 2025.
3. Room outlines: 7 Snowdon Towers rooms still drawn as their box (room solid edge topology) #90 and Opening geometry: cut the IfcOpeningElement from the wall location curve instead of the door/window bbox; recover the 63 slab/shading-device penetrations #227: room area not persisted, and opening sizes from the family type table rather than the instance box.

Two questions:

• Steffen, may we record house.rvt (flowbim.ee) and the BIMcollab 2015 model in our reference list (docs/reference-models.md: source, hash and licence only, fetched from origin, never vendored)? If their licences don't allow redistribution, we would list them as local-only oracles, as we do for Snowdon Towers.
• Jakob, test vectors with expected output would help most: a record's bytes (or its file, offset and sha256) and what you read from it. They go straight into our probes and can be checked on both sides.

Thank you for the scripts and the digest; we are working through them. A 2019 to 2023 file either of you can share would be very valuable, since that range is where neither of us has an oracle.

Best,
Griffin

[STE1200]

Hi Griffin,

Great to see the three merges — the schema going from 395 to 4,126 classes on the 2024 file is the page strip doing exactly what it did for us, and the Type-Mark match against the VIM export is a nicer oracle than anything we had for parameters. Congratulations, and thanks for the clean credit trail.

I'm attaching material
slik_rvt_test_vectors_260928.zip
rather than posting it: everything in it is yours to use in the repo with the usual credit, I'd just rather hand it to you directly than to the whole thread. Three parts: your questions, a test-vector pack, and one open item.

1. Reference list — yes to both, provenance below.

AA-SingleDwellingHouse-RVT-CIADD.rvt — Revit 2026, public download from flowbim.ee (https://flowbim.ee/files/content/cci/ENG/AA-SingleDwellingHouse-RVT-CIADD.rvt), SHA-256 eeff78f3d07dc23397d276f870f42240cb453cfdd39d965531a9d0ccc7d0a654; paired IFC …-CIADD.ifc, SHA-256 c9e2986c0f349b3aee0973a15d598c9fc82955e0b4d75b4e8ff99808be767342.
02_BIMcollab_Example_STR.rvt — Revit Architecture 2015 (build 20141119_0715), from the public BIMcollab example project package, which also ships the IFC2x3 export (02_BIMcollab_Example_STR_optimized.ifc), SHA-256 8cd1f122e751c33ea69e6f16c23ed4cd572ded3d0d04dfab50aaf0973e38e193.
As a third if useful: Autodesk's rac_basic_sample_project.rvt, 2017 build (20160130_1515), SHA-256 a1d3d0775ae0937e3f4c8fb97015b6e0884acefae52435d9cacd27d008f5fefb.
2. Files for the 2019–2023 gap. No project file in that window on our side, but two manufacturer families that are public downloads and carry the 2018 and 2022 schemas:

Geberit VariForm washbasin PRO_1833290 — Revit 2018 (build 20190510), ElementHeader tag 0x4EB; SHA-256 28b9d11116bb8b2a5b6af100918e7e4a4836d8f324d7a564b5f95e764872e5e4 and 0d48b22ca0fc18071705adab4fe2300c745cf155bd9b6eb9c4a2fc0c5be6fbb9 (two variants). Geometry is two DirectShapes with tessellated meshes — we decoded the mesh record (vertex block in f32 feet, u16 triangle indices, a repeated counter as anchor), a different channel from sketch forms.
Pucciplast Cassetta Eco 9/4 l flush tank — Revit 2022, tag 0x53C; EN variant SHA-256 a610ffcc3737c3f585bf5a391a4dc5a0141a15bc5d148240adacd6aaff81ae00. 17 sketch forms, 5 voids, dimensions match the manufacturer PDF; our sketch pipeline runs on it unchanged.
Same provenance class as the Stertil file: manufacturer downloads, reproducible by hash, not for redistribution in the repo.

3. Marker off the schema — the full row. ElementHeader tag read from each file's own Formats/Latest: 2014 → 0x49D, 2015 → 0x4B1, 2017 → 0x4C2, 2018 → 0x4EB, 2022 → 0x53C, 2026 → 0x5E5. In all six the u16 record marker equals that tag; a reader needs no version table.

4. Test vectors (attached). test_vectors.json plus a human-readable TEST_VECTORS.md and the generator script. Thirty vectors over five files (2014 family, 2022 family, 2015 project, 2017 project, 2026 project). Each vector gives file SHA-256, stream, byte offset in the page-stripped inflated stream, the raw bytes in hex, the field offsets inside the record, and the values we read. Kinds:

element_header — walls (and one Floor / FamilyInstance per project) with id, marker, category, flags, m_classDef resolved to the class name through the file's schema, and the bounding box in feet and mm. Six of them carry an IFC oracle: the IFC body of the same wall, reduced to oriented length / thickness / height so it is rotation-free. Five match to the millimetre; the sixth (house.rvt 381170) is 245 mm shorter in the IFC — exactly half the 490 mm thickness of its neighbour, i.e. the #238 cut-back in one number.
form_body (2014) — two ExtrusionElem bodies with head, Element-id block, m_cutting and the START/END doublemap: one solid (±828.5 mm) and one void (−1655 / +1015 mm).
curve_record — line and arc records inside VarSketch bodies (2014 and 2022) with endpoints.
param_pair (2022) — the [f64][i32 builtin] pairs for EXTRUSION_START/END.
elemtable_record (2014) — sketch → owning form.
Also in the pack, per project file: header-record count and chaining rate (99.5–99.8 %), and for the two files with IFC: 114/114 and 59/59 IFC walls have a header record. Two caveats written into the JSON: in family files the field at base is an ElementId, not a BuiltInCategory (−1 = none); and the 2022 START/END pairs are located by key search, not by a fixed offset — we have the fixed layout only for 2014.

5. RE: Validate Global/ElemTable body as a versioned ownership tree #152. Our note on the ElemTable frame still stands — 6-byte head, first record at 0x06, owner id at the record END; in the shifted frame we measure 251/1070 and 76/734 self-owning or cyclic records, in ours 0/0. No urgency; the dumps are ready whenever it fits your milestone plan.

If the vector format works for you, we can produce the same for any further file you can point us to (2019–2023 especially), and we'll re-run the pack against rvt-rs releases as you land the fixes.

Best, Steffen

[DrunkOnJava]

Hi Steffen,

Thank you. The pack arrived intact, and it is exactly the shape that helps: bytes, offsets and the value read, checkable from either side. We'll use it with credit, as you describe.

Marker off the schema. I checked your row on our side today. The ElementHeader tag, read from each file's own Formats/Latest across 22 files:

release	tag
2016	0x4B1
2017	0x4C2
2018	0x4EB
2019	0x4ED
2020	0x4F8
2021	0x513
2022	0x53C
2023	0x576
2024	0x59F
2025	0x5C7
2026	0x5E5

• On all eleven of our 2024 and 2025 files (Core Interior, Snowdon Towers, the four RE1 models, two 255ribeiro projects and the family corpus), the record-header constant we had measured per release is that tag.
• Our 2023 reader already takes it from the schema (RE-81).
• Your 2017, 2018, 2022 and 2026 values match ours exactly.
• Our 2016-labelled family carries 0x4B1, the tag you list for your 2015 project.

So the rule holds everywhere we can check it. The next step is #421: derive the marker from the schema instead of the release table. I'll record this there.

house.rvt 381170. Your 245 mm, half of the 490 mm neighbour, is RE-26's rule in one number: an end is cut back by half the thickness of the wall whose centreline lands on it. Since today that solver also runs on Revit 2023 records (RE-120), where it gives all 17 walls of a 2023 project Revit's exported box. An independent confirmation on 2026 is very welcome.

Reference list. Thank you for the provenance. I'm adding house.rvt, the BIMcollab 2015 model and rac_basic_sample_project 2017 to docs/reference-models.md with source and hash, credited to you. They are listed as local-only and not yet measured by us, and nothing is vendored. The Geberit and Pucciplast families go in the same way.

2019–2023. Since your post we have two 2023 projects with Revit exports (local only) and Einhoven (2023, MIT, magnetar-io/revit-test-datasets), plus the public phi-ag/rvt family corpus for 2016–2026. If you're willing, element_header vectors on Einhoven would give 2023 records a second reader. That is the release where only we have measured the 32-bit record layout so far.

#152. Noted. We haven't re-measured our ElemTable frame against yours yet. When we pick it up, I'll ask for the dumps rather than guess.

Thanks again,
Griffin

[jakobhirn-bit]

Hi Griffin,

thanks for the credit trail, and for saying plainly what helps. Here are the test
vectors you asked for. Everything below is from the two public Autodesk samples we
both hold, so you can check it from your side without anything from us.

Files (sha256 of the .rvt):

• rac_basic_sample_project_2026.rvt — bc547fe94274a17abbea89330fcf8800b85652e0b8e25562b153c102af3d99dc
• Snowdon Towers Sample Plumbing.rvt — 4f80526bd7823172e236d8c88968210a56c718e69a54a18b7919b3ae5610ae0a
  (the hash in your docs/reference-models.md)

Offsets are into the decompressed stream, page strip first, then inflate, as in F1.
Partition 0 of the Plumbing file is 214,169,636 bytes after decompression.

1. The schema gives every class number, not only the record marker

You merged the marker as the ElementHeader tag (RE-80). The same count gives every
other class number, and the file checks the count itself.

Count class definitions in Formats/Latest in stream order, starting at 12. An entry
is [u16 len][name][u16 P]; P & 0x8000 means the parent follows inline and takes the
next number. A field is [u32 len][name][u8 type][u8 kind][u16 C], and at type 0x0e
with C & 0x8000 the class follows inline and takes the next number.

The check: every one of those inline references names the number the count has just
reached. rac 2026 has 1,086 of them, Snowdon 2024 has 1,015, and in both files every
single one agrees. So the count is not a guess, the file confirms it a thousand times
over.

What we read off it, 2026 / 2024:

class	rac 2026	Snowdon 2024
ElementHeader	1509 (0x5E5)	1439 (0x59F)
Family	1967	1872
FamilyInstance	1989	1894
FamilySymbol	2022	1928
ContentMarker	931	891
ElementParents	1521	1451
FamilyInstancePatternHelper	1994	1899
InstanceInfo	2463	2353
RbsPipeCurve	3503	3349
RbsCurveConnectorManager	3432	3277

Three places where we had a fixed value and the class number replaced it:

• ContentDocuments section header. [u16 T][ff x4][u16 T-1][ff x4][16 B GUID],
  T = ContentMarker. rac starts a3 03 ff ff ff ff a2 03 ff ff ff ff, the Plumbing
  file 7b 03 ff ff ff ff 7a 03 ff ff ff ff. Searching for the 2026 bytes in the 2024
  file finds zero sections, so no family documents at all.
• Anchor before a nested placement matrix. ff ff ff ff [u16 FamilyInstancePatternHelper],
  then 12 f64 and the type id. 0x07CA in 2026, 0x076B in 2024.
• Axis anchor of an element record. ff ff ff ff [u16 ElementParents], then 6 f64.
  0x05F1 in 2026, 0x05AB in 2024.

2. The placement block: the matrix is not at a fixed offset

A placement head is [u64 id][u32 3][u32 0][ff ...]. We had the 12 f64 at head + 60,
which is right for 2026 and wrong for 2024: the 2024 layout has a second block in
between and the matrix sits at head + 84.

The structure holds in both. The matrix follows an anchor
04 80 08 00 | ff ff ff ff | [u16] | 00 00 00 00 | ff x8 | 00 x6, and the 12 f64 start
28 bytes after the anchor. Search the anchor from head + 24 and take head + 24 ... + 88
as the window.

Measured: on rac both rules find the same 385 placements. On the Plumbing file the fixed
offset finds 3 and the anchor finds 3,148.

3. Pipes: centreline and outside diameter, with a proof

This is your RE-129 negative and the geometry behind RE-130.

Test vector, Plumbing file, partition 0:

• Pipe element 1380417, record at 490615, length 1645.
• Record bounding box (6 f64 in the record): 21.7783 17.2812 30.6340 .. 22.1565 17.6562 31.8909.
• Its section body runs 19231968 .. 19233720 (section-chain bounds).
• Centreline. The body holds entries [u64 id of the connected element][u32][u32][3 x f64 point].
  At section + 1409: 41 10 15 00 00 00 00 00 00 00 00 00 01 00 00 00 then the point
  21.9658 17.4687 31.8904. At section + 1483:
  5d 1f 19 00 00 00 00 00 01 00 00 00 01 00 00 00 then 21.9690 17.4687 30.6345.
  Take the points that lie inside the record box; the two furthest apart are the ends.
  This pipe is slightly sloped, so its box diagonal is not its axis.
• Nominal size. At section + 140: cd 0c ff ff ff ff ce 0c then two f64, both
  0.3333 ft. The tags are RbsCurveConnectorManager and that class + 1 in the file's
  own schema (3277 / 3278 on 2024, 3432 / 3433 on 2026). For ducts the same two f64 are
  the width and the height.
• Outside diameter. Not stored as such, and the nominal value is not it: this is a
  4 inch pipe with a 4.5 inch outside diameter. Derive it: a cylinder with direction u,
  length L and radius r has the half edge |L*u_q|/2 + r*sqrt(1 - u_q^2) on axis q.
  Solve for r on each axis where sqrt(1 - u_q^2) is not near zero. Every such axis has
  to give the same r, and the box rebuilt from the cylinder has to match the box read.
  For 1380417 that gives r = 0.1875 ft on both well-conditioned axes.

That last step is the proof, not a fit: where the axes disagree, we build nothing and
count the case. On the Plumbing file 3,006 of 3,056 pipes pass. For the other 50 nothing
is missing (box, section and axis are there on all 3,056), they just fail the check.

Ducts we have not built. Width and height are in the same place, checked against the box
on four ducts of the HVAC file (14x4, 14x4, 4x4, 4x4 inch). What is missing is round
against rectangular: a 4x4 inch duct can be either, and we have not found the switch.

4. Three of your open issues

• Room outlines: 7 Snowdon Towers rooms still drawn as their box (room solid edge topology) #90, room outlines. We think the issue as framed cannot succeed: Revit does not
  store a room's boundaries at all, it computes them when the file opens. We construct
  them instead, by flood filling inside the room's box against the wall bands from the
  wall geometry, and mark every area produced that way as constructed rather than read.
  14 of 14 rooms on rac agree with Revit's areas.
• Opening geometry: cut the IfcOpeningElement from the wall location curve instead of the door/window bbox; recover the 63 slab/shading-device penetrations #227, opening geometry. Agreed with your RE-121 that the door's record box is not
  its body. What worked for us: take the opening from the regenerated family, that is the
  Left/Right by Bottom/Top references on the host face, and rotate it into the host. The
  instance box carries the 2D swing symbol and is too large.
• CLASS-16: MEP: the duct family, sloped runs, fittings and route geometry left after pipes and ducts #96, MEP fixtures. On the two Snowdon MEP files we now build plumbing fixtures
  179 of 179, air terminals 509 of 509 and pipe accessories 126 of 126, as regenerated
  family bodies. Pipe fittings are only 231 of 2,659 and duct fittings 43 of 997: the rest
  are swept blends, elbows and tees, which our shape builder cannot do yet.

5. Your two questions

Test vectors. The three above are meant as exactly that. If you want more in the same
shape, say which layer and we will cut them from the same two files.

A 2019 to 2023 file with an oracle. We do not hold one we can share: our corpus is
2024 to 2026, and everything older we have is client work. One route that costs nobody
anything: Autodesk still publishes the sample project files per release, and the help page
for each of 2019 to 2023 lists rac_basic, rac_advanced and the discipline samples.
Those are the same family of files as the 2026 sample you and we already use. If you want
an IFC oracle for one of them, we can open it read only in Revit 2026 and export IFC4
without saving, so the file itself stays at its release. Tell us which release and which
sample and we will do that.

6. What we took from you this week

Your RE-127 landed on the day we measured the same gap from the other side. We compared
our wall bodies against Revit's boxes on rac for the first time and found we cut walls
short at the ends, by half the neighbour's thickness. The joined-wall lists and the
consecutive-run tie break are the answer we did not have. Same for RE-126: we do not read
the flip byte at all yet, and now we know what it costs.

Also worth saying: F1 is in our reader as well, 64,896 payload out of 65,249 per page. Our
schema stream on rac is 496 KB and the count check above holds at all 1,086 points, the
last of them near the end of the stream, so the strip is doing its job on our side too.

Clean room: everything above comes from byte observation of the two public Autodesk sample
files named at the top and from comparison with Revit's own export of the same file. No
Autodesk or ODA source, no disassembly, no NDA material.

Best,
Jakob

[DrunkOnJava]

Hi Jakob,

Thank you. This is the shape we asked for: each claim comes with a hash, an offset and the value read. Where each part stands here.

Pipes (your section 3). Your entry layout holds on a licensed file. On the MIT RE1 Mechanical and Plumbing models (Revit 2025), the connector entries [u64 element][u32 index][u32 1][3 x f64] hold exactly the points at which Revit's own IFC starts and ends each pipe's extrusion, and your cylinder-box inversion gives Revit's radius. All 69 pipes (6 and 63) now export as circle-profile cylinders whose radius, axis ends and length match Revit's export to 0.00001 ft. Before, none had the profile and 23 had the right axis. It is in #522, with the finding in reports/element-framing/RE-131-pipe-cylinders.md and the run in Measure 36723473598. Credit is in the report, the changelog and the PR.

Three things we saw on RE1. At a connected end the entry is keyed by the element connected there, as you describe: pipe 442026's two ends are keyed by 442040 and 442191, two Closet Bend fittings that Revit's export places 0.1413 ft beyond the pipe's ends on its axis, each at the end it is keyed for. Pipes 441731 and 441849 have both entries keyed by the pipe itself; we did not check what sits at those ends. The two entries are not at a fixed distance (58 bytes apart for one pipe, 74 for another, and 3,889 for the same one in a second place), and other elements' connectors sit at the same points. So we find an entry by where its point falls in the pipe's box, and keep the furthest pair that passes your rebuild-the-box check. That check matters: an earlier rule that paired a pipe's own start entry with the next entry got one pipe wrong, and the rebuild rejects it.

What is not claimed. Every RE1 pipe runs along a principal axis, so the sloped case rests on your proof and not on an oracle in CI; your 3,006 of 3,056 on Snowdon is yours, on a file we cannot run. We read Revit 2025 only. Ducts and fittings keep their boxes.

Class numbers by definition ordinal. That is how #223 (RE-76) and our schema registry number classes, and the two ElementHeader values in your table are the ones we read from each file's own schema. I have not yet checked the other rows.

2019 to 2023. Thank you for the offer. We are choosing between the 2021 and 2022 rac_basic_sample_project and will tell you which; an IFC4 export from Revit 2026 without saving is exactly right.

Best,
Griffin

[DrunkOnJava]

Hi Jakob,

Two checks on your findings, both measured on GitHub's runners, and one ask.

Your class numbers (RE-133). All 20 values agree. The ten classes in your table, for Revit 2024 and 2026, are the tags Formats/Latest gives in rvt-rs, by the rule you describe: definition ordinals from 12, an inline parent or field class taking the next number. The 2026 column was checked on the Autodesk 2026 family and the 2024 column on Core Interior and the Autodesk 2024 family; Snowdon is not in CI, and the three 2024 files agree with each other and with yours. The same ten are measured on every release from 2016 to 2026, and each MIT project has exactly the tags of the Autodesk family of its release. Table and probe: RE-133.

Pipes and ducts from your anchor (RE-134). After m_pConnectorManager's two tags the curve's fields follow RbsCurve's schema order: width or diameter at +8, height at +16, the type's ElementId at +64. Against Revit's own IFC on RE1 Mechanical and Plumbing, the type id is Revit's type Tag for all 94 (25 ducts, 69 pipes), which is the link RE-129 could not find in the record. A duct's width and height are two of Revit's extrusion dimensions on 25 of 25, and the size text at +514 reads width x height in millimetres on 25 of 25.

The switch you could not find is not in RE1 either. All 25 ducts are rectangular in Revit's export, no redistributable model has a round or an oval duct, and a round duct is stored as width = height, as every pipe is here (69 of 69), so at the anchor it looks like a square one. If Snowdon has round or oval ducts, two cheap checks: whether the size text at +514 carries the project's round-duct prefix or suffix, and whether the u32 after a connector entry's point (1 on ducts, 3 on pipes here) differs between the shapes. What is seen but not decoded, including the connector references near +1,060 that Revit's IfcRelConnectsPorts would be written from, is in RE-134.

A model to settle the rest. Revit names every duct Rectangular Duct:<type>, and we do not guess a family we cannot read, so ducts stay Duct-<id> until there is an oracle. What we would most like is a small model you author and license as you choose (MIT, like the RE1 set, lets CI measure it): round, oval and rectangular ducts, a sloped run of pipe and of duct, elbows, tees and transitions, with Revit's IFC of it. Sloped pipes and fittings have no oracle in our corpus either. If exporting an Autodesk sample is easier for you, the 2022 rac_basic_sample_project would let us look at the pre-2023 element records (#421), and Autodesk's MEP sample project has ducts; we would only use those as local checks, since CI cannot fetch what we may not redistribute.

Best,
Griffin

[STE1200]

Hi Griffin,

here are the Einhoven vectors you asked for, plus the same for 2024_Core_Interior since both sit in the same MIT repo (fetched from origin today, hashes in the README, nothing redistributed).

slik_rvt_vectors_magnetar_260928.zip

Marker off the schema, two more rows. Einhoven: BasicFileInfo says Format 2023 (Build 20230828_1515), ElementHeader tag 0x576. Core Interior: Format 2024 (Build 20230509_0315), tag 0x59F. Both equal your table and both are the u16 record marker of the file. Header records chain through the length field at 99.77 % in both files (4,386 records on Einhoven, 42,319 on Core Interior). Einhoven uses the pre-2024 envelope ([u32 id][u32 len][u16 marker][u16 n], 12-byte head); Core Interior the 2024+ one.

#152, your two open points, measured on your own files.

• First record at 0x06. Both tables open with a 6-byte head (u16 element_count 1,370 / 1,411, u32 record_count 2,615 / 26,425), and the first record starts at 0x06. It is a real record: id 0, id2 0, owner unset, in both files. Tail after the last record: 19 bytes (28-byte layout) and 24 bytes (40-byte layout), same as on our 2014 family and 2026 project.
• Layout by release. 2023 → 28-byte records, u32 owner closing the record; 2024 → 40-byte records, u64 owner at +28. With our frame: 0 self-owned and 0 cycles on both files (owners set 339 / 22,368, every owner declared in the table). With the shifted frame: 7 / 7 on Einhoven and 304 self-owned on Core Interior — your numbers, reproduced independently. Owner classes on Core Interior by the owner's m_classDef: SWall 10,364, VarSketch 3,360, ElementGroup 1,009, Family 189 — the curtain-wall, sketch and group attributions you reported.

So the frame rule is now measured on 2014, 2023, 2024 and 2026; I'd expect 2015–2022 to follow, since the 28-byte layout with the 19-byte tail is unchanged from 2014 to 2023.

Vectors. element_header records with id, marker, category, flags, m_classDef resolved through the file's own schema, and the box: three SWall plus one FamilyInstance on Einhoven, three SWall plus one Floor on Core Interior, and in the ElemTable JSON six further SWall records of Core Interior with distinct length/thickness (5,867 × 152 up to 41,783 × 152 mm, one 16,612 × 152 × 9,449) with their full bytes. No IFC oracle here: the 20 KB 2024_Core_Interior.ifc in the repo carries no IfcWall.

One label to check. Our BIMcollab STR project reports "Autodesk Revit Architecture 2015 (Build 20141119_0715)" in BasicFileInfo and carries tag 0x4B1; your table lists 0x4B1 under 2016 for a family. One of the two labels is off by a year — if your 2016 family was saved by a 2016 build, the tag would be shared across the two releases, which would be worth knowing before #421 relies on it.

Best, Steffen

[DrunkOnJava]

Hi Steffen,

Thank you for the magnetar vectors, and for measuring the #152 frame on our own files. A six-byte head, the first record at 0x06 and the owner as the field that closes each record is the frame #499 landed, so your zero self-owned and zero cyclic records on Einhoven and Core Interior are the same rule confirmed from your side.

Your label question: neither label is off. Our 2016 family's BasicFileInfo reads "Autodesk Revit 2016 (Build: 20150110_1515(x64))", and your BIMcollab project reads Revit Architecture 2015 build 20141119_0715. Both carry ElementHeader tag 0x4B1, so one schema tag spans a late-2014 build labelled 2015 and an early-2015 build labelled 2016. A table keyed by release would misfile one of them; reading the marker from each file's own schema (#421) does not. That is the only pair we have measured.

The eight element_header vectors (three SWall and a FamilyInstance on Einhoven, three SWall and a Floor on Core Interior): we will check ids, classes, categories, flags and boxes against what rvt-rs reads from those files on GitHub's runners, and post the counts here.

Best,
Griffin

[DrunkOnJava]

Hi Steffen,

Your eight element_header vectors, checked on GitHub's runners against what rvt-rs reads from the two files (both hashes match yours): 6 of 8 agree on every field, and the other two are not read for a reason I can name.

Core Interior (2024): 4 of 4. Our record offset is yours exactly (delta 0) for each, and stream, BuiltInCategory, class (SWall 3669, Floor 2017), flags word and box agree. The flags are the u32 at +0x46: 0x1929 on the three walls and 0x0928 on the floor. That is the word our RE-128 reads as m_abFlags4Bytes (crediting this discussion), and its values on Core Interior are the ones RE-128 lists. The box sides agree to 0.05 mm, inside the 0.1 mm your values are rounded to.

Einhoven (2023): 2 of 4. Wall 2808 and the FamilyInstance 5317 agree on the same fields: offset delta 0 on the 2023 envelope too, class tags 3625 and 1856, flags 0x0929 and 0x0928, box. Walls 2921 and 3637 are not returned. Neither ElementId is declared in Global/ElemTable, which rvt-rs requires before it reads a record, and at your offsets the bytes where our decode expects a BuiltInCategory are not one. The records are there (the id, the record marker and the ElementHeader tag are where a record has them), so this is not a framing difference; I do not know what they are. Your pack gives them 0x0939, one bit more than 2808's 0x0929. Einhoven has no Revit export in our corpus, so I cannot say whether Revit exports them either.

The check is examples/probe_re132_slik_vectors.rs with your vectors and credit, and report RE-132, both in #524. If you have a Revit export of Einhoven, or know what the two undeclared walls are, that would settle it.

Best,
Griffin

[STE1200]

Hi Griffin,

thanks for running the eight vectors — 6 of 8 field-exact with delta 0 on both envelopes is the result we hoped for, and the two you did not read are explained. Your ElemTable gate is right to skip them.

Walls 2921 and 3637 are host-wall stubs of family documents embedded in the project. Evidence on Einhoven:

The partition holds 4,386 ElementHeader records, but only 2,522 of them carry an id declared in Global/ElemTable. The 1,864 undeclared records are, by class, a family document's inventory: CategoryElem 279, GStyleElem 279, FontElem 124, CurveElem 109, LinearDimString 100, DBViewType 83, SketchPlane 67, RefPlane 51, VarSketch 31 … — the same class mix as a standalone .rfa (our 2018 and 2022 families).
In stream order, 2921 sits in exactly that context: … Viewport, Viewer, DBViewPlan, DBDrawing, Viewport, BasicWallType 2920 (flags 0x93C), SWall 2921 (0x939), Viewer, DBViewSection, DBDrawing, Viewport … — the template views of a wall-hosted family with its host wall type and host wall. 3637 has the identical neighbourhood (BasicWallType 3636, then 3637, then the views).
Their ids live in the family document's own ElementId space: 3 ids in Einhoven and 4 in Core Interior occur in two header records each, and the undeclared range starts at 2901, inside the project's 0..5465.
Global/ContentDocuments holds 6 section headers in Einhoven and 46 in Core Interior (the [T][FF×4][T−1][FF×4][GUID] header with T = ContentMarker that Jakob described above) — 6 and 46 embedded family documents, whose element records are stored in the main partition, not in that stream.
Flag bit 0x10 (byte 0 of m_abFlags4Bytes) marks them: on Einhoven it is set on 888 of the 1,864 undeclared records and on exactly 1 of the 2,522 declared ones. On our Pucciplast 2022 family the only form with that bit is the template's host-wall stub (1,078 × 1,451 × 305 mm, ExtrusionElem 317742), and Jakob measured the same bit as "driven / template state" on form records. So 0x939 vs 0x929 is not noise: it is the host-stub marker.
The boxes fit a template host wall (3,251 × 152 × 3,048 and 2,286 × 152 × 3,048 mm), and Revit should not export them — they are not project elements. Core Interior has the same structure at scale: 42,319 header records, 19,657 declared, 22,662 belonging to the 46 embedded families; its three undeclared SWall records (23857, 17716, 18429) are the same kind, two of them with an empty box.

So the "category is not a BuiltInCategory at your offsets" observation may come from your decoder treating the record as a project element; the bytes read −2000011 at base for both walls with our envelope (n = 0), same as for 2808. If useful, we can add a declared_in_elemtable field to every vector so the gate is visible in the pack.

Two small things from the label answer: thank you — one tag spanning a late-2014 build labelled 2015 and an early-2015 build labelled 2016 is the strongest argument for #421 we have seen. And a cross-check on tag stability across files: the ten class numbers posted above for rac 2026 and Snowdon 2024 equal our schema tags on house.rvt 2026 and Core Interior 2024 on 10 of 10 each, so within one build family the tags are constant across files.

Best, Steffen

[DrunkOnJava]

Hi Steffen,

Thank you for explaining the two undeclared walls. It holds, and measuring it turned up two things to correct, one on each side. Everything below is from GitHub's runners (Measure run 36865908576); the probe and the report are in #547 (RE-135).

What holds. On the four RE1 models, Einhoven and Core Interior, the records after a project's leading record chain (RE-35: the project's own records come first, back to back) are the loaded families' own documents. The six files hold 187,421 records after their chains; none has an id declared in Global/ElemTable, none shares an id with a chain record, and none repeats one. The 2023 to 2026 Autodesk families have no records after their chain at all.

Einhoven's walls 2921 and 3637 and Core Interior's three (23857, 17716, 18429) all lie after the chain, with your neighbours: DBDrawing, Viewport, a wall type (BasicWallType, or WallAttributes for two of Core Interior's), the SWall, Viewer, DBViewSection, DBDrawing. The class mix is a family's. After the chain on Core Interior it is CategoryElem 3,266, GStyleElem 3,266, CurveElem 2,112, FontElem 1,464 and LinearDimString 1,280, and the 2024 Autodesk family has the same classes with 70 CategoryElem; per section header both files have 71 (3,266 over 46, 427 over 6). Global/ContentDocuments has 46 and 6 section headers, your counts. Your totals are close to ours: Einhoven's Partitions/0 has 4,376 records, 2,519 in the chain, against your 4,386 and 2,522; Core Interior's Partitions/46 has 42,270 against your 42,319.

Two corrections.

1. The chain's end, not the declaration, separates the two. The chain itself holds records whose id is undeclared: 737 on Core Interior (RoomElem 266, PostedWarningElem 213, CurveElem 56, FamilyInstance 45, Text3dElem 36 and smaller classes) and 1,611 on RE1 Electrical. Taking every undeclared record for an embedded family's would take 3 per cent of Core Interior's undeclared records wrongly. What those chain records are, we have not established.
2. Bit 0x10 is not the host-stub marker on these files. Einhoven's two walls carry 0x939, as in your pack; Core Interior's three carry 0x929, the word of its ordinary project walls. The bit is on none of Core Interior's 28,560 chain records and none of Einhoven's, but on 1,421 of RE1 Architecture's 4,672 and on 1,177 or 1,178 records of each standalone 2023 to 2026 Autodesk family. After the chain it is on 757 of 22,114 on Core Interior and 1,359 of 2,633 on Einhoven. It follows the kind of record, not the stub.

One difference we could not reproduce. You read an embedded document's ids as its own space and found three ids on Einhoven and four on Core Interior in two header records. Here no id after the chain repeats, and none equals a chain id, on any of the six files: the embedded records' ids are unique in the file. Within the chain ids do repeat (1,444 on Core Interior, 13 on Einhoven). We have not explained that and filed it as #548; if your reader has seen what the second record of an id is, we would like to know.

Two limits: our 2023 walk loses the last record of each run, and no 2023 record on Einhoven has declared parameter entries, so that shift is unmeasured there. And if you add a field to your vectors, whether the record lies inside the leading chain is more useful than whether its id is declared.

The explanation is yours, and the report, the changelog and the PR credit it.

Best,
Griffin

[DrunkOnJava]

Hi Steffen,

Three of your measurements, reproduced on releases we had not covered. Everything is from GitHub's runners and merged in #549 (RE-136 and RE-137); the files are the eleven Autodesk families of 2016 to 2026, the four RE1 models, Einhoven and Core Interior.

The pre-2024 envelope. Your [u32 id][u32 size][u16 tag][u16 entries] reads every Autodesk family from 2016 to 2023: on all eight, the number of records it finds equals the number of ids Global/ElemTable declares, to the record, with none left over and every record's class resolving through the file's own schema. The tags are 1201, 1218, 1259, 1261, 1272, 1299, 1340 and 1398 (the 0x4B1, 0x4C2, 0x4EB, 0x4ED, 0x4F8, 0x513, 0x53C and 0x576 of our earlier table). That is seven releases we had not measured, in standalone families. Projects of 2016 to 2022 are still unmeasured: the corpus has none.

The two ElemTable layouts. The record is 28 bytes on all of 2016 to 2023 (and Einhoven) and 40 bytes on 2024 to 2026 (the three families, Core Interior and the four RE1 models): 17 files, no other length and no file with two. So the transition is between 2023 and 2024, as you and Jakob said.

The chaining rate. Counting a position that carries the header tag as a candidate and a record whose size checks out as accepted: 99.46 per cent on Core Interior (50,951 candidates, 50,674 accepted), 99.62 per cent on Einhoven, 99.87 to 99.95 per cent on the families, 99.96 per cent on RE1 Electrical, Mechanical and Plumbing. That is your 99.5 to 99.8. RE1 Architecture is the exception at 95.75 per cent: 1,707 positions carry the header tag and are not records, and we have not looked at what they are. If you have seen the tag occur outside a record, we would like to know where.

Your grammar against our old Q4 note. Our April addendum read the u16 before a class's field count as a reference to an ancestor distinct from the parent, with nine classes resolving. With your grammar and the page strip, on those 17 files, none of the nine has the base the note named (HostObjAttr has base Symbol, which the note called its parent), and every base reference of every class resolves. The note, the README and the field documentation now say it did not reproduce. Your grammar is what made that check possible.

One thing from RE-135 settled. The ids that open two records in a project's chain are copies of one element's record in different partitions, never two in one stream and always the same class (873 of Core Interior's 1,444 are byte-identical; the rest differ, 236 of them walls). Which copy is current when they differ is open (#548).

Credit for the envelope, the layouts and the chaining rate is in the reports, the changelog and the PR.

Best,
Griffin

[STE1200]

Hi Griffin,

thank you for measuring it, and for both corrections. Both hold on our side too.

The repeated ids were ours. Our header reader is a scanner: it takes every position that carries the ElementHeader tag and has a plausible size, and it did not check that the record sits in a run. Walking the runs (a record whose end is the next record's start) on fresh dumps:

Einhoven: 4,386 candidates, 4,381 of them in 5 runs (2,520 · 657 · 556 · 424 · 224). That is your 4,376 plus the last record of each run your 2023 walk loses, and our 2,520 against your 2,519 for the leading chain. The other 5 candidates lie outside every run and are false hits.
Core Interior: 42,319 candidates in Partitions/46, 42,270 in runs of two or more — your number exactly. The 49 left over are false hits. Over all eight partitions the records in runs are 50,674, your accepted count, and Partitions/46's leading run of 20,156 plus the 8,404 records of the other partitions gives your 28,560 chain records.
Every repeated id came from false hits. On Einhoven the only one is id 0 (two false hits next to the real record 0). On Core Interior it is id 0 (three false hits), one id shared by two false hits, and six large garbage ids that each occur seven times. Among records that lie in a run, no id repeats, before or after the leading chain. So your reading stands and our "own id space" sentence was wrong.
Bit 0x10. Confirmed: Core Interior's 23857, 17716 and 18429 carry 0x929. Our marker reading came from one file and a single family form; we had not checked the second file. Withdrawn.

On your question about the tag outside a record, from these two files only (we have no RE1 models): the 49 false hits on Core Interior fall into three groups. Four lie inside the payload of real records in a run (three in two GeoLocation records, one in a GeoSite record, at 5.51 MB). Forty-two lie in long stretches with no records at all between 48.4 and 76.7 MB, as six positions that repeat seven times with the same lengths (1,456 · 753 · 410 · 420 · 708 · 494 bytes), surrounded by what reads as float64 data: seven copies of one structured block. The last three (two overlapping at 34.1 MB, one at 77.3 MB) we have not looked at. It may be worth checking whether RE1 Architecture's 1,707 also come in repeated groups. We have not identified the block.

We will drop the declared/undeclared field idea and, if a field helps, mark whether a record lies in the leading chain, as you suggest.

Best, Steffen

[DrunkOnJava]

Hi Steffen,

Thank you, and for taking the two readings back so cleanly. Three things, all measured on GitHub's runners.

RE1 Architecture's 1,707. We ran your question: for every position that carries the header tag and is not an accepted record, the id and size words, grouped (probe_re135_undeclared_records, run 36905901479).

• RE1 Architecture: 40,149 candidates, 38,442 accepted, 1,707 not. They are mostly single, not repeated groups: 1,431 distinct (id, size) pairs, and 32 pairs that occur three or more times cover 268 of the 1,707 positions. The most frequent size words are 16,777,215 (111 positions), 167,772,159 (29) and 1,644,167,167 (25), that is 0x00FFFFFF, 0x09FFFFFF and 0x61FFFFFF: size words made of 0xFF bytes, not plausible sizes.
• Core Interior: 277 positions over all eight partitions (50,951 candidates, 50,674 accepted), and here they do repeat: 26 pairs occur three or more times and cover 210 of the 277. The most frequent size words are 7 (35), 557,060 (28), 87,752,704 (14), 0 (13) and 4,294,967,295 (13).
• Einhoven: 20 positions, 18 distinct pairs, one that occurs three times.

So Core Interior has the repeated blocks you found and RE1 Architecture mostly does not. Our rule (a position counts where the tag matches outside an accepted record and its size or trailer fails) is not yours, so 277 is not comparable with your 49 for Partitions/46; we did not look inside the groups.

The repeated ids. Your account of the ones you saw holds, id 0 among them. The ones RE-136 and RE-139 report are another thing and are real: records that pass the strict rule (the header tag, the size and a trailer that repeats it) in two different partitions, never two in one partition. So "no id repeats among records in a run" is true within a partition and, on Core Interior, not across them: 1,444 ids have a record in Partitions/46 and in another partition, 873 byte-identical and 571 different. One to look at: walls 20796 to 20798 of 2024_Core_Interior.rvt, whose two records have boxes exactly one inch apart (the 571 that differ are mostly in Partitions/46 and 59). Does your run walk see them in two partitions?

Autodesk's own sample projects show what the two copies are. The 2021 rac_advanced project has two partitions and 4,037 ids in both. For the 750 whose boxes differ, the single record of the same element in the 2020 release agrees with the copy in Partitions/7 for all 750, and the 2022 release's with the copy in Partitions/8 for all 750: two revisions of the element, the later partition's newer (RE-143, #548; one file, so Core Interior stays open).

Your 2017 project. Autodesk publishes rac_basic, rst_basic and rac_advanced projects for every release from 2016 to 2027, and they are now in the Measure workflow (RE-140). The 2017 rac_basic has the sha256 you gave for it (a1d3d077…5fefb), so the file you measured is one every run can read: a strict walk of its chain holds a record for every one of its 7,945 table ids, with the first record's ids read from 0x06 (parse_records had missed them, fixed in #553). Your 2015 BIMcollab project is still not measured here.

Nothing is owed on your side beyond the Core Interior question above, if you have a minute for it.

[STE1200]

Hi Griffin,

yes, our run walk sees them in two partitions, and the numbers match yours.

Walls 20796 to 20798 each have one record in Partitions/46 and one in Partitions/59, all SWall with flags 0x1929. Boxes in inches (min x, y, z / max x, y, z):

id | Partitions/46 | Partitions/59 | record length 46 / 59 -- | -- | -- | -- 20796 | 573, 969, 912 / 900, 975, 1092 | 573, 968, 912 / 900, 976, 1092 | 305 / 313 20797 | 573, 693, 912 / 579, 972, 1092 | 573, 692, 912 / 579, 972, 1092 | 297 / 297 20798 | 576, 693, 912 / 1203, 699, 1092 | 576, 692, 912 / 1203, 700, 1092 | 361 / 361

So 20796 and 20798 are 6 in thick in Partitions/46 and 8 in in Partitions/59, grown by one inch on each face; 20797 is one inch longer at one end. That reads like a wall type change from 6 to 8 in with the joins following it. The IFC that ships with Core Interior holds no walls at all, so we could not check it there.

So we reproduced RE-143 instead, from Autodesk's host with your pinned hashes (2020, 2021 and 2022 racadvancedsampleproject.rvt). Our run walk gives 2020 one partition (7, 59,414 records in runs), 2021 two (7: 58,933, 8: 4,113, 4,037 ids in both, 887 of them different), 2022 one (9: 59,072). For the 802 ids whose two 2021 boxes differ, the 2020 record's box equals the Partitions/7 copy for all 802, and the 2022 record's box equals the Partitions/8 copy for all 802, 44 of them walls. Same result as yours; our 802 against your 750 is probably a different box rule (we compare all six doubles exactly, empty boxes included).

That settles one of ours. Einhoven has one wall in two partitions: 2808, in Partitions/0 at (1.5, 2471.5, 0) to (6001.5, 2671.5, 2998.6) mm, and in Partitions/2 moved by exactly (14705.5, 9501.5, 0) mm. Two family instances, 5317 and 5388, move by the same vector between the same two partitions, so it is one edit of the wall with what it hosts. Read the RE-143 way, the Partitions/2 copy is the current one, and the 2808 vector in our pack (and the record RE-132 read field-exact) is the earlier revision. We will mark that in the pack. A reader that takes the main partition alone reports the stale position for every element edited after the bulk of the file was written.

Over the whole file: 1,444 ids with records in two or more partitions; 873 whose copies are all byte-identical; 571 that differ, 236 of them walls. The differing ones sit mostly in Partitions/46 (567) and Partitions/59 (545). Same as yours.

On the 1,707: thank you for running it. Single, 0xFF-filled size words on RE1 Architecture and repeated groups on Core Interior is a clear split; we have nothing on RE1 to add.

Best, Steffen

[DrunkOnJava]

Thank you, Steffen. Your 802 against our 750 from a stricter box rule is reassuring; both agree on every id either of us dates.

Two things came out of following this through (RE-145, #569 and #565):

• The native route agrees with your reading. native_index::route_episode, which native_document uses to pick an element's current record, takes the later partition's copy wherever two copies differ:
  • 887 of 887 on 2021 rac_advanced;
  • 569 of 571 on Core Interior;
  • 5 of 6 on Einhoven, the sixth being 2846.
• The route sometimes points at a partition that holds no copy at all. On Einhoven, 2846 (copies in Partitions/0 and 3) and five single-copy elements route to Partitions/1. On Core Interior, 10 elements route to Partitions/48. The native path dropped those 16. Since fix(native_document): an element whose route holds none of its records takes its latest copy (#548) #565 it takes the latest partition that holds a copy, which is the one your RE-143 dating would pick.

Your wall 2808 and its two hosted instances moving together between Partitions/0 and 2 fits the same picture: one edit, written to the later partition. So the 2808 vector RE-132 read field-exact is, as you say, the earlier revision. Thank you for marking it in the pack. #548 is closed with the numbers in reports/element-framing/RE-145-current-copy-routing.md.