Schedules, Reports & Data

The single most useful documentation skill an LLM offers is turning a jumble into a table. Paste a page of messy site notes and ask for a door schedule with columns for location, door type, size, fire rating and hardware set, and you get a clean grid in seconds. Paste a supplier's meandering email and ask for a comparison table of the three quoted options against price, lead time and warranty. Read a wall of survey observations and ask for them grouped by room. This is the workhorse pattern of Module 6 and you will use it constantly.

It works because the raw material of a schedule is already latent in your notes - the model is not inventing content, it is re-arranging what you gave it into the format you asked for. That is a far safer operation than writing a spec from memory. Your job shifts from typing the table to checking that the re-arrangement is faithful.

Be explicit about the structure you want. Name the columns, the grouping, the sort order and the units. A vague make a schedule from these notes leaves the model to choose a shape; a precise request gets a shape you can drop straight into your documents.

Weak:  "Make a schedule from these notes."
Better: "From the notes below, build a door schedule as a table with
         columns: Door Ref, Room, Leaf Size, Fire Rating, Hardware Set,
         Notes. One row per door, sorted by Door Ref. If a value is
         missing in my notes, write MISSING - do not guess it."

That last instruction - write MISSING, do not guess - is the schedule equivalent of the spec's [VERIFY] tag, and it is just as important. It converts the model's instinct to fill every cell with something plausible into an honest map of the gaps you still need to close, which is exactly what a working schedule needs at this stage.

The same move works on the way in, not just the way out. If your notes are photos, a voice memo, or a scanned survey sheet, most current assistants can read them directly - so you can hand over the raw material rather than transcribing it first. That widens the win considerably: the messier and more varied your inputs, the more the model's ability to unify them into one clean structure is worth.

Minutes are a classic time-sink and a classic LLM win. Feed it your rough notes or a meeting transcript and ask for structured minutes: attendees and apologies, decisions made, action items with an owner and a due date, open risks or questions, and the next meeting. The action-items line is the whole point of minutes, and the model is good at pulling them out of a discussion where they were scattered across an hour of talk.

Reports work the same way. A site visit report, a stage report to a client, a design review summary - all follow a predictable structure the model can populate from your observations. Give it the sections you want and the audience, and it drafts a coherent report you then correct and sign. A useful trick is to ask for two versions from the same notes: a detailed internal record for the file, and a short, plain-language summary for a busy client who will not read three pages. The model produces both from one input in seconds, and you tailor each - the same underlying facts, pitched for two different readers.

Two cautions specific to minutes and reports. First, the model can subtly misattribute - recording that the wrong person committed to an action, or stating a decision as firmer than it was. Because minutes become the agreed record, these errors matter; read the actions and decisions against your own memory of the meeting. Second, an AI transcript-to-minutes step means the meeting audio passed through a tool - check that is allowed for the client and the content before you record sensitive discussions.

"Turn these meeting notes into minutes with sections: Attendees,
 Decisions, Actions (owner + due date), Open Questions, Next Meeting.
 Keep it under one page. Flag anything ambiguous as [CONFIRM]
 rather than guessing who agreed to what."

Beyond prose, LLMs can wrangle small datasets. Paste a block of numbers or a rough table and ask for it as clean CSV or JSON, deduplicated, with consistent units and a total row. Ask it to reconcile two lists (last month's finishes schedule against this month's) and report what changed. Ask it to summarise a spreadsheet of survey responses into three themes. For light, one-off data tidying this is genuinely useful and saves fiddly manual work.

But here the model's limits bite hardest. A plain LLM does arithmetic by predicting what the answer looks like, not by calculating - so it can produce totals that are subtly wrong, quietly drop a row, or transpose two figures with total confidence. Never trust an LLM's arithmetic on anything that matters. If numbers must be right, have it produce the structured data and do the maths in a spreadsheet, or use a tool with a genuine code / calculation mode (many assistants can now run real code to compute, which is far more trustworthy than free-text arithmetic - but check it ran, do not assume).

The safe division of labour with data: let the LLM do the structuring (reshape, relabel, group, reformat, summarise the shape) and keep the computing and the source-of-truth values under your control. Reshaping a table is low-risk; asserting a quantity or a sum is high-risk. Match your scrutiny to which one is happening.

The pattern across everything in this lesson: the structure the model produces is usually right; the facts inside it need checking. A door schedule with a perfect layout can still list a fire rating you never specified. Minutes with flawless formatting can attribute a decision to the wrong person. A tidy CSV can carry a total that is off by a row. The clean shape is seductive - it looks authoritative and complete, which makes it easy to skip the read-through. Do not.

Build a habit: for schedules, spot-check rows back to your source notes and look hard for MISSING flags you asked for; for minutes, read the decisions and actions against your memory and confirm owners and dates; for data, re-total anything that matters in a real calculator. This is fast - far faster than building the document from scratch - but it is not optional, because these documents get used. A schedule drives orders; minutes become the record; a report shapes a client decision.

The good news is that this verification is genuinely light compared with specs or compliance. You are checking a faithful re-arrangement of your own material, not hunting invented standards. That is why schedules, reports and data are one of the most reliable everyday AI wins in practice: high time-saving, contained risk, and a verification step you can do in minutes. Structure fast, check the facts, own the document.

The first time you turn notes into a schedule it feels like a neat trick; the real payoff comes when you make it a routine your whole practice can rely on. The move is to standardise the shape you ask for. If every door schedule you generate uses the same columns in the same order and the same units, the outputs drop straight into your templates, read consistently across projects, and are far quicker to verify because you know exactly where to look. Inconsistent, ad-hoc requests produce inconsistent tables you then have to reformat by hand - which erases the time you saved.

So save your good prompts. A short, reusable instruction - build a door schedule with these exact columns, one row per door, sorted by reference, write MISSING for gaps - becomes a small asset you reuse and refine. The same goes for minutes, site reports and product comparisons: a stored prompt per document type gives you a consistent, verifiable output every time and encodes the safety habits (flag uncertainty, do not guess) so you never have to remember them in the moment.

This is also the on-ramp to genuine automation. Once your prompts and formats are stable, you are a short step from the prompt libraries, custom assistants and light API workflows of Module 8 - where the same notes-to-schedule transformation can run with one click, or where a shared team assistant produces house-standard minutes for everyone. You do not need any of that yet. But building the disciplined, repeatable habit now - structure a known way, verify a known way - is exactly what makes scaling it up later both easy and safe.