Allow signal-owned platforms to advertise get_signals without activate_signal

[bokelley]

Summary

The current decisioning platform mapping treats signal-owned the same as signal-marketplace: both require and advertise get_signals plus activate_signal.

For publisher-owned signals that are already usable on the seller platform inventory, activate_signal is the wrong semantic. The seller returns its own first-party signals from get_signals; those signals can only be used on that seller inventory and are already active/usable in later media-buy targeting. There is no buyer-triggered destination provisioning step.

Current SDK behavior

• adcp.decisioning.handler.SPECIALISM_TO_ADVERTISED_TOOLS["signal-owned"] includes activate_signal.
• adcp.decisioning.dispatch.REQUIRED_METHODS_PER_SPECIALISM["signal-owned"] requires activate_signal.
• This forces owned-signal sellers either to expose a no-op/fictional activation API or avoid the signal-owned specialism.

Expected behavior

One of these would work:

1. Treat signal-owned as discovery-only by default: advertise/require get_signals, not activate_signal.
2. Add a capability/feature flag that distinguishes "owned signals already usable on this inventory" from "signals requiring destination provisioning".
3. Split the specialisms so marketplace/provisioned signals continue to require activate_signal, while seller-local owned signals do not.

signals.features.catalog_signals=True plus get_signals is sufficient for the discovery/catalog use case.

Observed in

• package: adcp==5.6.0

[bokelley]

Triage

Classification: Bug (spec-misalignment in specialism method surface)
Bucket(s): handlers, client
Status: drafting-pr
Milestone: omitted

What the experts said:

• code-reviewer: Non-breaking for adopters (removing a requirement is less restrictive); two tests needed updating + new tests for both the required-method split and the advertised-tools divergence; @runtime_checkable Protocol gap documented via docstring warning. Approved after fixes.
• ad-tech-protocol-expert: Option 1 (discovery-only) is semantically correct — activate_signal's destinations field supports both DSP activation and agent-type destinations, but the manifest discrepancy (signal_owned.exercised_tools includes activate_signal) is a spec authoring error, not a conformance requirement. exercised_tools describes what a buyer may encounter in a storyboard; it does not mandate implementation. Not a blocker.

My take: Option 1 (make signal-owned discovery-only) is the right fix — requiring activate_signal for first-party signals forces sellers to expose a semantically wrong method. The spec manifest discrepancy is surfaced in the PR body as a candidate spec errata item, with the alternative Option B path documented if the reviewer prefers to keep activate_signal advertised-but-optional.

Draft PR: #793 — implements REQUIRED_METHODS_PER_SPECIALISM["signal-owned"] = {"get_signals"} and SPECIALISM_TO_ADVERTISED_TOOLS["signal-owned"] = _SIGNALS_OWNED_ADVERTISED_TOOLS. All 4314 unit tests pass.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01Wj8hJ62PeTgk6J3aKn4PXp

---

Generated by Claude Code

[bokelley]

Closing as completed on current main. The decisioning surface now treats signal-owned as discovery-only: get_signals is required/advertised, activate_signal remains marketplace-only/optional, and OwnedSignalsPlatform plus tests document the split.