Portal owns service discovery, presentation, and channel entry. Its portal.service_directory capability projects provider-owned, versioned service definitions into available, explainably unavailable, or undiscoverable entries. It does not persist the institutional service promise or import Cases, Forms, Workflow, Access, or Policy tables.

The capability works in a reduced composition without a Services provider by returning an empty directory. When a provider is present, provider-level access filtering remains authoritative and Portal adds only presentation-oriented availability checks for publication, effective time, audience, module, and capability requirements.

The tenant-scoped /api/v1/portal/services endpoint and /portal WebUI expose the projection. Audience visibility is derived from trusted principal and active function-assignment state on the server.

POST /api/v1/portal/services/{service_id}/launch re-fetches and re-evaluates the exact Service revision before any effect. URL entries return a validated redirect. Case, form, and workflow bindings delegate through the optional cases.service_launcher, forms_runtime.service_launcher, and workflow_engine.service_launcher contracts; each is tenant-bound and replay-safe. A missing owner launcher makes the entry explainably unavailable. Form launch resolves an exact published <form-id>/<revision> and returns the owner's Form-instance route rather than persisting values in Portal.

See docs/SERVICE_DIRECTORY_CONCEPT.md.