Specifying a measurable generative task

A small team wants a clear record of what its meeting decided. Someone asks a model to “analyze the meeting and give me the results.” The response looks orderly, but combines an unapproved suggestion with a final decision and supplies a date that nobody agreed. The first problem is neither writing quality nor prompt length. It is the absence of a definition of a result. A specialist begins with the artifact the team will use and identifies the evidence needed for every field. Defining the task as extracting explicitly approved decisions provides a rule that can be applied before and after running a model.

A generative task produces text or other material from instructions and inputs. Its output may be new only in wording, as with a summary, or in composition, as with three suggested titles. Permission to generate wording is not permission to generate facts. Meeting-note extraction allows wording changes only within the source meaning. Title ideation may deliberately encourage variety. Ask which parts of an output must preserve source meaning, which allow invention, and which must remain unknown. These distinctions belong in the task specification rather than in an informal expectation that the model will somehow understand them.

Separate the business need from the model function. The business need may be reliable follow-up on commitments. The model function is converting notes into reviewable rows. Successful conversion does not establish better follow-up: the team might never read the register, or decisions might still lack accountable owners. State a bounded promise, such as preparing a verifiable draft register. Measure any improvement in follow-up through a separate operational trial. A user's satisfaction with a polished draft is useful feedback about presentation, but it does not demonstrate that the organizational outcome improved.

Start the task card with the user and the decision the output supports. Here the user is the meeting coordinator, who needs to identify follow-up after the minutes are approved. Next describe the input: synthetic notes containing role names, dates where supplied, and wording that distinguishes proposals, agreement and deferral. If the starting material were audio, transcription would be a separate stage with its own possible errors. A file's existence does not establish that its contents are complete. This exercise begins with supplied text and therefore does not test transcription quality or speaker identification.

Specify the output fields. For each decision, require its meaning, a short supporting passage, the accountable role if assigned, the deadline if stated, and a review flag when approval is ambiguous. Distinguish an accidentally empty field from an explicit indication that a value is absent from the source. Agree how to represent absence before evaluation. Turning “not stated” into an assumed date can make a register look more complete while making it less truthful. Do not infer the responsible role merely from the speaker: a speaker may be reporting another team's decision rather than accepting responsibility.

Define an inclusion rule that a person can apply. Include an item when the text explicitly records approval, exclude open proposals, and include an agreed deferral as a deferral decision. This rule is task-specific rather than a universal meeting rule. Excluding proposals would be wrong if the requested artifact were an ideas register. Use small boundary examples. “We propose starting Tuesday” is not an approved date. “We agreed to start the trial Tuesday” records a decision with a date. “We will defer choosing the date until resources are reviewed” records deferral without a start date. These examples distinguish phrases that can look similar during a quick reading.

Convert each requirement into a check. Completeness asks whether every approved decision was captured. Grounding asks whether the source supports every output row. Field validation asks whether all required fields are present, including explicit unknown values. Authority validation asks whether the output remained a draft rather than sending commitments to people. Row count alone cannot replace these checks. A system can produce the expected number of rows while replacing a real decision with a proposal. Compare each row's meaning with its supporting passage, and record omissions separately from unsupported additions so that later improvements address the actual error.

A small manual table can precede any tool use. Put the source sentence in the first column, its type in the second, extractable information in the third, and remaining unknowns in the fourth. If two readers classify a sentence differently, determine whether the source is ambiguous or the rule is ambiguous. Source ambiguity requires clarification from the coordinator or an unresolved status. Rule ambiguity requires revising the task card. Do not settle disagreement by guessing and then label the guess a reference answer. A reference answer needs evidence if a model's disagreement with it is to mean anything.

Assign responsibility after generation. The coordinator compares the draft with the minutes; the meeting owner approves the register through the team's normal process; follow-up then proceeds. Prompt wording does not grant authority to send messages or change dates. Record the task-card version, trial date and inputs. When the inclusion rule changes, revisit affected examples and expected outputs. Otherwise two prompt versions may appear comparable while performing different tasks. The purpose is a shared definition of success before prompt refinement, not an unnecessarily long document that nobody uses.