Core concepts

Most of Orneos is ordinary. This page covers the parts that are not, and the exact sense in which the ordinary words are used — a “team” in Orneos is a stronger boundary than the word usually implies, and that has consequences you will meet in search, permissions and sync.

For one-line definitions of everything else, see the Glossary.

Company

The top of the hierarchy. A company holds teams, members and billing identity. Your sign-in is bound to one company at a time.

Crossing a company boundary is the most destructive thing the app does to your browser: the entire local database is destroyed and rebuilt. That is deliberate — a replica holds exactly one company’s data, and carrying anything across would mean one company’s rows were readable in another’s session. See Local data and storage.

Team

The unit that actually owns work. Issues, projects, labels, board columns, saved views and Vault spaces all belong to exactly one team.

Team is also the sync scope: the server routes real-time events per team, your local database stores rows tagged by team, and your replay position is tracked per team. That means a team is not a filter applied to a shared pool of issues. It is a boundary, and an issue in a team you do not belong to is not merely hidden — it is not delivered to you at all.

You can belong to several teams in a company. One is active, and most workspace views show that team. The Search page also offers online Company scope for authorized cross-team issues. The others are kept converging in the background so switching is fast. See Companies and teams.

Issue

The unit of work, and the thing most of the app is about. Title, description, status, priority, assignee, dates, labels, and a team-scoped reference like ENG-42.

Issues nest (sub-issues) and link (typed relations: blocks, blocked by, relates to, duplicate of). See Issues and Sub-issues and relations.

Project

A container for issues with its own status and dates, optionally nested under a parent project, and optionally linked to other projects. Use it for a body of work with a beginning and an end. See Projects.

Vault

The documentation layer: spaces containing pages of rich text, co-edited in real time. An eligible Vault page linked from an issue contributes its title and link, but not its body, to that issue’s context bundle, which is the reason Vault is part of the product rather than a link to a different one. See Vault.

Intent

The agreement about a piece of work, attached to the issue: a goal, acceptance criteria, and non-goals.

Intent is not a description field with a nicer name. Three properties distinguish it:

• It is approved by a person, and records who and when.
• It is versioned. Revising creates a new revision; superseded revisions are kept and readable.
• It does not silently follow the issue. If the issue’s title or description changes after approval, the app marks the agreement as possibly stale — advisory, never blocking. A stale agreement is still the agreed one until a human approves a replacement.

That last property is the whole mechanism. An agreement that quietly updated itself to match whatever the work became could never be used to judge whether the work was right. See Intent.

Context bundle

A single markdown document assembled from your local data: the task, the approved Intent, relevant discussion, and eligible linked Vault references (titles and links, not page bodies) — with a source reference on every part and truncation marked where it happened.

It is bounded on purpose. A bundle that silently dropped the half you needed would be worse than one that says it was cut. See Context bundles.

The local replica

A real relational database running inside your browser, holding your company’s data for the teams you belong to. Local issue views read from it. Company Search, Vault page content and other online features have separate network paths.

Tabs on the same origin in the same browser profile share one replica through a shared worker, while rendered views update asynchronously. Completed local writes can survive ordinary refreshes and restarts, subject to browser storage and session-boundary limits. It is not a backup — see Local data and storage.

The operation log

Supported local-first changes are recorded in a durable queue for background synchronization. Some features, including Vault collaboration and membership administration, use separate data paths. A queued operation remains subject to server authorization and can fail.

Completed queue writes can survive ordinary reloads; an in-flight save is not a durability guarantee. This is why “the interface shows it” is not the same as “the server has it”. See How sync works and Offline and reconnect.

Sync scope and the replay cursor

The server assigns each change in a team a position in that team’s sequence. Your client records the highest position it has durably applied to the local replica, per team.

On reconnect it asks for everything after that position. If the gap is too large to replay, the server says so explicitly and the client re-downloads from scratch rather than guessing. Gap detection supports recovery; it is not a guarantee against all synchronization failures. See Offline and reconnect.