Geometry Kernel

Corvus is being designed around the full range of work architects need to fluidly move across, day in, day out. This includes fluidly moving between 2D drawing, 3D modeling, 4D planning, object metadata, object microdata, worksheets, rendering, presenting, and printing. Those requirements reach all the way down to the geometric foundation of the application. Rather than inherit a kernel optimized for a different class of product, Corvus is building a purpose-built AEC geometry kernel around the needs of architecture itself, including continuous workflows, persistent identity, large-scale project geometry, long-lived project state, real-time collaboration, interoperability, and a shared foundation across desktop and browser.

Purpose-built for AEC means building exactly what we need.

Corvus is not trying to reproduce Parasolid, ACIS, Open Cascade, or any other established kernel. Nor does building our own foundation mean every solver, numerical library, translator, or specialized algorithm must be developed internally. We should own the parts of the stack that determine what the product can become and use proven external technology wherever it provides the better engineering answer.

AEC needs geometry built for buildings, not machined parts.

Most geometric kernels in use today were created decades ago for mechanical CAD, where the job was to model manufactured machinery parts with precision. AEC asks something fundamentally different. Buildings are living systems of spaces, assemblies, relationships, data, documentation, and change. Corvus is building a purpose-built geometric kernel from the ground up for architecture, engineering, and construction, with native capabilities for the way buildings are actually conceived, coordinated, documented, analyzed, and delivered. Instead of forcing AEC workflows onto foundations designed for another industry, we can make the foundation itself understand AEC.

Humans define the product. The product defines the kernel.

A geometry kernel should not determine what Corvus can do or is allowed to become. We start with the experience architects need, then design the geometric foundation capable of supporting it. 2D drawing, 3D modeling, direct manipulation, parametric relationships, object intelligence, collaboration, history, data, automation, and AI are not features we want to bolt onto an unrelated core. They are foundational requirements.

Modern software should take advantage of modern hardware.

Corvus is being built in an era of multicore CPUs, powerful GPUs, WebAssembly, modern systems languages, parallel computation, and mature graphics APIs. We do not want to inherit architectural decisions made for the hardware constraints of decades ago. A purpose-built kernel lets us design computation, memory use, caching, rendering, and concurrency around the machines architects actually use today, while keeping the foundation lean enough to scale to large projects without requiring specialized hardware.

One foundation that can be deployed everywhere.

Corvus is intended to run across Mac, Windows, and the browser without becoming three separate modeling systems. The geometry core should behave consistently across environments while allowing each platform to use the graphics, interaction, and system capabilities it does best. At the same time, Corvus must work with the existing AEC ecosystem, including DWG, IFC, mesh, surface, solid, point-cloud, survey, GIS, and other project information. The goal is one clean internal foundation that can operate across platforms and interoperate with the outside world.

Moving fluidly between 2D, 3D, and 4D should be the new norm.

When 2D drawing, 3D modeling, 4D planning, and all metadata and microdata begin with the same computational foundation, they stop behaving like separate modes that must constantly be reconciled. A line can become part of a wall. A wall can carry the information needed for drawings, schedules, quantities, and analysis. Changes can flow naturally in every direction. Worksheet data is bidirectional, generated from the model, and continuously updated as the design evolves. BIM does not need to be layered onto the experience later because its underlying intelligence is present from the beginning. The result feels less like managing software and more like working directly with the structure you are creating.

True real-time multiplayer requires an architecture built around atomic change.

True real-time collaboration cannot be solved only at the interface layer. It has to reach all the way down to how geometry, relationships, actions, and state are represented and saved. Corvus is designing its geometric kernel around collaboration from the beginning, so multiple people can work fluidly in the same project without treating the model as one monolithic file or forcing every action into a single linear sequence. Elements can have durable identities. Relationships can remain explicit and queryable. Independent changes can happen concurrently, while genuine conflicts can be identified precisely. Collaboration becomes part of the architecture, not a workaround built on top of it.

AI will be far more meaningful when it understands the underlying geometry.

AI becomes much more useful when a project is composed of structured, persistent, addressable entities rather than opaque files or disconnected drawing primitives. A purpose-built geometry and project architecture gives Corvus the opportunity to let AI operate on the same underlying model as the architect. It can work with geometry, relationships, history, constraints, quantities, and data rather than merely generating commands at the surface.

We cannot be dependent on someone else's kernel.

Authoring and owning our own geometric kernel gives Corvus control over one of the most consequential layers of the product. We are not constrained by another company's licensing model, roadmap, technical assumptions, or definition of what the kernel should make possible. We can optimize the entire system around AEC, improve it as our users' needs evolve, and solve hard problems at their source instead of engineering around someone else's limitations. That independence can translate directly into faster performance, lower underlying costs, and greater freedom in how we price the product. Most importantly, we can keep making the right architectural decisions without becoming dependent on a third party.

Our kernel will contribute to the larger ecosystem.

The next generation of AEC tools will not only create buildings, they will help evaluate them. Startups are already transforming due diligence, code analysis, feasibility, cost, carbon, risk, and other decisions that depend on understanding a project in detail. A purpose-built Corvus kernel can give these systems richer, cleaner, more structured information about elements, relationships, geometry, quantities, and change. Instead of extracting intelligence from flattened drawings or inconsistent files, partners can work with data designed to be understood computationally. We want these companies to help shape what they need, so Corvus can become an extraordinary foundation for an entire ecosystem of AEC intelligence.

Join our waitlist.

You’ve already waited 49 years. What’s another two? AEC professionals have spent decades jumping through hoops and creating workarounds for convoluted software. No one dares to build something that will challenge the status quo. It's time for something fundamentally different and unapologetically human. Join the waitlist.