
Keep vendor facts beside the integration
A provider can describe its deployment options and processing regions. The application records which option it actually uses, so tooling can compare the configured choice with the provider’s declared facts.
This supports an inspectable account of external services. It does not turn a vendor description into proof of the application’s actual data flows.
Example — Distinguish hosted and self-hosted use
The same integration may support a vendor-hosted service or an operator-run deployment. The application records its choice explicitly rather than treating every selected provider as an external recipient.
For engineers
ProviderComplianceProfile carries deployment models, vendor-region labels and an optional legal identity. ApplicationProviderComplianceChoice carries the operator’s selection per configured provider. These are different facts: a vendor offering a region does not establish that the application selected it.
Wonder CRM records the self-hosted monitoring choice in its application configuration:
Selected from wildo.saas.config.ts; surrounding declarations and imports are omitted.
sentry: {
deploymentModel: ProviderDeploymentModel.SELF_HOSTED,
},
This selected entry belongs under providerComplianceChoices. The schema requires a region for a vendor-hosted choice and disallows a provider-processing-region field on a self-hosted choice. The operator’s own hosting description covers the latter; the provider-region field is not a general infrastructure locator.
Report disagreement instead of inventing agreement
The comparison helper makes a configured region outside the provider’s declared list visible:
Selected from provider-compliance-profile.shared.schemas.ts; surrounding declarations and imports are omitted.
for (const [providerRef, choice] of Object.entries(params.choices)) {
if (choice.processingRegion === undefined) continue;
const profile = params.profilesByProviderRef[providerRef];
// No profile is not an assertion about a region — it is a provider that declares no compliance
// profile at all, which is a different gap and belongs to whoever reports THAT.
if (profile === undefined) continue;
if (profile.processingRegions.includes(choice.processingRegion)) continue;
asserted.push({ providerRef, region: choice.processingRegion });
}
return asserted;
The companion’s compliance-primary-facts report consumes that result using profiles carried by provider specifications. An unlisted choice is reported as application-asserted, not refused automatically: it may be a typo or a provider list that needs updating.
A profile is generally optional, but backend composition requires it for a coding-agent provider. Where information is missing, keep that absence explicit. The profile is evidence about declared provider options, not a certificate, a transfer determination or proof that every outbound path has been identified.
Reconcile the configured services with the application’s actual operations and its processor information. Direct outbound requests, webhooks and application-owned integrations can carry data too; this metadata alone does not enumerate or constrain every egress path.