TenantAtlas/specs/294-provider-verification-runtime-semantics/data-model.md

Data Model: Provider Verification Runtime Semantics Stabilization

Overview

294 introduces no new application entity, table, or persisted runtime artifact. Its only modeled data is spec-local preparation truth for later implementation: one failure-classification artifact, one bounded failure-category inventory, and one bounded stabilization-seam inventory.

Pinned Failure-Classification Categories

Category	Meaning	Default Treatment in 294
surface-or-report-baseline-drift	stale visible provider connection or verification report expectation that no longer matches current shared summary/report truth	fix in 294
fixture-contract-drift	test setup no longer matches the repo's canonical startable verification or provider-operation fixture contract	fix in 294 before widening runtime changes
provider-verification-runtime-regression	a canonical shared runtime owner is still wrong after fixture alignment	allow minimal targeted fix in 294
dedupe-concurrency-contract-drift	current expectations for dedupe versus scopeBusy or queue counts no longer match the shared gate contract	fix in 294
out-of-scope-existing-debt	failure or drift outside the bounded provider/verification stabilization scope	document, do not silently absorb
resolved-or-not-needed	initially suspected drift no longer needs work after classification or adjacent repair	record and stop

Pinned Stabilization Seams

Seam Key	Meaning	Primary Targets
provider-neutrality-surface	provider connection create/edit/list/detail expectations around neutral target-scope disclosure and nested provider identity detail	ProviderConnectionSurfaceSummary, target-scope descriptor/normalizer, resource detail expectations
shared-startable-fixtures	canonical test fixture contract for queued verification and provider starts	tests/Pest.php, createUserWithTenant(...) call sites, provider connection factory usage
verification-start-contract	canonical verification start, dedupe, blocked, and new-run-after-completion behavior	StartVerification, directly implicated resolver/identity seams, verification feature tests
provider-dispatch-concurrency	canonical provider-operation dedupe versus scopeBusy behavior for the same connection	ProviderOperationStartGate, directly implicated run-identity owner, provider operation feature tests
verification-report-summary	canonical verification report counts and visible summary expectations	MicrosoftProviderHealthCheck, report writer/schema seams, report feature tests

Spec-Local Artifact: failure-classification.md

Field	Meaning
Group	failing test, failing scenario family, or grouped lane-visible mismatch
Seam	one pinned stabilization seam
Category	one pinned failure category
Observed Failure	short description of what the current failing output shows
Candidate Owner	current best owner seam to inspect first during implementation
Fix In 294?	yes, no, or only-if-runtime-owner-proven
Follow-up	next action if the group remains open
Status	current implementation-tracking note

Invariants

• The same six failure categories must appear in spec.md, plan.md, research.md, quickstart.md, tasks.md, checklists/requirements.md, and failure-classification.md.
• The same five stabilization seams must appear in spec.md, plan.md, research.md, quickstart.md, tasks.md, checklists/requirements.md, and failure-classification.md.
• 294 introduces no new runtime product state and no new runtime persistence.
• 294 must not widen into route-cutover repair, full-suite repair, or a broader provider-boundary foundation package.
• Browser proof remains conditional and reuses the existing Spec281ProviderConnectionScopeSmokeTest only when visible provider-connection disclosure changes.

Out-of-Scope Data Changes

• no database migrations by default
• no new provider-profile or verification-report persistence
• no new provider abstraction or registry
• no new verification schema version
• no new browser fixture family