What is Constellation?

Constellation is a multi-tenant collaboration platform for regulated B2B commerce — the industries where buying and selling is a programme, not a shopping cart: defence, aerospace, government procurement, manufacturing, supply chain.

The problem

In regulated industries, getting a product or service from a supplier to a buyer involves far more than a transaction. An agency publishes a need; suppliers respond; a programme office oversees delivery across multiple projects, stages, and review gates; every decision must be traceable years later. Today that work is scattered across generic SaaS tools that were never designed for it:

• Security postures don't fit. Generic tools can't offer per-field classification labels, clearance-gated visibility, or an air-gapped deployment — table stakes for defence and government work.
• Data isolation is bolted on. When one platform serves many customer organisations, "we filter by customer ID in the application" is not an acceptable isolation story for regulated data.
• The audit trail is an afterthought. Reconstructing who did what, when, and why across five disconnected tools is somewhere between painful and impossible.
• Nothing talks to each other. The catalogue lives in one tool, project delivery in another, organisational knowledge in a third — with copy-paste as the integration layer.

The solution

Constellation puts the whole collaboration lifecycle — identity, product knowledge, project delivery, documentation — on one platform with one security model:

• Hard tenant isolation. Every customer (tenant) is an isolation boundary enforced in the database itself via row-level security, not just in application code.
• A universal audit trail. Security-relevant actions across every module write to a single tamper-evident audit log — one place to answer "who did what".
• Modules that share a nervous system. Each module owns its data, and they integrate through published domain events — when a catalogue entry is published or a project gate passes, other modules (and your systems) can react.
• Deployable where your data must live. The same codebase runs as managed SaaS, as a dedicated cloud instance, or fully air-gapped on-premises.

Who runs on Constellation — tenant types

A tenant is one customer's isolated space on the platform. Its type reflects which side of the collaboration the customer sits on, and shapes its security posture:

Tenant type	Who they are	What they do on the platform
AGENCY	A buying organisation — government or enterprise	Searches the catalogue, shortlists suppliers, runs delivery projects with stage gates
SUPPLIER	A selling organisation	Publishes products, services, and capabilities; collaborates on delivery projects
PROGRAMME_OFFICE	An oversight body coordinating multi-party work	Tracks initiatives and projects across organisations; reviews gates; audits progress
PLATFORM_OPERATOR	The organisation running the platform itself	Administers tenants and holds the only tenant type allowed to grant unrestricted (*) permissions

Inside each tenant, member organisations (agencies, prime contractors, sub-tier suppliers, SMEs, programme offices) and their users collaborate under role-based access control. The Tenant types reference covers the permission posture of each type in detail.

The modules

Four modules are built and live today. Each is independently deployable but shares the platform's identity, event, and audit foundation.

📇 Directory

Who is allowed to do what. Tenants, organisations, users, roles, and permissions — the identity foundation every other module builds on. Includes organisation verification, certifications with expiry tracking, and capability tags for supplier matching. → Directory module

📦 Catalog

What is being bought and sold. AI-powered product information management: catalogue entries with semantic search, a configurable industry taxonomy (UNSPSC, ETIM, NATO FSC, CPV, or custom), AI-generated descriptions, and shortlists that turn search results into a curated supplier selection. → Catalog module

📋 Project Tracker

How the work gets delivered. Stage-gate project coordination: initiatives, projects, tasks, and issues, with configurable stage pipelines guarded by review gates, SLA-tracked issue queues, time tracking, and GitHub integration. → Project Tracker module

📖 Wiki

What the team knows. Self-hosted specifications and knowledge with classification-aware access control (UNCLASSIFIED … SECRET enforced at the database layer), typed links between pages forming a dependency graph, and full-text search — entirely on tenant-owned infrastructure. → Wiki module

Planned modules

Procurement (RFQs, bids, awards), Documentation, Supply Chain, Compliance, and CRM are planned but not yet built. Quality/helpdesk capabilities are not a separate module — they live in Project Tracker as issues with severity and SLA policies.

Deployment tiers

The same platform, three postures — every infrastructure dependency sits behind a provider abstraction, so moving up a tier changes configuration, not application code:

Capability	SaaS	Dedicated Cloud	On-Premises
Hosting	Managed, multi-tenant	Customer-dedicated instance	Air-gapped, self-hosted
Identity provider	Supabase Auth	Keycloak	Keycloak + HSM
Encryption at rest	Platform-managed	Customer-managed keys	HSM-backed
Classification	Not applicable	Optional	Mandatory
Audit trail	Universal hash-chained audit log	+ tamper-evident chain verification	+ air-gapped audit store

The universal audit log is a platform capability on every tier — the tiers differ in how its storage is hardened, not in whether actions are audited.

Who reads what

• Buyers, suppliers, and programme staff — continue with How the pieces fit together for a walkthrough of one collaboration scenario end to end.
• Administrators and security reviewers — see Tenant types and the Universal Audit Log.
• Developers — start at Local setup, then the Architecture overview.