Pre-Flight

re-Flight is onboarding that explains itself before apply. Drop the customer’s files as they actually send them. The pipeline maps columns, normalizes rows into staging, resolves supplier candidates, cross-validates entities, and produces a structured apply-plan—what would be created, what needs review, and why apply is blocked when conflicts are open. It feels lightweight for the person uploading—and safe for procurement and CS, because nothing is presented as “ready” without passing explicit gates in dry-run mode. How it works. Bring the file. Suppliers, POs, categories—same tenant, clear entity type. Map without guesswork. Headers align to canonical fields; low-confidence mappings are flagged for human review. Transform into staging. Raw cells become structured rows in FM field space—not a silent import. Resolve duplicates. Unified supplier candidates with traceable source IDs. Validate across modules. PO ↔ supplier, categories, transform errors, mapping quality—conflicts get rules, severity, and suggested owner. Apply-plan, not blind push. Counts, samples, conflicts, and block state in one JSON artifact for tickets and sign-off. Schema path (Tab 2). Mapping documents → draft import schema, checked against OpenAPI when available, replay against a stub when validated. Dry-run by design. Staging in PostgreSQL; outbound writes constrained—clarity before commitment.

Same recording as on Drive—now on Loom for easier viewing: https://www.loom.com/share/22a6becba44e41b38f85093af684f178