Add Provider Provenance Metadata to Improve Query402 Catalog Transparency#111
Open
Damilorlar wants to merge 2 commits into
Open
Add Provider Provenance Metadata to Improve Query402 Catalog Transparency#111Damilorlar wants to merge 2 commits into
Damilorlar wants to merge 2 commits into
Conversation
- Provenance type (mock|fallback|live|unknown) in shared types + schema - Set provenance on all 7 providers in pricing.ts - Compact color-coded badge in ControlDeckPage provider cards - Tests for catalog shape, provenance values, and baseline verification
…ence - Add network-aware resolveStellarExplorerUrl() supporting testnet and pubnet - Enhance buildTransactionLink/buildAccountLink with optional network param - Add paymentProofLinksSchema Zod schema for runtime validation - Use buildPaymentProofLinks in web x402 client to enrich responses - Include proofLinks in agent-client runPaidQuery return value - Display payment proof links in validate-real.ts output - Fix pre-existing provenance field in registry.test.ts and schemas.test.ts
|
@Damilorlar is attempting to deploy a commit to the emrekayat's projects Team on Vercel. A member of the Team first needs to authorize it. |
Owner
|
Thanks for the PR. I rechecked the merge ref from the maintainer account. The focused checks pass: git diff --check main...pr-111-merge
npm run test --workspace @query402/shared
npm run test --workspace @query402/api -- src/lib/pricing.test.ts src/providers/registry.test.ts src/routes/public.test.ts
npm run test --workspace @query402/agent-client
npm run typecheck --workspace @query402/api
npm run typecheck --workspace @query402/web
npm run typecheck --workspace @query402/agent-clientResults: shared tests pass (12), API tests pass (30), agent-client tests pass (9), and all typechecks pass. I tried to merge, but GitHub now reports the branch as |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
##closed #84
The Query402 provider catalog currently does not distinguish between deterministic demo providers, fallback providers, and live production providers. As a result, reviewers, investors, and end users may be unable to determine the credibility and origin of provider data before making payment decisions.
This project introduces a provenance field to the provider catalog, enabling each provider to explicitly indicate whether its data is sourced from a mock, fallback, live, or unknown provider. The dashboard will be updated to display this information as a compact badge, giving users immediate visibility into the provider's status while ensuring that unknown or missing provenance is never represented as live.
The implementation should update the provider catalog API, shared schemas, and frontend dashboard without affecting existing pricing, payment flows, or provider behavior. Appropriate tests should also be added to verify the catalog response structure and the correct rendering of provenance badges in the user interface.
Acceptance Criteria
Add a provenance field to every provider returned by the catalog.
Support the following provenance values:
mock – Deterministic demo provider.
fallback – AI or provider fallback mode.
live – Configured production provider.
unknown – Safe default when the provider source cannot be determined.
Display the provenance value as a compact badge in the dashboard.
Ensure unknown or missing provenance is never displayed as live.
Update shared schemas to include the provenance field.
Add tests covering:
Provider catalog response format.
Dashboard rendering of at least one provenance badge.
Ensure no changes are made to pricing, payment processing, or transaction behavior.
Maintain backward compatibility while improving transparency for SCF reviewers, investors, and end users.