docs: TI seeded service spec and capability_status metadata

- The QoD `service_specification_id` question is out of scope here and settled separately by

  ADR-0035: the platform seeds one QoD specification at deployment and OEG reads its id from

  configuration. Traffic Influence needs no seeded row — it resolves its specification from its

  required `appId` (`app_registration_id`, ADR-0011).

  required `appId` (`app_registration_id`, ADR-0011). Superseded for Traffic Influence by the

  ADR-0035 amendment of 2026-10-20: TI also uses a platform-seeded specification.

Revisit trigger:

- `/qos-profiles` and `/qos-profiles/{name}` remain unimplemented.

- `api_subscriptions` is not populated for QoD; per-tenant entitlement is not enforced.

- Traffic Influence is unaffected and out of scope here — it resolves `service_specification_id`

  from its required `appId` via `app_registration_id` (ADR-0011) and needs no seeded row.

## Amendment (2026-10-20) — Traffic Influence uses the same seeded-spec pattern

**Status:** accepted

**Date:** 2026-10-20

Traffic Influence also activates through `command.srm.network.capability.activate` and needs a

`service_specification_id` that references a real catalog row. Unlike QoD, CAMARA TI carries a

required `appId` — but that id identifies the **edge application** whose traffic is influenced,

not the TI capability offering itself. Using the app's `app_registration_id` as

`service_specification_id` would attach the session holder to a workload specification that has no

`traffic_influence` requirement, so planning would fail.

The platform therefore seeds **one** Traffic Influence service specification alongside the QoD

one, with the same ownership rules (platform provider, empty deployment units, one

`capability_kind=traffic_influence` network requirement). OEG holds the id in

`ti_settings.service_specification_id` / `TI_SETTINGS__SERVICE_SPECIFICATION_ID` (well-known

default `baba6a12-c7b6-507b-9805-5755d38131ee`, from `well_known_service_specification_id("traffic-influence")`)

and sends it on every TI activate.

The onboarded app is identified separately through

`network_capability.target.application_reference` (`service_specification_ref` /

`external_app_id` = CAMARA `appId`, optional `app_instance_id`). SRM resolves that reference to an

active workload instance and fills `target.application_server` before control-path resolution.

OEG still resolves `appId` → `app_registration_id` for its own `traffic_influences` bookkeeping

and for notification `selected_appInstanceId` scoping; that value is **not** the activate

command's `service_specification_id`.

This supersedes the earlier note that TI was out of scope for this ADR and "needs no seeded row".

Revisit trigger:

  "operation_id": "<the activate operation_id>",

  "state": "completed",

  "capability": "qod_session",

  "metadata": { "qos_status": "UNAVAILABLE", "qos_status_info": "duration_expired" },

  "metadata": { "capability_status": "UNAVAILABLE", "capability_status_info": "duration_expired" },

  "correlation_id": "…",

  "emitted_at": "2026-06-19T13:05:00Z"

}

```

`qos_status_info` is a new, optional metadata key distinguishing **why** a capability became

`capability_status_info` is an optional metadata key distinguishing **why** a capability became

unavailable. Defined values are `duration_expired` and `network_terminated`. It is metadata, never

`state` — backend and API-family vocabulary does not enter SRM's operational enum. When absent,

consumers treat the change as `network_terminated`, which preserves today's behaviour.

**OEG's mapping.** OEG maps `metadata.qos_status_info` to CAMARA's `statusInfo` on the

**OEG's mapping.** OEG maps `metadata.capability_status_info` to CAMARA's `statusInfo` on the

`QOS_STATUS_CHANGED` notification: `duration_expired` → `DURATION_EXPIRED`,

`network_terminated` → `NETWORK_TERMINATED`. The third CAMARA value, `DELETE_REQUESTED`, is

OEG-generated on the delete path and never arrives from SRM (ADR-0034).

- A CAMARA release that specifies expiry precision, or an API family whose expiry semantics differ

  from "terminate and report" — for example one requiring auto-renewal.

## Amendment (2026-10-21) — rename metadata keys

The status-event metadata keys are renamed from `qos_status` / `qos_status_info` to

`capability_status` / `capability_status_info`. Semantics and values are unchanged; the keys

apply to async network capabilities generally (QoD and Traffic Influence), not QoD alone.

* [ADR-0032](0032-databus-validation-failure-split-by-answerability.md) - DataBus validation failures split by answerability: dead-letter only unattributable messages; every readable-envelope failure returns failed_before_start

* [ADR-0033](0033-async-network-capability-caller-id.md) - async network-capability caller-facing ids (QoD sessionId, trafficInfluenceID) are OEG-minted and adopted as service_instance.id; external_ref reverts to the realization ref

* [ADR-0034](0034-network-capability-delete-is-async.md) - network-capability delete is async via command.srm.network.capability.deactivate, and its completion is consumed to a terminal record state

* [ADR-0035](0035-qod-session-service-specification.md) - a QoD session references one platform-seeded service specification held in OEG config; profile names stay unvalidated, and QoS profiles are a catalog-layer concern (resolves F2)

* [ADR-0036](0036-srm-owns-network-capability-expiry.md) - SRM owns expiry of async network capabilities and reports it via event.srm.operation.status metadata (qos_status_info); OEG runs no timer and maps it to CAMARA DURATION_EXPIRED

* [ADR-0035](0035-qod-session-service-specification.md) - a QoD session references one platform-seeded service specification held in OEG config; profile names stay unvalidated, and QoS profiles are a catalog-layer concern (resolves F2); amended 2026-10-20 so Traffic Influence uses the same seeded-spec pattern (app via `application_reference`)

* [ADR-0036](0036-srm-owns-network-capability-expiry.md) - SRM owns expiry of async network capabilities and reports it via event.srm.operation.status metadata (capability_status_info); OEG runs no timer and maps it to CAMARA DURATION_EXPIRED

* [ADR-0037](0037-canonical-target-ports.md) - target.device.ports / target.application_server.ports join srm.params/v1's canonical target descriptor, generic across every capability with a device/application-server target rather than allowlisted per capability_type

* [ADR-0038](0038-device-targeted-control-path-resolution.md) - device-targeted capabilities resolve their control path by probing candidate adapters with can_serve_target; the loop and the choice stay in SRM, the per-backend answer comes from TF-SDK

* [ADR-0039](0039-source-spec-stated-by-publisher.md) - source_spec is stated by the publishing component (OEG from CAMARA, FM from OPG.04) on network capability commands; SRM never derives it from the envelope source and never synthesizes a family, API, or version

| Callback | `CALLBACK_SETTINGS__TIMEOUT`, `__SECRET_KEY` | Default 10 s and unset; key must decode from base64url to exactly 32 bytes, validated at startup |

| QoD seed | `QOD_SETTINGS__SERVICE_SPECIFICATION_ID` | UUID default derived from `qod-session`; must match SRM seed |

| Location seed | `LOCATION_RETRIEVAL_SETTINGS__SERVICE_SPECIFICATION_ID` | UUID default derived from `location-context`; must match SRM seed |

| TI seed | `TI_SETTINGS__SERVICE_SPECIFICATION_ID` | UUID default derived from `traffic-influence`; selected SRM does **not** seed it (C02) |

| TI seed | `TI_SETTINGS__SERVICE_SPECIFICATION_ID` | UUID default derived from `traffic-influence`; must match SRM seed, which the referenced SRM revision predates (C02) |

| FM | `FM_SETTINGS__BASE_URL`, `__TIMEOUT` | HTTP URL default `http://localhost:8083`, 30 s; internal listener, not EWBI 8082 |

| Reconciliation | `RECONCILIATION_SETTINGS__ENABLED`, `__INTERVAL_SECONDS`, `__OPERATION_DEADLINE_SECONDS` | Defaults true, 60 s, 1800 s; force-fails stranded EAM operations, not backend cancellation |

| Gap | Why It Is Acceptable for Now | Workaround |

|---|---|---|

| C01/C02 QoD expiry owner and incompatible TI specification seed | Acceptance and accountable owner Unspecified | No agreed workaround; align decisions, OEG and SRM before relying on lifecycle correctness |

| C01 QoD expiry owner; C02 TI seed absent from the referenced SRM revision | C01 acceptance and accountable owner Unspecified; C02 is decided (ADR-0035 amendment) | No agreed C01 workaround; for C02, run against an SRM revision that seeds `traffic-influence` |

| C03/C04/C21 required outbox, broker-acknowledged EAM 202, changed-request 409 and replay/concurrency | These requirements do not establish acceptance of the implementation gap; acceptance/owner Unspecified | No guaranteed workaround; selected code lacks the outbox and required replay rule. Failure/retry/equivalence and operator policies remain Unspecified. |

| C09 private registry secret store/resolver | Acceptance/owner Unspecified | Reference generation alone is insufficient; no established workaround |

| C10 callbacks have one attempt; OQ-03 retry missing | Retry remains required; acceptance/owner Unspecified | Caller resource polling observes status; it does not fulfil notification delivery |

| Item | Missing | Plan | Already in Place |

|---|---|---|---|

| Reliable async lifecycle | Required outbox, broker-acknowledged EAM 202, changed-request 409, durable delivery and replay/late-event policy | Implement required outbox, acknowledgment and 409 behaviour; detailed recovery/equivalence and release remain Unspecified | SQL operations, event handlers and forced-failure sweep; no outbox or durable broker acknowledgment |

| Network alignment | QoD expiry/lifetime authority and TI specification agreement | Resolve C01/C02/C07/C08; implementation/release Unspecified | QoD/TI holders, activate/deactivate paths, QoD/location seeds in SRM |

| Network alignment | QoD expiry/lifetime authority; an SRM revision with the TI seed | Resolve C01/C07/C08 and move the SRM reference for C02; implementation/release Unspecified | QoD/TI holders, activate/deactivate paths, QoD/location seeds in SRM |

| Policy and discovery | Quota, usage/IEC/PEC, TMF facade and cache invalidation | Rate limit deferred; other sequence/release Unspecified | Roles/scopes, provider checks, EAM catalog reads |

| Notifications and operations | Retry/dead-letter, callback endpoint detail decision, operation GET | OQ-03/OQ-04/C11 decisions first; schedule Unspecified | Encrypted/tombstoned sink tokens and single-attempt delivery |

| API/operations completeness | Deployment PATCH policy, subscriber consent/routing, retention/migrations/backup, metrics | Proposals and decisions only; no invented delivery commitment | Existing supported family routes and native probes/logs |