What Is a Keyspace in Bugspot?

A keyspace is where an entry’s key comes from — the DS in DS-142. In Bugspot a keyspace is its own thing, separate from any project: one keyspace can back many projects, its numbers run continuously, and every key it hands out is unique across your whole company. That decoupling is the core difference from Jira, where the key is the project.

TL;DR

• A keyspace is a key prefix plus a running counter, owned by the company — not by a project.
• One keyspace can back many projects; each project draws from exactly one keyspace.
• Keys are unique company-wide: DS-142 always points to one entry, whichever project it lives in.
• So a prefix can stand for whatever you organize around — a team, an initiative, a product line — instead of being forced to equal one project, the way a Jira project key is.

What is a keyspace?

A keyspace is the namespace an entry key is minted from. It has two parts: a short prefix — two to ten uppercase letters or digits, like DS or ML — and a counter that hands out the next number. An entry’s visible key is just prefix-number, so DS-142 is the 142nd entry minted from the DS keyspace. Prefixes are unique within a company, and the counter uses each number once, so a full key never collides.

A project in Bugspot is attached to exactly one keyspace. When you file an entry in that project, the entry takes the next number from the keyspace — nothing about that number is a property of the project itself. Under the hood every entry also carries a stable UUID; the keyspace key is the human-readable name layered on top (more on that split in UUIDv7 entry IDs, and the human keys we kept).

How is a keyspace different from a Jira project key?

In Jira the key is the project. Every project has exactly one project key, that prefix is owned by that one project, and an issue key is simply <project key>-<number> (Atlassian: editing a project key). In Bugspot the prefix and the project are two separate things: a keyspace issues keys, and any number of projects can point at it. The surface looks the same — ABC-123 next to DS-142 — but the model underneath is the opposite.

(For the record, Jira’s default project-key format is two or more uppercase letters, [A-Z][A-Z]+; Bugspot allows two-to-ten uppercase letters or digits. Close enough that migrating prefixes rarely surprises anyone — it’s the ownership that differs, not the syntax.)

Why decouple the key from the project?

Because teams rarely organize the way “one key = one project” assumes. When the prefix is chained to a project, anything you’d want a shared prefix for — a team that owns five services, an initiative that spans repos — forces you to either cram unrelated work into one project or spin up a project just to mint the prefix. That’s how large Jira instances end up with dozens of “projects” that are really team folders in disguise.

Say your Data Science team owns three codebases — a data pipeline, a model-serving API, and a notebook platform. In Bugspot you point all three projects at a single DS keyspace. Now DS-1, DS-2, DS-3 number straight through the team’s work regardless of which repo each entry sits in, and DS means the Data Science team — exactly as people already say it out loud. The project still records where the code lives; the keyspace records whose namespace the work belongs to. Two axes, instead of one field doing both jobs badly.

You can see that shared counter directly. bugspot keyspaces list reports one NEXT number per keyspace — the value the next entry will take — no matter how many projects draw from it:

$ bugspot keyspaces list -o table
KEY  DESCRIPTION        NEXT  CREATED
DS   Data Science team  143   2026-03-22

One row, one counter. NEXT is 143, so DS-142 was the last key minted and the next entry — filed in any of the three projects — becomes DS-143. The number belongs to the DS keyspace, not to whichever project the entry lands in.

When should a project just have its own keyspace?

Often — decoupling is a capability, not an obligation. If a project maps cleanly to one team and one body of work, give it its own keyspace with a matching prefix and you’re done; that’s the familiar one-key-one-project setup, and it’s the right default. Reach for a shared keyspace only when a prefix should outlive or outspan a single project.

• One team, one codebase → one keyspace per project. Simple, and what most projects want.
• One team, several codebases → one shared keyspace the projects point at, so numbering and identity stay unified.
• A prefix people already say out loud (“that’s a DS ticket”) → make it a keyspace, not a project name.

How should you choose a keyspace prefix?

Treat a keyspace prefix as permanent, and tie it to something durable — a team, a product line, an initiative — not a temporary project codename. Keep it short and obvious: a good prefix is one a teammate can read a year later and know instantly what it points to.

Permanence matters because a key spreads the moment it exists. DS-142 starts showing up in pull requests, Slack threads, commit messages, and browser bookmarks within hours — none of which update themselves if the prefix later changes. This is also why Bugspot makes the key a company-wide name rather than a property of one project: a name you can paste anywhere shouldn’t shift because the work got reorganized.

Frequently asked questions

Keyspaces shipped in Bugspot’s very first month and are live in the public beta today. Spin up a company, point a couple of projects at one keyspace, and watch the numbering run straight through — it’s the fastest way to feel why a key that isn’t chained to a project changes how a team names its work.