Myelin Learning LabDashboardToolsStatus
Six operational briefs · version 2

Read before the decision.

Each brief defines its use case, required inputs, procedure, stop conditions, output, worked example, and primary framework.

Educational decision support: Confirm current law, facts, policy, contract terms, and professional duties for your context.

How to use a field brief

A brief is not a summary of a topic. It is the minimum you have to do before a specific decision, written so that a person who is tired, rushed, and accountable can still do it. That is why every one has the same six parts: when it applies, what you need in hand, the procedure, the conditions that mean stop, the record you must end up with, and one working rule short enough to remember under pressure.

Read the stop conditions first. They are the part people skip and the part that does the work. A procedure tells you how to proceed; a stop condition tells you when proceeding is the mistake. If any stop condition is met, the brief is finished — the answer is escalate, not continue carefully.

The required output is the point, not the paperwork. Each brief ends in a record because a decision you cannot reconstruct is a decision you cannot defend. Six months later, the question will not be whether you were careful; it will be what you actually checked, when, and on what evidence. Only the record answers that.

What these are not. They are educational decision support. They do not tell you what the law requires of you, what your regulator expects, or what your contract says — confirm current law, facts, policy, contract terms, and professional duties for your own context, and involve qualified people where your duties require it.

If you only read one: start with Brief 01 if you publish or send anything a model helped write, and Brief 02 if you are about to paste something into a tool. Those two cover the overwhelming majority of everyday exposure.

Brief 01 · Output verification

Before generated output becomes work product

Use when: A draft contains legal, scientific, financial, historical, policy, or other decision-relevant claims.

Required inputs

  • Exact draft and intended audience
  • Consequence if each claim is wrong
  • Original sources and current status
  • Named qualified reviewer

Minimum procedure

  1. Split the draft into atomic propositions.
  2. Classify fact, inference, opinion, recommendation, or forecast.
  3. Open the original source; locate a pinpoint.
  4. Test authority, method, population, comparator, date, and later history.
  5. Rewrite to the evidence boundary; record limitations.
  6. Assign retain, narrow, qualify, remove, or escalate.

Stop conditions

  • Source cannot be located or opened
  • Citation does not support the proposition
  • Material limitation or later history is unresolved
  • Controlling authority or denominator is unclear

Required output: A claim ledger containing wording, evidence, pinpoint, limitation, currency check, reviewer, date, and disposition.

Worked example

“Research proves AI improves care” becomes separate access, utilization, outcome, equity, and causation claims. Each is tested independently.

Working rule: Narrow the sentence to the evidence; never stretch the evidence to preserve the sentence.

What commonly goes wrong with this brief

Running the ledger over the sentences you already doubt. The claims that cause damage are the ones that read as obviously true — a round number, a familiar statute, a well-known study everyone cites. Split the whole draft, not the parts that feel shaky.

Ready-to-use checklist

Ticks are remembered in this browser only. Nothing is sent anywhere, and clearing your browser data clears them.

Primary framework: NIST AI Risk Management Framework · Last reviewed 16 August 2026

Brief 02 · Pre-prompt privacy

Before information enters an AI system

Use when: A proposed prompt, upload, connector, or workflow may expose information about people or confidential operations.

Required inputs

  • Purpose and affected people
  • Data inventory and source
  • Authority, notice, consent, duty, policy, and contract
  • Exact product, plan, settings, retention, reuse, access, and deletion

Minimum procedure

  1. Classify data and applicable duties.
  2. Remove everything not necessary for the purpose.
  3. Prefer synthetic, aggregated, redacted, or local alternatives.
  4. Verify actual plan-specific technical and contractual controls.
  5. Separate privacy, confidentiality, security, privilege, and records duties.
  6. Document proceed, escalate, or stop with owner and reassessment triggers.

Stop conditions

  • Missing authority or prohibited data
  • Unknown or unacceptable training/reuse
  • Unacceptable access, retention, transfer, or deletion
  • Sensitive/high-impact use without qualified approval

Required output: A pre-prompt decision record with purpose, data, authority, controls, owner, decision, and change triggers.

Worked example

A contract summary needs dates but not party identities: use only necessary clauses in an approved workflow and retain secure source records separately.

Working rule: Deleting later does not establish that the original disclosure was authorized.

What commonly goes wrong with this brief

Treating the gate as a form to complete after the decision is made. If you are filling it in to justify a prompt you have already sent, it is documentation, not a control. The gate only works upstream of disclosure, because disclosure is the step that cannot be undone.

Ready-to-use checklist

Ticks are remembered in this browser only. Nothing is sent anywhere, and clearing your browser data clears them.

Primary framework: NIST Privacy Framework · Last reviewed 16 August 2026

Brief 03 · Vendor procurement

Before an AI vendor becomes infrastructure

Use when: A team is evaluating, renewing, integrating, or materially expanding an AI product.

Required inputs

  • Defined use and prohibited uses
  • Data-flow and architecture documentation
  • Evaluation evidence and known limitations
  • Terms, security materials, subprocessors, service levels, exit plan

Minimum procedure

  1. Define outcome, affected people, and failure consequences.
  2. Map inputs, outputs, integrations, storage, access, and subprocessors.
  3. Test on representative workflows and edge cases.
  4. Evaluate privacy, security, accessibility, bias, reliability, and human controls.
  5. Negotiate ownership, confidentiality, audit, notice, liability, termination, and portability.
  6. Assign owner, monitoring metrics, incidents, change notice, and reassessment.

Stop conditions

  • Vendor will not answer material data questions
  • Evidence does not match the product/version/use
  • No safe exit, rollback, or incident path
  • Risk exceeds controls or organizational capacity

Required output: A decision packet: requirements, evidence matrix, unresolved risks, negotiated controls, accountable owner, and go/conditional/no-go decision.

Worked example

A polished demonstration is tested against real error modes, representative users, administrative configuration, and contract language before approval.

Working rule: A demonstration is not evidence of reliable operation in your workflow.

What commonly goes wrong with this brief

Evaluating the demo instead of the contract. Demonstrations are built to succeed; the terms are what governs you in eighteen months. If you only have an hour, spend it on data handling, exit and liability rather than on watching the product work.

Ready-to-use checklist

Ticks are remembered in this browser only. Nothing is sent anywhere, and clearing your browser data clears them.

Primary framework: FTC — Operation AI Comply enforcement sweep · Last reviewed 16 August 2026

Brief 04 · Human oversight

Before “human in the loop” counts as a control

Use when: AI influences triage, ranking, recommendations, approvals, access, safety, rights, or opportunities.

Required inputs

  • Decision map and affected people
  • Consequence, reversibility, and error detectability
  • Reviewer qualifications, workload, evidence, and authority
  • Notice, contest, remedy, monitoring, and pause conditions

Minimum procedure

  1. Map the real decision and downstream action.
  2. Name operator, reviewer, approver, escalation owner, and incident lead.
  3. Define evidence and thresholds for release or rejection.
  4. Give reviewers time and authority to disagree.
  5. Design notice, correction, independent challenge, and remedy.
  6. Monitor outcomes, subgroups, overrides, complaints, drift, misuse, and change.

Stop conditions

  • Reviewer cannot inspect evidence or override
  • Workload makes meaningful review impossible
  • Affected people cannot contest consequential errors
  • No monitoring, fallback, pause, or accountable owner

Required output: A control record naming people, evidence, decision rights, contest routes, metrics, thresholds, and incident actions.

Worked example

A benefits-review prioritization model is treated as consequential triage because it can delay access even if it does not issue the final eligibility decision.

Working rule: Review without authority, evidence, or time is ceremony—not oversight.

What commonly goes wrong with this brief

Naming a reviewer without giving them time, evidence, or the authority to say no. Every one of the three is load-bearing. A reviewer who cannot inspect the basis of a recommendation is approving a number, and a reviewer measured on throughput will approve whatever arrives.

Ready-to-use checklist

Ticks are remembered in this browser only. Nothing is sent anywhere, and clearing your browser data clears them.

Primary framework: NIST AI Risk Management Framework · Last reviewed 16 August 2026

Brief 05 · Incident response

When AI use may have caused harm or exposure

Use when: A complaint, near miss, disclosure, unsafe output, discriminatory effect, rights error, outage, or unauthorized use appears.

Required inputs

  • Prompts, outputs, logs, versions, data paths, approvals
  • Affected people, systems, decisions, and timeframe
  • Policies, contracts, notification duties, and owners
  • Prior incidents, monitoring signals, and changes

Minimum procedure

  1. Protect people and contain ongoing impact.
  2. Preserve evidence without quietly overwriting records.
  3. Notify designated legal, privacy, security, clinical, or operational owners as applicable.
  4. Assess scope, severity, affected groups, and notification/remedy duties.
  5. Identify root and contributing causes across the full system.
  6. Implement, assign, test, and monitor corrective actions before restart.

Stop conditions

  • Ongoing harm or exposure is not contained
  • Evidence is being lost
  • Required expertise or authority is absent
  • A proposed restart lacks verified controls

Required output: An incident record with timeline, impact, evidence, containment, notification, cause, repair, owner, deadline, and verification.

Worked example

Confidential text appears in summaries: stop the workflow, preserve evidence, assess scope, contain access, support affected people, fix pathways, and verify before restart.

Working rule: A near miss is governance evidence. Capture it before conditions recur.

What commonly goes wrong with this brief

Fixing it quietly. The instinct to resolve an incident before anyone notices destroys the evidence, skips the notification duty, and guarantees the same failure recurs because nothing was recorded. Contain first, preserve second, and notify the named owner before you tidy.

Ready-to-use checklist

Ticks are remembered in this browser only. Nothing is sent anywhere, and clearing your browser data clears them.

Primary framework: NIST Generative AI Profile (AI 600-1) · Last reviewed 16 August 2026

Brief 06 · Mental-health practice

Before AI touches a therapeutic context

Use when: AI supports administration, documentation, wellness conversation, clinical decisions, crisis response, diagnosis, or treatment.

Required inputs

  • Intended function, user, setting, and clinical responsibility
  • Study population, comparator, endpoints, attrition, exclusions, follow-up
  • Privacy, consent, secondary use, and vendor controls
  • Bias, crisis limits, escalation, monitoring, and evidence

Minimum procedure

  1. Separate administrative, supportive, diagnostic, treatment, and crisis functions.
  2. Match evidence to the exact product, population, outcome, and setting.
  3. Distinguish engagement, satisfaction, access, symptom change, safety, and clinical benefit.
  4. Evaluate exclusions, subgroup performance, attrition, and adverse events.
  5. Define clinician responsibility, disclosure, consent, crisis escalation, and fallback.
  6. Monitor outcomes, complaints, unsafe responses, unequal effects, and system changes.

Stop conditions

  • Marketing exceeds product-specific evidence
  • Crisis or complex users are excluded without a safe route
  • Privacy, consent, or clinical responsibility is unresolved
  • No qualified escalation, adverse-event, or monitoring process

Required output: A bounded use statement, evidence table, risk/control register, responsible clinician/owner, prohibited uses, and monitoring plan.

Worked example

An empathic chatbot is not described as therapeutic because conversational quality alone does not establish efficacy, safety, confidentiality, or clinical judgment.

Working rule: Sounding empathic is not evidence of safe or effective therapy.

What commonly goes wrong with this brief

Reading an evidence base for a category rather than for the product in front of you. Studies of one conversational agent, in one population, against one comparator, do not transfer to a different tool because both are described as AI mental-health support.

Ready-to-use checklist

Ticks are remembered in this browser only. Nothing is sent anywhere, and clearing your browser data clears them.

Primary framework: WHO — Ethics and governance of AI for health · Last reviewed 16 August 2026