For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt, and this page is available as Markdown at /reference/docs/context-catalogue.md.

Contexts, responsibilities and ownership

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

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

Service responsibilities

ServiceResponsibility
BetoParty Governance, Project, Support and Marketplace.
MetalloWorkload and execution lifecycles, Site delivery, Source Control, Resource Provisioning, SSH Access, Member Credentials and LLM Access.
ThemelioPython service foundation with no registered business contexts.
APIAuthentication, sessions, typed owner requests, server-authorised realtime audiences and the optional experimental MCP edge.
WebPresentation 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 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.

ContextOwnerAuthoritative responsibility
Party Governance (party_governance)BetoCanonical Parties, authentication eligibility, profiles and verified provider associations.
Project (project)BetoCanonical Projects, complete memberships, source evidence and current capability decisions.
Support (support)BetoCustomer links, tickets, messages and recoverable service-desk synchronisation.
Marketplace (marketplace)BetoOrders for fixed provider packs, recorded prices and the private OrderPlaced fact.
Source Control (source_control)MetalloRepository identity, provider bindings, GitLab group/member effects, repository grants, deletion and public publication.
Workload Portfolio (workload_portfolio)MetalloWorkload definitions, immutable revisions and interpretation of repository actions.
Execution Core (execution_core)MetalloLaunch acceptance, Runs and child Attempts, supervision, retry and cancellation.
Pipeline Coordination (pipeline_coordination)MetalloOrdered Workload steps, stable step-launch identities, progress and Pipeline cancellation.
Site Coordination (site_coordination)MetalloOrdered environment command streams, immutable Runtime results and acknowledgement progress.
Site Runtime (site_runtime)Metallo, deployed at the SiteNative execution and recovery, workspace identities, access enforcement and bounded private reads.
Resource Provisioning (resource_provisioning)MetalloAllocation lifecycle, configured/applied limits and Site-reported native account evidence. Its name and wider boundary remain under review.
SSH Access (ssh_access)MetalloMember public keys per Site, key generations, deployment/revocation and propagation.
Member Credentials (member_credentials)MetalloSealed offline consent, token refresh and revocation for native member actions.
LLM Access (llm_access)MetalloProject 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 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 and retained adaptor guide. 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, Slurm execution and public and Project-only service access. Site configuration determines activation. The Run log panel has the explicitly recorded five-second browser polling exception; ordinary platform projections use server-authorised realtime.

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 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

OwnerConsumersPublished responsibility
Party GovernanceAPI, Project, Support and enrolled Metallo contextsIdentity, eligibility, verified bindings, contacts and current generations.
ProjectAPI and enrolled Metallo contextsCapability decisions, provider correlation, complete snapshots and material/authority events.
Source ControlWorkload Portfolio, Execution Core and Site RuntimeRepository resolution, exact content, temporary grants and recovery.
Execution CorePipeline Coordination and execution lifecycle consumersRun queries, accepted-work evidence and completion facts.
Resource ProvisioningExecution and Site capabilities, SSH AccessApplied limits, allocation/account readiness and native identity evidence.
Site CoordinationSite Runtime and execution supervisionAuthenticated ordered commands, recorded results and progress.
Retained AUP adaptorAuthentication and SSH AccessRequired policy and exact member acceptance evidence.
Waldur Site AgentsResource Provisioning and LLM AccessProvider observations, membership/account reports and approved allocation evidence.
SMTP, LiteLLM, Open WebUI and ZammadTheir owning context adaptorsRestricted external effects with persisted retry and recovery.

Inter-service messages follow ADR 0046. 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.

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.

Page source

Source snapshot ยท Revision f928834c8.