Skip to content

Capability Governance Ledger

This ledger evaluates capabilities, not modules. A module is one possible implementation of a capability. The governance process evaluates whether the capability is already owned by an authoritative platform before deciding whether Bluefly should own any remaining implementation.

Governance Order

Every capability follows this strict evaluation order: Business Capability → Capability Inventory → Authoritative Owner → Platform Primitive → Native Capability Evaluation → Remaining Delta → Governance Outcome → Implementation Decision

Possible Governance Outcomes

  • Adopt: The ecosystem natively provides this.
  • Configure: The ecosystem provides this via configuration (Recipes/ECA).
  • Extend: The ecosystem requires a small plugin/hook.
  • Package: The capability is reusable and should be decoupled.
  • Upstream: The capability should be contributed to open source.
  • Differentiate: The capability is genuine Bluefly IP.
  • Retire: The capability is obsolete or entirely redundant.

Remaining Delta Classifications

  • NONE: Platform owns everything.
  • CONFIG: Configuration only.
  • EXTENSION: Plugin. Hook. Adapter. Recipe.
  • PACKAGE: Reusable software. Could live independently. Could become contrib/OSSA.
  • PRODUCT: Business differentiation.
  • UNKNOWN: Protected until evidence exists.

Platform Evaluation Order

Adopt → Configure → Extend → Package → Differentiate 1. Drupal Core 2. Drupal CMS 3. Drupal Contrib 4. Composer Ecosystem 5. OSSA 6. Bluefly Extension 7. Bluefly Product

1. Capability Inventory Standard Format

Before evaluating any capability, the following questions must be answered: * Capability: Name * Purpose: What does it do? * Consumers: Who or what uses it? * Inputs: What data does it take? * Outputs: What data does it yield? * Protocols: How does it communicate? * Storage: Where does it store state? * Execution: Where does it run? * Security: What are the boundaries? * Dependencies: What must exist for it to work? * Configuration: How is it configured? * Tests: How is it validated?

2. Governance Pipelines

Enhancement Pipeline (For Strategic Capabilities)

  1. Capability inventoried
  2. Authority identified
  3. Remaining delta defined
  4. Enhancement plan
  5. Implementation validated
  6. Receipt

Retirement Pipeline (For Redundant Capabilities)

  1. Capability inventoried
  2. Native capability evaluated
  3. Replacement demonstrated
  4. Replacement validated
  5. Redundancy proven
  6. Authority Receipt
  7. Candidate Retirement

Tier 0 — Strategic Platform Capabilities (Untouchable Core)

These projects CANNOT be retired. They must be built and enhanced to the highest Drupal 2026 standards.

1. Open Standard Agents (ai_agents_ossa)

  • Status: CRITICAL STRATEGIC CAPABILITY (The most important pillar)
  • Authoritative Owner: OSSA (Open Standard Server Agents)
  • Candidate Platform: drupal/ai_agents_ossa
  • Governance Goal: This is the definitive hub for AI orchestration.
  • Current Implementation: ai_agents_ossa (and related extensions)

2. DUADP (Decentralized Universal AI Discovery Protocol)

  • Status: Strategic Capability
  • Authoritative Owner: DUADP Specification
  • Candidate Platform: Drupal, OSSA, MCP, External Runtime
  • Governance Goal: Improve, Align, Upstream where possible, Reduce remaining delta.
  • Current Implementation: duadp Drupal module

3. API Normalization

  • Status: Strategic Capability
  • Authoritative Owner: OpenAPI, JSON Schema, Tool API, MCP
  • Governance Goal: Become the reference implementation of API normalization for Drupal.
  • Current Implementation: api_normalization Drupal module

4. Cedar Policy

  • Status: Strategic Capability
  • Authoritative Owner: AWS Cedar / Fine-grained access control
  • Governance Goal: Determine if it should become the definitive drupal/cedar_policy contrib module.
  • Current Implementation: cedar_policy Drupal module

5. Secure Drupal (Recipe)

  • Status: Strategic Capability
  • Authoritative Owner: Drupal Core Recipes
  • Governance Goal: Assemble security baseline configurations into a distributable Core Recipe rather than a custom module, adhering to "Configuration before code".
  • Current Implementation: Drupal Recipe

(This tier also includes Ai Provider Apple, DITA CCMS)

Tier 1 — Ecosystem-Owned Capabilities

(Formerly: Pure Ecosystem Replacement Candidates)

recipe_onboarding

  • Authoritative Owner: Configuration distribution
  • Remaining Delta: UNKNOWN
  • Pipeline: Retirement Pipeline (Pending capability inventory)

alternative_services

  • Authoritative Owner: Dependency injection and service overrides
  • Remaining Delta: UNKNOWN
  • Pipeline: Retirement Pipeline (Pending capability inventory)

Tier 2 — Boundary Capabilities

(Examples: MCP, OpenClaw, Tunnels, Code execution, Source connectors)

MCP Routing & Discovery

  • Authoritative Owner: MCP protocol discovery and routing surface
  • Candidate Platform: drupal/mcp_server, mcp_tools
  • Remaining Delta: UNKNOWN
  • Pipeline: Enhancement or Retirement Pipeline (Pending evaluation)
  • Current Implementation: mcp_registry

Acquia Source MCP Connection

  • Authoritative Owner: Data ingestion and MCP bridging for Acquia APIs
  • Candidate Platform: drupal/mcp_server, Tool API, Migrate API
  • Remaining Delta: UNKNOWN
  • Pipeline: Enhancement or Retirement Pipeline (Pending evaluation)
  • Current Implementation: source_connector (Custom Acquia Source MCP module)

Tier 3 — Differentiating Capabilities

Agent Marketplace

  • Authoritative Owner: Deployment, Agent analytics, Commerce integration
  • Remaining Delta: UNKNOWN
  • Governance Goal: Evaluate remaining delta against ai_agents_ossa.
  • Current Implementation: ai_agents_marketplace