The most useful work projects reduce the distance between messy evidence and a decision someone already needs to make. They do not begin by replacing a role or giving a model unrestricted access.
Prototype with historical or read-only data. Compare the model result with the outcome your team actually produced, then turn disagreements into evaluation cases.
Research and decision projects
Build a decision-brief generator that turns a controlled packet into a two-page recommendation with cited findings, uncertainties, and a decision table. Build an evidence-first research assistant that separates primary sources, secondary reporting, inference, disagreement, and open questions. Build an RFP or grant monitor that extracts eligibility, deadlines, required evidence, and a go/no-go recommendation for human review.
- First version: three source documents and one fixed brief template.
- Success test: every material claim links to allowed evidence.
- Boundary: the system recommends; the accountable person decides.
Meetings, support, and operations
Create a meeting-to-commitment tracker that extracts decisions, owners, due dates, dependencies, and unresolved questions rather than another transcript summary. Create a support distiller that produces the issue, reproduction steps, impact, sentiment, and recommended route. Create an intake classifier that redacts unnecessary sensitive fields and sends ambiguous cases to review.
- First version: fifty historical resolved examples.
- Success test: known owners and routes match the approved record.
- Boundary: no message is sent and no ticket is closed automatically.
Spreadsheets, documents, and code
Build a spreadsheet anomaly reviewer that identifies suspicious formulas, outliers, missing values, and reconciliation gaps without silently changing the workbook. Build a policy change explainer that compares versions and shows affected teams, dates, and unresolved conflicts. Build a code-change explainer that uses a diff, tests, and architecture notes to describe downstream impact and review risk.
- First version: plant known errors in a safe copy.
- Success test: known issues are found without inventing dependencies.
- Boundary: changes remain proposals until a qualified reviewer accepts them.
The first useful automation is often a better review queue, not automatic execution.
Primary sources