A mid-sized legal firm has thousands of PDFs — contracts, case notes, policy briefs, court filings — scattered across a shared drive. Every time someone needs to locate a specific clause, precedent, or policy detail, they spend hours doing it manually. The firm won't send confidential documents to any external service. Everything must stay on their own machine.

You've been brought in to fix this. No cloud APIs. No subscriptions. Just a system that lets anyone on the team ask a question in plain English and get an accurate, sourced answer from their own documents.

Build a system where a user points to a folder of documents (PDFs, text files, or a mix) and asks natural language questions about the content inside. The system should return a coherent, accurate answer alongside the specific document or passage it drew from.

The entire system must run locally — no external LLM API calls. Someone with a standard laptop and no GPU should be able to install and run it. Expose it via CLI, a web UI (Gradio or Streamlit), or both.

Bonus: handle edge cases — 300+ page documents, questions needing context from multiple files, or queries where the answer simply doesn't exist in the corpus.

• How do you make a document searchable by meaning rather than keywords? A user asking about a "termination clause" shouldn't need to know the exact phrasing in the contract.
• When a user asks a question, how do you efficiently locate the right passage from potentially thousands of pages?
• How do you ensure the answer is grounded in the documents — not fabricated by the model?
• What happens when a question requires combining information from multiple different documents?
• A 500-page document can't be fed to a model all at once — how do you handle that?
• How do you keep the system modular so the underlying LLM or storage layer can be swapped out independently?

An investigative journalist is deep into a corporate fraud story. She has hundreds of news articles, press releases, SEC filings, and leaked emails. The story isn't just about what happened — it's about who is connected to whom, and how. Which executives sit on which boards? Which companies share investors? Who signed which contracts with whom?

Mapping this manually would take weeks. She needs a system that automatically extracts the key players and surfaces how they connect — a living map of relationships she can explore and query.

Build a system that takes a collection of text documents — news articles, Wikipedia pages, research papers, any corpus of your choice — and automatically identifies the important entities: people, organisations, locations, dates, concepts. Then map how these entities relate to each other and make that network navigable.

A basic output: "Person X is a director of Company Y." A strong output: "Person X signed a contract with Company Y in 2021, later flagged by Regulator Z in a 2023 investigation." The richer your relationship extraction, the better.

The network must be visualisable — a graph in the browser, an export for Gephi, or a queryable interface. A user should be able to start at one entity and trace connections outward.

• How do you decide which entities in a document are actually worth tracking?
• "Tesla", "Tesla Inc.", "the EV maker", "Elon's car company" — all the same across different articles. How do you resolve these into one node?
• How do you determine that a relationship exists between two entities — and what type it is?
• How do you store and query a network of thousands of entities and tens of thousands of relationships efficiently?
• What makes a graph genuinely useful to a non-technical user — what does a good interface actually need?
• What happens when two documents contradict each other — does your system surface that?

A strategy consultant gets a client question at 9am: "What are the top 5 players in the Indian EdTech space, what funding rounds have they raised in the past two years, and what's each company's current product focus?" Answering this properly means hitting multiple sources, cross-referencing data, filtering noise, and synthesising a clean brief. They need it in 10 minutes, not 3 hours.

They don't want to prompt an AI step by step. They want to type one question and get a structured, sourced answer back — no babysitting required.

Build a system that takes a complex, open-ended question and autonomously figures out how to answer it. It should decompose the question into sub-tasks, decide what information it needs and where to find it, execute those steps in sequence, handle partial failures gracefully, and return a clean structured final answer — all without the user guiding each step.

Information sources are your call: local files, a free web search API, a pre-loaded knowledge base, or a combination. The requirement is autonomy — one input in, complete answer out.

Bonus: surface the reasoning trace. Show the user what steps the system decided to take and how it arrived at its answer. This is a prompt engineering challenge as much as a code one — think carefully about how you instruct the model to expose its own reasoning.

• How does the system break a vague question into concrete, answerable sub-tasks?
• How does it decide what to do next based on what it's already found — can it adapt mid-task?
• What happens when a step returns garbage data — does everything crash, or does it try a different path?
• How do you prevent it from looping, repeating searches, or hallucinating that it found something it didn't?
• How do you combine partial answers from multiple steps into one coherent final response?
• How do you prompt the model to make its reasoning legible — and what does a good reasoning trace look like to a user?

A product manager at a fast-growing D2C brand needs competitive intelligence — daily. Which competitors launched new products? Did pricing change? What are customers saying in reviews? Are competitors hiring in new cities, signalling expansion? This data is scattered across dozens of websites, updated constantly, and manually checking them every morning isn't an option.

The PM needs a system that automatically collects, cleans, stores, and surfaces this information on a schedule — and doesn't break the moment a website redesigns its layout.

Build a data collection pipeline that monitors a set of websites or online sources of your choosing, extracts structured information on a schedule, stores it in a clean and queryable format, and exposes it through a simple interface — a dashboard, CLI query tool, or both.

Pick any domain that interests you: e-commerce prices, tech job postings, movie reviews, research paper titles, startup funding announcements — anything real and publicly accessible.

The system must be resilient: if one source fails or changes its HTML structure, the rest of the pipeline keeps running. Data across runs must be deduplicated cleanly. The pipeline should run on a schedule automatically — no manual triggers.

• Some websites render content with JavaScript — a basic HTML request returns nothing. How do you handle those?
• The same product appears on three sites with slightly different names and prices. How do you track it as one record?
• If one scraper fails mid-run, how do you ensure the rest complete and the failure is clearly logged?
• How do you schedule and automate the pipeline so it runs without anyone pressing a button?
• How should data be structured so it's easy to query — even by someone who can't write SQL?
• If data volume grows 10x over several months, does your storage approach still hold up?