Add Provider Provenance Metadata to Improve Query402 Catalog Transparency#111
Add Provider Provenance Metadata to Improve Query402 Catalog Transparency#111Damilorlar 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. |
|
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 |
|
Rechecked: after the other PRs were merged this one now has merge conflicts with |
2 participants
##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.