Letting AI read the resumes and suggest the schema
A pile of PDFs becomes a structured library when the AI extracts the names, proposes columns, and lets you keep only the ones that matter. Schema as a conversation.
Takeaway 1
The document library is the database — files plus columns is the schema.
Takeaway 2
AI extracts metadata from inside the file, not from a separate form.
Takeaway 3
You curate the schema — the AI proposes, you accept, edit, or drop.
A document library is your candidate database
Resumes arrive as files. Drop them in a SharePoint document library and you already have a table — every file is a row, and every column you add becomes a queryable field. There's no separate database to provision. The library is the workspace.
This matters because the next step — asking AI to fill in columns from the files themselves — only works when files and columns live side by side. The library co-locates the documents and their derived metadata.
In SharePoint, the document library doubles as the table. Files are rows, columns are derived metadata. Resume triage runs entirely in this one surface.
One sentence creates a column from file content
The opening move is a single ask: "Extract the person's name from each one of these files and add them to a new candidate name column." The AI reads every resume, picks out the name, and lands it in a new column — one row per file, populated.
The user reviews the column and decides to keep it. From that point on, every new resume that lands in the library can be extracted into the same column automatically.
Extraction is column-shaped. You describe the field you want, the AI reads the file, and the answer lands in the column for every row at once.
It looks like the AI is filling out a form. It isn't — the column is the form, and the files are the source. There's no intermediate data entry step.
Ask the AI what other columns would help
After the name column lands, the next prompt is "Suggest a few more columns that'll help me organize these resumes." The AI looks at what's in the files and proposes options: primary skill, years of experience, education, job title.
This flips the usual schema design pattern. Instead of guessing what columns the library needs up front, you let the AI read the corpus and tell you what's in there worth tracking.
Schema discovery beats schema design. The AI already knows what's in the resumes — let it tell you what fields to bother tracking.
Curate the suggestions — keep some, drop others
Suggestions are not commands. In the demo, primary skill is rejected ("a little noisy"), years of experience is dropped, but education and job title are kept. The user is still the editor.
This back-and-forth — propose, evaluate, accept or reject — is how the schema actually gets built. Each kept column becomes another lens for filtering candidates later. Each rejection saves a column that would have added noise without signal.
"AI organizing your data" sounds passive, like watching it work. The real value comes from your edits — the schema is a conversation, not a delivery.
Flashcards — Foundations
01 · Foundations
Document Library
tap to reveal →
A SharePoint container of files that doubles as a table — each file is a row, each column is queryable metadata. The single workspace for resume triage.
← tap to flip back
01 · Foundations
Extracted Column
tap to reveal →
A library column whose values are pulled from file contents by AI in a single instruction. The candidate name column is the first example in the demo.
← tap to flip back
01 · Foundations
Column Suggestions
tap to reveal →
AI-proposed fields based on what it sees inside the files. Flips schema design from guessing up front to discovering after reading the corpus.
← tap to flip back
01 · Foundations
Schema Curation
tap to reveal →
The keep-or-drop pass on AI suggestions. The user accepts useful columns and rejects noisy ones, treating the schema as a conversation rather than a delivery.