Skip to main content

Governance & Change Management

The Base Product Specification (BPS) is designed to evolve with industry needs.
This section describes the governance framework for maintaining, extending, and versioning BPS.

1. Governance Objectives​

  • Ensure stability of the core BPS model.
  • Allow extensions for domain-specific needs without fragmentation.
  • Maintain transparency in decision-making and version control.
  • Encourage community participation while preserving conformance guarantees.

2. Versioning Policy​

  • BPS uses Semantic Versioning (SemVer): MAJOR.MINOR.PATCH.

    • MAJOR — incompatible changes to the core model.
    • MINOR — backward-compatible feature additions (new entities, relationships, vocab).
    • PATCH — editorial clarifications, bug fixes, or documentation updates.

  • A product descriptor MUST declare the BPS version to which it conforms.

3. Change Proposal Process​

  • Changes to BPS are managed via a public Request for Comment (RFC)-style process:

    1. Proposal Submission: Contributors submit a change request.
    2. Review: Governance body and community review for impact.
    3. Decision: Changes are accepted, deferred, or rejected.
    4. Publication: Approved changes are merged into the next release.

  • Accepted proposals are published as BPS Notes (informative) or BPS Extensions (normative).

4. Profiles & Extensions​

  • Profiles:

    • A profile is a restricted use of BPS, tailored for a specific domain (e.g., AI Products, Data Products).
    • Profiles MUST explicitly reference the base BPS version they build upon.

  • Extensions:

    • Extensions MAY introduce additional entities, attributes, or vocabularies.
    • Extensions MUST NOT override or redefine mandatory BPS concepts.
    • Extensions SHOULD provide mappings back to the BPS core for interoperability.

5. Governance Roles​

5.1 Current Roles​

At the initial stage, governance is exercised by a small founding team:

  • Chief Editor & Founding Architect (alias: KaizenX)

    • Responsible for conceptual integrity of BPS.
    • Exercises editorial authority and curates official releases.
    • Maintains the authoritative repository and ensures alignment with long-term vision.

  • Outreach & Adoption Lead (Mr Sharad K)

    • Responsible for external engagement through meetups, seminars, and public communications.
    • Gathers and synthesizes community feedback.
    • Translates adoption insights into proposals and change requests for editorial review.

Together, these two individuals serve as the Initial Maintainers and the Interim Review Board, responsible for day-to-day contributions, triaging issues, and validating conceptual consistency.

5.2 Future Roles​

As adoption grows, additional roles MAY be introduced:

  • Maintainers: Trusted contributors with responsibility for publishing new versions and ensuring quality.
  • Review Board: A rotating panel of experts validating extensions and major changes.
  • Community Contributors: Broader ecosystem participants submitting clarifications, extensions, or domain-specific profiles (e.g., AIPDS/AIPROD).
  • Consumers: Users of PDS/PROD descriptors providing applied feedback.

6. Alignment with External Standards​

  • BPS governance monitors developments in:

    • ISO/IEC AI and software standards
    • W3C metadata standards (DCAT, PROV-O, Dublin Core)
    • Industry initiatives (Open Data Mesh, EKGF)

  • Future BPS versions MAY integrate new external standards to maintain relevance.

7. Deprecation Policy​

  • Deprecated features MUST be clearly marked in the specification.
  • Deprecation implies removal in the next MAJOR version.
  • Implementers SHOULD migrate away from deprecated features promptly.

8. Transparency & Community​

  • Governance processes MUST be documented and open.
  • Meeting minutes, proposals, and decisions SHOULD be published.
  • Feedback channels (e.g., GitHub issues, mailing lists, working groups) MUST be maintained.

The founding team also intends to author the specifications for AIPDS (AI Product Deployment Specification) and AIPROD (AI Product Semantic Specification).
These will serve as the first concrete application of BPS in a specialized product domain, demonstrating the extensibility of the base model.

10. Long-Term Vision​

The governance of BPS aims to balance:

  • Stability (for adoption and tooling).
  • Flexibility (to accommodate new product domains).
  • Interoperability (alignment with global standards).

By doing so, BPS remains a trustworthy and extensible meta-specification for product descriptors across domains.

11. Workflow​

Governance Workflow​

12. Release History​

BPS v0.1 — Draft Release​

  • Release Date: 2025-09-19
  • Status: First Draft (DRAFT)
  • Approved by:
    • Chief Editor (KaizenX)
    • Outreach & Adoption Lead (Sharad K)

Summary​

  • Established the foundational meta-model of BPS.
  • Published canonical semantic binding in RDF/OWL Turtle (bps-0.1.ttl).
  • Added validation shapes in SHACL, JSON-LD context, and JSON Schema for developer use.
  • Released human-readable serialization guide and download index page.
  • Namespace established at: https://kivanura.org/spec/bps/0.1/.

Notes​

  • This is the first ever release of BPS, serving as a draft baseline.
  • Terms, classes, and properties may change before a 1.0.0 stable release.
  • Future domain-specific specifications (DPDS/DPROD, AIPDS/AIPROD, etc.) will declare conformance to BPS.