docs: add FDC3 v3 web guidance for route-scoped identity, context-only apps, and private context types

website/docs/api/ref/GetAgent.md

@@ -155,7 +155,11 @@ As web applications can navigate to or be navigated by users to different URLs a
 
 :::
 
-Finally, if there is still no Desktop Agent available, or an issue prevents connection to it, the `getAgent()` function will reject its promise with a message from the [`AgentError`](./Errors#agenterror) enumeration.
+::: note 
+
+When several FDC3-enabled applications are hosted on the same origin (e.g. `https://myplatform.example.com/trade` and `https://myplatform.example.com/watchlist`), each should be registered as a separate AppD record using a URL that includes the distinguishing path.  
+
+:::
 
 ## Injected iframes for adaptors and user interfaces
 

website/docs/app-directory/overview.md

@@ -97,10 +97,16 @@ The AppD API specification defines the optional use of an access token to identi
 
 The specification does not define or make mandatory any authorizations or roles that a provider or enterprise can define.
 
-A key concept in the App Directory is how applications are identified and referenced across different environments. Application identifiers are used both to uniquely describe apps within a directory and, in some cases, to locate the directory instance that hosts an application’s record.
+## Application `interop` Metadata
+
+AppD records include an optional `interop` field that describes how the application uses FDC3 APIs. This metadata serves multiple purposes: it supports intent resolution by declaring what intents the app listens for (`interop.intents.listensFor`) and raises (`interop.intents.raises`); it enables app catalog UIs to surface apps that interoperate with a given application; and it documents the app's interactions with User Channels (`interop.userChannels`) and App Channels (`interop.appChannels`) for other developers and desktop assemblers. See the [App Directory specification](pathname:///schemas/next/app-directory.html) (or the raw [OpenAPI schema](https://fdc3.finos.org/schemas/next/appd.schema.json)) for the full definition of the `interop` field.
+
+Applications only need to complete the elements of the `interop` element that they make use of.  An app that only listens to context on a user channel need only complete this section, for example.
 
 ## Application Identifiers
 
+A key concept in the App Directory is how applications are identified and referenced across different environments. Application identifiers are used both to uniquely describe apps within a directory and, in some cases, to locate the directory instance that hosts an application's record.
+
 Application Records served by an app directory are each labelled with an identifier, `appId`, which should be unique within the app directory instance and may be used to refer to or retrieve the application's record via the [app directory API](spec). This identifier may be made globally unique through a nested namespace approach and email address construction (`appId@fqdn`) where `@` followed by the app directory instance's host name is appended to it. The resulting globally unique identifier is known as a 'fully qualified application identifier'.
 
 Fully qualified appIds may be used to locate the appD instance hosting the application's record. See the [Service Discovery](#service-discovery) section for details.

website/docs/context/spec.md

@@ -115,6 +115,20 @@ organization-specific namespace, e.g. `blackrock.fund`.
 
 All well-known types at FDC3 level are prefixed with `fdc3`. For private type definitions, or type definitions issued by other organizations, different namespaces MUST be used, e.g. `blackrock.fund`, etc.
 
+#### Private and Proprietary Context Types
+
+Organizations frequently need to share domain-specific data that is not (yet) covered by a standardized FDC3 context type. FDC3 explicitly supports this through the use of organization-specific namespaces.
+
+Private context type names MUST be prefixed with a namespace that is unique to the issuing organization. Using a reverse-domain convention (e.g. `com.example`) or a well-known organizational abbreviation (e.g. `acme`) avoids collisions with both FDC3-defined types and types created by other organizations:
+
+```
+com.example.account       ✔  reverse-domain namespace
+acme.rfq                  ✔  organizational abbreviation
+account                   ✗  no namespace — risks collision with future standard types
+fdc3.account              ✗  reserved for FDC3 standard types
+```
+
+
 ### `name`
 
 Context data objects may include an optional name property that can be used for more information, or display purposes. Some