# DD — Run access with current Project permissions (#755, #766)

[Common design](dd.md) · [Tasks and completion status](adr.md) ·
[Local Party and Project views](party-project-views.md) ·
[Integration plan #750](https://github.com/pharos-ai-factory/pharos-platform/issues/750).

Status: the capability split, decision-time owner check and accepted-work
continuation rule are implemented in the application policy, and the views
consume Beto's authority events. Project suspension/closure commands,
accepted-work retention and native operation credentials remain activation
dependencies. Production workers stay paused.

## Capabilities

Beto Project decides the operation named by `CheckProjectCapability`:

| Context | Capability | Current-person operation |
| --- | --- | --- |
| Execution Core | `runs.view` | list/read operational state, initiator and resource use |
| Execution Core | `runs.output.view` | read logs and published results |
| Execution Core | `runs.launch` | accept a new Run launch |
| Execution Core | `runs.retry` | request a manual retry |
| Execution Core | `runs.cancel` | request cancellation |
| Workload Portfolio | `workloads.view` | read a Workload or action catalogue |
| Workload Portfolio | `workloads.manage` | create, revise, retire or prepare a Workload |
| Pipeline Coordination | `pipelines.view` | read a Pipeline |
| Pipeline Coordination | `pipelines.start` | accept a new Pipeline |
| Pipeline Coordination | `pipelines.cancel` | request cancellation |

Every port names its capability. An answer for another capability, person or
canonical Project is uncorrelated and fails for retry. Both contract roles hold
these capabilities under the provisioning policy, so the local views make the
same membership decision. A refusal keeps the API's existing forbidden outcome
and names the missing permission.

`project.read`, `project.execute`, `project.manage` and `launch-workloads` remain
transitional Beto aliases for existing callers. New Metallo callers refuse them.

## Evidence at decision time

The local views (#757, #780) decide membership eligibility after matching Beto's
checkpoints, including provider bindings. They also keep Beto's latest authority per
Project: a decision defers, a refusal included, unless that authority is ready,
unexpired and describes the Project revision the view holds
([Project authority](party-project-views.md#project-authority-798)). Every allowing
person decision is still confirmed with Beto at decision time
(`adaptors/project_access.py`):

- The view answers first. Its refusal stands without a call.
- Every allow asks `CheckProjectCapability` through the context's enrolled caller.
  Beto's refusal wins, including a removal Beto has applied before the view sees it.
- `stale_authority`, `temporarily_unavailable`, an unauthorised scope, a source
  state other than ready or an expired `valid_until` defers the operation.
- An unknown Project is a refusal. A contradictory answer is uncorrelated.
- Each answer serves only the operation that asked; Metallo does not cache it.

The queries remain until a context atomically applies Beto's material and authority
revisions, proves consumer progress within the remaining absolute validity,
repairs divergence, and fails closed during restart or incomplete rebuild.

#791 enrolled one caller per Metallo context for both Beto owners. The execution
worker confirms with `pharos_execution_core_views` and the pipeline coordinator with
`pharos_pipeline_coordination_views`, both over Execution Core's view. With that,
the coordinator has no unconnected owner left; every overlay still installs it with
zero replicas until #771. The execution worker composes its resource and account queries
through Resource Provisioning, with saved input and retry owner adaptors. Account queries
require fresh Site confirmation. `metallo-requests` has its own
query-only caller, `pharos_metallo_requests_views`, under the `execution_core`
subject; its broker declaration sets `consume_events: false`, so it cannot take the
execution worker's view deliveries (#791 placed Workload Portfolio's caller in
`metallo`). It reads both views over their databases and confirms every allowing
decision with Beto through that caller. Its repository owners come from Source
Control (#796). The execution worker then processes an accepted launch under its
saved acceptance, without asking about the person again.

## Leaving a Project

Suspend the person's access to that Project immediately, within the access-removal
bound in the [Beto contract](../../../../../contracts/project/messaging/README.md#current-decisions-and-accepted-work).
Once applied, they cannot start, manually retry, cancel, read or collect output.
Their personal Project SSH/provider access, sessions and private workspace access
are withdrawn too. Leaving one Project does not disable their Party or access to
other Projects. Party disablement remains a separate, wider decision.

Accepted work may finish. Other members inspect, collect or cancel it under their
own current permissions. The initiator stays recorded and every later action
records its requester. Final removal of the retained native account/resources
waits for natural completion or completed authorised cancellation, including
stage-out and cleanup. An administrator can request cancellation to finish
offboarding sooner; departure alone does not cancel the work.

Beto Project owns the suspension decision and access facts. Its current
source-managed implementation does not provide Project-membership suspension;
the commands, state and published facts are owner work in #755. Pending final
removal must be represented separately from permission eligibility, so retention
never requires active human membership.

Operator observation, cancellation and cleanup use separate audited authority.
They remain available when personal access or a native execution grant is revoked.

## Work that outlives its initiator

A person decision such as launch, manual retry or cancellation checks that
person's current permission. Processing an accepted Run, its automatic Attempt
retries and later steps declared in an accepted Pipeline use bounded accepted-work
authority while the Project and deadline remain valid.

Starting a whole `actions.yaml` accepts one Pipeline with all ordered step
definitions saved as waiting. The file itself grants no execution authority;
only a submitted and accepted Pipeline or individual launch does. The coordinator
continues those saved steps after personal suspension. It creates each Run when
that step becomes eligible, after the previous step satisfies its advancement
condition. Inputs are resolved then, including the commit pushed by a preceding
step. Each Run's automatic retries retain its pinned inputs. Future native jobs
and future output commits are not created or resolved at Pipeline acceptance.

Pipeline Coordination's `AcceptedSteps` query confirms the exact saved launching
step, its order and cancellation state. Execution Core records that owner revision
and Pipeline/step provenance with the launch. The internal continuation path
requires this evidence and cannot be selected by a member's launch request.
Revising or retiring the editable Workload preserves its already accepted exact
revision. Unknown or changed scope is refused; unavailable owner evidence remains
retryable. Recovery keeps the original launch and Run identities.

Before activation, the accepted record must name the canonical Project, management
generation, authority revision, accepted-work identity, exact Workload/Pipeline
revisions, immutable inputs, environment and deadline. A changed definition, added
step or changed immutable input is a new decision. Accepted-but-queued work keeps
its saved deadline. Replay preserves the original record and cannot renew it.


### Configured deadline and expiry

The deployment configures the maximum accepted-work lifetime, initially 14 days.
Execution Core and Pipeline Coordination record the absolute deadline when they
accept work, shortened by any earlier requested or Site limit. Later configuration
changes apply only to new acceptances. All declared Pipeline steps inherit the
Pipeline's saved deadline; no step, retry, replay or credential renewal extends it.

At expiry, refuse new compute dispatch, automatic retries and later Pipeline
steps. An already-running native job continues within its own Site wall-time
limit unless it is explicitly cancelled. Keep observation, stage-out of that
running work, cancellation and cleanup available through scoped operational
authority. The native account remains retained until those obligations finish.
Expiry alone cannot release the account or silently delete running work.

#766/#810 must implement and validate the deployment setting and persist the
accepted value. #805 must use the same setting and default when reconciled.
#771 must cover expiry before dispatch and between steps, a running job crossing
the deadline, stage-out and cleanup afterwards, and configuration changes that
leave existing deadlines unchanged. These remain activation requirements.

Project closure or an authority-generation change stops future dispatch and
records durable cancellation/cleanup work for queued and running work. An explicit
security cancellation follows the same path. Those Beto owner commands and the
Metallo authority-event consumer remain activation work.

Execution Core no longer rechecks the initiator while planning an accepted launch,
dispatching its saved instructions, issuing its Run-scoped source credential or
creating an automatic Attempt retry. The twelve-day training case therefore
continues after its initiator leaves on day ten. That person loses all access;
another authorised member uses their own `runs.view`, `runs.output.view` or
`runs.cancel` capability.

### Retained native identity and operation authority

Use the existing native identity for accepted work (option B in #765). The
Runtime may retain the initiator's exact account binding while that person loses
personal access. HPC keeps the verified `site_username`; the Slurm Project
account/association supplies accounting and allocation information. It is not a
shared POSIX user.

Kubernetes retains Runtime's member impersonation. The existing
[`job-policy.yaml`](../../../../../gitops/manifests/pharos-site-runtime/access/job-policy.yaml)
already scopes workspace PVCs and repository Secrets to both member and Attempt.
Preserve those checks and require evidence for the exact accepted Run/Attempt,
operation and binding generation. Naming checks alone do not establish accepted
authority or prevent a forged Attempt selection. Pods continue using the
unprivileged `workload` account with no mounted service-account token.

| Owner | Remaining responsibility |
| --- | --- |
| Beto Project (#755) | Publish Project-specific suspension and access changes independently of pending final removal. |
| Execution Core (#766) | Publish precise accepted-work requirements and durable release, with revisioned query/snapshot repair. Include Pipeline Coordination's published remaining-step requirements. |
| Resource/Site owner (#765) | Retain the exact native binding and required resources, publish desired/applied revisions, and deprovision after all obligations are released. |
| Site Runtime (#765, #779) | Enforce the allowed operation against accepted evidence and binding generation, preserving native recovery and isolation. |
| Source Control (#762) | Issue/renew/revoke bounded repository credentials for accepted Git/LFS work, including late stage-out. |

The retention record identifies canonical Party, Project, Site/resource, exact
account binding generation, accepted Run/Pipeline evidence, permitted operations
and execution/cleanup deadlines. Resolve and persist the native binding before
dispatch. Published requirements must also cover accepted work awaiting planning,
queued Runs, automatic retries and gaps before later declared Pipeline steps;
completion of one Attempt alone cannot release resources they still need.

Retention ends only after the relevant work and cleanup obligations are settled.
Release the departed Project's association and resources independently; a shared
native account remains while another authorised Project still requires it.
Consumers use integration events for local views and revisioned snapshots/queries
for initial load and repair. A source outage cannot create a grant or silently
deprovision a retained account. Replay cannot extend the deadline or revive a
released generation. Ordinary offboarding preserves that exact binding; explicit
binding retirement/replacement, Project closure and security cancellation fence
the old grant and reconcile remaining work through independent management
authority. A replacement account never inherits the previous grant.

Retained authority covers only the saved work. It grants no personal SSH/OIDC or
general offline-token access, new launch, changed work, or manual retry without a
currently authorised requester. Repository credentials, input resolution (#767),
native dispatch and stage-out all enforce the same accepted-work boundary.

### Site activation requirements

Keeping a Unix account does not guarantee a fresh native JWT after GRNET disables
the person. #779 must provide narrowly scoped Runtime authority for accepted
operations and independent observation/cancellation/cleanup authority. Retaining
a general personal offline token does not satisfy that requirement.

One HPC `site_username` may remain personally usable through another Project.
That SSH/native access must not expose the departed Project's workspace or permit
new `sbatch` submissions against its retained allocation. The Site owner must
prove Project-specific withdrawal alongside Runtime-only accepted operations.
Where the Site cannot enforce that separation, continuation remains disabled
until an appropriate Site control is available.

The current providers do not implement the full retention and native-authority
contract. Execution workers and the coordinator stay paused through #771
qualification with real owners. The application continuation tests below do not
establish those provider guarantees.

## Information boundaries

`runs.view` exposes operational state, initiator and resource use.
`runs.output.view` exposes logs and published results, which may contain repository
material. Repository access and private workspace access retain their own rules.

## Verification

- Unit cases cover every final capability and refuse all transitional aliases.
  Run, Workload and Pipeline operations ask their exact capability. Every
  uncorrelated answer fails for retry.
- Continuation cases cover accepted planning, native dispatch, source credentials
  and automatic retry after initiator removal or authority-query outage. New
  cancellation remains a current-person decision.
- Pipeline hand-off tests cover suspension before first dispatch and between
  steps, exact accepted revisions after Workload revision/retirement, ordered
  readiness, cancellation, forged scope and durable owner provenance. PostgreSQL
  cases also reload the records, recover a lost hand-off and check step-time input
  resolution and unchanged pins on automatic retry. Source-version and permission
  owners in these cases are test doubles; live credential and Site authority
  remain #771 requirements.
- Pending #771 cases cover personal suspension with retained queued work, later
  Pipeline steps, stage-out, natural completion, authorised cancellation and
  final release; source outage/replay; binding retirement/replacement; forged
  Attempt selection; loss of personal GRNET credentials; and the shared HPC
  username across two Projects. These are activation requirements, not results
  claimed by the current unit tests.
- The decision-time tests cover local refusal, missing caller, allow, refusal,
  unknown Project, stale/unavailable evidence, expired validity and contradictory
  answers. The broker lane sends the check through the enrolled view identity.
- `pnpm verify` and applicable integration evidence are recorded on the pull request.

`pnpm test:integration` also runs `scripts/metallo_beto_integration.py` against
its disposable PostgreSQL and RabbitMQ. Beto's production composition publishes
and answers queries; Metallo's production caller, synchroniser and access adaptor
consume those replies. The lane covers all ten capabilities through the three
enrolled callers, the authority fields added by #798, pending source evidence,
unchanged-read renewal, revocation before local delivery, checkpoint repair and
rebuild. Identity proof and source acquisition use fixtures; Waldur, native
execution and the full #771 journey remain separate qualification.