An external client/plugin question prompted this clarification:

If a server already models deployed systems using a 1:1 System:Deployment pattern, does that mean the server is already "attaching features to deployments"?

The answer is not necessarily.

Creating a Deployment resource for a System and exposing samplingFeatures from that Deployment are related, but they are not the same thing.

There are three distinct facts a server may or may not expose:

1. A System exists.
2. A corresponding Deployment exists.
3. The Deployment exposes a samplingFeatures association.

Many publisher patterns implemented so far focus on (1) and (2).

The question being asked by client developers is often about (3):

Can a client start from the deployment and discover the associated sampling features directly from the deployment side of the resource graph?

That is a separate capability from merely creating a deployment record.

The existing OS4CSAPI design work intentionally treats Deployment as the operational face of a System in many publisher patterns:

• one operationally meaningful system
• one corresponding deployment
• often a 1:1 relationship for user-facing navigation

This is the pattern described in CSAPI_Deployed_Systems_Design_Pattern.

However, a 1:1 deployment pattern does not automatically imply that all system associations are re-exposed from the deployment.

In other words:

• System A may expose /systems/{id}/samplingFeatures
• Deployment A may exist as the operational wrapper for System A
• but Deployment A may still fail to expose /deployments/{id}/samplingFeatures

The deployment exists, but deployment-scoped discovery is still incomplete.

OGC API - Connected Systems Part 1 treats Deployment as a first-class feature resource with its own associations.

Two standards facts matter here:

Part 1 defines samplingFeatures as a valid Deployment association.

In plain terms, a deployment can expose:

• the systems deployed during the deployment
• the features of interest observed/controlled during the deployment
• the sampling features associated to systems deployed during the deployment

This means Joana's request is standards-aligned, not a plugin-specific invention.

Part 1 also explicitly distinguishes:

• deployment location
• sampling-feature geometry

This distinction is important. A deployment can have a place/time context without that being equivalent to the geometry of the sampling footprint, sensor point, coverage polygon, or observed area.

So "we already have deployment geometry" is not the same as "we already publish deployment-linked sampling features."

A 1:1 System:Deployment pattern can provide:

• operational naming
• valid-time scoping
• deployment hierarchy
• deployment-scoped datastream or observation queries
• continuity of operational role even when hardware changes

These are the strengths already documented in the deployment design reports.

It does not automatically guarantee:

• a samplingFeatures link in the deployment representation
• a working /deployments/{id}/samplingFeatures traversal
• deployment-scoped aggregation of sampling features across subdeployments
• client discoverability of sampling features when the user navigates from deployments first

Those behaviors must be explicitly published.

When a client developer asks for features "attached to deployments," they usually mean one or more of the following:

1. The deployment representation contains a discoverable samplingFeatures association link.
2. The nested route /deployments/{id}/samplingFeatures exists and returns useful results.
3. A deployment-centered workflow can retrieve the same relevant feature geometry that is otherwise only discoverable from the system side.

This is mainly a resource-graph discoverability request.

It is not necessarily a demand for a different underlying data model.

If a publisher uses a 1:1 deployment pattern, then deployment-linked sampling features are often a reasonable next publishing enhancement, because:

• the system-side association may already exist
• the deployment is already treated as the operational face of the system
• deployment-first client workflows become more complete and intuitive

In many such cases, publishing deployment-linked sampling features is closer to:

• exposing an already meaningful association from another traversal point

than to:

• inventing a wholly new modeling concept

That said, it is still an implementation choice. The Part 1 association is useful and standards-grounded, but it is not the same thing as saying every deployment must always expose it in all publishers.

Use this distinction:

Do we create deployments for deployed systems?

This is the 1:1 deployed-system pattern.

Does a deployment explicitly publish samplingFeatures as an associated resource set?

This is the deployment-linked sampling-features question.

Can a client starting from a deployment discover the relevant feature geometry without having to pivot manually to systems first?

This is usually what plugin authors care about most.

If asked whether "we already do this," the best accurate response is:

We often already model deployed systems with a 1:1 System:Deployment pattern, but that is not automatically the same as publishing deployment-linked samplingFeatures. The real question is whether the deployment resource itself exposes a discoverable samplingFeatures association or traversal.

That framing preserves the value of the existing deployed-system pattern while correctly identifying the missing capability.

The likely misunderstanding is:

• internal assumption: "we already create deployments, so deployments already have the same feature relationships"
• client expectation: "if deployments are first-class operational resources, I should be able to discover sampling features from them directly"

Those are not equivalent.

A server can already be doing good deployment modeling and still have room to improve deployment-scoped sampling-feature discoverability.