Skip to content

Add vendorExtensions mechanism for platform-specific data - #42

Open
m-messer wants to merge 2 commits into
mainfrom
feature/vendor-extensions
Open

m-messer wants to merge 2 commits into
mainfrom
feature/vendor-extensions

Conversation

@m-messer

Copy link
Copy Markdown
Contributor

Summary

  • Adds a generic vendorExtensions extension point (paths/shared/schemas/VendorExtensions.yml), referenced from ChatRequest.context, ChatRequest.configuration, EvaluateRequest.configuration, and User, so platform-specific data doesn't have to be forced into core schemas or fork the spec.
  • Vendors namespace their fields under x-<platform-slug> inside vendorExtensions, following the OpenAPI Specification Extensions convention.
  • Adds VENDOR_EXTENSIONS.md, a namespace registry (namespace → owner → docs link) to prevent collisions, plus the governance rule that a concept only graduates into a core/shared schema once ≥2 independent platforms need the identical shape.
  • Links the registry from README.md and CONTRIBUTING.md.
  • Registers Lambda Feedback's x-lf namespace, documented at https://github.com/lambda-feedback/mued-vendor-spec.

Background: module/set/question were found to be Lambda-Feedback-specific concepts during spec work, not universal — this gives vendors a sanctioned extension point instead of baking platform vocabulary into core schemas.

Test plan

  • npm run lint — no new errors/warnings vs. main baseline (8 pre-existing warnings, unrelated to this change)
  • npm run bundle — all four vendorExtensions occurrences resolve correctly in dist/openapi.yml
  • Reviewer sign-off on the registry/governance model in VENDOR_EXTENSIONS.md

🤖 Generated with Claude Code

https://claude.ai/code/session_017BgnWSuAQFVeeTDrUmo4Uc

m-messer and others added 2 commits August 21, 2026 13:37
Lambda Feedback's x-lf schema fragments are published at
lambda-feedback/mued-vendor-spec.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017BgnWSuAQFVeeTDrUmo4Uc
@maximiliansoelch

Copy link
Copy Markdown
Contributor

@m-messer Can you explain a bit more in detail what the idea behind this will be and why we need it (also, why the additionalProperties field that we deliberately used already in the spec is not enough for your use case)?

Just so I can better understand the reasoning behind this? 🙂

@m-messer

Copy link
Copy Markdown
Contributor Author

@maximiliansoelch Sorry, it wasn't clear in the first place. The idea behind vendor extensions is to formalise platform-specific schemas. The example for Lambda Feedback can be found here: https://github.com/lambda-feedback/mued-vendor-spec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants