This guide gives you a reusable starting pattern. It is designed to help you see the work more clearly; it is not a substitute for judgment, source checking, or responsibility for the result.
Prepare the inputs before you ask for output.
The model only sees what you give it. Spend a few minutes naming the reader, desired result, and uncertain information. This makes a first draft easier to assess and reduces the need for decorative rewriting later.
Make the evidence trail reviewable.
Create a brief that a decision owner can audit without rereading every source first.
Inputs required
- Decision boundary. One choice, its owner, and the consequence of being wrong or delaying.
- Source register. A label, publisher, stable location, date, scope, and limitation for each material source.
- Labeled notes. Short observations or quotations kept beside their source labels—not a merged narrative.
Method sequence
- Map. Group notes by claim without deciding whether the claim is true.
- Challenge. Surface source conflicts, stale evidence, undefined terms, and missing source labels.
- Brief. Write only the decision-relevant findings, limits, and next verification work.
- Verify. Reopen original records for decision-critical claims before sharing the brief.
Public sources used in this guide
- NYC Open Data: 311 Service Requests from 2020 to PresentPublic-source walkthrough: dataset scope, fields, and update caveat.
Public-source walkthrough
A dataset note is evidence about scope—not proof of a trend
This walkthrough uses the published dataset documentation to model an evidence register. It does not reproduce a city analysis or report a result.
- Question
- Does one public service-request category warrant a separately scoped review?
- Recordable source facts
- Agency-directed request scope; daily updates; fields include problem type, agency, and location.
- Not established
- Volume, trend, cause, service quality, or a recommended intervention.
- Human next step
- Define a date range and method, reproduce the query, and review the interpretation with the accountable owner.
The example shows provenance discipline only. It is not a client case, an NYC performance finding, or a claimed analysis result.
Original working artifact
Research brief evidence ledger
Copy this original working record before drafting; it keeps the source trail and decision boundary visible.
# Research brief evidence ledger ## Decision boundary - Decision question: - Decision owner / reviewer: - What changes if we are wrong: ## Source register | Label | Publisher / author | Link or file | Published / accessed | Scope used | Limitation / freshness risk | | --- | --- | --- | --- | --- | --- | | [S1] | | | | | | | [S2] | | | | | | ## Claim record | Claim or observation | Source label | Interpretation (separate from source) | Counterevidence / gap | Next verification | | --- | --- | --- | --- | --- | | | | | | | ## One-page brief 1. Supported findings: 2. Limitations or conflicts: 3. Open question and next verification: 4. Recommendation only if the record supports it:
Give the task a useful brief.
Prepare a one-page research brief from the source register and notes below. Decision question: [one choice, not a broad topic] Audience and decision owner: [who will review and decide] Source register: [source label | publisher | link or file | publication/access date | scope or limitation] Notes by source: [paste only labeled excerpts or observations] Return these blocks in order: (1) decision question and scope, (2) findings with source labels, (3) conflicting or limited evidence, (4) open questions and next verification step, and (5) a recommendation only if the supplied record supports it. For each material statement, keep the source label. Mark unsupported claims “Not supported in supplied record” and dated material “Needs freshness check.” Do not invent facts, citations, users, results, or certainty.
Replace every bracketed field with your real context. Read the output before reuse.
Four steps that keep the result usable.
- 1
Write one decision question that can be answered, deferred, or narrowed.
- 2
Build a source register before drafting prose; include the link, date, and a scope note for every decision-relevant source.
- 3
Keep observations, interpretations, and recommendations in separate lines so AI cannot silently promote one into another.
- 4
Ask for contradictions and freshness risks before asking for a conclusion.
- 5
Open the original source for every claim that could change the decision.
Start with a decision, not a topic
“Research our support problem” produces an endless collection exercise. “Should we investigate one support category before changing the help flow?” gives the brief a stopping rule. The decision question should identify the choice, the person or group who owns it, and the consequence of being wrong. If none is known, the brief can still map the evidence, but it should say that it is exploratory rather than decision-ready.
Build a source register before writing prose
A source label alone is not enough when a reader needs to reopen the record. Record the publisher or author, a stable link or file location, the publication or access date, the part you used, and one limitation. That small ledger exposes mismatched time periods, vendor claims presented as neutral evidence, and notes that cannot be found again. It also gives an AI draft something concrete to preserve instead of encouraging it to smooth the sources into anonymous statements.
Keep observations, interpretations, and recommendations apart
An observation reports what a source says. An interpretation explains what that might mean for the question. A recommendation asks someone to choose or act. These are different kinds of sentences, and they deserve different labels. When they share a paragraph, an AI system can make the transition between them look natural even when the source never supported it. A useful brief leaves the hand-off visible.
Public-source walkthrough: read the dataset notes before counting
New York City’s public 311 dataset is a useful example of why metadata belongs in the brief. Its documentation says the data covers requests that can be directed to specific agencies, is updated daily, and contains fields such as problem type, responding agency, and location. A careful brief can record those facts, the access date, and a narrow question such as whether a category deserves further review. It cannot claim that a category is rising, that a service is failing, or why residents are reporting it unless a reproducible analysis and appropriate interpretation support those claims.
Use AI to expose conflicts before it drafts a conclusion
Give the model a constrained task: list claims that disagree, facts that are too old for the decision window, and source labels missing from material statements. This is more valuable than asking it to resolve the contradiction. A conflict may reflect different definitions, different periods, or a genuine uncertainty that the decision owner needs to accept. Preserve both sides and name the exact next check rather than letting fluent prose select a winner.
Make the one-page shape do real work
A compact brief can use five fixed blocks: decision question; supported findings; limitations or counterevidence; open verification work; and a proposed next move. The constraint is intentional. It forces the writer to choose what changes the decision and stops background context from disguising an unsupported recommendation. A source register can sit below the page or be linked as the working record, but decision-critical claims should still retain their short labels in the body.
Know when the brief is not ready to recommend
Do not add a recommendation merely because the document has a recommendation heading. Stop at “not ready to decide” when the source is missing, the data period is mismatched, a key term is undefined, or the owner has not stated the trade-off they are willing to make. That is a useful result: it converts vague uncertainty into a small verification task with a person responsible for reviewing it.
Run a human check.
- Can each material statement be traced to a source label and an openable record?
- Does the source register show date, scope, and limitation rather than just a title?
- Does the brief separate observations, interpretations, and a recommendation?
- Are contradictions and freshness risks shown instead of silently resolved?
- Would a decision owner know the smallest next verification step and who must review it?
Keep your human check visible.
Mark the checks you have personally reviewed. This is a local reading aid—not evidence that a claim, commitment, or decision is correct.
This checklist is stored only in this browser when storage is available. It is not sent to Knexio or used for analytics.
AI is strongest here when it makes missing information, structure, and options easier to see. The moment an output becomes a claim, commitment, or decision, bring a person back into the loop.
What this page specifically establishes
This page is an editorial walkthrough for turning labeled source notes into a decision-facing brief; it is not a reported client result or an independent analysis of the example dataset.