Editorial, evidence, review and AI-use policy

How this guide is written, checked and changed

Controlled document: ACC-DOC-EDITORIAL
Candidate version: 0.2
Status: Public editorial and evidence policy for the live Phase 1 guide
Checked: 5 August 2026

The short version

This is a human-led information project. It is being built to help people understand FND, prepare useful questions and find other relevant sources of support. It is not a clinical service and it does not diagnose, triage or replace individual medical advice.

The project owner makes the final decision on the exact version of any material released. Sources, limitations, uncertainty and the real review status must remain visible. AI may help organise research, compare drafts, test structured data and support production, but it is not an author, evidence source, clinical authority or independent reviewer.

No page should claim independent clinical, lived-experience or accessibility review unless that review actually happened and its scope was recorded.

Who is responsible

Robert Campbell is the project owner and the final exact-version release authority.

Robert Campbell currently holds the permanent owner, editorial, accessibility, correction and release functions for this one-person project. There is no standing clinical-governance team. Clinical input is advisory, periodic and recorded; its absence on an exact page is disclosed rather than hidden.

How information is produced

1. Start with a real user need

Each proposed page or tool should identify:

• who it is for;
• what question or task it helps with;
• what it must not imply or decide;
• the safety, jurisdiction and accessibility boundaries that apply.

The public navigation should remain calm and broad even where the internal research taxonomy is highly detailed.

2. Search for appropriate sources

UK national guidance and authoritative public information are prioritised for UK pathways, rights and service rules. International guidelines, systematic reviews, research studies, professional consensus and specialist patient information are used where they add relevant evidence.

Sources are recorded in the master evidence register. A source's existence does not automatically make every statement in it suitable for every person, symptom, age group or UK nation.

3. Extract claims with their limits

Medical statements are recorded as traceable claims with linked sources, population, phenotype, jurisdiction, evidence type, certainty, limitations, safety implications and review status.

The project distinguishes:

• recognised FND findings;
• associated symptoms;
• separately diagnosable conditions;
• alternative explanations requiring assessment;
• established evidence, expert consensus and emerging or limited evidence;
• research evidence and lived experience.

No single symptom, examination feature, video or normal test is presented as proof that an individual has FND.

4. Write for people, not for a register

Drafting converts the governed research into calm, plain language. It should answer the user's immediate question first, explain uncertainty without becoming vague and provide a safe next step without creating a self-diagnosis or automated-triage tool.

Detailed internal descriptors may support search and routing. They must not be presented as proof that every descriptor is uniquely caused by FND.

5. Check the exact wording and evidence

Before an exact version can be considered for release, the owner checks the applicable source, wording, date, population, jurisdiction, limitations, uncertainty, safety boundary, correction route and transparency information.

Automated checks can identify missing fields, stale targets, unsupported links, failed boundaries and inconsistent metadata. Passing an automated check is not clinical approval.

6. Record real review status

Specialist, patient, supporter, patient-information and accessibility advice is considered when available. The reviewer, discipline, scope, date, conflicts and findings are recorded internally. Public naming or employer attribution is separate and opt-in.

Review is advisory to the owner decision. The public page must say whether the exact version was independently reviewed, what discipline reviewed it and the scope of that review. If no independent review occurred, it must say so plainly.

7. Preview and decide

The owner should see a compact change set: what changed, what did not, whether claims or boundaries changed, the exact target and the validation result. The available decisions are approve, request changes, withhold or withdraw.

Approval applies only to the exact recorded version. It does not automatically approve later edits, a different page or a directory listing.

8. Build and verify

The approved source is built into an immutable candidate with file hashes and a release record. Staging and post-deployment checks verify the actual candidate and active release. A stale decision, changed file or failed gate prevents release.

9. Review, correct or withdraw

Pages are reviewed on a planned schedule and when a material trigger occurs, such as new guidance, a changed source, a safety concern, a service-route change or a credible correction report.

Unsafe or unsupported material may be withheld while a correction is prepared. Withholding preserves the audit history and does not imply that a replacement has already been approved.

What page-level evidence information should show

Public medical and practical-information pages should make the following understandable without requiring the reader to inspect the internal register:

• what kind of information the page contains;
• who it is for and the relevant jurisdiction;
• the main evidence type and direct sources;
• important limitations, uncertainty and safety boundaries;
• when the information and sources were checked;
• the exact-version owner release date;
• the actual independent-review status;
• how to report a problem or changed source;
• a link to funding, independence and conflict information when that document exists.

These fields are the public metadata model. Contact routes, accountable roles and production details are maintained from real operating evidence and updated when they change.

Evidence labels

Evidence labels describe the kind of support behind a statement. They do not grant publication approval.

• Clinical guideline: recommendations issued by a recognised guideline body for a defined population and setting.
• Systematic or evidence review: research that searches for and assesses a body of studies using a stated method.
• Individual study: one study whose design, population and limitations must be considered.
• Expert clinical consensus: specialist agreement or practice guidance where direct research may be incomplete.
• NHS or government information: official public information, policy, regulation or service guidance relevant to its stated jurisdiction.
• Registered-charity guidance: information produced by a charity; useful context but not automatically a clinical authority.
• Emerging or limited evidence: a plausible or early finding that is not established enough to present as settled fact.
• Lived experience: a person's account of what happened to them; valuable for understanding needs and impact but not proof of diagnosis, cause or treatment effectiveness.

How AI assistance is used

AI may support:

• research organisation and candidate-source discovery;
• structured claim, source and page-mapping work;
• comparison, summarisation and plain-language drafting;
• code, test and document-production assistance;
• consistency, link and missing-field checks;
• prototype and accessibility-test preparation.

AI must not:

• be treated as a source or substitute for opening and checking the cited material;
• diagnose a person or decide whether an event is functional, epileptic or an emergency;
• invent a source, review, approval, contact, affiliation or service fact;
• make the final release decision;
• be described as an independent reviewer or clinical authority.

Direct sources are opened and checked against the exact claim attributed to them. Generated wording, structured data, documents and code are inspected and tested by a human in proportion to their risk. Robert Campbell remains accountable for the final exact-version decision.

Material changes and corrections

A public change record should be created when an approved release is materially altered. It should state:

• the publication date;
• the affected page and version;
• the change class;
• what changed and why;
• the real independent-review status and owner handling;
• the replacement release or version;
• whether users or organisations were notified.

Material change classes include factual or clinical corrections, safety corrections or urgent withdrawal, evidence or recommendation changes, service-access or rights changes, accessibility corrections and clarifications that change meaning. Spelling and presentation maintenance may be logged internally without overstating it as a substantive correction.

Private reporter details, reviewer correspondence, personal information and protected security information must not appear in the public log.

Earlier approved versions are retained internally for traceability. Unsafe, unlawfully publishable or security-sensitive material may be excluded from any public archive while the internal decision history is preserved.

Current review and release status

• Owner exact-version decision: approved through the controlled successor transaction for version 0.2.
• Independent editorial review: not obtained for this version.
• Independent clinical review: not obtained for this version.
• Patient-information review: not obtained for this version.
• Lived-experience or supporter review: not obtained for this version.
• Accessibility checks: automated, keyboard, responsive-layout, 200% text, no-JavaScript and route checks passed for the released static build; independent assistive-technology user testing has not taken place.
• Public correction route: operational at corrections@fndguide.co.uk with hello@fndguide.co.uk as the tested fallback.
• Public release: the first Phase 1 release went live on 5 August 2026 and is recorded as DEPLOYED_VERIFIED in the release-operations state.

Controlled sources for this draft

• FND_Phase1_Human_Editing_and_Publishing_Workflow_v0.1.md
• FND_Phase1_Editor_Options_and_Owner_Review_Assessment_v0.1.md
• governance/phase1-publication-gate-contract.json
• governance/phase1-public-accountability-contract.json
• outputs/owner-batch-approval/approval-summary.json

This document covers ACC-EDITORIAL-001, ACC-EVIDENCE-001 and ACC-AI-001. The separate Changes page records public releases and material corrections. The exact owner decision is recorded in the accountability state. Approval of this policy does not approve a later edit, a directory record or independent review that did not happen.