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