Why this exists

LMS reports become hard to trust when the same metric name means different things to different people.

What you should leave with
  • A report request that names the decision before anyone builds a dashboard.
  • A shared definition for the metric, source field, cadence, owner, and caveat.
  • A way to stop one LMS metric from meaning different things in different conversations.
Use this when
  • A leader asks for a report before naming the decision it should support.
  • Completion, attendance, assignment, enrollment, status, or overdue metrics are being interpreted differently.
  • The team needs one shared report definition before building a dashboard.
Systems thinking move

Treat a report request as a decision-design problem. The first job is to define what decision the report supports and what the data can honestly say.

How to use this in the next meeting

Before building the report, fill one card with the decision, metric definition, source field, owner, cadence, and caveat.

Working tool

Use the rows as a thinking aid, not a compliance form.

Signal What to do What it tells you about the system
Decision Name the decision this report should support. The report has a purpose beyond visibility.
Audience Name who will use the report and what action they can take. Different audiences need different cuts, not one dashboard for everyone.
Metric definition Define exactly what the metric includes and excludes. The team stops arguing over the same label.
Source field Name the LMS field, report export, or system table behind the metric. The definition can be checked and maintained.
Cadence and owner Name how often it updates and who owns the definition. Reporting becomes a maintained system instead of a one-time request.
Caveat Write what the report does not prove. Leaders can use the data without overclaiming impact.
Three ways to act

Start with the lightest version that still changes the work.

Manual way

Use one report-definition card in the request conversation. Do not build the report until the decision, metric definition, source field, and caveat are clear.

Microsoft 365 or Google Workspace way

Use Microsoft Lists, SharePoint, Excel, Sheets, Power BI notes, Looker Studio documentation, or a data dictionary to store report definitions next to the reports people use.

AI-assisted way

Use AI to draft report definitions from approved request notes, identify ambiguous metric language, suggest caveats, and create questions for the LMS owner. A person validates every source field and data claim.

Unconventional moves
  • A report request is not ready until the decision is named.
  • Put the caveat on the report, not in a separate explanation nobody reads.
  • Define completion, attendance, assignment, enrollment, overdue, and active learner before building another dashboard.
  • Make report definitions versioned decisions so old logic does not quietly survive a migration.
  • Do not use one report for all audiences when each audience can take a different action.
Copy-ready field tool

Paste this into the tool next to the work.

Report definition

# LMS Report Definition Card

Use before building or changing an LMS report.

Report name:

Decision this supports:

Audience:

Action this audience can take:

| Field | Definition |
| --- | --- |
| Metric name |  |
| What it includes |  |
| What it excludes |  |
| Source field or export |  |
| Update cadence |  |
| Owner |  |
| Caveat |  |

Rule:
A report definition is part of the report. If the definition is missing, the report is not decision-ready.
Prompt starters

Use AI to inspect the work, not replace the owner.

These prompts are strongest when you give the model approved source material and ask it to separate known facts, assumptions, missing information, risks, decisions needed, and next actions.

Open the model-aware prompt vault

ChatGPT GPT-5 family

Use an outcome-first prompt with the job, approved source material, constraints, and the exact artifact you want back.

I am working on Turn an LMS report request into a decision-ready definition for an L&D system problem.

Goal: Help me turn the notes below into a practical next move.

Context: Use this when an LMS report request is vague and the team needs to define the decision, metric, source, and caveat before building.

Use these working fields: decision, audience, metric definition, source field, cadence, owner, caveat.

Rules:
- Use only the source notes I provide.
- Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
- Separate known facts, assumptions, missing information, and next actions.
- Flag anything that needs requester, reviewer, leader, legal, compliance, LMS owner, or manager confirmation.
- Keep the output practical enough to review in a working meeting.

Source notes:
[paste approved notes here]

Return:
1. Report definition card
2. Known facts
3. Assumptions
4. Missing information
5. Ambiguous metric language
6. Caveats
7. Questions for the LMS owner

Claude 4 family

Use XML-style sections so context, source material, task, constraints, and output format stay separate.

<context>
I am working on Turn an LMS report request into a decision-ready definition for an L&D system problem.
Use this when an LMS report request is vague and the team needs to define the decision, metric, source, and caveat before building.
</context>

<source_notes>
[paste approved notes here]
</source_notes>

<task>
Turn the source notes into a practical next move using these working fields: decision, audience, metric definition, source field, cadence, owner, caveat.
</task>

<constraints>
Use only the source notes provided.
Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
Separate known facts, assumptions, missing information, risks, and next actions.
Flag anything that changes scope, ownership, evidence, risk, or decision rights.
</constraints>

<output_format>
1. Report definition card
2. Known facts
3. Assumptions
4. Missing information
5. Ambiguous metric language
6. Caveats
7. Questions for the LMS owner
</output_format>

Gemini 3 family

Use a clear task, labeled input, and one example pattern. For Obsidian context, use approved excerpts, Drive exports, Google Docs, or NotebookLM source sets.

Task: Help me make progress on Turn an LMS report request into a decision-ready definition from the notes provided.

Context: Use this when an LMS report request is vague and the team needs to define the decision, metric, source, and caveat before building.

Working fields:
- decision
- audience
- metric definition
- source field
- cadence
- owner
- caveat

Example pattern:
Field: Missing information
Good answer: Name the specific information to confirm, who can confirm it, and why it affects the next decision.

Rules:
- Use only the source notes provided.
- If information is missing, write "Needs confirmation".
- Keep the output concise and reviewable.
- End with the next best action.

Source notes:
[paste approved notes here]

Output format:
1. Report definition card
2. Known facts
3. Assumptions
4. Missing information
5. Ambiguous metric language
6. Caveats
7. Questions for the LMS owner

Microsoft 365 Copilot

Use goal, context, source, expectations, and output. For Obsidian context, use approved excerpts, Word summaries, OneDrive files, SharePoint pages, Teams context, or Outlook threads.

Goal: Help me make progress on Turn an LMS report request into a decision-ready definition.

Context: Use this when an LMS report request is vague and the team needs to define the decision, metric, source, and caveat before building.

Source: Use the selected document, meeting notes, spreadsheet, email thread, SharePoint file, or pasted notes as the only source.

Expectations:
- Work with these fields: decision, audience, metric definition, source field, cadence, owner, caveat.
- Mark uncertain items as "Needs confirmation".
- Do not add facts that are not in the source.
- Separate known facts, assumptions, missing information, risks, and next actions.
- Summarize the top review questions for the team.

Output:
1. Report definition card
2. Known facts
3. Assumptions
4. Missing information
5. Ambiguous metric language
6. Caveats
7. Questions for the LMS owner
Sources behind this tool

The research move is practical, not academic.

Try this one thing today

Take one report request and write the decision, metric definition, source field, and caveat before building anything.