What the model can do with your notes and what it still needs

The meeting notes are a mess. You hand them to an assistant, and it turns them into a short, readable update. Then you ask whether the rollout has finished. “Yes,” it says, even though the notes said the rollout was paused.

Those were two different jobs. One transformed text you supplied; the other needed information nobody had supplied. Seeing that difference helps explain both why AI can be useful and why an answer that sounds perfectly natural can be wrong.

The notes and answers here are constructed teaching examples, not product-test results. You can examine them without programming or paying for an account.

The work can be useful without a chat window

An email filter gives us another way in. A handwritten rule might flag a phrase, but that phrase could appear in both spam and ordinary mail. A model trained on examples can use relationships among many signals to suggest a category. A demand forecast uses learned patterns to estimate a quantity instead. Neither needs a chat window.

Training a model from examples rather than writing every decision rule by hand is machine learning. It is one approach within artificial intelligence, the broader field concerned with tasks such as recognition, prediction and content generation. “Learning” here means training; it does not mean every use permanently teaches the model a fact.

A generative model produces content. A language model can reshape meeting notes, translate a paragraph or draft code from a description. What counts as useful depends on the assignment and the material it receives.

For each job, name the input, the result and the decision it serves. The summary helps a colleague reconstruct a meeting; the forecast helps a planner prepare capacity. Those purposes give us a firmer test than whether the output feels impressively “AI.”

Training happens before this request

Picture a simplified training example: the text is “The meeting begins at noon,” but the model sees only “The meeting begins at.” The target is the continuation in that example, not whichever ending sounds reasonable to us. The training process compares the model’s prediction with that target and adjusts numerical settings to improve its predictions. This is an illustration of the mechanism, not a result from a model we trained. Repeated across examples, training teaches relationships among words, ideas and kinds of answers; later training can improve instruction-following and other behaviors.

Those adjustable settings are weights. They help determine what the model computes when it next sees text. They are not a folder containing the meeting note for the app to reopen. The weights and training guide follows that process further.

Now paste your own meeting notes and ask for an update. The trained model computes an answer using its existing weights; that use is called inference. Your notes supply material for this request. Pasting them does not, by itself, repeat the training process and change the weights. Whether the service stores those notes or uses them later is a separate question governed by product, account and settings policies.

A shorter note needs the same facts

Return to the meeting notes: “The rollout is paused. Two checks failed. We will investigate before restarting.” A faithful shorter version is “The rollout is paused while the team investigates two failed checks.” Asking for a different tone or language changes the transformation, not the underlying event.

“The rollout restarted successfully” sounds plausible too. But it adds an event the notes never established. An unsupported generated claim is often called a hallucination. Here the difference is visible without the label: one sentence shortens the source; the other supplies a new ending.

Language models commonly work with tokens: words, parts of words, punctuation or other text units. During generation, the model calculates possible next tokens from the available context, a selection procedure chooses one and the sequence grows. This repeated step sits inside a rich learned system sensitive to instructions, concepts and relationships across text. It can produce the successful-restart sentence even though the notes never say a restart happened.

So check both the transformation and its factual support. A fluent translation can change a deadline. A smooth code explanation can omit a decisive branch. Readability helps someone use an answer, but it cannot establish that the facts survived.

The app supplies the material and the means to act

The app supplies the instructions, messages and other material the model receives as context. Yesterday’s conversation helps today only if the app includes it or offers a way to retrieve it. The model cannot reach through the interface and search everything you once opened.

Retrieval can search a collection and supply relevant passages. Choose an old maintenance note, though, and the model might faithfully explain an obsolete procedure. Tools add another step: the model requests a calculation, lookup or operation; surrounding software performs it and returns the result. An agent application can repeat that exchange, choosing its next step from what comes back.

That is how a coding request can become an edit and test run when tools and permission are available. It also separates possible failures. A missing maintenance note points toward retrieval. A claim beyond the note points toward the answer. A correct instruction applied to the wrong service points toward execution. Swapping models cannot fix all three.

“Summarize these notes” provides both source and transformation. “Has the service recovered?” needs current observations. Making yesterday’s report more convincing cannot supply today’s result.

What can the Orchard note actually tell us?

For a separate reading exercise, consider Orchard, a fictional service. Its web process answers requests; a different worker sends queued receipts. The handover below is the assistant’s entire source, not access to the running service:

Orchard service note

The /health endpoint confirms that the web process responds.
It does not test the background worker.
The worker sends queued receipts to the configured mail service.
A worker restart does not clear the receipt queue.
No current queue depth or delivery result is included in this note.

An endpoint is an address another program can request. Here /health checks the web process. Queue depth is the number of waiting items. Ask three questions: what does the endpoint test, does restarting the worker empty the queue, and how many receipts are waiting now?

No model is needed to build the answer key. The note supports “the web process” and “no.” It gives no current count. Underline the supporting sentences, and mark the missing information rather than guessing a number.

If you have an approved chat application, paste the fictional note and ask those questions. Give it no operational access:

Use only the Orchard service note below.
Answer each question and identify the supporting sentence.
If the note does not establish an answer, say what is missing.

Questions:
1. What does /health test?
2. Does a worker restart empty the receipt queue?
3. How many receipts are queued right now?

[Paste the Orchard service note here.]

Now combine the facts: “The health endpoint responds after a worker restart. Have the queued receipts been delivered?” The note still cannot settle delivery. A useful answer identifies the current worker or mail-service result needed. Unsupported does not automatically mean false; it means unverified.

This is the same gap as a paused rollout becoming a successful restart. A current event needs more than a plausible continuation of an older note. Even three correct answers would demonstrate one small successful case, not general reliability. This exercise makes the support, the gaps and the checking effort visible.

Give each request the information its job needs

The same assistant can summarize, translate and draft code because learned capabilities operate inside an app that supplies information and tools. Some requests need only the text you provide. Others need retrieval, a current measurement or permission to act.

The shorter meeting update was already useful. Deciding whether the rollout finished is a separate job, with a separate information need. Once that distinction is clear, you can ask for the missing observation instead of another confident version of the same notes. The next lesson follows a model request and its response.

Sources and example scope

Google’s introduction to machine learning supports the distinctions among learning, classification, prediction and generation. Its language-model introduction covers tokens and sequence prediction. The site’s inference guide follows a request into its response. OpenAI’s function-calling guide describes model tool requests and application execution. NIST’s generative AI risk profile discusses unsupported generated claims. The notes, Orchard service and proposed answers are constructed examples. No AI product or production system was tested for this lesson.