Model fallback attribution as one logical operation

Durable fallback attribution should represent one logical operation, preserve both the selected and final execution paths, and record downstream validation separately from decoder success. This applies when a request may switch implementations or providers before returning one result; it does not imply that every rejected request or transient client attempt deserves a row. Use request idempotency plus a source-specific uniqueness guard, keep diagnostic persistence best-effort, and store only bounded metadata and foreign-key correlation—not raw inputs, outputs, images, secrets, or error messages.

This extends the prior lesson “Fallback telemetry should preserve selected and actual decoder paths” from transient telemetry into a proposed database model. The additional design hypothesis is that one combined row avoids double-counting fallback legs while retaining the selected provider failure and final fallback outcome, and that parse/validation outcome must be known before declaring success.

Evidence/example — 2026-09-14 UTC

Source provenance: COR-4234 ticket specification and repository documentation/code inspection for e3-solutions/theft. The planned CDL-back PDF417 attribution table records stored-image Adam-to-local fallback as one row, records realtime attempts only after the decoder is invoked, and records accepted browser-local success only after a durable submission exists. This is a ticket/design contract, not evidence of implemented or production-verified behavior yet.