Skip to content

Bluefly Governance Lifecycle

Governing Principle: The purpose of this lifecycle is not to maximize reuse or minimize custom code. The purpose is to identify the correct authority for every capability and accurately classify the remaining delta through evidence before implementation begins. Reuse, configuration, extensions, packages, and product differentiation are all valid outcomes. Success is measured by correct classification supported by evidence, not by the amount of custom code removed.

This document defines the strict, recursive lifecycle for all engineering initiatives, introducing a Capability Governance layer above traditional Architecture Decision Records (ADRs). This ensures all engineering work is evidence-driven and prevents runtimes from accidentally usurping specification authorities.

The 7-Stage Decision Pipeline

0. Initiate

  • Question: Why are we evaluating this capability?
  • Outputs: Problem Statement, Scope, Success Criteria, Constraints, Stakeholders.
  • Purpose: Prevents the execution of governance overhead on trivial changes that do not warrant evaluation.

1. Discover

  • Question: What capabilities exist?
  • Outputs:
    • Capability Catalog: The high-level map (e.g., "OSSA exists").
    • Capability Inventory: The decomposition (e.g., "OSSA consists of Manifest Validation, Discovery, Registry UI").
  • Purpose: Maps the domain landscape and breaks monolithic concepts into atomic capabilities.

2. Govern

  • Question: Who owns this capability?
  • Outputs: Capability Governance Record (CGR).
  • Purpose: Determines authority assignments (Specification, Reference, Operational, Governance) across all decomposed capabilities in the inventory.

3. Investigate

  • Question: What evidence is missing?
  • Outputs: Delta Discovery Plan, Evidence Artifacts (*_benchmark.md, *_matrix.md), Evidence Receipt.
  • Purpose: Conducts falsifiable experiments to discover the lowest-authority implementation that satisfies the capability. Classifies the delta (NONE, CONFIG, EXTENSION, PACKAGE, PRODUCT).

4. Decide

  • Question: What should we do?
  • Outputs: Architecture Decision Record (ADR).
  • Rule: An ADR cannot be written until the Engineering Investigation has issued an Evidence Receipt. The ADR summarizes evidence rather than proposing assumptions.

5. Implement

  • Question: How do we execute?
  • Outputs: Implementation Plan, Work Breakdown.
  • Purpose: Maps the ADR into explicit, actionable engineering tasks (file paths, classes, configs).

6. Verify (Recursive Feedback)

  • Question: Did we accomplish it?
  • Outputs: Verification Report, Updated Capability Catalog/CGR.
  • Purpose: Proves the implementation satisfies the initial capability without regression. Crucially, the outputs feed directly back into Stage 1 (Discover) to update the authoritative records of what currently exists.

The Capability Authorities

Every capability evaluation must separate ownership to prevent runtimes from assuming specification authority. 1. Specification Authority: The canonical contract (e.g., DUADP Protocol, OSSA Schema). 2. Reference Implementation: The reusable library (e.g., NPM package @blueflyio/openstandardagents). 3. Operational Authority: The environment running the implementation (e.g., Drupal, Node Agent). 4. Governance Authority: The board or maintainer with the authority to approve changes (e.g., Bluefly Architecture Board, OSSA Maintainers).