How the pieces fit together
The fastest way to understand Constellation is to follow one piece of work through the platform. This page walks a single scenario — an agency sourcing equipment from suppliers and managing the delivery — and shows which module carries each step.
The cast: Northfield Agency (an AGENCY tenant) needs ruggedised field communication equipment. Several suppliers have published their offerings to the catalogue. A programme office will oversee the delivery.
1. Finding what's out there — Catalog
A procurement officer at Northfield doesn't start with a folder of supplier PDFs. She starts with a search.
Catalog's semantic search understands intent, not just keywords — a query like "portable encrypted radio for vehicle mounting" finds relevant entries even when no supplier used those exact words, because entries are matched by meaning (vector embeddings) as well as text. Results can be narrowed by the tenant's configured taxonomy — UNSPSC, ETIM, NATO FSC, CPV, or a custom hierarchy — so "communications equipment" can be browsed as a tree, not just queried.
From the results she builds a shortlist: a curated selection of catalogue entries that represents "these are the candidates we're taking forward". A shortlist stays ACTIVE while the selection is being worked, and is ARCHIVED once it has served its purpose — so the list the evaluation actually ran against stays on record.
Turning a shortlist into a formal RFQ, collecting bids, and awarding a contract is the job of the Procurement module — planned, not yet built. Today the shortlist is the hand-off artifact: the evaluation and delivery work it feeds is run in Project Tracker.
2. Running the work — Project Tracker
The evaluation and delivery becomes a project in Project Tracker, under an initiative — the long-running container the programme office uses to group related projects and watch progress roll up.
The project gets a stage pipeline that mirrors how regulated delivery actually works: stages like Evaluation → Contracting → Delivery → Acceptance, separated by gates. A gate is a review checkpoint — designated reviewers vote PASS, FAIL, WAIVE, or HOLD, and the project only progresses to the next stage when its gate passes. No one "just moves the card".
Inside stages, the team plans tasks (grouped under epics when the work spans workstreams) and tracks unplanned issues — defects, incidents, support tickets — with severity levels and SLA policies, so a supplier's overdue response is visible before it becomes a crisis.
3. Capturing what the team knows — Wiki
Evaluation criteria, meeting minutes, technical assessments, decision records: the knowledge around the project lands in a Wiki space — a per-team container of markdown pages with typed links between them (this assessment depends_on that requirement; this decision supersedes the earlier one), forming a browsable dependency graph rather than a pile of documents.
Because this is regulated work, pages carry a classification (UNCLASSIFIED … SECRET), and the database itself — not an honour system — enforces who can read what. A summary page classified UNCLASSIFIED can safely coexist with a SECRET technical annex in the same space; users see exactly the slice their clearance allows.
4. Deciding who sees what — Directory
None of the above works without an answer to who is asking? Directory holds it: the tenant, its member organisations (Northfield's procurement department, the programme office, each supplier's team), their users, and the roles and permissions that gate every action in every module.
Every request in the scenario above — the search, the shortlist edit, the gate vote, the wiki page read — is checked against the caller's tenant membership and permissions before anything happens. Suppliers see their own catalogue entries and the projects they're part of; Northfield's internal evaluation notes stay out of a supplier reader's reach when they are classified above that reader's clearance (finer-grained per-space and per-page access rules are a planned layer on top of today's tenant + clearance scoping). Directory also tracks organisation certifications with expiry dates, so a supplier whose compliance certificate lapses mid-delivery raises a platform event, not a surprise at audit time.
5. The paper trail — events and audit
Two things happen automatically underneath every step:
- Domain events. Each module publishes facts about what happened —
catalog.shortlist.created,projects.gate.reviewed,directory.credential.expired— through a reliable outbox, so other modules and external systems can react without being wired together directly. The full catalogue is in the Domain events index. - Audit entries. Security-relevant actions write to the universal audit log, hash-chained so tampering is detectable. When someone asks — months later — who approved the gate that moved this project into Contracting, and when? — the answer is one query, not an archaeology project.
The scenario at a glance
Where to go next
- What each module can do in depth — the module pages cover capabilities, data model, and APIs.
- The security model behind the scenario — Tenant types and Tenancy & RLS.
- Want to build on it? — Local setup gets the platform running in about ten minutes.