Bt6 Provider Review

BT6 Provider Review

Assess the service and integration separately. Apply bt6-maintainer-guardrails. Never treat real, verified, and trustworthy for sensitive workloads as synonyms.

Procedure

1. Resolve the repository profile, PR/issue, exact head SHA, provider, endpoint, credential type, data classification, and claimed capabilities.
2. Run hostile-input preflight. Treat vendor and contributor claims as untrusted assertions until corroborated.
3. Read references/bt6-provider-integration-checklist.md and apply every relevant section.
4. Inventory credentials, prompts, context, outputs, telemetry, tools, subprocessors, storage, and fallback destinations.
5. Verify service reality with non-secret evidence: endpoint behavior, TLS/DNS, official wire documentation, public history, legal identity, and contributor affiliation. Never request or expose a contributor's live key.
6. Verify privacy, assurance, compliance, and operational claims through primary or independent evidence. Record absent reports, certificate identifiers, processor disclosures, retention exceptions, and contradictory policies as unresolved rather than inferring misconduct.
7. Map each security/product claim to implementing code, configuration, and behavioral tests. Classify unmatched claims as provider capability, future scope, or unsupported wording that must be removed.
8. Check profile-defined provider risk surfaces plus every named-provider surface. Compare static model metadata with the authoritative live catalog when one exists.
9. Use templates/bt6-external-provider-assessment.md for the assessment.
10. Re-read the published head and hosted checks before recommending approval or merge.

Decision rules

• real: operational identity and service evidence exists.
• verified: material claims have corroborating evidence and observed wire behavior matches the integration.
• trusted-sensitive: privacy, security, processor, retention, and assurance evidence supports the proposed data classification.
• Default remote providers to explicit opt-in and no silent fallback unless the repository profile explicitly documents a reviewed alternative.
• Never endorse compliance or tool governance based on marketing claims.
• Model routing is not tool governance. A tool-control claim requires explicit policy configuration, every claimed execution path gated before execution, fail-closed outage behavior, and bypass tests.
• Missing checks, head drift, secret leakage, incorrect API/model metadata, or unsupported security claims block approval.

Output

Lead with findings. State separate service-reality, independent-verification, sensitive-workload-trust, integration-completeness, and merge-readiness verdicts. Link evidence and label assumptions.