Technical Writing and Documentation SOP and Operating Playbook

Model Role SOP / Operating Playbook

Technical Writer / Documentation Specialist

Document type: Evidence-derived operating model for local adaptation
Research geography: United States
Evidence date: 11 September 2026
Course: Professional Certificate in Technical Writing and Documentation
Version: 1.0

This playbook turns an authorised documentation need into usable, controlled, maintainable information. It covers procedures, user and administrator guides, knowledge-base content, release notes and related technical documentation across IT, service, manufacturing and regulated operations. It is not a live employer procedure, a universal U.S. policy, a regulated submission, a safety instruction or legal advice. Every field marked [[LOCAL — ...]] must be completed from the organisation's current approved policy, system configuration and decision-rights map before operational use.

1. Purpose and scope

The Technical Writer / Documentation Specialist operates the path from source evidence to released information. The role identifies the audience and task, collects and reconciles technical evidence, selects an appropriate content structure, drafts and tests content, coordinates specialist review, publishes through an authorised channel and maintains the result through change and retirement.

The role owns documentation quality within delegated authority. It does not convert editorial skill into engineering, safety, clinical, quality, regulatory, legal, security or release authority.

In scope

• clarify the audience, task, use context, information need and acceptance criteria;
• establish the authoritative sources and named subject-matter owners;
• identify affected documents when products, processes, services or obligations change;
• interview subject-matter experts and reconcile evidence without inventing missing facts;
• plan content types, information architecture, navigation, metadata and reuse;
• author and revise procedures, SOPs, work instructions and runbooks within an approved process;
• author and revise user, administrator, operator, installation, maintenance and service guides;
• create and maintain knowledge-base articles, troubleshooting content and help-centre structures;
• prepare release notes, changelogs and change communications from approved release evidence;
• create or coordinate diagrams, screenshots, examples and other explanatory assets;
• apply technical editing, terminology, plain-language, accessibility, findability and localisation-readiness checks;
• coordinate technical, editorial, quality and other required reviews;
• preserve document identity, version, status, comments, approvals and publication evidence;
• publish only through an authorised channel after required approvals;
• monitor feedback, defects, search behaviour and task evidence using defined denominators;
• revise, supersede, archive or retire information through the approved lifecycle; and
• use approved AI assistance with source grounding, access control, human verification and accountable approval.

Explicitly out of scope

The Technical Writer / Documentation Specialist does not independently:

• decide engineering design, product behaviour, technical limits or acceptance criteria;
• approve production, product or software release;
• approve equipment safety, maintenance authority, warnings or protective measures;
• make or approve clinical, quality, regulatory or legal interpretations;
• approve regulated-product claims or make a submission decision without delegated authority;
• classify cybersecurity, privacy, export-controlled or otherwise sensitive information;
• own records-retention, validation or electronic-signature policy;
• override a quality-management, configuration-management or change-control process;
• claim that content is legally compliant, regulator-approved or universally accessible without the responsible specialist's decision;
• publish confidential employer material in a portfolio or external tool;
• treat a generated answer, automated score or vendor certificate as proof of correctness; or
• allow AI to publish autonomously.

The operating cycle ends only when the authoritative system records the released or retired state, required evidence is retained and the next accountable owner accepts any continuing action.

3. Operating roles and RACI-like decision ownership

Use R for responsible action, A for accountable decision, C for consulted evidence and I for informed. One person may hold multiple roles, but the authority remains explicit. Local policy overrides this model.

Non-transferable decision rule

Documentation approval confirms only the authority actually delegated to that approver. A clean editorial review does not approve engineering behaviour. A source SME's comment does not replace product-release approval. A published page does not prove legal compliance. When authority is unclear, hold the affected claim or release and route a decision-ready escalation.

4. Required inputs and source quality

Intake inputs

• request or change identifier;
• requesting owner and accountable source owner;
• business or operational reason;
• audience, task and use environment;
• required content type and publication channel, if known;
• product, process, service, configuration and version applicability;
• desired date and the event driving it;
• risk, sensitivity, regulatory or accessibility flags;
• affected existing content, known dependencies and localisation scope;
• required reviewers, approvers and publication owner; and
• acceptance and closure evidence.

Technical and operational sources

• approved requirements, specifications and design records;
• released code, interface definitions, schemas and tested behaviour;
• approved process maps, work instructions, drawings, bills of material and configuration records;
• issue, change, release, incident, audit, deviation or corrective-action records;
• approved policy, quality-system or regulatory source material;
• existing controlled documents and their revision history;
• subject-matter interviews, demonstrations and observations;
• validated test evidence and representative task results;
• service cases, search evidence and user feedback with appropriate access; and
• current terminology, style, accessibility and localisation requirements.

Source-quality hierarchy

Use the strongest available source and record its status. A typical hierarchy is:

1. released and approved baseline in the authoritative system;
2. approved change or decision record tied to the baseline;
3. accountable source owner's written confirmation;
4. observed or tested behaviour with recorded environment and result;
5. draft specification or ticket clearly marked provisional;
6. meeting note, memory, copied text or generated summary requiring verification.

Lower-ranked evidence may help investigation but must not silently override a controlled source. If a lower-ranked source appears more current, reconcile the conflict with the accountable owner.

Source register

Source-readiness test

Before drafting a critical statement or instruction, ask:

1. What exact source supports it?
2. Is the source approved for this configuration, audience, site and version?
3. Is the statement a fact, interpretation, instruction, warning or decision?
4. Who is authorised to make that type of statement?
5. Is there conflicting or newer evidence?
6. Can a reviewer reproduce the source path and decision?
7. Does access to the source permit use in this document and channel?

If a critical answer is unknown, mark the gap and escalate. Do not convert uncertainty into fluent prose.

5. Intake-to-retirement workflow

The normal control chain is:

authorised trigger → scoped intake → source baseline → content plan → draft → verification → review and approval → controlled publication → monitoring and maintenance → supersession or retirement

Each stage needs an entry condition, accountable action, evidence record and explicit exit condition.

Stage 0 — Validate the trigger and open controlled work

Trigger: A new product, process, service, issue, release, engineering change, audit action, user problem, scheduled review or retirement need reaches documentation.

Actions

1. Record the request/change identifier, requester, date and intended outcome.
2. Confirm that the work is authorised or identify the approval required to begin.
3. Identify affected product/process version, audience, location, channel and deadline driver.
4. Assign the Technical Writer and accountable source owner.
5. Flag safety, quality, clinical, regulatory, legal, security, export, privacy, records, validation, accessibility or localisation implications.
6. Link known affected documents and dependencies.
7. Record next action, owner and due date.

Decision: Is there enough authorised information to scope the work?

• If yes, proceed to source baselining.
• If no, hold unsupported drafting and route the missing decision.

Minimum record: request ID, trigger, scope, audience, applicability, owner, priority rationale, due event and open controls.

Stage 1 — Baseline sources and determine change impact

Trigger: The request is authorised and ownership is known.

Actions

1. Build or update the source register.
2. Confirm the released baseline and pending approved changes.
3. Interview SMEs using precise questions tied to tasks and decisions.
4. Observe or reproduce behaviour where authorised and feasible.
5. Compare the new evidence with existing content.
6. Identify affected content units, links, examples, visuals, translations and downstream systems.
7. Record conflicts, unknowns and decision owners.

Decision: Is the evidence complete enough to plan and draft without invention?

• If yes, freeze the working source set and proceed.
• If partially, draft only unaffected sections and keep blocked claims visibly unresolved.
• If no, escalate and hold the affected work.

Output: source baseline, change-impact register and open-question log.

Stage 2 — Plan the information product

Trigger: A usable source baseline exists.

Actions

1. Define the primary audience, task, context and expected outcome.
2. Select the content type: procedure, guide, KB article, release note, reference or controlled record.
3. Choose the approved template and metadata model.
4. Define prerequisites, decision points, warnings, limitations, examples and verification criteria.
5. Decide what can be reused and what must remain context-specific.
6. Plan navigation, search terms, related links and localisation scope.
7. Map reviewers and approvers to claims and risk.
8. Define completion evidence and publication channel.

Quality test: Another writer should be able to explain who the content is for, what it enables, which sources control it, who must approve it and what will trigger maintenance.

Stage 3 — Draft from controlled evidence

Trigger: The plan and working source set are ready.

Actions

1. Draft task-first content in the approved structure.
2. Keep each instruction, limit and claim traceable to a source or owner.
3. Separate prerequisites, actions, expected results and recovery paths.
4. Use consistent terms and stable identifiers.
5. Create screenshots, diagrams, code samples or examples from an approved environment.
6. Mark assumptions, placeholders and unresolved claims visibly.
7. Record the draft version and source baseline.

Control: Never disguise a placeholder as a fact. Never copy a warning, acceptance criterion, product limit or regulated claim from a similar context without confirmation for the current applicability.

Stage 4 — Verify technical and operational truth

Trigger: The draft is structurally complete enough to test.

Actions

1. Execute steps or examples in the recorded environment where authorised.
2. Confirm prerequisites, order, branching, expected results and recovery.
3. Test commands, links, API examples, identifiers and screenshots.
4. Compare instructions with the released product/process configuration.
5. Route safety, quality, clinical, regulatory, legal and security claims to their authorised owners.
6. Record defects, decisions, retest evidence and unresolved exceptions.

Decision: Does the draft describe the approved reality for its stated applicability?

• If yes, proceed to formal review.
• If no, return to the source owner or affected drafting stage.
• If verification cannot be performed, disclose the limitation and obtain an authorised decision before release.

Stage 5 — Conduct editorial, usability, accessibility and findability review

Trigger: Technical verification evidence is available.

Actions

1. Check purpose, audience, task sequence and completion criteria.
2. Edit for accuracy, clarity, concision, consistency and terminology.
3. Check headings, navigation, metadata, labels, link text and search terms.
4. Check accessibility requirements assigned to documentation.
5. Check localisation readiness and protected variables.
6. Run the approved style, link, terminology and build checks.
7. Conduct a representative task or findability test when required.
8. Record findings and their disposition.

Control: Editorial quality cannot cure an unverified technical claim. Accessibility checks performed by the writer do not become a legal-conformance decision unless that authority is explicitly delegated.

Stage 6 — Resolve review and obtain approvals

Trigger: The content passes the applicable quality checks.

Actions

1. Route each reviewer only the decisions within their authority.
2. Preserve comments, responses and decision owners.
3. Resolve contradictory comments through the accountable source owner.
4. Reverify any content changed during review.
5. Confirm required approvals, dates and applicable version.
6. Produce the release candidate and evidence package.

Decision: Are all required approvals complete and internally consistent?

• If yes, authorise publication through the named channel owner.
• If no, hold publication and escalate the exact missing decision.

Stage 7 — Publish through the authorised channel

Trigger: The release candidate and approval evidence are complete.

Actions

1. Confirm document ID, version, status, effective date and applicability.
2. Build or render the approved output.
3. Validate formatting, links, navigation, metadata and access permissions in the delivery channel.
4. Publish using the authorised account or hand off to the channel owner.
5. Read back the public or controlled result.
6. Record URL/location, publication receipt, checksum or version evidence where required.
7. Update affected links, indexes and change records.
8. Communicate availability only after read-back succeeds.

Control: A successful upload is not proof of successful publication. The delivered artefact must be read back from the user-facing or controlled channel.

Stage 8 — Monitor, maintain, supersede and retire

Trigger: Content is released or reaches a scheduled/event-driven review.

Actions

1. Monitor feedback, defects, task evidence, search behaviour and change signals.
2. Triage issues by impact, applicability and urgency.
3. Link confirmed defects to a corrective change.
4. Review content when its product, process, policy, configuration or obligation changes.
5. Confirm that translations and reused components remain aligned.
6. Supersede or retire content through the approved route.
7. Preserve redirects, notices, history and evidence required by local policy.
8. Close only when ownership, status and downstream effects are reconciled.

6. Content-stream operating playbooks

Stream A — Procedures, SOPs, work instructions and runbooks

Primary question: What authorised work must a defined role perform, under which conditions, and how is correct completion recognised?

Minimum structure

• purpose and applicability;
• owner and authorised performer;
• prerequisites, tools, access and required records;
• inputs and current source references;
• hazards, warnings or quality controls supplied by authorised owners;
• numbered actions in execution order;
• decision points and exception routes;
• expected outcomes and verification criteria;
• evidence to record;
• escalation and stop-work conditions;
• version, effective date and approval; and
• review or change trigger.

Special controls

• Observe the real or validated process when feasible.
• Do not invent a missing step because the sequence appears obvious.
• Keep operator action separate from system response and approval action.
• Route warnings, limits and acceptance criteria to the responsible specialist.
• For controlled operations, reconcile every field, signature, exception and handoff against the approved model.

Stream B — User, administrator, operator, installation, maintenance and service guides

Primary question: What task is the reader trying to complete in a defined product/configuration context?

Minimum structure

• audience and task outcome;
• supported product/version/configuration;
• prerequisites, permissions and dependencies;
• task steps and expected results;
• decision points, troubleshooting and recovery;
• limits and escalation route;
• related reference and next task;
• accessibility and localisation considerations; and
• feedback and maintenance route.

Special controls

• Test tasks from the reader's starting state, not the expert's memory.
• Label optional, destructive, irreversible or privileged actions clearly.
• Keep conceptual explanation near the decision it supports.
• Use screenshots only when they add information; record version and avoid sensitive data.
• For code and API examples, test syntax, credentials placeholders, response and failure path.

Stream C — Knowledge-base and help-centre content

Primary question: Can a person or authorised system find the correct answer, understand its applicability and act without being misled by stale or conflicting content?

Minimum structure

• one primary question or task;
• audience and applicability metadata;
• concise answer or diagnostic path;
• ordered actions and expected outcomes;
• escalation or support route;
• canonical source and owner;
• related content, synonyms and search terms;
• review date and stale-content trigger; and
• access classification.

Special controls

• Assign one canonical article for each controlled answer.
• Detect duplicate, regional and version conflicts before connecting content to search or AI retrieval.
• Test common queries, zero-result queries and misleading top results.
• Preserve permissions when federating repositories.
• Treat deflection and retrieval volume as activity signals, not proof that the answer was correct.

Stream D — Release notes, changelogs and change communications

Primary question: What approved change matters to which audience, when does it apply and what action is required?

Minimum structure

• release/change identifier and date;
• product/service/configuration scope;
• audience;
• new, changed, fixed, deprecated or removed behaviour;
• user/operator action and migration path;
• known limitations supplied by authorised owners;
• links to updated guides and reference;
• support/escalation route; and
• approval and publication evidence.

Special controls

• Derive entries from approved change/release records, not commit titles alone.
• Distinguish shipped, enabled, preview, deprecated and planned status.
• Do not announce security details, regulated claims or customer commitments without specialist approval.
• Confirm all linked documentation is ready or disclose the gap and owner.
• Maintain one traceable relationship between release item, affected content and published note.

7. Work cadence

Daily cadence

• review new requests, defects, change notifications and blocked reviews;
• confirm owner, next action, due event and risk for each active item;
• interview SMEs and reconcile source gaps;
• draft, edit, test and resolve comments;
• check publication queues and read-back evidence;
• triage urgent content defects and unauthorised exposure;
• update status in the authoritative system; and
• escalate unresolved decisions before they become hidden deadline risk.

Weekly cadence

• review work in progress by change/release milestone rather than page count alone;
• inspect ageing requests, blocked approvals and stale source decisions;
• reconcile upcoming releases, engineering changes, audits and service priorities;
• sample published content for link, search, applicability and task quality;
• review user/support feedback and assign evidence-based corrections;
• check localisation and reused-component dependencies;
• review AI-assisted work for grounding and verification evidence; and
• publish a concise risk/decision log to accountable owners.

Monthly or locally defined review cadence

• review overdue scheduled content and retirement candidates;
• analyse defined quality indicators with numerators, denominators and exclusions;
• inspect defect themes, rework causes and approval bottlenecks;
• review taxonomy, duplicate content, search gaps and broken navigation;
• assess accessibility and localisation findings with specialist owners;
• review templates, style guidance and contributor compliance;
• sample permissions, version identity and publication receipts;
• review AI tools, prompts, access boundaries and known failure modes; and
• agree a bounded improvement experiment with an owner and follow-up measure.

Event-driven cadence

Immediate review is triggered by:

• product or software release;
• engineering or configuration change;
• process transfer, validation event or production change;
• new regulation, policy or approved interpretation supplied by the accountable owner;
• audit finding, deviation, CAPA or safety issue;
• incident, outage or repeated support failure;
• security, privacy or export-classification change;
• accessibility defect or blocked critical task;
• localisation release or terminology change;
• generated-content defect or unauthorised AI action;
• source conflict or withdrawn approval; and
• repository, platform or publishing-channel migration.

8. Handoffs and service interfaces

Requester-to-documentation handoff

Minimum package: authorised request, accountable owner, audience/task, applicability, source locations, deadline driver, known risk and acceptance condition.

SME-to-writer handoff

Minimum package: source version, facts/steps owned by the SME, assumptions, unresolved decisions, examples or demonstrations, and review commitment.

Writer-to-reviewer handoff

Minimum package: release-candidate version, review scope, source baseline, change summary, questions requiring decision, required response format and due event.

Reviewer-to-approver handoff

Minimum package: resolved comments, remaining exceptions, technical verification evidence, specialist decisions and exact version proposed for approval.

Approval-to-publication handoff

Minimum package: approved artefact/checksum, approval identities and dates, effective/applicability data, channel, access rule, release time and rollback/withdrawal route.

Publication-to-service/operations handoff

Minimum package: public or controlled location, version, audience, change summary, known limitations, support route, feedback route and next review trigger.

Decision-ready handoff format

1. Decision needed: one sentence.
2. Why now: release, risk or dependency.
3. Evidence: authoritative sources and versions.
4. Options: supported alternatives without hidden recommendation.
5. Documentation impact: affected artefacts, audiences and channels.
6. Owner: role authorised to decide.
7. Due event: operational consequence, not an invented deadline.
8. Record location: where the decision and follow-up will be retained.

9. Document quality gates

No gate may be waived merely because a date is close. An authorised exception must name the unresolved risk, temporary control, decision owner, expiry and closure evidence.

10. Version, change, review, approval and publication controls

Minimum document identity

• document/content ID;
• title and content type;
• owner;
• audience and applicability;
• source baseline;
• version and status;
• effective/publication date;
• supersedes/superseded-by relationship;
• required review date or event trigger;
• access classification supplied by the authorised owner; and
• authoritative location.

Change record

Review controls

• Assign reviewers by decision authority, not availability alone.
• Ask reviewers to distinguish defects, questions, preferences and decisions.
• Preserve the original comment and the documented disposition.
• Resolve conflicting instructions through the accountable owner.
• Reopen verification when review changes a step, limit, example or claim.
• Do not treat silence as approval unless an authorised policy explicitly defines it.

Approval controls

• Approval must identify the artefact, version and scope approved.
• Specialist approval applies only to the specialist's authority.
• Approval must be recorded in the authorised system.
• Expired, withdrawn or conditional approval must remain visible.
• A writer may recommend documentation readiness but may not infer an underlying product/process approval.

Publication controls

• Publish only the approved version through an authorised account.
• Validate access, metadata, rendering, links and search/index behaviour.
• Read back the delivered artefact from the intended channel.
• Record receipt, URL/location, timestamp and checksum/version where required.
• Provide a withdrawal or correction route for material defects.
• Prevent simultaneous uncontrolled copies from appearing authoritative.

11. Regulated and high-reliability operations controls

This section is a control pattern, not a substitute for the organisation's quality system or regulatory interpretation.

Additional required controls

• state site, product, process, equipment, configuration and effective applicability;
• use only approved controlled templates and repositories;
• preserve source-to-content traceability at the level required locally;
• route validation strategy and acceptance to the authorised quality/validation owner;
• confirm required training or effective-date dependencies;
• preserve audit trail, comments, signatures and change evidence through the approved system;
• reconcile electronic instruction fields against the approved source model;
• distinguish draft, approved, effective, obsolete and archived states;
• prevent obsolete copies from remaining available at the point of work;
• route deviations, CAPA, inspection, labelling, submission and claim decisions to designated specialists;
• verify that translations and rendered outputs preserve controlled meaning; and
• stop release when traceability, approval identity or applicability is broken.

Writer's authority in controlled operations

The writer may structure content, identify gaps, coordinate review, test usability, enforce documentation standards and recommend whether the documentation package meets its stated criteria. The writer does not independently approve the underlying manufacturing process, validated state, quality disposition, clinical meaning, regulated claim, signature policy or production release.

12. Accessibility, findability and localisation readiness

Accessibility operating checks

• use descriptive headings and a logical hierarchy;
• provide meaningful link text and navigation labels;
• write clear instructions with explicit context and outcomes;
• supply text alternatives for informative visuals;
• preserve table headers, reading order and semantic structure;
• ensure instructions do not rely only on colour, position or sensory description;
• check keyboard, focus, captions or document requirements assigned to the content type;
• test with approved tools and representative users where required;
• record unresolved issues and their accountable owner; and
• avoid universal conformance claims outside delegated authority.

Findability operating checks

• use the language users employ as well as approved terminology;
• assign one clear title and canonical location;
• include product/version/applicability metadata;
• define synonyms and related questions;
• link prerequisites, next tasks and recovery content;
• test common queries and likely misspellings;
• review zero-result and repeated-search patterns;
• prevent stale duplicates from outranking current content; and
• keep permission boundaries intact in search and AI retrieval.

Localisation-readiness checks

• use stable terminology and one concept per segment;
• expand ambiguous acronyms and remove avoidable idiom;
• protect variables, code, product names and non-translatable metadata;
• preserve context for reusable segments;
• freeze the approved source before translation;
• identify locale owners and required human review;
• test layout, links and task flow in each released locale; and
• retain source/translation version alignment.

13. Metrics with explicit denominators

Metrics support investigation; they do not prove causation, legal compliance, safety, individual performance or content correctness by themselves.

Metric record

For every reported indicator, retain:

• exact name and purpose;
• numerator and denominator;
• observation period and cohort;
• source system and extraction time;
• inclusions, exclusions and missing data;
• owner and review audience;
• comparison basis, if any;
• limitation statement; and
• next investigation or corrective action.

14. Exception and escalation playbooks

Exception A — Sources conflict

Pause the affected claim or instruction. Record both sources, versions and owners. Ask the accountable product/process owner to identify the controlling decision. Update all dependent content only after the conflict is resolved and recorded.

Exception B — Critical source is missing

Mark the gap visibly. Continue only unaffected work. Send a decision-ready escalation with the exact fact, step or limit required. Do not generate a plausible substitute.

Exception C — Reviewers disagree

Separate editorial preference from technical or specialist decision. Route each unresolved point to the role accountable for that type of decision. Preserve the comments and final rationale.

Exception D — Release deadline arrives before documentation is ready

State which gate failed, affected users, risk and minimum safe options. The product/release authority decides whether the underlying release proceeds; the documentation publication owner decides only within delegated authority. Do not mark incomplete documentation complete.

Exception E — Published instruction is materially wrong

Triage impact immediately. Use the authorised correction, withdrawal or warning channel. Notify source, release, service and specialist owners. Preserve the defective version, incident evidence, correction and read-back receipt according to policy.

Exception F — Obsolete content remains discoverable

Confirm the canonical current version, remove or mark obsolete copies through authorised channels, add redirects/notices, reindex where applicable and test common search paths. Investigate the lifecycle control that allowed duplication.

Exception G — Accessibility barrier blocks a critical task

Record the affected task, environment and evidence. Provide an authorised alternative route if available. Escalate conformance and remediation priority to the accountable accessibility/legal owner. Do not claim legal sufficiency.

Exception H — Sensitive or classified information may be exposed

Stop distribution and further copying. Preserve minimum necessary evidence, restrict access and route to [[LOCAL — security/privacy/export classification owner]]. Do not make an improvised classification decision.

Exception I — Regulated or safety claim lacks approval

Hold the claim and affected publication. Identify the exact approval and owner required. Do not weaken, paraphrase or omit a critical warning to bypass review.

Exception J — Translation does not match the released source

Hold the affected locale, identify the source/translation version mismatch, route meaning questions to the source owner and locale specialist, then reverify task flow and rendering before release.

Exception K — AI output invents, blends or exposes information

Stop using the output. Compare it with authorised sources, remove unsupported content, assess disclosure, record the failure and notify the AI/data owner. Perform independent human verification before any reuse.

Exception L — Publication receipt is ambiguous

Do not retry blindly. Read the target channel and provider state, reconcile whether the exact version exists, then either confirm the receipt or perform one authorised recovery action. Avoid duplicate publication.

Escalation record

15. AI-assisted documentation controls

Potentially permitted uses, subject to local policy

• search and organise an approved source set;
• propose an outline or content model;
• draft text grounded in supplied sources;
• summarise a change record for human review;
• suggest terminology, metadata, tags or related links;
• identify inconsistent wording or possible stale content;
• generate test cases, review questions or alternative explanations;
• transform approved content between authorised formats; and
• assist with translation preparation or quality routing.

Prohibited or separately authorised uses

• uploading restricted information to an unapproved service;
• treating model memory or web search as the authoritative product/process source;
• inventing requirements, warnings, limits, claims, approvals or release status;
• deciding safety, clinical, quality, regulatory, legal, security or classification questions;
• replacing required SME, validation or accessibility review;
• silently merging conflicting sources;
• changing controlled content without traceability; and
• autonomous publication.

AI work record

• approved tool and configured environment;
• permitted task;
• source set and versions;
• restricted-data check;
• prompt or transformation record where policy requires it;
• generated candidate output location;
• detected unsupported/conflicting statements;
• human verifier and verification method;
• specialist approvals required;
• final disposition; and
• incident/escalation record if applicable.

Human verification checklist

1. Every material claim traces to an approved source.
2. Steps and examples work in the stated environment.
3. Preconditions, limits, warnings and exceptions remain intact.
4. The output does not blend products, versions, sites or audiences.
5. Restricted information and access rules are respected.
6. Links, identifiers, commands and variables are correct.
7. Required specialist decisions are present.
8. The exact final version passed normal review and approval.

AI may accelerate transformation. It does not establish truth or approval.

18. Quick operating test

Before declaring documentation controlled and ready, ask:

1. Is the request authorised and owned?
2. Are audience, task, context and applicability explicit?
3. Are authoritative sources, versions and owners recorded?
4. Are conflicts and missing decisions visible rather than silently resolved?
5. Is the selected content type appropriate for the user need?
6. Can every critical step, limit, warning and claim be traced?
7. Were tasks, commands, examples, links and outputs verified?
8. Did the right specialist decide engineering, safety, clinical, quality, regulatory, legal and security matters?
9. Did editorial, usability, accessibility, findability and localisation checks run as applicable?
10. Are review comments and dispositions preserved?
11. Are approvals tied to the exact release candidate?
12. Is documentation approval clearly separate from product/process/release approval?
13. Was the delivered artefact read back from the intended channel?
14. Are version, status, owner and maintenance trigger visible?
15. Are AI-assisted changes grounded and human-verified?
16. Are metrics defined with numerators, denominators, exclusions and limitations?
17. Can serious defects be withdrawn or corrected through an authorised route?
18. Is obsolete content superseded or retired without breaking the evidence trail?

Any “no” creates an open control or exception. Record its owner and next action.