Plugin Lifecycle

Plugins run at lifecycle moments where their required context exists. Odock does not publish private phase order, internal contracts, queue behavior, or source wiring. The public model is enough to reason about behavior, rollout, and evidence.

Lifecycle Moments

These names are conceptual. Your deployment may add gateway work around them: authentication, access grants, policies, SafetySec, budgets, quotas, routing, usage recording, and reconciliation.

Before Upstream Work

Use this moment when a plugin must act before content or metadata leaves Odock.

Common examples:

• request enrichment with tenant, project, billing, or trace metadata
• custom headers for approved upstream integrations
• tenant-specific eligibility checks
• proprietary DLP checks before egress
• custom approval workflow before sensitive model use
• route-specific webhook calls that must complete before upstream work

Possible outcomes:

• allow the request unchanged
• add metadata or headers
• transform approved request fields
• block with a user-visible reason
• emit request-side evidence

Do not place response-dependent plugins here. The response does not exist yet.

After Upstream Response

Use this moment when the plugin needs the provider or MCP response before acting.

Common examples:

• response DLP or classification integration
• response metadata enrichment
• post-response policy evidence before the caller sees the response
• custom response transformation for a specific tenant or tool
• analytics signals that depend on output status or content

Possible outcomes:

• allow the response unchanged
• transform approved response fields
• block or replace the response when configured to enforce
• emit response-aware evidence

Use SafetySec instead of a plugin for prompt safety, response safety, redaction, leakage prevention, or repeated-risk behavior.

After Response Or Evidence Stage

Use this moment for work that should not delay the caller and cannot change the result.

Common examples:

• audit export
• SIEM forwarding
• webhook delivery
• email notifications
• analytics warehouse export
• request id correlation
• post-response recommendation signals
• detection of special words or business events for reporting

Use it for background recording, export, or analysis. Do not use it for enforcement that should stop a request.

Ordered, Independent, And Background Work

Use ordered work when a plugin may change state, transform content, or stop the request. Use independent work for observation and evidence that do not depend on other plugins. Use background work for audit export, webhooks, email, or analytics.

Ask: can this plugin change what the caller receives, or only record and export evidence?

For lane mechanics, including how plugins and active flows are ordered together, see Execution Lanes.

Decision Tree

Evidence Expectations

A plugin should leave evidence for:

• request id
• plugin name or display name
• lifecycle moment used
• action taken
• user-visible result, if any
• scope: organisation, team, API key, model, MCP server, or tenant
• external system called, if applicable
• whether the plugin changed request or response data
• whether the plugin ran in the response path or background

For current custom plugin delivery, see Request A Custom Plugin. For the planned self-service ecosystem, see Marketplace. For conditional, multi-step behavior across these same moments without a custom plugin, see Flow Studio.