Generate a real data dictionary from a raw schema dump instead of column names with guessed descriptions

You are building a data dictionary entry-by-entry from the schema I give you, in the disciplined style of a data analyst who documents ambiguity rather than papering over it.

RAW SCHEMA OR COLUMN LIST
user_id (int), status (varchar), amount (decimal), created_at (timestamp), updated_at (timestamp), src (varchar), flag (boolean)

TABLE/DATASET PURPOSE (IF KNOWN)
Tracks subscription billing events for the core SaaS product

ANY BUSINESS CONTEXT ALREADY KNOWN
"src" likely refers to acquisition channel based on how it's used elsewhere in the codebase, but not confirmed for this table

WHO WILL USE THIS DICTIONARY
New analysts on the BI team who didn't build this pipeline

For each column, produce: the column name, inferred data type, a plain-language definition, and a note on units or format where relevant (currency, timezone, encoding). Where a column name is genuinely self-explanatory given standard conventions (e.g., created_at as a timestamp) and the business context provided, write the definition directly. Where a column name is ambiguous, non-obvious, or could plausibly mean two different things (a column called status with no visible value list, a column called amount with no stated currency or sign convention), do not guess — write the definition as "needs confirmation" and state the specific question that would resolve it, rather than inventing a plausible-sounding definition that might be wrong and would look authoritative regardless. Flag any column that looks like it duplicates or overlaps with another (two date columns that might represent the same event) as worth reconciling before this dictionary is treated as final. Note any column whose name suggests personal or sensitive data (email, ssn, ip_address-style fields) so that access-control questions get raised at documentation time rather than after the data's already in wide use.

WHAT NOT TO DO
Do not write a confident-sounding definition for a column you're actually guessing at — an incorrect data dictionary entry is worse than an honest "unconfirmed," because it gets treated as ground truth by everyone who reads it afterward. Do not skip flagging likely enum columns (status, type, category-style fields) as needing their actual value list documented — a definition without the possible values is incomplete for this kind of field.

OUTPUT FORMAT
Table: column name | inferred type | definition | confirmed or needs-confirmation | note (units, sensitive-data flag, overlap flag, or the specific question to resolve it).
Followed by: a short list of the columns most in need of a follow-up conversation with whoever owns this data, ranked by how much of the dictionary's usefulness depends on getting them right.