Choose generative AI by the output contract, not the demo.

Decision question: Can a user find and interpret permitted evidence across maintained records without treating generated prose as the source of truth?

Good fit when

The knowledge set has named owners, stable access rules, identifiable versions, useful passage-level retrieval, and a user who can inspect the source before relying on the answer.

Required context

Approved corpus, document identity and version, ownership, access and retention rules, freshness signals, representative questions, expected passages, conflicting records, prohibited topics, terminology, and no-answer examples.

Model boundary

Retrieve only within the user's permitted scope, assemble cited context, generate a bounded response, check every factual claim against accessible evidence, and abstain when support is missing, conflicting, stale, or out of scope.

Retained authority

Source owners decide what is authoritative and correct or withdraw records. The user inspects evidence and owns any interpretation or action. The model cannot expand access, change a source, or turn its response into a binding record.

Evaluation evidence

Retrieval coverage, permission isolation, claim-to-source support, citation correctness, unresolved conflict, abstention quality, correction rate, user over-reliance, review time, latency, cost, and behavior after source change.

Characteristic failure

Prompt injection inside retrieved content, stale authority, hidden permission leakage, plausible synthesis across conflicting sources, citation mismatch, an answer that obscures omitted evidence, or reuse outside the tested audience.

Operating requirement

Maintain the source register, access tests, index freshness, question set, unsupported-claim review, user feedback, incident route, source withdrawal, model-change gate, and a direct path back to the records.

Decision question: Can the system expose material similarities, differences, obligations, gaps, or themes across a known document set while preserving the full text for review?

Good fit when

The documents are identifiable and lawfully usable, comparison dimensions can be stated, page or section evidence can be retained, and a domain owner can judge materiality and missing coverage.

Required context

Complete files, versions, hierarchy, dates, authorship or authority, usage rights, comparison questions, defined terms, required fields, exclusions, known amendments, expected differences, and materiality rules.

Model boundary

Parse and preserve document structure, locate evidence for each comparison dimension, generate a traceable synthesis, mark missing and conflicting material, and block any conclusion that lacks a link to the inspected text.

Retained authority

A domain owner decides whether the documents are complete, which version governs, whether a difference is material, and what action follows. Legal or professional interpretation stays with qualified reviewers where required.

Evaluation evidence

Document and section coverage, exact support for each comparison, missed and false differences, table or clause reconstruction, terminology handling, reviewer disagreement, correction effort, and performance on deliberately incomplete sets.

Characteristic failure

Partial extraction, footnotes or tables losing meaning, a later amendment being missed, two sources being blended, absence being presented as permission, copied confidential text, or a summary replacing full-document review.

Operating requirement

Version and retain the comparison record, source locations, extraction warnings, reviewer decisions, and amendments. Re-run affected comparisons when a document or rule changes and keep a manual inspection path.

Decision question: Can a person prepare a useful message, report, proposal section, procedure, or response without giving the model the send, publish, promise, or approval decision?

Good fit when

The audience and purpose are known, permitted facts and style rules are available, the work is reviewable before use, and the accountable author has enough time and competence to own the final result.

Required context

Approved facts and source material, audience, purpose, required sections, terminology, tone, brand rules, prohibited claims, privacy limits, examples with valid usage rights, disclosures, and reviewer rubric.

Model boundary

Generate a visibly marked draft, attach the supporting facts, show additions and unresolved fields, run deterministic structure and policy checks, and require the author to move approved content through a separate release path.

Retained authority

The author selects recipients, verifies claims, judges context and tone, owns commitments, edits or rejects the draft, and initiates any send or publication action outside the generation boundary.

Evaluation evidence

Unsupported claims, material omissions, factual corrections, prohibited language, privacy findings, copied phrasing, rejection rate, review time, author disagreement, downstream corrections, and comparison with the current drafting process.

Characteristic failure

Fluency turning review into a ritual, invented facts, confidential prompt context, wrong audience, disguised automation, unintended commitments, style imitation without rights, accidental release, or draft reuse beyond the approved purpose.

Operating requirement

Keep source and policy owners, a separate approval state, version history, correction and withdrawal paths, reviewer-capacity limits, and a non-generative template when evidence or review is unavailable.

Decision question: Can known material be translated, simplified, restructured, extracted, or converted while preserving the required meaning, coverage, labels, and source relationship?

Good fit when

The complete source is available, the target form and audience are explicit, critical terminology can be controlled, omissions are detectable, and qualified review can cover consequential or specialized meaning.

Required context

Source identity, language and locale, target language or schema, required fields and order, terminology lists, numbers and units, tables, accessibility needs, privacy and rights, examples, and known ambiguity.

Model boundary

Transform only the identified material, preserve a source-to-output map, validate required structure and exact values with ordinary code, flag ambiguity and missing coverage, and separate literal content from added explanation.

Retained authority

The content owner approves meaning and audience. Qualified language or domain reviewers decide specialized terms and ambiguity. The model cannot certify equivalence, accessibility, legal effect, or professional accuracy.

Evaluation evidence

Section and field coverage, numerical fidelity, terminology consistency, meaning errors by consequence, omissions, additions, formatting validity, locale review, accessibility checks, and reviewer time on representative difficult material.

Characteristic failure

Dropped qualifiers, changed numbers, flattened tables, false equivalence, inaccessible layout, regional mismatch, specialized terms rendered incorrectly, explanations mixed with source meaning, or a partial input treated as complete.

Operating requirement

Maintain source versions, term owners, transformation schemas, deterministic validators, reviewer routes, correction history, and reprocessing rules when the source, locale, format, audience, or model changes.

Decision question: Can a team explore or prepare text, image, audio, or video material while keeping rights, consent, identity, disclosure, provenance, and publication decisions explicit?

Good fit when

Synthetic creation is the declared purpose, input and reference rights are documented, prohibited subjects and identity uses are enforceable, and every external release has an accountable content owner.

Required context

Owned or permitted references, licenses, subject consent where applicable, identity and style boundaries, audience, content policy, disclosure rules, accessibility needs, provenance plan, retention, and takedown contacts.

Model boundary

Create candidates in an isolated workspace, retain prompt and ingredient records as appropriate, apply content and identity restrictions, review the complete asset, attach required disclosure or provenance data, and publish through a separate controlled path.

Retained authority

Rights and content owners approve inputs and destination. The responsible publisher decides representation, disclosure, accessibility, and release. Affected people retain applicable reporting, objection, correction, or removal routes.

Evaluation evidence

Input-rights coverage, prohibited-subject tests, identity and similarity review, privacy findings, disclosure and provenance retention, accessibility checks, rejection reasons, reviewer agreement, removal response, and behavior after editing or reposting.

Characteristic failure

Unauthorized reference material, deceptive identity use, false provenance, privacy loss, harmful or illegal content, inaccessible media, missing disclosure, metadata removal, a detector treated as conclusive, or downstream reuse beyond permission.

Operating requirement

Keep an asset register, rights and consent evidence, version and ingredient history, approval and destination records, disclosure and provenance checks, correction and takedown procedures, and rules for retained or deleted working material.

Decision question: Can a model propose code, tests, queries, configurations, documentation, or migration plans while the repository, verification, security, release, and production authorities remain outside it?

Good fit when

The task has a controlled workspace, explicit interfaces, reproducible checks, protected secrets and data, competent review, and no direct route from generated output to production or irreversible state change.

Required context

Relevant source and contracts, architecture and coding rules, dependency policy, threat model, test fixtures, acceptance cases, licenses, environment limits, secret boundaries, rollback path, and review ownership.

Model boundary

Generate a reviewable change in an isolated branch or workspace, inspect dependencies and provenance, run static and dynamic checks, test failure and rollback, require human review, and release through the existing controlled delivery process.

Retained authority

Engineers own design and code judgment. Security and data owners decide risk within their mandates. Authorized maintainers approve merge and release. Production, secrets, migrations, and destructive actions remain separately controlled.

Evaluation evidence

Diff review, contract and regression tests, security findings, dependency and license checks, performance where relevant, generated-test validity, failure and rollback behavior, reviewer corrections, maintainability, and production observation after approved release.

Characteristic failure

Plausible but incorrect code, hidden vulnerabilities, fabricated APIs, weak tests that mirror the same mistake, secret exposure, unnecessary dependencies, incompatible licenses, destructive commands, or automation bypassing repository controls.

Operating requirement

Treat generated work as untrusted input, preserve normal review and release records, isolate credentials, monitor accepted changes, keep rollback and incident paths, revalidate model or tool changes, and retain staff ownership of the codebase.