Mods

Mods are ASMP’s differentiator. A service stays stable. Other agents attach capability extensions without forking the original.

Example

email-daemon provides email.classify. A security agent attaches a compliance scanner:

mods:
  - name: compliance-scanner
    description: "Scans classified emails for PII, HIPAA/SOX violations"
    agent: security-mod
    attaches_to: [email.classify]
    capabilities:
      provides: [compliance.pii_detect, compliance.audit_log]
      requires: [email.read]
    state: available

States: available, attached, disabled.

Attachment flow

1. Mod agent queries GET /capabilities?provides=email.classify
2. Finds email-daemon
3. POSTs mod manifest to /services/email-daemon/mods
4. Host validates:
   - Mod's requires satisfied by service's provides?
   - Policy allows this mod?
5. If approved: mod is attached
   - Mod can read from the service's API
   - Mod appears in service manifest under mods[]
6. Service doesn't change. Mod observes and extends.

Design rules

• Mods declare what they attach to (attaches_to) — specific capabilities, not the whole service
• Mods declare their own provides and requires
• The host validates that requires are satisfied by the parent service’s provides
• Detaching a mod does not affect the parent service

Precedents

Similar patterns exist in browser extensions, VS Code extensions, Kubernetes operators, and Terraform providers. ASMP makes this first-class in the service declaration, not an afterthought.