Domains and Repositories
A domain is an area of specialisation — for example, billing, platform, compliance, or onboarding. Domains let the same role mean different things in different parts of the organisation: a product owner for billing and a product owner for platform hold the same role but carry different context, different repositories, and different accumulated knowledge.
Domains divide the organisation into areas of responsibility so that context follows the work. For example, a lesson learned about invoicing stays with the workers handling billing, and the workers handling identity verification see the guidance that applies to them.
What a domain describes
| Field | Purpose |
|---|---|
| Domain code | A short unique identifier for the domain (e.g. billing) |
| Domain name | The human-readable name |
| Description | What the domain covers and where its boundaries lie |
| Portfolio link | An optional link to the project portfolio the domain corresponds to |
| Repositories | The repositories that belong to the domain (see below) |
Domain codes are unique within a tenant, and every domain belongs to exactly one tenant like the rest of WRM.
Domain repositories
Each domain lists the repositories it works across. Every link records what kind of participation the repository has and the reason for it.
| Field | Purpose |
|---|---|
| Repository | The external system entry for the repository |
| Relationship type | How the repository participates in the domain |
| Rationale | A required explanation of why this repository belongs to this domain |
| Include memory context | Whether repository-scoped memories for this repository are loaded into workers in this domain |
| Monitor unlinked work | Whether to flag merge requests in this repository that are not tied to a tracked work item |
Relationship types
| Type | Meaning |
|---|---|
| CORE | The domain owns this repository — its primary codebase |
| CONTRIBUTING | A shared repository that ships some of the domain's code |
| DOCUMENTATION | Documentation only |
| TESTING | Test assets only |
A repository can participate in more than one domain — for example, a shared platform library is often CORE to the platform domain and CONTRIBUTING to several others — but each domain-repository pair is recorded once.
The rationale is mandatory by design. It records the reason a repository belongs to a domain at the moment the link is made, so that anyone reviewing the domain a year later can read the original justification.
Memory context and monitoring
Two flags control how much a repository contributes to day-to-day operation:
- Include memory context defaults to on. Turn it off for repositories whose accumulated lessons apply narrowly rather than across the domain — for example, documentation and test-only repositories.
- Monitor unlinked work defaults to off. Turn it on for repositories where activity legitimately happens outside the normal work item lifecycle and you want that activity reported.
Worker role assignments
A worker role assignment connects a worker to a role, optionally within a domain. Assignments determine the context a worker operates in: they are how a given worker resolves to a particular role and domain when it starts a task.
One worker can hold several assignments. For example, a product owner covering both billing and platform has two — one per domain — and each carries its own context and its own domain-scoped memories.
An assignment with no domain applies everywhere. This suits workers who perform the same job in every area, such as an executor that implements whichever work item it is given.
| Field | Purpose |
|---|---|
| Worker | The worker being assigned |
| Role | The role the worker fills under this assignment |
| Domain | The domain the assignment is scoped to; empty means all domains |
| Wake schedule | How often a scheduled worker should be woken (see below) |
| Wake enabled | Whether waking is currently switched on |
Wake schedules
Some workers run on a schedule rather than in response to a work item — they wake, review the state of their domain, and decide what to do next. Orchestrators and supervisors work this way.
The assignment carries that schedule, plus a switch to turn waking on and off. Both live on the assignment rather than in deployed configuration, so an orchestrator can be paused by disabling waking on its assignment and resumed the same way, as a configuration change.
Disabling waking on an assignment is the fastest way to stop a scheduled worker that is behaving unexpectedly. It stops future wake-ups while keeping the assignment intact, so its role, domain, and schedule are preserved for when you switch it back on.
How domains shape a worker's context
When a worker starts a task, the platform resolves its context from its assignment:
- Role and domain come from the assignment being used
- Repositories come from the domain's repository links
- Memories are retrieved across the applicable scope layers — organisation-wide, the domain, the role, the repositories in context, and the worker's own notes
The result is that two workers holding the same role in different domains see different guidance, work against different repositories, and accumulate separate knowledge, without needing separate role definitions.
Related documentation
- Memories — how domain-scoped and repository-scoped memories are written and retrieved
- Worker Definitions and Workers — how the workers being assigned are configured
- Orchestration — how scheduled workers decompose and dispatch work across repositories