# Contexts, responsibilities and ownership

Reviewed against `integration/current` on 9 November 2026; the exact source is in
[the integration baseline](integration-baseline.json). This catalogue describes
registered ownership and current integration boundaries. Context READMEs retain
operation details, activation requirements and qualification evidence.

[contracts/contexts.json](../contracts/contexts.json) registers 14 contexts.
[ARCHITECTURE.md](../ARCHITECTURE.md) records the shared architectural rules.
A registered context may still have development stand-ins or disabled processes.

## Service responsibilities

| Service | Responsibility |
| --- | --- |
| Beto | Party Governance, Project, Support and Marketplace. |
| Metallo | Workload and execution lifecycles, Site delivery, Source Control, Resource Provisioning, SSH Access, Member Credentials and LLM Access. |
| Themelio | Python service foundation with no registered business contexts. |
| API | Authentication, sessions, typed owner requests, server-authorised realtime audiences and the optional experimental MCP edge. |
| Web | Presentation and interaction through published API and realtime contracts. |

The retained web application in `compat/themelio` provides the current Pharos
Platform experience. Its implementation name is distinct from the empty
`services/themelio` foundation. The [compatibility guide](content/compatibility/index.md)
records the migration boundary; `legacy/` preserves historical source.

## Registered contexts

Every PostgreSQL context has its own logical database, credentials and migration
ownership. Site Runtime owns private Site-local SQLite journals.

| Context | Owner | Authoritative responsibility |
| --- | --- | --- |
| [Party Governance](../services/beto/contexts/party_governance/README.md) (`party_governance`) | Beto | Canonical Parties, authentication eligibility, profiles and verified provider associations. |
| [Project](../services/beto/contexts/project/README.md) (`project`) | Beto | Canonical Projects, complete memberships, source evidence and current capability decisions. |
| [Support](../services/beto/contexts/support/README.md) (`support`) | Beto | Customer links, tickets, messages and recoverable service-desk synchronisation. |
| [Marketplace](../services/beto/contexts/marketplace/README.md) (`marketplace`) | Beto | Orders for fixed provider packs, recorded prices and the private OrderPlaced fact. |
| [Source Control](../services/metallo/contexts/source_control/README.md) (`source_control`) | Metallo | Repository identity, provider bindings, GitLab group/member effects, repository grants, deletion and public publication. |
| [Workload Portfolio](../services/metallo/contexts/workload_portfolio/README.md) (`workload_portfolio`) | Metallo | Workload definitions, immutable revisions and interpretation of repository actions. |
| [Execution Core](../services/metallo/contexts/execution_core/README.md) (`execution_core`) | Metallo | Launch acceptance, Runs and child Attempts, supervision, retry and cancellation. |
| [Pipeline Coordination](../services/metallo/contexts/pipeline_coordination/README.md) (`pipeline_coordination`) | Metallo | Ordered Workload steps, stable step-launch identities, progress and Pipeline cancellation. |
| [Site Coordination](../services/metallo/contexts/site_coordination/README.md) (`site_coordination`) | Metallo | Ordered environment command streams, immutable Runtime results and acknowledgement progress. |
| [Site Runtime](../services/metallo/contexts/site_runtime/README.md) (`site_runtime`) | Metallo, deployed at the Site | Native execution and recovery, workspace identities, access enforcement and bounded private reads. |
| [Resource Provisioning](../services/metallo/contexts/resource_provisioning/README.md) (`resource_provisioning`) | Metallo | Allocation lifecycle, configured/applied limits and Site-reported native account evidence. Its name and wider boundary remain under review. |
| [SSH Access](../services/metallo/contexts/ssh_access/README.md) (`ssh_access`) | Metallo | Member public keys per Site, key generations, deployment/revocation and propagation. |
| [Member Credentials](../services/metallo/contexts/member_credentials/README.md) (`member_credentials`) | Metallo | Sealed offline consent, token refresh and revocation for native member actions. |
| [LLM Access](../services/metallo/contexts/llm_access/README.md) (`llm_access`) | Metallo | Project LLM allocations, gateway/chat fulfilment, budgets, personal keys and delivery/usage recovery. |

## Governance and access

Party Governance supplies canonical identity, authentication generations and
verified external-account associations. Project acquires complete qualified
Waldur observations, resolves members through Party Governance and owns the
capability decision. Provider identifiers remain opaque bindings.

Project material revisions and authority revisions have separate meanings.
Successful unchanged source reads renew authority without changing the material
Project. Consumers own their projections, bootstrap checkpoints, receipts and
expiry handling. The [Project contract](../contracts/project/messaging/README.md)
defines current decisions, accepted-work continuation and freshness.

The Go API owns browser authentication and sessions. The retained web supplies
bounded provider-account and AUP operations through its private adaptor.
See the [authentication guide](../services/api/adaptors/authentication/README.md)
and [retained adaptor guide](../compat/themelio/services/web/src/lib/api-authentication/README.md).
Neither Source Control nor a repository namespace owns canonical Party identity.

## Repositories and execution

Source Control is the GitLab Project group/member writer and preserves repository
identity through provider renames and transfers. It supplies authorised reads and
recoverable repository grants. Public publication maintains a separate public
copy while the authoring repository remains private. Creation, catalogue reads
and forks still have retained compatibility routes.

Workload Portfolio interprets `actions.yaml` and saves immutable execution
revisions. Execution Core owns launch acceptance and the Run lifecycle; Attempts
are children of their Run. Pipeline Coordination saves stable step launches and
follows Run outcomes through owner queries and completion events. A successful
Pipeline may leave a healthy service running.

Resource Provisioning supplies allocation limits, readiness and reported native
accounts. Site Coordination owns delivery order and acknowledgement, while Site
Runtime owns native execution, uncertain-effect recovery and exact native
identities. A delivered instruction and a running workload are separate facts.

Current execution documentation covers [Run logs](../services/metallo/docs/epics/instantiate-and-run/run-logs.md),
[Slurm execution](../services/metallo/docs/epics/instantiate-and-run/slurm-run-path.md)
and [public and Project-only service access](decisions/0069-project-private-run-services.md).
Site configuration determines activation. The Run log panel has the explicitly
recorded five-second browser polling exception; ordinary platform projections
use [server-authorised realtime](../CLIENT-SUBSCRIPTIONS.md).

## Member and AI services

SSH Access combines Beto identity and membership, Resource Provisioning account
and allocation evidence, and the retained AUP policy reader. It owns public-key
work and confirmed propagation; the Site account writer retains native account
creation. Its normal composition uses canonical owner adaptors. Development
fixtures remain explicitly gated.

Member Credentials owns sealed offline grants and refreshes a member token for
an authorised native action. Superseded or ended consent has durable revocation
work. Neither Site Runtime nor browser projections own these secrets.

LLM Access reconciles LiteLLM teams/keys and Open WebUI access, reports monthly
usage and answers Project budget, chat-entry and personal-key requests. Budget
and measured spend use EUR; token/request rates are separate limits. Personal
keys have sealed pending mail delivery and never appear in browser projections.
Chat membership can use the configured Site Agent policy or Beto-owned
membership. The Beto mode includes key revocation and requires the documented
member-link preflight before an existing installation switches policy.

Support consumes Party registration, verified contact and access events to link
and maintain its service-desk customer. Each ticket and message belongs to its
caller. Zammad remains the desk-side authority; private replies and internal
notes are excluded from the member conversation. Current multi-replica and
provider qualification limits remain in its README.

Marketplace serves PlaceOrder and ListProjectOrders through RabbitMQ and HTTP,
with its own Order persistence and private event. Its catalogue and buyer ports
are development stand-ins; provider fulfilment and real buyer authority remain
later work. Its registration does not establish a live resource-purchase journey.

The [experimental MCP gateway](../services/api/services/mcp/README.md) is an
API-owned technical edge. Its OAuth broker has technical persistence and calls
the current API's owner contracts. It introduces no new business context and
remains an explicitly selected development profile.

## Contracts across boundaries

| Owner | Consumers | Published responsibility |
| --- | --- | --- |
| Party Governance | API, Project, Support and enrolled Metallo contexts | Identity, eligibility, verified bindings, contacts and current generations. |
| Project | API and enrolled Metallo contexts | Capability decisions, provider correlation, complete snapshots and material/authority events. |
| Source Control | Workload Portfolio, Execution Core and Site Runtime | Repository resolution, exact content, temporary grants and recovery. |
| Execution Core | Pipeline Coordination and execution lifecycle consumers | Run queries, accepted-work evidence and completion facts. |
| Resource Provisioning | Execution and Site capabilities, SSH Access | Applied limits, allocation/account readiness and native identity evidence. |
| Site Coordination | Site Runtime and execution supervision | Authenticated ordered commands, recorded results and progress. |
| Retained AUP adaptor | Authentication and SSH Access | Required policy and exact member acceptance evidence. |
| Waldur Site Agents | Resource Provisioning and LLM Access | Provider observations, membership/account reports and approved allocation evidence. |
| SMTP, LiteLLM, Open WebUI and Zammad | Their owning context adaptors | Restricted external effects with persisted retry and recovery. |

Inter-service messages follow [ADR 0046](decisions/0046-service-communication-and-composition.md).
Canonical facts and owner queries cross boundaries; another context's database
remains private. Native Site grants, TokenReview and their exact route scopes are
specified by [Site Coordination](../services/metallo/contexts/site_coordination/README.md).

## Remaining boundary work

- Confirm Resource Provisioning's wider allocation and native-account boundary,
  and reduce reader write authority tracked in its README.
- Complete Marketplace's catalogue, buyer authority and provider fulfilment.
- Decide owners for broader model/dataset semantics, immutable non-Git inputs
  and portable storage before registering new contexts.
- Retain one writer for each provider capability throughout handover. Activation,
  recovery and real-provider qualification belong in each owning guide.

Update this catalogue when registration or ownership changes. Keep feature
instructions, endpoint schemas and dated qualification evidence with their owners.