Capability Governance Record (CGR)¶
1. Capability Classification¶
- Capability Class: [e.g., Protocol, Validation Library, Framework Integration, End-User Product]
- Primary Capability: [Name of the capability being evaluated]
2. Capability Inventory¶
Briefly describe the capability and its core responsibilities in the ecosystem.
3. Protocol / Specification¶
- Specification: [Name of the specification]
- Specification Authority: [e.g., Open Standard, Bluefly Specification]
4. Reference Implementations¶
- Implementations: [List reference implementations, e.g., NPM Library, Drupal Contrib, CLI]
- Implementation Authority: [e.g., NPM Ecosystem, Drupal Contrib]
5. Operational Authority¶
- Operational Layer: [Where this actually runs in production]
- Operational Authority: [e.g., Bluefly Product, Specific Website (ContextControl), Gas Town]
6. Implementation Inventory¶
What specific components/modules make up the current implementation under review?
7. Reusable Primitive Analysis¶
What is the smallest reusable primitive? Map the dependency direction. * [e.g., Specification] → [e.g., NPM Library] → [e.g., Drupal Adapter] → [e.g., CLI]
8. Dependency Graph¶
How this capability interacts with the rest of the platform. * Consumes: [What core APIs or services it uses] * Provides: [What net-new functionality it offers] * Extends: [What plugin APIs or systems it extends] * Depends On: [Hard dependencies] * Publishes: [Manifests, endpoints, or specs] * Exposes: [UIs, registries, or routes]
9. Authority Evaluation Order¶
Evaluate authorities in order, then record the stopping point. Business Capability → Open Standards → Existing Protocols → Drupal Core → Drupal CMS → Drupal Contrib → Composer Ecosystem → NPM Ecosystem → OSSA → Bluefly Extension → Bluefly Product
- Stopped at: [Authoritative layer]
- Reason: [Why it stops here]
10. Capability Comparison Matrix¶
Mandatory Rule: Split "Uses" from "Owns". A capability using a core API does not own it.
| Feature | Uses | Owned By | Gap (Delta Taxonomy) |
|---|---|---|---|
| [e.g., Async Queue] | [e.g., Drupal Queue API] | [e.g., Drupal Core] | NONE |
| [e.g., Protocol Handler] | [e.g., NPM Library] | [e.g., Bluefly Spec] | PRODUCT |
| [e.g., Registry Serialization] | [e.g., JSON:API] | [e.g., Drupal Core] | CONFIG |
11. Delta Classification¶
Summary of the Delta based on the matrix above. * Delta: [PRODUCT, EXTENSION, CONFIG, NONE] * Confidence: [HIGH, MEDIUM, LOW] * Reason: [Explanation]
12. Enhancement Backlog (The Engineering Plan)¶
What ultimately reduces custom code.
Move to Core / Config (NONE / CONFIG) * [e.g., Queue execution] * [e.g., JSON:API serialization]
Move to Contrib (EXTENSION) * [e.g., ECA integrations] * [e.g., Tool API bindings]
Retain as Product / Upstream NPM (PRODUCT) * [e.g., Federation algorithm, NPM base libraries]
13. Governance Outcome¶
- Target Outcome: [e.g., Candidate Package / Differentiate]
14. Evidence Receipt¶
- [x] Capability inventoried (Class, Specs, Implementations)
- [x] Authorities identified (Spec, Implementation, Operational)
- [x] Reusable Primitives mapped
- [x] Dependency Graph completed
- [x] Capability Matrix (Uses vs Owns) finalized
- [ ] Enhancement plan drafted
- [ ] Implementation validated
- [ ] Receipt