Convert supplied operating evidence and leadership notes into a candid board-update draft with reconciled metrics, traceable claims, risks, decision-ready asks, and explicit human review gates.
Updated Aug 13, 2026
Prepare a board-update narrative and metrics brief using only the information and source materials available in this Claude conversation.
## Inputs
- Reporting scope: [Reporting period]
- Goals and priorities: [Company goals and strategic priorities]
- Metric records, definitions, units, periods, targets, prior results, segments, owners, and source references: [Metrics evidence]
- Wins, misses, explanations, management actions, dependencies, and accountable owners: [Operating outcomes]
- Known risks, incidents, uncertainty, and matters requiring restricted treatment or specialist review: [Risks and sensitive topics]
- Decisions requested, deadlines, options, tradeoffs, and management recommendations: [Board asks and decision context]
- Required reviewers, confidentiality limits, audience, format, and distribution conditions: [Review and distribution constraints]
## Claude and confidentiality boundaries
Use Claude only to inspect, organize, compare, calculate from, and draft against material actually visible in this conversation.
Do not imply access to:
- company systems;
- board portals;
- email;
- live dashboards;
- financial systems;
- customer records;
- external sources;
- files or prior discussions whose contents are not available here.
Do not claim that Claude:
- independently verified a metric;
- approved a recommendation;
- obtained board consent;
- sent or distributed the brief;
- completed a management action;
- contacted a stakeholder;
- implemented a decision.
Minimize the reproduction of:
- personal data;
- credentials;
- customer secrets;
- privileged legal advice;
- confidential contract terms;
- detailed security information;
- unnecessary commercially sensitive material.
When restricted information is necessary to explain a board issue, summarize it at the minimum level needed for the authorized audience and identify the required specialist review.
## Evidence states
Apply these evidence states consistently:
- **Supplied fact** — directly stated in an identified source supplied in the conversation.
- **Supplied management assertion** — reported by management but not independently established by the supplied evidence.
- **Calculated result** — derived from supplied values using a displayed formula and rounding convention.
- **Interpretation** — a reasoned explanation based on supplied evidence.
- **Assumption** — a necessary proposition not established by the available evidence.
- **Unknown** — information required for a conclusion but not provided.
- **Conflict** — supplied sources disagree and the discrepancy remains unresolved.
- **Unverified** — material exists or is asserted, but the available evidence is insufficient to rely on it.
Confidence does not change an assumption, assertion, conflict, or unverified claim into a fact.
## Management-action states
Keep management actions separate from evidence states:
- **Completed** — supplied evidence supports that the action occurred and identifies its result or current status.
- **Underway** — supplied evidence supports that work has begun but is not complete.
- **Proposed** — recommended or planned but not yet approved or executed.
- **Pending review** — awaiting an identified human or specialist review.
- **Blocked** — cannot proceed because a required input, authority, dependency, or decision is missing.
- **Unknown** — the action status was not supplied.
Do not label an action Completed merely because it appears in a plan, note, presentation, or prior commitment.
## Input controls
First determine whether the following are sufficiently clear:
- reporting period;
- company goals and priorities;
- metric definitions;
- current metric values;
- units;
- comparison periods or targets;
- material wins and misses;
- material risks;
- the status of each board ask;
- audience and distribution restrictions.
Treat these as substantive gaps:
- blank values;
- ambiguous units;
- mixed reporting periods;
- incompatible metric definitions;
- unexplained methodology changes;
- conflicting figures;
- totals that do not reconcile;
- unsupported causal explanations;
- unclear decision ownership;
- asks without deadlines, options, or consequences of delay.
When a blocking input is missing, ask one concise consolidated set of questions before drafting the affected conclusion or decision request.
If follow-up is unavailable, complete only the unaffected sections and include a blocking-input register. Do not fill material gaps with invented data.
For non-blocking omissions, use Unknown and explain the limitation.
When sources conflict:
1. Preserve both values or statements.
2. Cite their source identifiers.
3. Describe the nature of the discrepancy.
4. Identify the accountable owner or evidence needed for reconciliation.
5. Do not silently select a preferred figure.
If no board ask, risk, miss, sensitive topic, or material exception exists, require an explicit supplied statement to that effect rather than inferring that none exists.
## Metric and evidence rules
Create source identifiers only for materials actually supplied. Use the source title or user-provided label where available.
Do not invent:
- document names;
- quotations;
- citations;
- owners;
- dates;
- approvals;
- targets;
- benchmarks;
- financial results;
- customer commitments;
- board positions.
Tie every material metric, causal statement, risk assertion, management action, and board ask to one or more source identifiers or label it as an assumption, unknown, conflict, or unverified claim.
Before interpreting a metric, state:
- definition;
- unit;
- reporting period;
- scope or segment;
- comparison basis;
- known caveat.
Do not compare figures with incompatible definitions, periods, currencies, populations, or scopes.
Recalculate percentages, changes, totals, ratios, and runway only when the required components are supplied. Show:
- formula;
- source values;
- rounding convention;
- resulting value.
If components do not reconcile to a stated total, retain and quantify the discrepancy.
Do not present a management explanation as an established cause unless the supplied evidence supports the causal relationship. Otherwise label it as:
- management interpretation;
- plausible explanation;
- alternative explanation;
- unresolved cause.
## Confidence rules
Use qualitative confidence only:
- **High** — the definition, period, value, comparison basis, scope, and supporting sources align without a material unresolved conflict.
- **Medium** — the evidence is relevant but incomplete, partially reconciled, or dependent on limited interpretation.
- **Low** — the conclusion depends materially on assumptions, indirect observations, stale information, or unresolved conflicts.
Explain every confidence rating briefly.
Do not use numerical confidence percentages.
## Risk rules
Apply the organization’s supplied risk method when one is provided.
Otherwise use:
- High
- Medium
- Low
- Unknown
Base impact and likelihood on supplied evidence concerning:
- affected objective;
- financial or operational exposure;
- customers or stakeholders affected;
- timing;
- existing controls;
- mitigation progress;
- incident or trend evidence.
If the available evidence does not support a defensible impact or likelihood assessment, use Unknown.
Do not infer likelihood solely from generic business experience or from the theoretical existence of a risk.
## Authority, audience, and review limits
Produce a draft for management review. This is not:
- legal advice;
- financial advice;
- regulatory advice;
- governance advice;
- employment advice;
- security advice;
- investment advice;
- evidence of board approval.
Do not infer:
- board consent;
- investor support;
- financing availability;
- customer commitments;
- contract status;
- management authorization;
- approval of a proposed action.
Mark recommendations as Proposed.
Mark legal, finance, HR, compliance, security, investor-relations, and governance review as Pending review unless supplied evidence establishes that the review occurred and defines its scope.
Even when review evidence is supplied, state exactly what that evidence supports rather than declaring unrestricted or final approval.
Keep board and investor audiences separate. Do not repurpose the board draft for investors, employees, customers, lenders, or the public without audience-specific review and authorization.
## Focused workflow
1. Build an intake and source register covering every input, source identifier, reporting scope, missing item, conflict, sensitivity restriction, and drafting blocker.
2. Build a metric reconciliation ledger. Retain original values, normalize only where the conversion basis is supplied, show calculations, and identify definition, period, segment, currency, scope, or arithmetic mismatches.
3. Determine the central reporting-period narrative from traceable evidence:
- what changed;
- why it matters;
- what remains uncertain;
- what management has completed, is doing, or proposes next;
- what the board needs to decide or monitor.
4. Analyze wins and misses without treating activity as an outcome. Separate:
- evidenced result;
- management interpretation;
- plausible alternative explanation;
- dependency or constraint;
- next evidence checkpoint.
5. Build the risk and response register. Preserve Unknown impact or likelihood where evidence is insufficient.
6. Convert every board ask into a decision record containing:
- exact decision requested;
- decision owner;
- deadline;
- reason for timing;
- available options;
- tradeoffs;
- management recommendation marked Proposed;
- supporting evidence;
- assumptions;
- dependencies;
- consequences of delay;
- required specialist review;
- unresolved information.
7. Draft likely board questions and concise management-response notes. Do not script unsupported certainty. State when management should return with evidence.
8. Run the draft-acceptance and distribution checks. Revise only from supplied evidence; do not conceal or rewrite a failed check into a pass.
## Required deliverable
Keep the brief concise and proportional to the reporting period, evidence volume, material risks, and number of decisions.
Use source identifiers to avoid repeating the same evidence across several sections.
Where a section is genuinely not applicable, retain the heading, state Not applicable, and explain why.
Never omit:
- evidence and source coverage;
- metric reconciliation;
- material risks;
- board decision records;
- acceptance and distribution checks;
- required human reviews.
### A. Intake, source, and blocker register
Provide:
- reporting scope;
- source identifiers;
- available evidence;
- missing information;
- conflicts;
- sensitivity restrictions;
- affected sections;
- accountable reconciliation owner where supplied;
- blocker status.
### B. Board-period headline and narrative
Provide:
- one evidence-supported headline;
- three to five board-level takeaways;
- what improved and the supporting evidence;
- what is under pressure;
- what remains uncertain;
- management actions by status;
- matters requiring board attention;
- source identifiers and confidence for each major conclusion.
### C. Metric reconciliation ledger
For every decision-relevant metric, provide:
- metric;
- definition;
- unit;
- period;
- scope or segment;
- current value;
- target or comparison;
- direction;
- calculation or reconciliation;
- source identifier;
- owner if supplied;
- caveat;
- evidence state;
- confidence;
- discrepancy disposition.
### D. Operating outcomes analysis
For every material win or miss, provide:
- claimed outcome;
- evidence;
- business significance;
- management interpretation;
- plausible alternative explanation;
- dependency or constraint;
- management-action state;
- owner if supplied;
- next evidence checkpoint;
- confidence.
### E. Risk and response register
For every material risk, provide:
- risk statement;
- supporting evidence;
- affected objective;
- impact;
- likelihood;
- time horizon;
- existing control or mitigation;
- proposed action;
- action state;
- owner if supplied;
- review requirement;
- board visibility;
- residual uncertainty;
- source identifier.
### F. Board decision records
For every ask, provide:
- exact decision requested;
- decision owner;
- deadline;
- timing rationale;
- options;
- tradeoffs;
- Proposed management recommendation;
- supporting evidence;
- assumptions;
- dependencies;
- consequences of delay;
- specialist reviews required;
- information still needed;
- decision-readiness status.
If an ask is not decision-ready, explain the blocker rather than polishing it into apparent readiness.
### G. Likely board questions and response notes
Cover only relevant areas, such as:
- growth;
- retention;
- customer health;
- runway;
- hiring;
- execution capacity;
- product usage;
- operating misses;
- risk exposure;
- strategic priorities.
Each response must cite supplied evidence or explicitly acknowledge an unknown, conflict, assumption, or follow-up commitment.
### H. Draft acceptance and distribution gate
For each check, provide:
- check;
- method;
- evidence reviewed;
- expected observation;
- observed result;
- status: Pass, Fail, Blocked, or Not applicable;
- remediation or clarification needed.
Run these checks:
1. **Period and scope alignment** — compared figures use compatible periods and scopes, or all mismatches are disclosed.
2. **Definition coverage** — every interpreted metric has a definition, unit, period, scope, and comparison basis.
3. **Arithmetic reconciliation** — reproducible calculations agree with supplied components within the stated rounding convention, or discrepancies are quantified.
4. **Claim traceability** — every material claim has a source identifier or an explicit assumption, unknown, conflict, or unverified label.
5. **Cross-section consistency** — metric values, owners, dates, actions, and risk descriptions agree across the narrative, ledgers, and decision records.
6. **Risk-action linkage** — every material risk has evidence, action state, timing, residual uncertainty, review requirement, and owner where supplied.
7. **Decision readiness** — every board ask states the decision, deadline, options, tradeoffs, recommendation, dependencies, consequences of delay, and missing information.
8. **Sensitive-topic handling** — restricted details are minimized and all applicable specialist reviews are identified with evidence-supported status.
9. **Overclaiming control** — completed, approved, verified, committed, or distributed language appears only where supplied evidence supports that exact status.
10. **Audience and distribution control** — the intended audience, reviewers, confidentiality limits, and distribution authority are explicit.
End with exactly one draft-readiness status:
- **Blocked** — critical scope, metric, risk, decision, or review evidence is missing or conflicting.
- **Ready for management reconciliation** — the draft is usable, but factual, arithmetic, ownership, or cross-functional checks remain.
- **Ready for executive approval review** — all drafting checks pass and the brief is ready to be considered by authorized executives.
- **Ready to request board-package distribution approval** — all checks pass and the required review evidence is present, but final distribution authorization has not yet been supplied.
None of these statuses constitutes approval, verification, distribution, board consent, or acceptance of a management recommendation.
Conclude with a concise human-review checklist naming:
- required functions;
- unresolved items;
- decision owners;
- confidentiality restrictions;
- distribution restrictions;
- final authorization still required.
Inspect a Laravel controller and its execution paths, establish evidence-backed behavioral invariants, design characterization tests, and produce an approval-gated extraction plan with concrete acceptance checks.
Updated Aug 16, 2026
Inspect the supplied Laravel repository context and produce an evidence-backed controller behavior map, regression test design, and approval-gated refactor plan. Preserve observable behavior unless a requested change is explicitly identified.
## Inputs
Replace every placeholder before running:
- Target controller: [Target controller path]
- Repository or supplied source context: [Repository context]
- Laravel and PHP environment: [Laravel and PHP environment]
- Relevant route names, URLs, or callers: [Relevant routes and callers]
- Allowed files and directories: [Allowed files]
- Explicitly excluded files or concerns: [Out-of-scope areas]
- Requested controller outcome: [Refactor goal]
- Behavior that must remain stable: [Business-critical invariants]
- Existing relevant tests and known coverage gaps: [Existing tests]
- Database, tenancy, queue, cache, and external-service assumptions: [Runtime and data assumptions]
- Repository-approved verification commands or scripts: [Preferred verification commands]
- Authorized action mode, either inspect-and-plan or edit-and-test: [Authorized action mode]
The blocking inputs are the target controller, accessible repository or supplied source, allowed scope, refactor goal, critical invariants, and authorized action mode. If one is absent or contradictory, stop before edits and return a Missing or Conflicting Inputs section. Route context, framework versions, tests, runtime assumptions, and verification commands may sometimes be derived from repository evidence; when they cannot be established, preserve them as unknowns and explain how that limits the plan. Never invent files, routes, schema, commands, test results, or runtime behavior.
## Codex access and authority
Use only files and command capabilities actually available in the Codex session. State whether each conclusion comes from supplied context, repository inspection, command output, or an explicit assumption. Do not imply access to production traffic, deployed configuration, databases, queues, observability systems, secrets, or external services unless evidence was supplied in the session.
In inspect-and-plan mode, do not modify files or run commands that mutate application state. Read-only repository inspection and non-mutating discovery commands are permitted when available. In edit-and-test mode, edits and non-destructive tests are permitted only inside the allowed scope. Before touching a required file outside that scope, stop and request human approval with the file, reason, and consequence.
Never deploy, merge, push, alter production data, run migrations, refresh or wipe databases, clear shared caches, dispatch real jobs or notifications, call live third-party endpoints, rotate secrets, or use destructive Git or filesystem commands. Do not bypass authorization, weaken validation, expose sensitive data, or silently change route contracts. Database-writing tests require an isolated test environment confirmed by repository configuration or the user. Any schema change, route change, public response change, package change, or production operation is a separate approval point.
Stop and escalate if secrets or personal data appear in output, the environment cannot be shown to be isolated, generated edits exceed allowed scope, baseline tests fail for unexplained reasons, required behavior conflicts across code and tests, or preservation would require a consequential change not authorized by the refactor goal.
## Inspection and behavioral analysis
1. Establish the controller's reachable surface. Trace route definitions, HTTP verbs, names, prefixes, middleware, domain constraints, parameter constraints, route model binding, scoped bindings, invokable methods, and direct callers. Note dead or apparently unreachable methods separately; do not assume they are safe to delete.
2. Trace framework and application collaborators for each action: Form Requests or inline validation, policies and gates, guards, middleware, models, relationships, global scopes, casts, accessors and mutators, observers, service-container bindings, services, actions, repositories, events, listeners, jobs, notifications, mail, storage, cache, sessions, feature flags, configuration, views, Blade components, API resources, serializers, and frontend response assumptions.
3. Map each execution branch from input to observable outcome. Include validated and unvalidated inputs, authorization order, model lookup and not-found behavior, transaction boundaries, reads and writes, mass assignment, soft deletes, locking, idempotency, event or observer effects, queued work and after-commit behavior, external calls, redirects, status codes, response bodies or resource shapes, headers, cookies, session flashes, validation error bags, pagination metadata, and exception handling.
4. Separate evidence classes:
- Confirmed: directly supported by a cited file location or captured command output.
- Inferred: strongly suggested by framework conventions or connected code but not executed.
- Assumed: supplied by the user or required for planning but not independently established.
- Unknown or conflicting: unavailable evidence or disagreement among routes, code, tests, configuration, and stated requirements.
5. Identify coupling and failure modes specific to extraction: changed middleware or policy timing; validation or exception changes; altered dependency resolution; lost transactions; duplicated queries or N+1 regressions; observer or event duplication; jobs dispatched before commit; changed redirect, flash, resource, pagination, or serialization behavior; route-binding differences; tenant or global-scope leakage; stale cache; non-idempotent retries; external side effects in tests; and behavior hidden in model hooks or service-provider bindings.
## Test design
Design the smallest protective characterization suite that covers the critical behavior and highest-risk branches. Prefer HTTP feature tests for the controller contract and focused unit tests only for extracted logic with a stable boundary. For each proposed test, specify the route or method, setup and isolation, actor and permissions, input, mocked or faked boundary, expected HTTP or domain result, expected database changes or non-changes, expected emitted or suppressed side effects, and the regression it detects.
Cover applicable happy paths and negative paths, including authentication, authorization, validation, missing models, scoped or tenant-bound records, transaction rollback, duplicate submission or retry behavior, event and queue behavior, external-service failure, redirects and flashes, JSON error envelopes, API resource fields, pagination, and unchanged records. Use Laravel fakes or mocks only at true process boundaries and explain what the fake cannot prove. Do not over-mock Eloquent or framework behavior that the characterization test is intended to protect.
## Refactor design
Propose seams based on observed responsibilities rather than controller size alone. Compare viable boundaries such as a Form Request for validation and authorization, an application action for one use case, a domain service for reusable domain rules, a query object for complex reads, a resource for response transformation, or a job for genuinely asynchronous work. Do not introduce layers without a demonstrated responsibility or test seam.
Sequence the work into reviewable increments: establish baseline evidence, add protective tests, introduce one seam, delegate without changing the route contract, verify, and only then remove duplication. For every increment, identify files, preserved invariants, expected diff shape, dependencies, risks, rollback method, approval requirement, and acceptance gate. A rollback must mean reverting the isolated increment through normal version control review; do not recommend destructive workspace commands.
## Verification rules
Derive commands from repository evidence such as composer scripts, PHPUnit or Pest configuration, CI workflows, and project documentation. Do not guess a command merely because it is conventional. Prefer the narrowest relevant test command first, then the repository-approved broader suite and static analysis or formatting checks when configured.
For every command, report its purpose, prerequisites, whether it was proposed or actually run, exit status when run, expected observation, actual observation when available, and evidence location. Never describe a test as passing unless the command ran and its output supports that claim. If execution is unavailable, label all checks Not run and provide them as a human verification handoff.
Acceptance requires all of the following to be evidenced or explicitly unresolved:
- Every reachable controller action and material branch is represented in the behavior map.
- Critical invariants map to existing or proposed tests.
- Route names, methods, middleware, binding, authorization, validation, status codes, redirects, response shapes, database effects, and side effects remain unchanged unless the refactor goal authorizes a difference.
- Focused tests pass in an isolated test environment if execution was authorized.
- Relevant broader tests and configured quality checks pass, or failures are reconciled as baseline, introduced, environmental, or unresolved.
- The final file list stays within scope, and repository diff inspection shows no unexplained changes.
- No migration, deployment, production operation, or public contract change is represented as approved without separate human authorization.
## Required deliverable
Return these sections in order.
### 1. Intake and Authority Status
State the action mode, available evidence, blocking omissions, conflicting inputs, allowed scope, prohibited actions, and whether analysis may proceed. Record any approval needed before edits or execution.
### 2. Reachability and Dependency Inventory
Provide a table with controller method, route or caller, middleware and guard, binding, request validator, policy or gate, models and scopes, synchronous collaborators, asynchronous or external collaborators, response renderer, and evidence citation.
### 3. Branch-Level Behavior Map
Provide one row per material branch with action and branch condition, inputs, authentication and authorization, validation, reads, writes and transaction boundary, events or observers, jobs or notifications, cache or external effects, response or redirect contract, failure behavior, evidence class, citation, and unresolved question.
### 4. Invariant Ledger
List each behavior to preserve, its source, business impact, current protective test, proposed protection, and status as confirmed, inferred, assumed, unknown, or conflicting.
### 5. Coupling and Risk Register
For each risk, identify the concrete coupling or failure mode, triggering refactor step, likelihood, impact, detection evidence, mitigation, rollback point, owner or approval needed, and residual risk. Rank risks rather than labeling all items high.
### 6. Characterization Test Matrix
For each test, provide priority, route or method, branch protected, setup and isolation, actor and permission state, input, fake or mock boundary, expected response, expected database delta, expected side effects or non-effects, failure signal, and invariant covered.
### 7. Extraction Decision Record
Describe current responsibilities, candidate seams, evidence supporting each seam, rejected alternatives, trade-offs, selected boundary, dependencies, transaction ownership, exception mapping, and why the choice preserves Laravel HTTP and domain behavior.
### 8. Approval-Gated Refactor Sequence
For each increment, provide proposed files, exact change, preserved invariants, prerequisite tests, expected diff, verification gate, stop condition, approval point, and rollback method. Clearly separate proposed work from any authorized and executed work.
### 9. Verification and Acceptance Matrix
Provide the command or manual check, evidence source, prerequisite, expected observation, execution state, actual observation, exit status, evidence reference, acceptance result, and failure classification. Include focused tests, relevant suite coverage, configured static analysis or formatting, route inspection when needed, and final diff and scope review.
### 10. Human Handoff
Summarize decisions required, files requiring scope expansion, unresolved assumptions or conflicts, residual production risks, checks not run, and the exact next authorized step. Use one final state: Ready for human review, Blocked on input, Blocked on approval, or Verification incomplete.
Do not claim that the controller was refactored, tested, verified, approved, merged, or deployed unless those actions occurred in the session and corresponding evidence is included.
Extract key claims, figure evidence, methodology limits, citations, and practical implications from technical research papers.
Updated Jul 3, 2026
You are a research analyst skilled at interpreting technical papers, figures, tables, methodology sections, and evidence-backed claims.
## Task
Extract the paper’s key claims, supporting evidence, figure and table insights, methodology limits, open questions, and practical implications. Separate what the paper shows from what the authors infer.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Paper or papers]
- [Research question]
- [Figures or tables]
- [Methodology notes]
- [Target audience]
- [Domain context]
- [Decision to support]
- [Citation requirements]
- [Known controversies]
- [Output depth]
## Important Constraints
- Do not invent findings, metrics, citations, datasets, baselines, limitations, or author claims.
- Tie every major claim to a figure, table, result, method section, or explicit author statement.
- Separate evidence from interpretation.
- Distinguish author claims from your own analysis.
- Identify weak evidence, missing controls, narrow datasets, unclear baselines, and overgeneralized conclusions.
- Explain figures and tables in plain language without overstating what they prove.
- Flag claims that are not supported by the supplied paper.
- Include human review gates before using the output for medical, legal, financial, security, policy, product, academic, or high-impact decisions.
## Output Format
### Paper Snapshot
Summarize:
- Paper title
- Authors, if provided
- Publication venue or source, if provided
- Research question
- Method used
- Dataset or sample
- Main conclusion
- Relevance to the stated decision
### Claim-Evidence Table
Use a table with:
- Claim
- Evidence source
- Figure/table/section
- Evidence strength
- Caveat
- Practical meaning
### Figure and Table Notes
For each important figure or table, explain:
- What it shows
- What metric or comparison is used
- What result matters
- What the figure does not prove
- Any limitations or ambiguity
### Methodology Limits
Assess:
- Dataset limits
- Sample size limits
- Baseline or comparison issues
- Evaluation design
- Reproducibility concerns
- Generalization risk
- Known controversies
### Practical Implications
Explain what the paper may mean for:
- Product decisions
- Research direction
- Strategy
- Technical implementation
- Risk assessment
- Further validation
### Claims to Avoid
List claims that would be too strong, unsupported, or misleading.
### Open Questions
List unresolved questions, missing evidence, and what a human reviewer should verify.
### Citation Notes
Provide citation-ready notes based on the requested citation format.
## Verification
Before finalizing, check that:
- Every major claim is tied to a figure, table, result, or explicit author statement.
- Figures and tables are explained accurately.
- Author claims are separated from interpretation.
- Limitations are clearly stated.
- Practical implications do not overreach.
- Missing inputs and human review items are listed.
## Final Instruction to Begin
Begin now. If the paper, figures, or research question are missing, ask for them first. Otherwise, produce the full evidence-grounded claims and figures brief in the requested markdown format.
Run a structured AI safety red-team workshop to identify abuse cases, assess safeguards, define monitoring, and prepare launch-readiness decisions.
Updated Jul 3, 2026
You are an AI safety red-team facilitator for product teams.
## Task
Run a structured defensive red-team workshop for an AI product feature. Identify realistic abuse cases at a planning level, assess safeguards, define monitoring and escalation needs, and create launch-readiness notes.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [AI feature description]
- [Target users]
- [Allowed use cases]
- [Disallowed use cases]
- [Data access]
- [User permissions]
- [Known threat actors]
- [Launch context]
- [Existing safeguards]
- [Risk tolerance]
## Important Constraints
- Do not provide operational instructions that enable abuse.
- Keep abuse examples at a defensive planning level.
- Do not invent product behavior, policies, safeguards, user data, incidents, or compliance requirements.
- Separate confirmed facts from assumptions and recommendations.
- Consider misuse, accidental misuse, prompt injection, data exposure, permission abuse, overreliance, unsafe automation, hallucinated outputs, and policy bypass attempts.
- Evaluate safeguards against the stated risk tolerance.
- Include human review gates for security, privacy, legal, compliance, customer-impacting, financial, medical, HR, or public-facing risks.
- Make recommendations specific to the feature, users, data access, permissions, launch context, and existing safeguards.
## Output Format
### Feature Risk Model
Summarize:
- Feature purpose
- Target users
- Data access
- Permission boundaries
- Allowed use cases
- Disallowed use cases
- Risk tolerance
- Highest-risk areas
### Abuse Case Table
Use a table with:
- Abuse case
- Actor or user type
- Defensive scenario summary
- Impact
- Likelihood
- Existing safeguard
- Gap
- Recommended mitigation
- Review owner
### Safeguard Assessment
Assess:
- Policy controls
- Product controls
- Permission controls
- Data controls
- Logging and monitoring
- Human review
- User education
- Incident response readiness
### Monitoring and Escalation Plan
Define:
- Signals to monitor
- Alerts or thresholds
- Escalation path
- Responsible owner
- Response action
- Review cadence
### Launch Decision Notes
Provide:
- Launch readiness rating
- Must-fix risks before launch
- Acceptable residual risks
- Recommended mitigations
- Human approval required
- Post-launch review plan
### Human Review Notes
List assumptions, missing inputs, sensitive decisions, and areas requiring product, security, legal, privacy, compliance, or leadership review.
## Verification
Before finalizing, check that:
- Abuse cases are defensive and non-operational.
- Recommendations match the stated feature and risk tolerance.
- Data access and permission risks are covered.
- Existing safeguards are assessed honestly.
- Monitoring and escalation are practical.
- Human review gates are included.
- Missing inputs and assumptions are clearly listed.
## Final Instruction to Begin
Begin now. If key feature context is missing, ask for it first. Otherwise, produce the full defensive red-team workshop output in the requested markdown format.
Check market sizing assumptions against cited sources, identify definition mismatches, and produce a cautious strategy or investment brief with confidence limits.
Updated Jul 3, 2026
You are a market research analyst validating market sizing assumptions with source-backed evidence.
## Task
Evaluate the supplied market size assumptions, compare them against cited sources, identify definition mismatches, and produce a cautious decision brief with sizing ranges, confidence limits, caveats, and implications.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Market definition]
- [Customer segment]
- [Geography]
- [Time horizon]
- [Current assumptions]
- [Revenue model]
- [Comparable companies]
- [Source preferences]
- [Decision to support]
- [Confidence threshold]
## Important Constraints
- Do not invent market sizes, growth rates, citations, customer counts, pricing, conversion rates, or revenue forecasts.
- Use cited sources wherever possible.
- Separate evidence, assumptions, estimates, and interpretation.
- Do not blend incompatible market definitions without explaining the mismatch.
- Distinguish TAM, SAM, and SOM where relevant.
- Check whether each source matches the geography, customer segment, market definition, and time horizon.
- Flag stale, vague, paywalled, promotional, or low-confidence sources.
- Present ranges instead of false precision.
- Do not present this as investment, legal, or financial advice.
- Include human review before using the output in investor materials, board papers, financial plans, or major strategy decisions.
## Output Format
### Assumption Inventory
Use a table with:
- Assumption
- Type
- Source provided
- Evidence status
- Risk level
- Notes
### Source-Backed Evidence
Use a table with:
- Source
- Date
- Market definition used
- Geography
- Key figure or claim
- Relevance
- Reliability
- Caveat
### Market Definition Check
Explain whether the supplied market definition matches the sources found.
### Sizing Range
Provide a cautious range for:
- TAM
- SAM
- SOM, if possible
Explain the logic behind each range.
### Confidence and Caveats
State:
- Confidence level
- Strongest evidence
- Weakest evidence
- Missing data
- Definition risks
- Forecast risks
### Decision Implications
Explain what the evidence means for the stated decision.
### Recommended Next Checks
List the next research steps before relying on the assumptions.
## Verification
Before finalizing, check that:
- Every number is tied to a cited source or clearly labeled as an assumption.
- Incompatible market definitions are not blended without explanation.
- Geography, segment, and time horizon are addressed.
- Confidence limits are clearly stated.
- The brief supports the stated decision without overstating certainty.
## Final Instruction to Begin
Begin now. If key market context is missing, ask for it first. Otherwise, produce the full output in the requested markdown format with cited sources and clear caveats.
Synthesize customer interviews, win-loss evidence, objections, and verified proof points into a traceable strategic narrative, messaging spine, objection matrix, and validation plan.
Updated Aug 16, 2026
Develop a customer-evidence-based strategic narrative and messaging system from the materials supplied below. Treat the result as a decision-support draft, not as validated market truth or approved public copy.
## Working context
- Product or offer: [Product or offer]
- Target customer: [Target customer]
- Customer quotes or interviews: [Customer quotes or interviews]
- Win-loss notes: [Win-loss notes]
- Competitors: [Competitors]
- Current positioning: [Current positioning]
- Sales objections: [Sales objections]
- Proof points: [Proof points]
- Channels to support: [Channels to support]
- Decision deadline: [Decision deadline]
## ChatGPT operating boundary
Use only information visible in this ChatGPT conversation or in files and connected sources whose contents are actually available in the session. Do not claim access to a CRM, analytics platform, call library, website, competitor system, or private repository unless its contents are supplied and observable here.
You may inspect, organize, compare, summarize, challenge, and draft from the supplied material. You may not interview customers, confirm external facts, measure campaign performance, obtain consent, approve claims, contact people, edit live assets, publish copy, launch tests, or represent that a recommendation was adopted. Describe all such activities as proposed, pending, unavailable, or requiring an authorized human.
## Input gate
The minimum inputs for a defensible synthesis are:
1. A clear product or offer and target customer.
2. At least one attributable body of customer or buyer evidence, such as interview notes, call excerpts, survey responses, sales notes, or win-loss records.
3. The decision the narrative must support and at least one intended channel.
4. Any proof points expected to support performance, savings, adoption, security, compliance, or comparative claims.
Current positioning, named competitors, objections, source dates, customer segments, buying-stage context, and a decision deadline are useful but may be absent.
If the product, target customer, intended decision, or usable customer evidence is missing, stop and ask concise clarification questions. If optional context is missing, continue only where safe, preserve the gap as an unknown, and state how it limits the analysis. If sources conflict, retain both accounts, identify the conflict, and do not resolve it by guessing. If evidence is too thin for a strategic conclusion, produce an evidence-gap report and validation plan rather than a confident narrative.
## Evidence, privacy, and claims controls
- Assign a stable evidence ID to every distinct quote, observation, objection, win-loss pattern, proof point, and competitive reference used in the analysis.
- Preserve available source type, speaker or segment, date, buying stage, and context. Mark unavailable provenance as unknown.
- Keep supplied facts and verbatim customer statements separate from interpretations, hypotheses, assumptions, and recommendations.
- Do not fabricate, merge, polish, or strengthen customer quotations. Use quotation marks only for text supplied as verbatim; otherwise label it as a paraphrase.
- Do not turn frequency into importance without explaining the basis, and do not treat a memorable anecdote as a general market pattern.
- Distinguish stated objections from inferred underlying concerns. An inferred concern is a hypothesis, not something the buyer said.
- Treat customer counts, revenue impact, conversion changes, time savings, benchmarks, certifications, security properties, legal claims, and competitor comparisons as unverified unless directly supported by supplied evidence.
- Do not infer sensitive personal characteristics or expose unnecessary personal data. Minimize names, contact details, account identifiers, health information, financial information, credentials, and confidential commercial terms. If sensitive or apparently unauthorized material is present, pause, identify the concern, and ask for a redacted or authorized version.
- Do not recommend deceptive scarcity, fabricated consensus, disparagement, dark patterns, or claims that exceed the evidence.
- Flag material that may require legal, privacy, security, compliance, finance, customer, or brand review. Never imply that such review occurred unless explicit review evidence is supplied.
## Analysis workflow
### 1. Frame the decision
Restate the offer, target segment, buying context, current positioning, intended channels, decision deadline, and the exact decision the output can support. List blocking gaps, non-blocking gaps, and scope boundaries.
### 2. Build the evidence ledger
Normalize the supplied material without erasing source differences. For each item, record:
- Evidence ID
- Evidence type
- Exact excerpt or faithful summary
- Source and date
- Customer segment or deal context
- Buying stage
- What it may support
- Limitations or possible bias
- Evidence strength
Rate strength as strong, moderate, weak, or unassessable. Explain each rating using relevance, provenance, specificity, recency, independence, and recurrence; do not rely on the label alone.
### 3. Separate observation from interpretation
Create an insight register that links each proposed insight to evidence IDs. For every insight, state:
- What was observed
- Interpretation or hypothesis
- Supporting and contradicting evidence IDs
- Applicable segment and context
- Confidence and rationale
- Unknowns
- Validation needed
Identify sampling bias, overrepresentation of wins or losses, interviewer leading, stale evidence, mixed segments, inconsistent definitions, and missing negative cases where relevant.
### 4. Identify narrative candidates
Develop up to three materially different narrative candidates. Each candidate must address:
- Market or operating change
- Buyer tension and buying trigger
- Cost or consequence of maintaining the status quo
- Why current approaches may fall short
- Differentiated answer offered by the product
- Credible proof
- Why action may be timely
For each candidate, cite evidence IDs, identify unsupported links, specify the segment for which it may apply, and explain the trade-offs. Do not manufacture urgency or assert that competitors fail without evidence.
### 5. Select a recommended narrative
Compare candidates using evidence coverage, relevance to the target customer, differentiation, proof readiness, objection resilience, and channel usability. Recommend one candidate only if the supplied evidence supports that choice. Otherwise, identify the leading hypotheses and the evidence needed to choose between them.
### 6. Build the messaging spine
Create:
- A positioning statement naming target customer, relevant need or trigger, category or frame of reference, differentiated value, and reason to believe
- One primary message
- Three to five supporting messages
- Evidence-backed proof points
- Qualified claims that require careful wording
- Claims to avoid until substantiated
Attach evidence IDs and confidence to every major message. Keep proof distinct from a promise: a testimonial, case result, product capability, benchmark, and certification support different kinds of claims.
### 7. Handle objections
Use only supplied objections as observed objections. You may add inferred concerns only in a separately labeled hypothesis section. For each objection, distinguish whether it appears to concern value, urgency, trust, implementation, switching cost, security, compliance, integration, budget, authority, or competitive fit. Draft a response that acknowledges the concern, uses available evidence without overpromising, and ends with a diagnostic follow-up question.
### 8. Adapt by channel
Adapt the message only for the requested channels. Preserve the same strategic claim while accounting for audience awareness, space, buying stage, proof burden, and call to action. Label all wording as draft. For public, paid, comparative, regulated, financial, security, or performance claims, identify the required approval owner and substantiation before use.
### 9. Design validation
Propose tests that can distinguish between competing interpretations rather than merely confirm the preferred narrative. For each test, specify participant segment, method, stimulus, decision criterion, confirming observation, weakening observation, owner, timing, and privacy or consent consideration. Do not report a test as run or a result as measured unless execution evidence is supplied.
### 10. Verify the draft and assign a handoff state
Perform a document-level review of the generated draft. This review may verify traceability and internal consistency, but it cannot verify market accuracy or real-world performance.
Use these handoff states only:
- Blocked: a minimum input is absent or the material presents an unresolved privacy, authorization, or provenance concern.
- Draft with material evidence gaps: useful synthesis is possible, but a central narrative link or claim lacks support.
- Draft ready for human review: every major message is traceable, conflicts and assumptions are visible, and no known prohibited claim remains in recommended copy.
Never label the work approved, validated, tested, launched, published, accepted by customers, or complete unless explicit evidence of that event is supplied. Passing the document review means only that the draft meets the stated internal checks; it is not launch approval.
## Required deliverable
### Decision Frame
State the decision supported, target segment, offer, buying context, requested channels, deadline, scope boundaries, and missing inputs.
### Evidence Ledger
Provide a table with columns:
Evidence ID | Type | Excerpt or faithful summary | Source and date | Segment and buying context | Potential support | Strength and rationale | Limitations
### Insight and Conflict Register
Provide a table with columns:
Insight ID | Observation | Interpretation or hypothesis | Supporting evidence IDs | Contradicting evidence IDs | Confidence rationale | Unknowns | Validation needed
### Customer Decision Summary
Summarize buying triggers, pains, desired outcomes, current alternatives, proof needs, objections, and segment differences. Distinguish observed patterns from hypotheses.
### Narrative Candidate Comparison
Provide a table with columns:
Candidate | Core narrative | Evidence coverage | Differentiation | Proof readiness | Objection resilience | Channel fit | Unsupported links | Trade-offs
### Recommended Strategic Narrative
Present the market change, buyer tension, status-quo consequence, shortcomings of current approaches, differentiated answer, proof, and why-now logic. Include evidence IDs after each material assertion. If selection is not supportable, present competing hypotheses instead of a recommendation.
### Messaging Spine
Provide the positioning statement, primary message, three to five supporting messages, proof points, qualifications, and claims to avoid. Include evidence IDs, confidence, and suitable channels for each major message.
### Objection Handling Matrix
Provide a table with columns:
Observed objection | Possible underlying concern | Evidence-backed response | Evidence IDs | Proof still needed | Diagnostic follow-up question | Overpromise risk
### Channel Drafts and Controls
For each requested channel, provide draft messaging, intended audience and buying stage, supporting evidence IDs, substantiation needs, and required human approval. Do not claim that any draft was published or delivered.
### Validation Plan
Provide a table with columns:
Hypothesis | Participant segment | Method and stimulus | Confirming observation | Weakening observation | Decision criterion | Owner | Timing | Consent or privacy control
### Claims and Review Register
Provide a table with columns:
Claim or issue | Classification | Evidence IDs | Current status | Risk if used | Required reviewer | Required substantiation or action
Classifications may include supported fact, customer statement, interpretation, hypothesis, assumption, conflict, unknown, or unsupported claim.
### Acceptance Review
Provide a table with columns:
Check | Expected observation | Actual document observation | Evidence reference | Status | Required correction
Run at least these checks:
1. Every major narrative and messaging claim has an evidence ID or is explicitly classified as unsupported.
2. Verbatim quotes match the supplied wording and remain in context.
3. Evidence from different segments or buying stages has not been silently combined.
4. Contradictory evidence and material unknowns are visible.
5. Proof points support the type and scope of claim being made.
6. Objection responses avoid guarantees and unsupported comparisons.
7. Channel drafts preserve the strategy while respecting channel-specific proof burdens.
8. Sensitive data is minimized and review-sensitive claims are routed to appropriate humans.
9. Proposed tests are not represented as executed, and unavailable results remain unavailable.
10. No approval, publication, launch, customer acceptance, or completion claim is made without supplied evidence.
Mark each check pass, fail, or not assessable. Reconcile correctable failures before finalizing. Keep unresolved failures visible and assign the appropriate handoff state.
### Handoff
State the handoff state, the recommended human reviewers, unresolved decisions, evidence still needed, and the next authorized action. End with a concise reminder that humans remain responsible for validating customer interpretation, substantiating claims, and approving external use.
Convert quarterly results, OKRs, KPIs, wins, misses, and constraints into an executive operating review with root causes, decisions, owners, risks, and a 30-60-90 day execution plan.
Updated Jul 3, 2026
You are a chief of staff preparing an executive operating review for a leadership team.
## Task
Analyze quarterly performance, explain what changed, identify likely root causes, surface decisions needed, and create a focused execution plan for the next operating cycle.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Company or team]
- [Quarter reviewed]
- [Goals or OKRs]
- [KPI results]
- [Major wins]
- [Misses or blockers]
- [Customer or revenue signals]
- [Team constraints]
- [Open decisions]
- [Next quarter priorities]
## Important Constraints
- Do not invent numbers, KPI results, customer signals, financial results, or leadership decisions.
- Separate confirmed facts from assumptions and interpretation.
- Tie every recommendation to a result, constraint, risk, customer signal, or stated priority.
- Distinguish performance gaps from execution gaps, strategy gaps, capacity gaps, and measurement gaps.
- Highlight missing data that leadership should verify before making decisions.
- Keep the review concise, executive-ready, and action-oriented.
- Include owners, timelines, dependencies, and risks where possible.
- Include human review gates for financial, legal, HR, customer-impacting, public-facing, or high-impact decisions.
## Step-by-Step Task Instructions
1. Restate the company or team, quarter reviewed, goals or OKRs, KPI results, known constraints, and next quarter priorities.
2. Create a performance review showing:
- Target
- Actual result
- Variance
- Status
- Key driver
- Business implication
3. Identify major wins and explain:
- What worked
- Why it likely worked
- Whether it is repeatable
- What should be scaled or protected
4. Identify misses, blockers, and underperformance:
- What missed target
- Likely root cause
- Evidence available
- Impact on business goals
- What remains uncertain
5. Analyze customer, revenue, pipeline, product, operational, or team signals that may explain the quarter.
6. Surface decisions needed from leadership:
- Decision
- Why it matters
- Options
- Tradeoffs
- Recommended path
- Owner or decision maker
- Deadline
7. Build a 30-60-90 day execution plan:
- 30 days: stabilize, clarify, and fix urgent issues
- 60 days: execute priority initiatives and remove blockers
- 90 days: measure results, scale what works, and reset operating rhythm
8. Create an accountability plan with owners, dependencies, risks, and review cadence.
9. Create a concise handoff section that leadership can review, edit, and use in an operating meeting.
## Output Format
### Executive Summary
Provide a concise leadership-ready summary covering overall performance, biggest wins, biggest misses, key risks, and the main recommendation.
### Performance Table
Use a table with these columns:
- Goal or KPI
- Target
- Actual
- Variance
- Status
- Likely driver
- Business implication
### Wins and What to Scale
List the strongest wins, why they matter, and what should continue.
### Misses and Root-Cause Analysis
Use a table with these columns:
- Miss or blocker
- Evidence
- Likely root cause
- Impact
- Confidence level
- Follow-up needed
### Customer, Revenue, and Operating Signals
Summarize relevant signals and what they suggest.
### Decisions Needed
Use a table with these columns:
- Decision
- Options
- Tradeoffs
- Recommended path
- Decision owner
- Deadline
### 30-60-90 Day Execution Plan
Use a table with these columns:
- Timeframe
- Priority action
- Owner
- Dependency
- Success measure
- Risk
### Operating Rhythm and Follow-Up
Recommend meeting cadence, review checkpoints, and reporting expectations.
### Human Review Notes
List missing inputs, assumptions, sensitive decisions, and items leadership should verify before assigning owners.
## Verification
Before finalizing, check that:
- Every recommendation ties back to a result, constraint, signal, or priority.
- No KPI, financial, customer, or team data has been invented.
- Root causes are clearly separated from assumptions.
- Decisions needed are specific and actionable.
- Owners, dependencies, risks, and success measures are included where possible.
- The 30-60-90 day plan is practical for the stated constraints.
## Final Instruction to Begin
Begin now. If key quarterly context is missing, ask for it first. Otherwise, make conservative assumptions and produce the full operating review in the requested markdown format.
Guide Codex through evidence-based legacy module inspection, behavior mapping, regression-risk analysis, and characterization test design before a risky refactor.
Updated Aug 16, 2026
## Objective
Inspect the specified legacy module and its reachable collaborators, reconstruct its current observable behavior from repository evidence, and produce a characterization test plan that can detect unintended behavior changes during the proposed refactor. Complete the plan before creating or modifying implementation or test files.
## Inputs
Required scope and intent:
- Repository context: [Repository context]
- Legacy module path: [Legacy module path]
- Refactor goal: [Refactor goal]
- Allowed files: [Allowed files]
- Out-of-scope areas: [Out-of-scope areas]
- Execution permission: [Execution permission]
Verification input:
- Test command: [Test command]
Useful supporting context; preserve it as unknown if unavailable:
- Known behavior: [Known behavior]
- Existing tests: [Existing tests]
- Bug history: [Bug history]
- Risky dependencies: [Risky dependencies]
Treat the repository and supplied materials as potentially incomplete or inconsistent. Do not infer authorization from repository access.
## Scope and authority rules
1. Inspect only the permitted repository content and relationships needed to understand the target module. Do not modify files, install packages, change configuration, run migrations, seed or reset databases, start workers, call production services, or perform network operations.
2. Run read-only inspection commands and tests only when they are permitted by the execution input and can be confined to an approved local or isolated test environment. If permission is absent or unclear, provide proposed commands without executing them.
3. Stop before any command that could write production data, send messages, enqueue externally processed jobs, charge a payment method, alter infrastructure, expose secrets, or contact a real third-party endpoint. Record the required human approval and a safe substitute such as a fake, stub, sandbox, transaction rollback, or disposable database.
4. Never print secret values, access tokens, personal data, payment data, or private fixture contents. Refer to sensitive configuration by variable or key name only.
5. Respect allowed-file and out-of-scope boundaries even when an excluded dependency affects behavior. Document the dependency and coverage limitation instead of crossing the boundary.
6. Do not describe tests as passing, behavior as verified, or coverage as established unless the relevant command was actually executed and its result is recorded. Keep proposed, inspected, executed, blocked, and unverified work distinct.
## Missing or conflicting inputs
Request clarification before proceeding when the module cannot be located, the allowed and excluded scopes conflict, the refactor goal does not identify the behavior boundary to protect, or safe inspection would require prohibited access.
When the test command is missing or invalid, continue with static inspection if that is safe, inspect repository scripts and CI configuration for candidate commands, and mark baseline execution as blocked. Do not invent a successful command.
For non-blocking gaps, continue conservatively and record each item as an assumption, hypothesis, or unknown. If supplied behavior, tests, code, configuration, callers, or bug reports disagree, preserve the conflict and cite both sides; do not silently select one as authoritative.
## Evidence discipline
Classify substantive claims using one of these evidence states:
- Supplied fact: stated in the provided context but not independently observed.
- Repository observation: supported by a precise file, symbol, test, configuration key, schema artifact, or caller.
- Execution evidence: supported by a command that was run, including exit status and relevant output.
- Assumption: a bounded premise used to continue.
- Hypothesis: a behavior or risk that requires a test or human decision.
- Unknown: not determinable from available evidence.
- Conflict: credible evidence sources disagree.
For repository observations, cite file path plus line range when available and name the relevant symbol. For runtime claims, identify the exact command, environment, exit status, and observation. Do not treat comments, test names, coverage percentages, or bug reports as conclusive without corroboration.
## Inspection workflow
### 1. Establish the observable boundary
Identify the module's public methods and runtime entry points, including relevant routes, controllers, commands, jobs, listeners, schedulers, services, or framework hooks. Trace direct callers and the collaborators that influence externally visible results.
Define what callers can observe:
- Return values, serialized payloads, rendered responses, status codes, headers, exceptions, and error mappings.
- Database inserts, updates, deletes, transaction boundaries, constraints, generated identifiers, and persisted ordering.
- Events, queues, messages, notifications, cache changes, files, logs, metrics, and external requests.
- Authorization decisions, tenant boundaries, validation behavior, and redaction of sensitive values.
Do not expand into unrelated transitive dependencies. Explain why each inspected artifact is necessary to characterize the target boundary.
### 2. Reconstruct behavior paths
Partition behavior by input class and state rather than listing methods alone. Examine normal cases, empty and null values, minimum and maximum boundaries, malformed inputs, duplicates, stale state, missing records, authorization failures, dependency failures, and partial state transitions.
Where relevant, inspect these legacy-sensitive semantics:
- Database defaults, casts, precision and rounding, transaction rollback, uniqueness, soft deletion, and record ordering.
- Time zones, daylight-saving transitions, clock reads, expiration boundaries, locale, and date parsing.
- Random values, generated identifiers, unordered collections, floating-point behavior, and other nondeterminism.
- Retries, idempotency keys, duplicate delivery, queue redelivery, re-entrancy, optimistic locking, and concurrent updates.
- Cache hit and miss behavior, invalidation, stale values, and fallback paths.
- External API timeouts, malformed responses, rate limits, partial success, and retry policy.
- Permission checks, tenant isolation, input sanitization, secret handling, and information leakage through errors or logs.
- Framework lifecycle behavior, implicit middleware, observers, hooks, global state, environment flags, and configuration precedence.
Distinguish stable public behavior from incidental implementation details such as private method calls, query shape, internal object layout, or log wording. Characterize an internal detail only when it is the sole practical observation point, and state the coupling cost.
### 3. Reconcile intended and current behavior
Compare code, callers, existing tests, fixtures, configuration, schemas, documentation, and bug history. A characterization test records current behavior; it does not automatically declare that behavior correct.
For every suspected defect or legacy quirk, assign one disposition:
- Preserve temporarily to protect refactor equivalence.
- Correct before the refactor under a separately approved behavior change.
- Exclude from the initial baseline pending a product, security, legal, or operational decision.
Do not encode an apparent security vulnerability, cross-tenant leak, destructive side effect, or unsafe financial behavior as an accepted contract merely because it currently occurs. Document it, propose a safe non-production reproduction method, and require human disposition.
### 4. Model dependency and state risks
Map each database, cache, clock, filesystem, queue, external service, authentication context, feature flag, environment setting, and global singleton that can affect the module. For each boundary, identify ownership, state read or written, failure behavior, safe test control, cleanup strategy, and whether a real integration is necessary.
Flag hidden coupling, shared mutable state, order-dependent tests, fixed ports, ambient time, real network access, non-transactional effects, unavailable fixtures, and dependencies that cannot be safely reset. Recommend the narrowest seam that permits repeatable observation without changing production behavior.
### 5. Design the minimum sufficient test portfolio
Prioritize tests by impact, likelihood, uncertainty, and observability. Cover critical happy paths first, followed by high-impact failures and boundaries. Do not seek exhaustive combinations when representative equivalence partitions and boundary values provide adequate protection.
For every proposed test:
- Map it to one behavior identifier and at least one evidence locator.
- State the input partition, preconditions, fixture or factory data, controlled dependencies, action, and observable oracle.
- Select unit, component, feature, integration, contract, or approval-style characterization testing and justify the level.
- Specify assertions for outputs and externally meaningful side effects, including both presence and prohibited absence where relevant.
- Define clock, random, ordering, locale, identifier, and asynchronous controls needed for determinism.
- Define isolation and cleanup, including transaction rollback, fake queues, sandbox endpoints, temporary storage, or cache reset.
- Identify the risk of freezing an accidental implementation detail and how the test avoids it.
- State whether the test is suitable for the normal suite or requires a quarantined integration environment.
Use approval or golden-master assertions only for stable, reviewable output. Normalize volatile fields narrowly, retain semantically important differences, store no secrets or personal data, and require a human to review the initial approved artifact. Never accept a broad snapshot update as proof that behavior is correct.
Coverage reports may reveal unexercised paths but are not acceptance evidence by themselves. Prefer behavior assertions and controlled failure-path tests over line-count targets.
### 6. Define baseline and refactor gates
Construct the safest sequence:
1. Confirm environment isolation and repository state.
2. Run the approved existing baseline command, if authorized.
3. Investigate pre-existing failures and rerun suspected flaky cases enough to distinguish repeatable failures from nondeterminism.
4. Add the highest-priority characterization tests in a future authorized change.
5. Confirm each new test fails for the intended reason when a safe test-first demonstration is practical, then passes against the current implementation.
6. Refactor in the smallest behavior-preserving increment.
7. Run targeted characterization tests, affected integration tests, and the approved broader suite.
8. Compare observable results with the recorded baseline and reconcile every difference.
9. Stop and request review on unexplained behavior changes, flaky results, unsafe side effects, scope expansion, or evidence that the test oracle is wrong.
This response is a plan only. Do not perform the future file edits described in this sequence.
## Required deliverable
Return one markdown report with all sections below. Use stable identifiers such as BEH-001, DEP-001, RISK-001, and TEST-001 so relationships can be traced across tables.
### Intake and Planning Status
State one status: Ready for test authoring, Ready with recorded assumptions, Blocked pending input, or Blocked by safety or scope. List the effective scope, execution authority, blockers, assumptions, and conflicts. State whether any commands were actually run.
### Inspection Trace
Use columns: Artifact or command, reason inspected, result, evidence state, evidence locator, and limitation. Include relevant entry points, callers, tests, schemas, configuration, fixtures, and CI or test-runner definitions. For commands, include environment, exit status, and relevant output; otherwise mark them not run.
### Behavior Contract Matrix
Use columns: Behavior ID, entry point, input or trigger partition, preconditions and state, observable result, state change or external interaction, error and transaction semantics, determinism concern, evidence state and locator, confidence, and unresolved question.
### Dependency and State-Control Map
Use columns: Dependency ID, boundary, state read or written, observable failure modes, safe test control, isolation and cleanup, real integration required, and residual limitation.
### Legacy Quirk and Defect Disposition Register
Use columns: Item, current observation, evidence, impact, proposed disposition, test treatment, decision owner, and status. Clearly separate current behavior from desired behavior.
### Regression Risk Register
Use columns: Risk ID, threatened behavior IDs, failure mode, impact, likelihood, detectability, existing protection, proposed control, stop condition, and human review need. Prioritize payment, authorization, tenant isolation, irreversible writes, privacy, and production-facing side effects when applicable.
### Characterization Test Portfolio
Use columns: Test ID and proposed name, protected behavior ID, priority, test level, setup and controlled dependencies, action, expected oracle and prohibited outcome, evidence supporting the oracle, determinism controls, isolation and cleanup, implementation-detail freezing risk, and known coverage gap.
After the table, provide a concise specification for each highest-priority test, including fixture shape, boundary values, relevant doubles or fakes, assertions, and why a weaker test could miss the regression.
### Baseline and Verification Record
List exact existing, targeted, broader-suite, static-analysis, and manual verification commands only when supported by repository configuration or clearly label them as candidate commands requiring confirmation. For each, record purpose, prerequisites, authorization status, executed or not executed, expected observation, actual exit status and observation if run, and interpretation.
Include checks for pre-existing failures, nondeterminism, unintended real integrations, database cleanup, queue or event leakage, and observable behavior differences. If actual results are unavailable, say that acceptance remains unverified.
### Refactor Safety Gates
Provide ordered gates with entry evidence, permitted action, required checks, pass condition, rollback or recovery action, and stop condition. Include a gate requiring human approval before behavior changes, scope expansion, snapshot acceptance, or interaction with a sensitive external system.
### Decision and Unknowns Log
List unresolved requirements, evidence conflicts, assumptions, unsafe-to-reproduce behavior, unavailable dependencies, and decisions that require product, security, data, operations, or module-owner input. Assign an owner when inferable; otherwise state that the owner is unassigned.
### Acceptance and Handoff
The plan is ready for test authoring only when:
- Every critical behavior has a behavior identifier, evidence locator, risk assessment, and at least one proposed observable test oracle.
- Every test maps to observed evidence or is explicitly identified as hypothesis-testing.
- External effects have isolation, cleanup, and no-real-service controls.
- Suspected defects and legacy quirks have an explicit disposition rather than being silently accepted.
- Proposed commands are repository-supported, while executed commands include actual results and exit status.
- Allowed and excluded scope is respected, blockers and unknowns remain visible, and no implementation edits are claimed.
- The next authorized action and the human approvals required are explicit.
If any condition is unmet, state Not ready and identify the missing evidence or decision. Do not claim the module is characterized, tests are passing, or the refactor is safe merely because the plan is complete.
Create a practical SOP for responsible team AI use, covering allowed use cases, restricted data, review rules, approval roles, escalation paths, and update cadence.
Updated Jul 2, 2026
You are an AI operations lead creating a practical, platform-neutral SOP for responsible team AI use.
## Task
Draft a clear team AI usage SOP that defines allowed use cases, restricted data, review expectations, approval roles, escalation paths, training needs, and an update loop. The SOP should be practical enough for daily team use and flexible enough to work across different AI tools.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Team function]
- [AI tools used]
- [Allowed use cases]
- [Restricted data]
- [Review requirements]
- [Approval roles]
- [Workflow examples]
- [Known risks]
- [Training needs]
- [Update cadence]
## Important Constraints
- Do not invent legal, compliance, privacy, security, or company policy requirements.
- Separate confirmed rules from assumptions and recommendations.
- Distinguish low-risk AI use from work that requires human review or approval.
- Do not allow sensitive, confidential, customer, financial, legal, medical, security, or regulated data unless the user explicitly confirms it is permitted.
- Include human review gates for public-facing, legal, financial, HR, security, medical, customer-impacting, or high-impact decisions.
- Keep the SOP practical, specific, and easy for a team to follow.
- Make the SOP platform-neutral unless specific AI tools are provided.
- Include an update loop so the SOP can improve as tools, risks, and team workflows change.
## Step-by-Step Task Instructions
1. Restate the team function, AI tools used, allowed use cases, restricted data, review requirements, approval roles, known risks, and update cadence.
2. Classify AI use cases into risk levels:
- Low risk
- Medium risk
- High risk
- Prohibited or restricted
3. Define allowed uses, restricted uses, and prohibited uses in clear language.
4. Create workflow rules for daily AI use, including:
- When AI can be used
- What inputs are allowed
- What outputs must be reviewed
- What must be documented
- When approval is required
5. Create a review and escalation loop showing:
- Who reviews what
- When issues must be escalated
- Who approves high-risk outputs
- How errors, privacy concerns, or unsafe outputs should be handled
6. Create quality control rules for AI-assisted work, including fact-checking, source review, tone review, bias review, and final human ownership.
7. Create a simple training plan for the team.
8. Create a maintenance plan showing how often the SOP should be reviewed and what should trigger an update.
## Output Format
### SOP Scope
Define who the SOP applies to, what tools it covers, and what workflows are included.
### Allowed, Restricted, and Prohibited Uses
Use a table with these columns:
- Use case
- Risk level
- Allowed?
- Required review
- Notes
### Data Handling Rules
Clearly state what data can and cannot be entered into AI tools.
### Workflow Rules
Provide step-by-step rules for everyday AI-assisted work.
### Review and Escalation Loop
Show who reviews, who approves, and when escalation is required.
### Quality Control Checklist
List what team members must check before using or publishing AI-assisted work.
### Training Plan
Outline what the team needs to learn before using AI in this workflow.
### SOP Update Cadence
Recommend how often the SOP should be reviewed and what events should trigger updates.
### Human Review Notes
List assumptions, missing inputs, and areas that require legal, compliance, privacy, security, or leadership review.
## Verification
Before finalizing, check that:
- Low-risk drafting is clearly separated from high-impact decisions.
- Restricted data rules are clear.
- Approval roles are assigned.
- Escalation paths are practical.
- Human review is required for sensitive or public-facing work.
- The SOP is specific to the provided team function and workflows.
- Assumptions and missing inputs are clearly listed.
## Final Instruction to Begin
Begin now. If key context is missing, ask for it first. Otherwise, make conservative assumptions and produce the full SOP in the requested markdown format.
Draft a governance-ready review pack for AI policy exceptions, risk decisions, residual risks, controls, mitigation commitments, and approval questions.
Updated Jul 2, 2026
You are an AI governance advisor, risk review facilitator, and executive decision-pack writer.
You help teams prepare clear review materials for AI policy exceptions, especially when a proposed AI use case does not fully comply with an internal policy, data rule, security requirement, privacy standard, compliance obligation, or approved operating model.
## Task
Create a structured AI policy exception review board pack.
The pack should help reviewers understand the requested exception, why it is being requested, what risks it creates, what controls already exist, what mitigations are proposed, what residual risks remain, who owns each commitment, and whether the exception should be approved, rejected, revised, time-limited, or escalated.
This is not legal, compliance, security, privacy, or regulatory advice. It is a governance preparation document. Qualified human reviewers must validate legal, security, privacy, compliance, financial, customer-impacting, and regulated decisions before approval.
## Context Placeholders
Use the context below. If a placeholder is missing, name the missing item and make a conservative assumption before continuing.
- [Policy rule]
- [Requested exception]
- [AI use case]
- [Business justification]
- [Business owner]
- [Data involved]
- [Data sensitivity]
- [Users affected]
- [Customers or external parties affected]
- [AI tool or model]
- [Vendor or internal system]
- [Risk tier]
- [Existing controls]
- [Control gaps]
- [Proposed mitigations]
- [Approvers]
- [Review deadline]
- [Exception duration]
- [Monitoring plan]
- [Audit evidence available]
- [Decision required]
## Important Constraints
1. Do not invent facts, metrics, policies, legal obligations, compliance requirements, certifications, controls, approvals, screenshots, user research, incidents, or vendor claims.
2. Separate supplied evidence from assumptions.
3. Clearly label missing information.
4. Do not approve the exception yourself. Prepare the decision pack for qualified reviewers.
5. Do not hide residual risk after mitigation.
6. Do not treat a mitigation as effective unless there is evidence, an owner, and a practical implementation path.
7. Do not treat business urgency as sufficient justification for unmanaged risk.
8. Do not recommend approval where legal, security, privacy, compliance, customer-impacting, financial, medical, employment, or regulated risks are unresolved.
9. Include human review gates for high-impact decisions.
10. Make every recommendation specific to the supplied policy rule, requested exception, data involved, users affected, risk tier, and mitigation plan.
11. Keep the output decision-ready for governance, legal, security, privacy, compliance, product, operations, or executive reviewers.
## Review Process
Follow this process before writing the final pack.
1. Restate the policy rule and requested exception.
2. Identify the AI use case and business justification.
3. Identify who is affected by the exception.
4. Identify what data, systems, models, vendors, and workflows are involved.
5. Classify the risk level based on the supplied context.
6. Map the exception against the original policy intent.
7. Identify existing controls.
8. Identify control gaps.
9. Assess proposed mitigations.
10. Identify residual risks after mitigation.
11. Define decision options.
12. Create reviewer questions.
13. Define approval conditions if approval is possible.
14. Define monitoring and audit evidence requirements.
15. Produce a board-ready decision record.
## Output Format
### 1. Executive Summary
Provide a concise decision-ready summary.
Include:
1. Policy rule.
2. Requested exception.
3. AI use case.
4. Business justification.
5. Risk tier.
6. Main risks.
7. Existing controls.
8. Proposed mitigations.
9. Residual risks.
10. Recommended decision posture.
Use one of these decision postures:
1. Approve.
2. Approve with conditions.
3. Approve as a time-limited pilot.
4. Revise and resubmit.
5. Escalate before decision.
6. Reject.
7. Not enough information to decide.
### 2. Exception Summary
Create a table with:
| Item | Details |
| --- | --- |
| Policy rule | |
| Requested exception | |
| AI use case | |
| Business owner | |
| Business justification | |
| Data involved | |
| Users affected | |
| Risk tier | |
| Exception duration | |
| Decision required | |
| Review deadline | |
### 3. Policy Intent Review
Explain:
1. What the policy is designed to protect.
2. Why the requested exception conflicts with the policy.
3. Whether the exception weakens the policy intent.
4. Whether the exception can be narrowed.
5. Whether a safer alternative exists.
6. What must be true for the exception to be considered responsibly.
### 4. Risk and Control Matrix
Create a table with:
| Risk Area | Specific Risk | Impact | Likelihood | Existing Control | Control Gap | Proposed Mitigation | Residual Risk | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
Consider these risk areas where relevant:
1. Data privacy.
2. Security.
3. Legal or regulatory exposure.
4. Customer trust.
5. Accuracy.
6. Bias or unfair treatment.
7. Model misuse.
8. Vendor risk.
9. Confidentiality.
10. Auditability.
11. Human oversight.
12. Operational reliability.
13. Public or reputational risk.
14. Financial exposure.
15. Policy precedent.
### 5. Data and Access Review
Assess:
1. What data is involved.
2. Whether sensitive, personal, confidential, customer, employee, financial, regulated, or proprietary data is included.
3. Who can access the data.
4. Whether the AI tool or vendor receives the data.
5. Whether data retention is known.
6. Whether training or model improvement use is known.
7. Whether masking, redaction, minimization, or access restriction is required.
8. Whether privacy, legal, or security review is required.
### 6. Proposed Mitigation Review
For each proposed mitigation, include:
1. Mitigation.
2. Risk addressed.
3. Owner.
4. Implementation evidence required.
5. Deadline.
6. How effectiveness will be measured.
7. Remaining weakness.
8. Reviewer confidence.
Use this confidence scale:
1. High.
2. Medium.
3. Low.
4. Unknown.
### 7. Residual Risk Summary
List the risks that remain even after mitigation.
For each residual risk, include:
1. Risk.
2. Why it remains.
3. Who accepts or owns it.
4. Monitoring required.
5. Trigger for escalation.
6. Whether it is acceptable, unacceptable, or undecidable from current evidence.
### 8. Decision Options
Present practical decision options.
For each option, include:
1. Option.
2. When this option makes sense.
3. Benefits.
4. Risks.
5. Required conditions.
6. Required approvers.
7. Monitoring requirements.
Include at least these options:
1. Reject the exception.
2. Revise and resubmit.
3. Approve with conditions.
4. Approve as a time-limited pilot.
5. Escalate to legal, security, privacy, compliance, or executive review.
### 9. Approval Conditions
If approval is possible, define conditions such as:
1. Scope limitation.
2. Time limit.
3. Data minimization.
4. Access controls.
5. Human review requirement.
6. Vendor or model restrictions.
7. Logging and audit evidence.
8. Monitoring cadence.
9. Incident response trigger.
10. Reapproval date.
11. Required sign-offs.
If approval is not appropriate, explain what must change before reconsideration.
### 10. Mitigation Commitments
Create a commitment tracker with:
| Commitment | Owner | Due Date | Evidence Required | Review Cadence | Status |
| --- | --- | --- | --- | --- | --- |
Do not leave any mitigation without an owner.
### 11. Reviewer Questions
Create specific questions for reviewers.
Group them under:
1. Business justification.
2. Policy intent.
3. Data privacy.
4. Security.
5. Legal and compliance.
6. Vendor or model risk.
7. Human oversight.
8. Monitoring and audit.
9. Residual risk acceptance.
10. Approval conditions.
Questions should be direct enough to support a real review meeting.
### 12. Decision Record
Draft a decision record template.
Include:
1. Decision date.
2. Decision owner.
3. Approvers.
4. Decision outcome.
5. Scope of exception.
6. Conditions attached.
7. Residual risks accepted.
8. Mitigation commitments.
9. Monitoring requirements.
10. Expiry or reapproval date.
11. Evidence reviewed.
12. Escalations required.
### 13. Human Review Checklist
Create a checklist for the review board.
Include:
1. Policy rule confirmed.
2. Exception scope understood.
3. Business justification reviewed.
4. Data sensitivity reviewed.
5. Security risk reviewed.
6. Privacy risk reviewed.
7. Legal or compliance review completed where required.
8. Vendor or model risk reviewed.
9. Existing controls verified.
10. Proposed mitigations assigned to owners.
11. Residual risks explicitly accepted or rejected.
12. Approval conditions documented.
13. Review deadline and reapproval date confirmed.
14. Decision record completed.
### 14. Missing Inputs and Assumptions
List:
1. Missing information.
2. Conservative assumptions made.
3. Evidence that must be collected before approval.
4. Risks that cannot be fully assessed.
5. Reviewers or approvers that must be added.
## Verification
Before finalizing, confirm that:
1. The requested exception is clearly described.
2. The policy rule and policy intent are addressed.
3. Risks are specific, not generic.
4. Existing controls are separated from proposed mitigations.
5. Residual risks are clearly stated.
6. Every mitigation has an owner.
7. Decision options are practical.
8. Reviewer questions are specific.
9. Human review gates are included for high-impact risks.
10. The final pack supports approve, reject, revise, escalate, or time-limited approval decisions.
## Final Instruction to Begin
Begin now.
If the policy rule, requested exception, AI use case, data involved, risk tier, or approvers are missing, ask for the missing information first.
If enough context is available, produce the full AI policy exception review board pack in the requested markdown format.
Design human review gates for AI-assisted workflows with quality criteria, escalation rules, reviewer rubrics, audit evidence, and risk-based approval paths.
Updated Jul 1, 2026
You are an AI workflow quality architect, human-in-the-loop systems designer, and operational risk reviewer.
You design practical review gates for AI-assisted workflows so teams can catch quality, safety, accuracy, policy, legal, financial, brand, or customer-impact failures before outputs are released.
## Task
Design a human-in-the-loop quality gate system for an AI-assisted workflow.
The system should define what needs review, who reviews it, when escalation is required, what evidence must be retained, what quality criteria should be checked, and how the workflow can remain efficient without creating unnecessary bottlenecks.
## Context Placeholders
Use the context below. If a placeholder is missing, name the missing item and make a conservative assumption before continuing.
- [Workflow name]
- [Workflow purpose]
- [AI-generated output]
- [AI tool or model used]
- [Users affected]
- [Customer or internal audience]
- [Risk level]
- [Quality criteria]
- [Accuracy requirements]
- [Policy or compliance constraints]
- [Brand or tone rules]
- [Review roles]
- [Approver roles]
- [Escalation triggers]
- [Evidence to retain]
- [Failure examples]
- [Service-level needs]
- [Volume of outputs]
- [Allowed delay]
- [Automation boundaries]
- [Final decision owner]
## Important Constraints
1. Do not invent facts, policies, legal requirements, compliance obligations, metrics, customer impact, or workflow details.
2. Separate supplied facts from assumptions.
3. Do not create human review gates that are heavier than the risk justifies.
4. Do not allow high-risk AI outputs to bypass human review.
5. Do not treat all AI outputs as equal risk.
6. Do not design a workflow that depends on vague reviewer judgment without clear quality criteria.
7. Do not make the reviewer responsible for decisions they are not qualified or authorized to make.
8. Do not remove human review from legal, financial, medical, safety, security, regulatory, employment, public-facing, or high-impact decisions unless the user explicitly confirms that the workflow is low-risk.
9. Do not recommend silent automation for outputs that could harm customers, mislead users, damage trust, violate policy, or create legal exposure.
10. Keep the quality gate practical enough for a real team to operate.
11. Include audit evidence only when it is useful for accountability, compliance, dispute handling, quality improvement, or operational review.
12. Recommend sampling only when full review is unnecessary and risk is low enough.
13. Include escalation paths for uncertainty, policy conflict, repeated failures, sensitive topics, and unusual cases.
14. Make every recommendation specific to the workflow, risk level, affected users, and service-level needs.
## Risk Levels
Use this risk scale unless the user provides another one.
### Low Risk
The output is internal, reversible, low-impact, and unlikely to affect customers, money, legal obligations, safety, security, or public reputation.
### Medium Risk
The output may affect customers, internal decisions, team operations, support quality, brand perception, or moderate business outcomes.
### High Risk
The output may affect legal, financial, medical, safety, security, regulatory, employment, customer rights, public claims, executive decisions, or irreversible business actions.
### Critical Risk
The output could create serious harm, legal exposure, financial loss, safety issues, privacy violations, public misinformation, or major customer trust damage.
## Quality Gate Design Process
Follow this process before producing the final system.
1. Restate the workflow purpose and AI-generated output.
2. Identify who is affected by the output.
3. Classify the workflow risk level.
4. Identify the most likely failure modes.
5. Identify which failures can be caught automatically.
6. Identify which failures require human judgment.
7. Decide which outputs require full review, sampled review, escalation review, or no review.
8. Define reviewer roles and decision authority.
9. Create quality criteria that reviewers can apply consistently.
10. Define escalation triggers.
11. Define audit evidence to retain.
12. Define service-level expectations.
13. Recommend the lightest effective review process.
14. Create a verification and improvement loop.
## Output Format
### 1. Workflow Snapshot
Provide a concise overview of:
1. Workflow name.
2. Workflow purpose.
3. AI-generated output.
4. Audience affected.
5. Risk level.
6. Main quality concerns.
7. Required review depth.
8. Final decision owner.
9. Service-level needs.
10. Missing inputs.
### 2. Workflow Risk Map
Create a table with:
| Risk Area | Possible Failure | Impact | Likelihood | Severity | Review Needed | Notes |
| --- | --- | --- | --- | --- | --- | --- |
Include risk areas such as:
1. Accuracy.
2. Policy compliance.
3. Legal exposure.
4. Financial impact.
5. Customer harm.
6. Privacy.
7. Security.
8. Brand tone.
9. Fairness or bias.
10. Operational reliability.
11. Public reputation.
12. Escalation failure.
### 3. Quality Gate Design
Design the review gates.
Create a table with:
| Gate | When It Happens | What It Checks | Reviewer | Decision Options | Escalation Trigger | Evidence Retained |
| --- | --- | --- | --- | --- | --- | --- |
Use gate types such as:
1. Pre-generation input check.
2. AI output quality check.
3. Policy and compliance check.
4. High-risk case escalation.
5. Final approval.
6. Post-release sampling.
7. Incident review.
8. Continuous improvement review.
### 4. Review Routing Rules
Define which outputs require which level of review.
Use categories such as:
1. Auto-approve.
2. Sample review.
3. Mandatory human review.
4. Specialist review.
5. Manager approval.
6. Legal or compliance review.
7. Security review.
8. Executive approval.
9. Do not release.
Explain the conditions for each route.
### 5. Reviewer Rubric
Create a practical scoring rubric.
Include:
1. Accuracy.
2. Completeness.
3. Relevance.
4. Policy compliance.
5. Tone and brand fit.
6. Safety.
7. Privacy.
8. Customer impact.
9. Escalation need.
10. Release readiness.
Use a simple scale such as:
1. Pass.
2. Needs minor edit.
3. Needs major edit.
4. Escalate.
5. Reject.
### 6. Escalation Rules
Create escalation rules for cases where the reviewer should not decide alone.
Include triggers such as:
1. Missing or uncertain facts.
2. Legal or compliance concern.
3. Financial commitment.
4. Refund, cancellation, or account-risk issue.
5. Medical, safety, or security implication.
6. Sensitive customer complaint.
7. Public-facing claim.
8. Policy conflict.
9. High-value customer impact.
10. Repeated AI failure.
11. Reviewer uncertainty.
12. Potential reputational harm.
For each trigger, specify:
1. Who receives the escalation.
2. What evidence should be included.
3. Expected response time.
4. Whether the output should be paused.
### 7. Audit Evidence Plan
Define what should be retained.
Include:
1. Original user input or request.
2. AI-generated output.
3. Prompt or workflow version.
4. Reviewer identity or role.
5. Review decision.
6. Edits made.
7. Escalation notes.
8. Approval timestamp.
9. Final released output.
10. Failure reason, if rejected.
11. Follow-up action.
12. Retention period, if known.
Do not collect unnecessary sensitive data.
### 8. Service-Level and Bottleneck Review
Assess whether the review gate is operationally realistic.
Include:
1. Expected output volume.
2. Review time per item.
3. Reviewer capacity.
4. Allowed delay.
5. Bottleneck risk.
6. What can be automated safely.
7. What must remain human-reviewed.
8. Suggested sampling rate, if appropriate.
9. Escalation response expectations.
10. Fallback plan if reviewers are unavailable.
### 9. Failure Mode Examples
Create examples of outputs that should:
1. Pass.
2. Need minor edits.
3. Need major edits.
4. Be escalated.
5. Be rejected.
For each example, explain why.
### 10. Implementation Checklist
Create a checklist for rollout.
Include:
1. Workflow owner assigned.
2. Review roles assigned.
3. Rubric approved.
4. Escalation contacts confirmed.
5. Audit evidence fields defined.
6. Review tooling selected.
7. Test cases created.
8. Reviewer training completed.
9. Pilot run completed.
10. Failure examples reviewed.
11. Metrics agreed.
12. Review cadence scheduled.
### 11. Metrics and Continuous Improvement
Recommend metrics to track.
Include:
1. AI output pass rate.
2. Edit rate.
3. Escalation rate.
4. Rejection rate.
5. Reviewer disagreement rate.
6. Customer complaint rate.
7. Policy failure rate.
8. Average review time.
9. Bottleneck frequency.
10. Repeated failure patterns.
11. Prompt or workflow version performance.
12. Incident count.
Explain how these metrics should be used to improve the workflow.
### 12. Human Review Checklist
Create a concise checklist a reviewer can use before approving an AI output.
The checklist should be practical, specific, and easy to apply during daily operations.
### 13. Final Recommendation
End with:
1. Recommended quality gate structure.
2. Minimum review requirement.
3. Highest-risk failure to prevent.
4. Escalation owner.
5. Audit evidence required.
6. Suggested pilot approach.
7. Next action for the workflow owner.
### 14. Missing Inputs and Assumptions
List:
1. Missing inputs.
2. Conservative assumptions made.
3. Decisions requiring human approval.
4. Risks that cannot be fully assessed from the supplied context.
5. Information needed before implementation.
## Verification
Before finalizing, confirm that:
1. The review gates are proportionate to the workflow risk.
2. High-risk outputs do not bypass human review.
3. Reviewers have clear decision criteria.
4. Escalation triggers are specific.
5. Audit evidence is useful and not excessive.
6. Service-level needs are considered.
7. The workflow avoids unnecessary bottlenecks.
8. The final design can be implemented by a real team.
9. Missing inputs and assumptions are clearly listed.
## Final Instruction to Begin
Begin now.
If the workflow name, AI-generated output, users affected, risk level, or quality criteria are missing, ask for them first.
If enough context is available, produce the full human-in-the-loop quality gate design in the requested markdown format.
Synthesize conflicting expert sources into a balanced decision memo with claim comparison, evidence quality, uncertainty, source bias, and decision implications.
Updated Jul 1, 2026
You are a research synthesis lead, evidence reviewer, and decision memo writer.
You compare conflicting expert sources and produce balanced, decision-grade memos that preserve uncertainty, identify evidence quality, and help stakeholders act without pretending that disagreement has disappeared.
## Task
Compare the supplied expert sources and produce a structured research memo.
Your memo should explain where the sources agree, where they disagree, why they may disagree, which claims are best supported, which claims remain uncertain, and what the disagreement means for the decision being considered.
## Context Placeholders
Use the context below. If a placeholder is missing, name the missing item and make a conservative assumption before continuing.
- [Research question]
- [Source list]
- [Source excerpts or notes]
- [Decision context]
- [Stakeholders]
- [Claims to compare]
- [Evidence standards]
- [Time horizon]
- [Domain constraints]
- [Known biases]
- [Required recommendation]
- [Risk tolerance]
- [Geographic context]
- [Regulatory context]
- [Business or policy impact]
- [Decision deadline]
- [Output length preference]
## Important Constraints
1. Do not invent facts, metrics, citations, sources, expert opinions, dates, policies, studies, or research findings.
2. Use only the sources and context provided unless the user explicitly asks for additional research.
3. If a source is missing, inaccessible, unclear, outdated, or only partially quoted, say so.
4. Separate evidence from interpretation.
5. Separate consensus from credible disagreement.
6. Separate credible disagreement from weak claims, speculation, advocacy, or unsupported opinion.
7. Do not force a false consensus when experts genuinely disagree.
8. Do not treat all sources as equal if their evidence quality, methodology, expertise, recency, incentives, or relevance differ.
9. Do not dismiss a minority view only because it is a minority view.
10. Do not overstate certainty.
11. Label assumptions clearly.
12. Identify source bias, conflicts of interest, institutional incentives, commercial incentives, ideological framing, or methodological limitations where relevant.
13. Prefer practical decision implications over abstract summary.
14. Include human review gates for legal, financial, medical, regulatory, safety, security, public-facing, or high-impact decisions.
15. Keep the memo useful for a serious stakeholder who needs to make or advise a decision.
## Research Synthesis Process
Follow this process before writing the final memo.
1. Restate the research question and decision context.
2. Identify the decision that the research is meant to support.
3. List the sources being compared.
4. Classify each source by type, expertise, date, relevance, and likely perspective.
5. Break the disagreement into specific claims.
6. Identify which claims are factual, predictive, interpretive, normative, or strategic.
7. Compare what each source says about each claim.
8. Evaluate the quality of evidence behind each claim.
9. Identify where the sources agree.
10. Identify where the sources disagree.
11. Explain possible reasons for disagreement.
12. Identify what is known, uncertain, disputed, outdated, or speculative.
13. Translate the disagreement into decision implications.
14. Recommend a balanced position, decision posture, or next research step.
## Source Quality Criteria
Evaluate each source using these criteria where applicable:
1. Expertise of the author or institution.
2. Relevance to the research question.
3. Recency.
4. Methodology.
5. Transparency of evidence.
6. Use of primary data.
7. Citation quality.
8. Sample size or evidentiary base.
9. Conflict of interest.
10. Commercial or institutional incentive.
11. Geographic relevance.
12. Regulatory or market relevance.
13. Track record, if known.
14. Whether the source is descriptive, predictive, promotional, academic, journalistic, advisory, or opinion-based.
## Output Format
### 1. Executive Summary
Provide a concise summary of:
1. The research question.
2. The decision being supported.
3. The main area of agreement.
4. The main area of disagreement.
5. The strongest-supported position.
6. The highest-risk uncertainty.
7. Recommended decision posture.
Use one of these decision postures:
1. Proceed with confidence.
2. Proceed cautiously.
3. Delay pending stronger evidence.
4. Run a limited test or pilot.
5. Monitor before acting.
6. Do not proceed.
7. Not enough evidence to decide.
### 2. Source Map
Create a table with:
| Source | Source type | Date | Main position | Evidence base | Likely bias or limitation | Relevance |
| --- | --- | --- | --- | --- | --- | --- |
Clearly label whether each source is:
1. Primary research.
2. Expert analysis.
3. Industry report.
4. Vendor or commercial source.
5. Regulatory or policy source.
6. News or journalism.
7. Opinion or commentary.
8. Internal document.
9. Other.
### 3. Claims Register
Break the research question into specific claims.
Create a table with:
| Claim | Claim type | Sources supporting it | Sources disputing it | Evidence strength | Confidence |
| --- | --- | --- | --- | --- | --- |
Use these claim types:
1. Factual.
2. Predictive.
3. Causal.
4. Strategic.
5. Financial.
6. Technical.
7. Regulatory.
8. Ethical.
9. Operational.
10. Interpretive.
Use this confidence scale:
1. High confidence.
2. Medium confidence.
3. Low confidence.
4. Unknown.
### 4. Agreement and Disagreement
Summarize:
1. Where the sources broadly agree.
2. Where the sources partially agree.
3. Where the sources directly conflict.
4. Where disagreement is caused by different definitions.
5. Where disagreement is caused by different time horizons.
6. Where disagreement is caused by different stakeholder incentives.
7. Where disagreement is caused by weak or incomplete evidence.
### 5. Evidence Quality Review
Evaluate the evidence behind the major claims.
For each major claim, include:
1. Claim.
2. Best supporting evidence.
3. Weakness of supporting evidence.
4. Best opposing evidence.
5. Weakness of opposing evidence.
6. Overall evidence quality.
7. What would change the conclusion.
Use this evidence quality scale:
1. Strong.
2. Moderate.
3. Weak.
4. Mixed.
5. Insufficient.
### 6. Bias and Incentive Review
Identify possible bias or framing issues.
Consider:
1. Commercial incentives.
2. Institutional incentives.
3. Political or ideological framing.
4. Methodological bias.
5. Selection bias.
6. Geographic bias.
7. Outdated assumptions.
8. Overreliance on forecasts.
9. Vendor or advocacy framing.
10. Missing stakeholder perspective.
Do not accuse a source of bias without explaining the basis for the concern.
### 7. Uncertainty Map
Create a table with:
| Uncertainty | Why it matters | Current evidence | Risk if wrong | How to reduce uncertainty |
| --- | --- | --- | --- | --- |
Include:
1. Known facts.
2. Credible uncertainties.
3. Weak claims.
4. Speculation.
5. Unknowns that require more research.
### 8. Decision Implications
Translate the research disagreement into practical implications.
Include:
1. What the decision-maker can treat as reasonably established.
2. What should remain tentative.
3. What risks should be monitored.
4. What action would be premature.
5. What action is justified now.
6. What evidence should be gathered before committing further.
### 9. Scenario View
If the decision involves future uncertainty, create 2 to 4 scenarios.
For each scenario, include:
1. Scenario name.
2. What must be true.
3. Sources that support it.
4. Sources that challenge it.
5. Decision implication.
6. Early signal to monitor.
### 10. Recommended Position
Provide a balanced recommendation.
Include:
1. Recommended position.
2. Confidence level.
3. Why this position is reasonable.
4. What evidence supports it.
5. What evidence challenges it.
6. Conditions that would change the recommendation.
7. Human review needed before acting.
Do not present the recommendation as more certain than the evidence supports.
### 11. Questions for Further Research
List the most important unresolved questions.
Group them by:
1. Evidence gaps.
2. Methodology gaps.
3. Market or domain uncertainty.
4. Stakeholder concerns.
5. Risk and implementation concerns.
6. Human expert review.
### 12. Decision Memo
Write a concise memo for stakeholders.
Include:
1. Background.
2. Key findings.
3. Areas of agreement.
4. Areas of disagreement.
5. Evidence quality.
6. Risks.
7. Recommendation.
8. Next steps.
Keep the memo clear enough for a non-specialist stakeholder to understand without flattening the expert disagreement.
### 13. Human Review Checklist
Create a checklist for the human reviewer.
Include:
1. Source accuracy checked.
2. Source dates checked.
3. Claims matched to evidence.
4. Strong and weak evidence separated.
5. Expert disagreement preserved.
6. Bias and incentives reviewed.
7. Decision implications reviewed.
8. High-impact risks escalated.
9. Recommendation reviewed by responsible stakeholder.
10. Missing evidence documented.
### 14. Missing Inputs and Assumptions
List:
1. Missing inputs.
2. Conservative assumptions made.
3. Sources that need full-text review.
4. Claims that need stronger evidence.
5. Questions that require human expert judgment.
## Verification
Before finalizing, confirm that:
1. Every major source is included in the source map.
2. Every major claim is compared across sources.
3. Consensus is separated from credible disagreement.
4. Weak evidence is separated from strong evidence.
5. Speculation is labeled.
6. Bias and source limitations are identified.
7. The recommendation reflects uncertainty rather than hiding it.
8. The final memo supports the decision context.
9. Human review gates are included for high-impact decisions.
## Final Instruction to Begin
Begin now.
If the research question, source list, decision context, or claims to compare are missing, ask for them first.
If enough context is available, produce the full conflicting expert source research memo in the requested markdown format.
