merge branch develop into fm-srm-handoff

**Implementing a component**

1. Read [platform/architecture.md](platform/architecture.md) for the end-to-end mental model.

2. Open the component folder ([oeg/](oeg/), [srm/](srm/), [fm/](fm/), [tf-sdk/](tf-sdk/)) via its `index.md`.

2. Open the component folder ([oeg/](oeg/), [srm/](srm/), [fm/](fm/), [tf-sdk/](tf-sdk/), [portal/](portal/)) via its `index.md`.

3. Follow architecture → interface contract → persistence model → flow walk-throughs in that order.

4. When a spec cites an ADR, read the decision record for the rationale behind the rule.

| [srm/](srm/) | Service Resource Manager — orchestration and inventory |

| [fm/](fm/) | Federation Manager — cross-operator EWBI federation |

| [tf-sdk/](tf-sdk/) | Transformation Function SDK — vendor adapters inside SRM |

| [portal/](portal/) | Portal — developer portal and admin console |

| [decisions/](decisions/) | Architecture Decision Records |

| [external-specs/](external-specs/) | Vendored third-party API definitions |

| [archive/](archive/) | Superseded working documents |

# ADR-0006: `oeg_db` schema — the flow docs' schema is authoritative; `app_registrations` is the CAMARA app record

**Status:** accepted

**Status:** accepted — "client identity is the JWT `client_id` (= `tenant_id`)" is amended by [ADR-0048](/decisions/0048-platform-roles.md): `tenant_id` is the token's `organization` claim, else its `sub`, and `app_provider_id` is the `sub`; `api_subscriptions` is reserved for per-product quota and validity. Everything else stands

**Date:** 2026-07-04

**Affects:** [oeg/persistence-model.md](/oeg/persistence-model.md), [oeg/app-registration-flow.md](/oeg/app-registration-flow.md), [oeg/app-instance-flow.md](/oeg/app-instance-flow.md), [oeg/app-deployment-flow.md](/oeg/app-deployment-flow.md)

# ADR-0018: Federation tenancy — the partner OP is the tenant; federation agreements map partner requests to local service specifications

**Status:** accepted

**Status:** accepted — the manual app mapping is now the fallback: an application the partner onboarded over the EWBI is resolved from that onboarding first ([ADR-0068](/decisions/0068-fm-onboards-apps-at-partners-over-ewbi-before-installapp.md)). The partner-as-tenant decision is unchanged.

**Date:** 2026-07-05

**Affects:** [fm/overview-and-architecture.md](/fm/overview-and-architecture.md), [fm/requirements-and-design.md](/fm/requirements-and-design.md), [fm/implementation-and-delivery.md](/fm/implementation-and-delivery.md)

# ADR-0027: TF-SDK exposes one generic `CapabilityExecutionAdapter` interface across all domains

**Status:** accepted

**Status:** accepted — the four discovery methods are moved off this interface onto a separate `TopologyDiscoveryAdapter` by [ADR-0055](/decisions/0055-topology-discovery-is-a-separate-adapter-interface.md) (they were "optional" members here, which left an empty result ambiguous). [ADR-0061](/decisions/0061-use-short-execution-action-vocabulary.md) proposes shorter method names; the generic execution interface and `capability_kind` dispatch stand.

**Date:** 2026-07-07

**Affects:** [platform/architecture.md](/platform/architecture.md), [platform/future-architecture.md](/platform/future-architecture.md), [srm/architecture.md](/srm/architecture.md), TF-SDK

discovery methods (`get_zones`, `get_domains`, `get_capabilities`, `get_control_path_bindings`) —

implemented uniformly across compute, network, and future domains (charging, consent,

intelligence, data, business, trust, custom). Capability-specific behavior is selected by a

`capability_kind` string (e.g. `deploy_workload`, `qod_session`, `traffic_influence`) carried in

`capability_kind` string (e.g. `workload`, `qod_session`, `traffic_influence`) carried in

the normalized request, never by a distinct adapter base class per domain. Adapter/executor

resolution itself is governed separately by ADR-0004 (`control_path_ref` via the runtime

ControlPathRegistry); this decision is scoped to the shape of the interface SRM codes against,

# ADR-0034: Network-capability delete is async, and its completion is consumed to a terminal record state

**Status:** accepted — the blanket "reads of a terminal record return `404`" rule and step 3's "returns `204`" are amended by [ADR-0049](/decisions/0049-terminal-record-read-follows-camara-schema.md) (each family follows its own vendored CAMARA schema: Traffic Influence reads a deleted policy as `200` and deletes with `202`); everything else stands

**Status:** accepted — the blanket "reads of a terminal record return `404`" rule and step 3's "returns `204`" are amended by [ADR-0047](/decisions/0047-terminal-record-read-follows-camara-schema.md) (each family follows its own vendored CAMARA schema: Traffic Influence reads a deleted policy as `200` and deletes with `202`); everything else stands

**Date:** 2026-08-05

**Affects:** [oeg/persistence-model.md](/oeg/persistence-model.md), [oeg/interface-contract.md](/oeg/interface-contract.md), [srm/interface-contract.md](/srm/interface-contract.md)

representation for a deleted resource — true of QoD, whose `QosStatus` enum is

`REQUESTED`/`AVAILABLE`/`UNAVAILABLE`. Traffic Influence's `state` enum does document

`deletion in progress` and `deleted`, so it reads them back as `200`

([ADR-0049](/decisions/0049-terminal-record-read-follows-camara-schema.md)). Either way the row is

([ADR-0047](/decisions/0047-terminal-record-read-follows-camara-schema.md)). Either way the row is

retained for audit and for the `operations` history; it is not removed.

## Consequences