ADR-0024: Module Library Admits Both Provenance Types
Accepted
Date: 2026-06-10
Context
A Module is a pre-composed business-domain assembly. Two sources of Modules are reasonable:
- Platform-composed: the platform team assembles a Module from raw Adapters, validates it, admits it.
- Curated from open source: a high-quality open-source modular project already exists (Lago for billing, Ory Kratos for auth, BillingGoat for subscriptions); the platform wraps it as a Module.
Forcing one path eliminates valid options. Allowing both requires the Manifest schema and curation pipeline to handle both.
Decision
The Module Library admits both provenance types. The Module Manifest records which kind:
provenance.composition_source: "platform-composed"— Module is assembled from raw Adapters by the platform team. Manifest lists constituent Adapters.provenance.composition_source: "upstream"— Module wraps an existing open-source project. Manifest records the upstream project’s identity and the wrapping integration.
The Composer treats both identically at resolution and runtime; the distinction matters only for provenance auditing and curation tracking.
Rationale
- Best of both worlds: leverage high-quality upstream projects when they exist; build custom when they don’t.
- The tomato analogy (from the design conversation): puree can be made or bought; the dish doesn’t care, but the kitchen records which.
- Some domains have excellent open-source modular projects; others don’t. The platform adapts to reality.
- Curation effort is minimized by not reinventing what already exists well.
Consequences
- Module Manifest schema supports both provenance types with required fields differing per type.
- The Curation Pipeline includes vetting paths for both kinds: composition validation for platform-composed; wrapper validation for upstream.
- License and security scanning applies to both: platform-composed Modules inherit constituent Adapter licenses; upstream Modules carry the upstream project’s license.