Infrastructure for engineering software.
Rine is building the engineering-file intelligence layer for software companies and AI systems operating in engineering-heavy industries.
We build APIs, tools, and infrastructure that make engineering files programmable — so product teams can read, parse, normalize, convert, render, and extract structured information without rebuilding that layer themselves.
Engineering software keeps rebuilding the same infrastructure.
Every engineering-heavy software product eventually encounters files.
Drawings. CAD. Models. Specifications. Technical documents. And behind seemingly simple product features sit difficult infrastructure problems: format parsing, geometry, representations, conversions, rendering, version differences, diagnostics, semantic extraction, and interoperability.
Most product teams do not exist to solve those problems. They encounter them because their actual product depends on them.
Instead of every software company independently building and maintaining engineering-file infrastructure, Rine is building a shared layer that products and AI systems can depend on.
Rine exists to make that layer reusable.
A common layer between engineering files and software.
Rine's technical architecture is built around a simple idea. This hub-and-spoke structure is the foundation of Project La Vinci, Rine's first major product expression.
As support expands, new formats should connect into a reusable infrastructure layer rather than forcing every downstream product capability to be rebuilt independently.
AEC is where we started. It isn't where Rine ends.
Rine's first learning environment is architecture, engineering, and construction, where drawing sets, CAD files, BIM workflows, specifications, and technical documents create obvious file-infrastructure problems. But the underlying problem is broader.
Engineering-file infrastructure appears across:
Rine is being built as infrastructure for engineering-heavy software broadly — not as a single-industry application.
The company is the customer.
Rine is not an individual-engineer SaaS product and it is not a drafting or file-conversion service.
We build infrastructure for companies creating software and AI products that depend on engineering information. The commercial model is B2B infrastructure and API partnership.
Developers build with Rine.
Access engineering-file capabilities through clean programmable APIs.
Software products embed Rine.
Integrate engineering-file infrastructure directly into product workflows.
AI systems consume Rine's infrastructure.
Feed structured engineering representations into agents, search, and reasoning systems.
Built from real file problems.
Rine's roadmap is not meant to be a checklist of every engineering format in existence.
Observe the file problem.
Understand what a software product is trying to do.
Define the required behavior.
What must be extracted, transformed, rendered, compared, or preserved?
Test against representative files.
Use real-world examples and explicit success criteria.
Build reusable infrastructure.
Turn validated requirements into capabilities that can serve more than one workflow.
Expand from evidence.
Add formats and capabilities because recurring problems justify them — not because a format happens to be popular.
A few things we intend to keep true.
Infrastructure over services
Rine should become something software companies depend on, not a manual conversion shop.
Evidence over assumptions
A customer telling us a hypothesized problem does not exist is useful information.
Explicit boundaries
If a format, fidelity level, endpoint, or reliability level has not been verified, we don't present it as though it has.
Reusable primitives
We prefer capabilities that strengthen the common engineering-file layer rather than one-off implementations.
Developer-first
The product should make complex engineering-file operations accessible through clean programmable interfaces.
Evidence-led discipline.
On 10 October 2026, we paused active development of Project La Vinci's parser-and-conversion path.
Rather than treating sunk engineering effort as product strategy, we made an explicit checkpoint: pipeline execution without crashes is not the same as source fidelity. Rine is now focusing engineering resources directly around demonstrated customer pull—turning engineering information inside technical documents and drawings into structured workflow data.
01. Source Fidelity Over Blind Execution
Automated testing on our 1,000-file corpus proved container resilience, but manual inspection revealed visual fidelity failures. We refuse to sell conversion APIs that fail human verification.
02. Demonstrated Customer Demand
Software teams repeatedly tell us their bottleneck is not basic format conversion—it is extracting structured data from technical drawings and specifications into business applications.
03. Assets Preserved for Future Direction
Our DWG parser codebase, 1,000-file validation corpus, and LAVINCI_CAD_IR_V3 schema remain active technical assets underpinning our next generation of workflow tools.
Building software around engineering files?
If your product depends on engineering-file ingestion, extraction, normalization, conversion, rendering, technical-document intelligence, or another related infrastructure problem, we'd like to understand the workflow.
We're especially interested in problems where engineering-file infrastructure is becoming something your team repeatedly has to build, maintain, or work around.
Talk to Rine
Engineering files should be infrastructure, not an obstacle.
Rine is building the layer underneath.