Drop a file, get a table
Getting a CSV into a database is a job everyone has done and nobody enjoys. Look at the file, guess the types, write the CREATE TABLE, write the loader, discover row 40,000 has a comma in it. SnoutData now does the whole path: drop the file, review what it proposes, run it.
We call it a data flow. It has three parts and they are always the same three: a source, some optional reshaping, and a destination. Drag a file onto the window and the wizard opens with it already parsed, typed and shaped, so the first thing you see is a proposal to review rather than an empty form asking you to describe your own file back to it.
The types are proposed, with reasons
A structure advisor reads a sample and proposes the columns and their types, and tells you why it picked each one. You disagree with it by changing it, not by starting over: rename a column, force a type, drop one you do not want.
Where a record contains a repeating group, an order with line items inside it, and the parent has a key, that group can become a child table with a foreign key back rather than being flattened into columns or stringified into one. That is usually the thing you would have done by hand, and it is the thing most importers do not do at all.
You see the statements before they run
Before anything executes you see the exact CREATE TABLE and INSERT statements and where the data is going. If the destination connection is flagged as production, the same guardrails that protect a query you typed by hand apply here too.
Nothing happens because the app assumed something and did not mention it. That is the whole design rule for this feature, and it is why the wizard shows you a proposal instead of a progress bar.
Then it is a thing you can run again
The flow is saved. Run it by hand, or put it on a schedule and let it catch up on what it missed if the machine was asleep. A second run moves what is new rather than everything again, using a cursor where the source has a natural order and a content hash where it does not.
And every run is recorded: what it read, what it wrote, what changed, what it skipped. The next time somebody asks why a number moved, the answer is in the ledger instead of in your memory.
The destination is not only a table
A SQL table is the common case, but the same flow can land in a MongoDB collection with the nesting kept, a file (CSV, JSON, JSONL or a Markdown report), a validated JSONL fine-tuning set, or a vector index. The source and the shaping do not change; only where it ends up does.