Engineering Guidelines

Humans first. Period. We define the human need, then product requirement, and then technical outcome before moving on to architecture or implementation. We remain willing to abandon our own ideas when requirements, evidence, or better thinking point elsewhere. Corvus must be both deeply human and technically exceptional. The standard is not what is easiest to build, most familiar, or most technically interesting. The standard is to build what will be most helpful to millions of people.

Human

Every technical decision, from the deepest system architecture to the smallest implementation detail, ultimately reaches a person trying to do meaningful work. Keeping that person at the center of every macro and micro engineering decision is our north star.

Empathy

Engineers must step into the shoes of the people using Corvus and understand the work they are trying to do. We should not expose people to unnecessary complexity simply because that complexity exists inside the system. Nor should we make technical limitations their problem when better engineering can make those limitations disappear. Understanding the human consequence of a technical decision is part of understanding the decision itself.

Responsibility

We should not choose what is easiest for us to build when it makes life harder for millions of people who may eventually use Corvus. Every shortcut, constraint, compromise, and technical decision has consequences downstream. Human-first does not mean technically compromised; it demands exceptional engineering because making sophisticated technology feel natural, fast, reliable, and humane is hard.

Product

Engineering exists to make the product vision real. Technical elegance, novelty, convention, and convenience are valuable only when they serve the experience we intend to create. The product should drive the technology, not the other way around, ever.

Requirements

Requirements come before architecture. We should define what must be true of the system before deciding how the system will make it true. A good engineering requirement should be discrete, understandable, testable, and capable of being satisfied by more than one technical approach whenever the problem allows it.

Sequence

Engineering decisions should happen in their proper order. Human needs inform product requirements, product requirements inform technical requirements, technical requirements inform architecture, and architecture informs implementation. Skipping ahead creates assumptions that can quietly constrain everything that follows and lead to an unusable product.

Flexibility

We should hold ideas strongly enough to explore them rigorously and loosely enough to abandon them when something better emerges. An elegant architecture, promising technology, proving proof of concept, successful prototype, or personally compelling idea should never become a constraint simply because we have invested time or energy in it. Evidence should change our minds, requirements should challenge our assumptions, and better ideas should replace earlier ones.

Freedom

Corvus should never unnecessarily constrain what people can create simply because some geometry, workflow, or representation is easier for the system to accommodate. Architects, designers, fabricators, and other people working with the built environment should be free to draw and model the forms their work requires. Technical difficulty is our problem to solve, not a limitation we should casually pass along to the person designing.

Simplicity

Complexity should have to earn its place. We should prefer the simplest system that fully satisfies the requirements rather than introduce abstraction, infrastructure, dependencies, or machinery in anticipation of problems we do not yet have. Simple does not mean unsophisticated. The hardest engineering can produce the simplest experience.

Correctness

Corvus should do what it says it does. Geometry, information, calculations, relationships, transformations, commands, and system behavior should produce correct and predictable results. The system should prevent invalid or contradictory states wherever practical, detect them when prevention is not possible, and make failures explicit rather than allowing errors to propagate silently. Correctness should be designed into the system, verified continuously, and evaluated against clearly defined requirements.

Precision

Architecture and construction demand precision. Corvus should preserve the accuracy required by professional work across geometry, dimensions, coordinates, units, transformations, calculations, and output. Different operations may require different numerical methods and representations, but their behavior, limits, and tolerances should be deliberate and understood. Approximation should be used only where appropriate, bounded where necessary, and never silently substituted when the product promises a more precise result.

Determinism

Where Corvus depends on repeatable computation, the same supported inputs and operations should produce equivalent results across the environments in which those guarantees matter. Determinism should make project state reproducible, history trustworthy, synchronization dependable, and computation safely reusable. Where behavior is intentionally probabilistic, approximate, or environment-dependent, that boundary should be explicit and should not compromise deterministic guarantees elsewhere in the system.

Integrity

The project must remain internally coherent as it changes. Geometry, objects, relationships, information, worksheets, drawings, views, and other representations should not quietly become contradictory versions of reality. Corvus should protect the integrity of the work rather than place that burden on the person using it.

Identity

Things in Corvus should retain meaningful identity over time. An object should not become an unrelated object simply because it was edited, viewed differently, synchronized, referenced, or represented somewhere else. Durable identity enables relationships, history, collaboration, references, and many of the behaviors that make one coherent project possible.

Atomicity

Actions in Corvus should be discrete, complete, and understandable. A meaningful operation should either succeed as intended or fail without leaving the project in an ambiguous or partially changed state. Atomicity should protect project integrity, make history and undo comprehensible, and provide a dependable foundation for concurrent work without prescribing the technical mechanism used to achieve it.

Relationships

Relationships among things should remain meaningful as the project evolves. When one element depends on another, Corvus should understand and preserve that dependency according to the product's rules. People should not have to manually repair relationships simply because the system failed to maintain what it already knew.

Performance

Speed is a human experience expressed through engineering. Drawing, modeling, selecting, manipulating, navigating, calculating, loading, syncing, rendering, and other frequent operations should happen quickly enough that Corvus does not interrupt thought. Lag is not merely a technical deficiency. It changes how people work, so performance should be designed into the system from the beginning.

Responsiveness

Corvus should acknowledge interaction immediately even when the underlying work takes longer to complete. People should not be left wondering whether the system received an action or whether something is happening. Engineering should support an experience in which the product remains communicative and responsive under meaningful computational load.

Scale

Corvus should remain capable as the work becomes larger. More geometry, objects, drawings, information, collaborators, history, references, and assets should not fundamentally change the experience or force people into artificial workflows created solely to accommodate technical limitations. Scale should be defined through measurable operating conditions rather than vague claims about supporting large projects.

Resources

Corvus should use computing resources responsibly. Memory, processing, graphics resources, storage, network capacity, and energy should be consumed in proportion to the work being performed. People should not need unnecessarily specialized hardware simply because the system uses resources inefficiently.

Multiplayer

Drawing, modeling, editing, and other fundamental project activity should exist naturally within a multiplayer environment. Working with other people should be a normal state of Corvus rather than a special collaborative mode entered after the fact. The underlying system should assume that more than one person may be interacting with a project at the same time.

Concurrency

People should be able to work simultaneously without managing the mechanics of concurrency themselves. Independent activity should proceed independently, while genuinely conflicting activity should be handled quickly and predictably. Whatever technical mechanisms make this possible should remain as invisible as practical to the people doing the work.

Synchronization

Corvus should synchronize work continuously and automatically whenever connectivity permits. Changes should propagate quickly and correctly across participants and devices without requiring people to save, upload, download, check in, check out, or otherwise manage synchronization manually. Latency, interruption, and reconnection should not compromise the coherence of the project.

Persistence

Work should be durable. A person's confidence that their work exists should not depend on remembering to perform a mechanical saving ritual or understanding how Corvus stores information internally. Persistence should protect work continuously and reliably according to clearly defined guarantees.

History

A project should retain meaningful history as it evolves. Corvus should preserve enough information to support recovery, authorship, understanding, collaboration, and other product behaviors that depend on knowing what happened before. History should remain useful without becoming an uncontrolled burden on performance or scale.

Recovery

Failures, interruptions, crashes, and mistakes should not casually destroy work. Corvus should recover to a known and understandable state whenever recovery is possible. Engineering for recovery means assuming that imperfect conditions will occur and designing the system accordingly.

Offline

People should be able to continue meaningful work when connectivity disappears without having anticipated the outage or prepared the project in advance. Offline work should not require checking projects out, manually downloading models, or performing other preparatory rituals. When connectivity returns, Corvus should reconcile supported offline work safely and with as little human intervention as possible.

Networks

Real networks are imperfect. Latency changes, connections disappear, bandwidth becomes constrained, and services occasionally become unreachable. Corvus should behave predictably under degraded network conditions and avoid turning ordinary connectivity problems into project-integrity problems.

Interoperability

Corvus must participate responsibly in the larger ecosystem of tools used to design and construct the built environment. People should be able to bring drawings, models, and information into Corvus and take them out again without unnecessary friction. Interoperability should preserve the properties required by the workflow rather than become a collection of nominally supported file formats.

Fidelity

Translation should preserve meaning as faithfully as the source and destination formats allow. Geometry, units, coordinates, information, and other required properties should survive exchange wherever the formats permit it. When something cannot survive intact, Corvus should make meaningful loss visible rather than silently pretending nothing changed.

Reference

Projects should be able to maintain reliable relationships with appropriate external information. Files, models, images, data, and other referenced resources should remain identifiable and manageable as projects, teams, and locations change. References should not become mysterious dependencies that people are afraid to disturb.

Native

Corvus should take full advantage of the capabilities of the desktop platforms we choose to support. Professional drawing, modeling, computation, and rendering should have appropriate access to modern hardware acceleration and platform capabilities rather than being artificially limited to a lowest common denominator. The particular technologies used to achieve this should follow from the requirements and the best available engineering approach for each platform.

Browser

The browser should provide meaningful access to Corvus without requiring every participant to install the full professional application. Appropriate browser experiences should allow people to navigate projects, inspect drawings and sheets, work with project information, review reports, mark up documents, sketch, comment, and perform other defined tasks. Browser capability should reflect what people need to accomplish rather than pursue feature parity for its own sake.

Hardware

Professional-quality work should be possible on appropriately defined, broadly attainable hardware. Corvus should use available computing capabilities intelligently without making expensive or specialized equipment an unnecessary prerequisite for serious work. Hardware expectations should be explicit and measurable.

Graphics

Corvus should display the work accurately, smoothly, and consistently. Geometry, linework, materials, transparency, text, images, and other visual information should remain trustworthy across the ways people view and manipulate a project. Graphics engineering should serve both visual fidelity and interactive performance.

Rendering

Rendering should scale from immediate visual feedback to the fidelity required for communication. The engineering system should support changes in visual quality without forcing the project into a disconnected representation or workflow. Seeing the work and changing the work should remain closely connected.

Output

What leaves Corvus should preserve the intent of what exists inside it. Printed drawings, PDFs, images, presentations, exported files, and other outputs should maintain the required geometry, dimensions, linework, typography, color, resolution, and information. Output reliability is part of professional trust in the product.

Reliability

Corvus should behave predictably over sustained professional use. Individual faults should be contained wherever possible rather than cascading into broader failures or damaged projects. Reliability should be measured against realistic working conditions, not only ideal demonstrations.

Availability

Services required for normal operation should meet clearly defined availability expectations. When a service becomes unavailable, Corvus should preserve as much useful functionality as the product and security model permit. Temporary infrastructure problems should not automatically become total product failures.

Security

Security protects people's work, identity, intellectual property, and trust. Corvus should prevent unauthorized access, alteration, disclosure, and destruction throughout the lifecycle of project information. Security should be designed into the system without becoming an excuse for unnecessary friction.

Permissions

Access should reflect clearly defined human relationships to projects and information. Corvus should reliably enforce who can see, change, share, administer, or otherwise act on something. Permission behavior should remain understandable as teams and projects become more complex.

Privacy

People should understand how Corvus handles their information and project data. Information should be collected, retained, accessed, and used only in ways consistent with legitimate product needs and clearly established expectations. Technical capability to access information does not by itself justify accessing it.

Kernel

The geometric kernel must serve the product rather than force the product to serve the kernel. It must ultimately support the geometric freedom, precision, performance, scale, interoperability, and other requirements Corvus establishes for professional work in the built environment. Whether Corvus develops its own kernel, licenses one, adapts one, combines approaches, or changes direction should remain an engineering and business decision until the requirements and evidence justify narrowing the options.

AI

AI should operate within the same engineering standards as the rest of Corvus. Access to project information should respect permissions and privacy, consequential actions should remain attributable and appropriately reversible, and probabilistic behavior should not compromise deterministic guarantees elsewhere in the system. Intelligence should expand capability without weakening trust.

Extensibility

Corvus should be capable of growing beyond the capabilities we can anticipate today. New functionality should be able to extend the product without undermining its coherence, integrity, performance, or security. Extensibility should preserve the principles of Corvus rather than create parallel systems around them.

Observability

When Corvus behaves unexpectedly, engineers should be able to understand why. The system should provide sufficient evidence to diagnose performance problems, failures, inconsistencies, and other important conditions without relying on guesswork. Observability should help us improve Corvus without compromising the privacy or security of the people using it.

Architecture

Architecture should emerge from the requirements rather than precede them. Engineers should be free to consider competing approaches, test assumptions, build proofs of concept, and choose the architecture that best satisfies the product's actual needs. Technologies, patterns, vendors, languages, frameworks, and infrastructure should remain means rather than become ends.

Dependencies

Every external dependency creates both capability and obligation. Libraries, services, platforms, vendors, formats, and other dependencies should be adopted deliberately with consideration for reliability, performance, security, longevity, portability, control, and the cost of eventually replacing them. Convenience today should not create unnecessary fragility tomorrow.

Verification

A requirement is only useful if we can determine whether Corvus satisfies it. Engineering requirements should define observable outcomes and the conditions under which those outcomes are evaluated. Whenever possible, a requirement should produce a clear pass or fail rather than an argument about whether it feels complete.

Evidence

Engineering decisions should be grounded in evidence rather than confidence alone. Measurement, profiling, testing, prototypes, experiments, user conditions, and production behavior should help us distinguish what we know from what we assume. When evidence contradicts an assumption, we should change the assumption.

Craft

Engineering at Corvus is a craft. Good engineering is not measured by the amount of code written, the novelty of the architecture, or the sophistication of the terminology used to describe it. It is measured by how reliably, elegantly, and sustainably the system makes an extraordinary product possible.

Peer Review

Important engineering work should have a second set of capable eyes before it becomes part of Corvus. Our buddy system pairs engineers to challenge assumptions, catch mistakes, share context, and improve the quality of decisions without creating layers of approval or bureaucracy. Peer review is not about permission or hierarchy; it is about shared responsibility for the integrity of what we build.

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.